Programcılar inşaat sektöründen neler öğrenebilir? [kapalı]

İş arkadaşlarınızla yazılım tasarım ve geliştirme ilkeleri hakkında konuşurken, analojiler için en yaygın kaynaklardan birinin inşaat endüstrisi olduğunu fark ettim. Biz inşa yazılım ve biz tasarım ve yapı olarak kabul mimarisi .

Öğrenmenin (veya öğretmenin) en iyi yollarından biri analojileri analiz etmektir - inşaattan başka hangi analojiler çıkarılabilir? (zaten yazılımda ortak kullanımda olsun veya olmasın).

Lütfen programlama konseptinin yapım konseptine nasıl benzer olduğuna dair bir açıklama veya kişisel deneyiminizi belirtiniz.

^{[ Sanat ve beşeri bilimlerden fikir almak için alınan konsept programlama programları için kredi ]}

Tasarım desenlerinin geldiği yer burasıdır.

Konsepti dünyaya tanıttığı iddia edilen kişi, 1977’de “A Pattern Language: Kasabalar, Yapılar, İnşaat” adlı kitabında Christopher Alexander’dı . Oradan Dörtlü Çete (GoF) aldı ve geri kalanı tarih oldu.

Şimdi bile dersler sırasında ve yazılım geliştirme ve mimarlık kitaplarında inşaat dünyası ile yazılım geliştirme dünyası arasındaki analojiler hakim olmaya devam ediyor.

Düşünebildiğim veya hatırlayabildiğim bazı analojiler ve referanslar:

• Örneğin, bir binanın inşaatı sırasında ihtiyaçların değiştirilmesi , müşteriye bunun ne kadar saçma olduğunu daha açık bir hale getirebilir, örneğin: "OH ve az önce bitirdiğiniz mutfağın yerine bir garaj istiyorum".
• İskele gibi geçici yardımlar ( inşaat dünyasında anlam | yazılım geliştirme )
• Müşteriler, maliyet ödemeden özellik eklemeye devam edemezler , çoğu zaman ücretsiz olarak iş yapmak isterler ve bazen kabullenecek kadar aptalız; bu sadece inşaat dünyasında gerçekleşemez (bkz: sürünen şartlar). . ).
• Rolleri yazılım geliştirme: mimar çözümün dizaynına uygundur; danışman ve müteahhit değiştirilebilir terimler olabilir; işçiler programcılar.
• Müşteri her iki durumda da doğru gereksinimleri sağlayamaz .
• Bütçeler ve zaman tahminleri çoğu zaman yanlıştır.
• Ürün sonuna kadar gerçek haliyle görülemez .
• Bir binada nasıl inşaat hataları inşa sonra, aynı şekilde yazılım vardır böcek .
• Ürün kötü bir şekilde yapılırsa, bazen tamir etmek yerine yıkılması ve yeniden başlatılması tercih edilir .
• Düşük kaliteli işin gerçek ve gerçek sonuçlarını bilmeden , müşteri en ucuz çözümü ister .
• Açık Kaynak . Bu konuşmayı sadece " Neden Tüm İşler Açık Kaynağa Dayalı Olacak " adlı "Doc Searls" dan izliyordum , burada inşaat camiasının binalarda bazı şeyler olduğu zaman bile, açık kaynak camiasına benzer şekilde patent almak yerine teknikleri ve genel bilgileri nasıl paylaştığını anlatıyor. yerleşik özel ürünler içerir.
• Müşteri aktif olarak katılıyorsa, projeler herkes için daha iyi hale gelir .

(Daha fazla akla gelirse, onları ekleyeceğim.)

Genel analojinin doğru olduğunu düşünmeyenler var, bunun için önerilen bir okuma Yazılım İnşası Analojisinin Bozulması . Ayrıca, bu konuda SO başlıklı bir soru var Yazılım ve bina yapımı arasındaki analojinin nesi var? .

Yazılım geliştirme tarihi boyunca inşaat endüstrisinden pek çok kelime ve fikir aldık ve aslında birçok kişiye ulaştık ve alacak bir şey olduğunu sanmıyorum.

Müşterilerin bir spesifikasyon yapmasını, daha sonra bir mimar planlamasını, ardından mühendisleri inşaat endüstrisinden uygulayan maymunları tasarlayıp kodlamasının tüm sürecini aldık ve tamamen yanlış yönlendirildik.

Çünkü bir ev inşa ettiğinizde, temeliniz yanlışsa, etkileneceksiniz. Cidden etkilendi. Bir binayı kaldırmak ve temellerini değiştirmek, her şeyi hurdaya çıkarmak ve baştan başlamaktan daha pahalı. Ancak yazılımda bu tamamen mümkün. Modemi sunucu odasına taşımam dışında, hiçbir şey fark etmeden bir istemci yazılımını bir istemci-sunucu çözümüne yeniledim. Bu, sakinlerin uyurken beton temelini bir tekneyle değiştirmek gibi.

Yazılım değil inşaat gibi . İşte bu yüzden, tüm yazılım endüstrisi, ilk kez, naitelerin başında bir süre açık kaldı ve projelerin tüm "şelale" süreci, birkaç yıl içinde çevik süreçlerle değiştirildi.

Gelince kelimelerin çok haklı ve yanlış, inşaat alınır.

Çerçeve , henüz alınmamış en açık olanıdır. Ve borular var .

Bu analojiyi kullandım ... birçok yazılım projesi başlar, çünkü bazı yazılımlara ihtiyaç duyan kişi bir "tamircinin" eşdeğerini bilir ve bu kişiyi bir bahçe kulübesinin yazılımını oluşturmak için işe alır. İşini çok iyi yapan küçük ve kullanışlı bir uygulamadır.

Müşteri daha sonra tamirciye geri döner, çalışmalarından memnun kalır ve bir şeyi daha yapmak için yazılımı değiştirmelerini ister. Çoğu zaman, bu yeni özelliğin orijinal isteğiyle pek ilgisi yok, bu yüzden neredeyse sizden ayrı bir girişe sahip bahçenin arkasına başka bir oda inşa etmenizi istiyorlar.

Sonra kulübenin içine bir ışık koymak istiyorlar, bu yüzden tamirciyi geri alıyorlar ve evdeki ana panelden tek bir devre geçiriyor, her odanın tavanına bir çekme zinciri ışık şalteri takıyor ve onları devreye bağlıyor .

Müşteri daha sonra bazı elektrikli el aletleri çalıştırmak istediklerine karar verir, ancak devre kesiciyi üflemeye devam eder, böylece kişiyi geri çağırır ve aslında ana panele koştuğu tek devreyi sökmek zorunda kalır ve daha büyük bir iletken ve kulübenin alt paneli. Kabloyu iki kez çalıştırmak ve iki elektrik izni vb. Ödemek zorunda kaldı. Bu verimsiz.

Sonra müşteri saçma bir şey ister: bahçemdeki bahçeyi bir garaja çevirir misiniz? Yaptığın hiçbir şeyi yeniden yapmanı istemiyorum ... Sadece daha büyük yapmanı istiyorum böylece arabamı oraya park edebilirim. Daha sonra, birçok durumda, tamirci "müşterinin her zaman haklı olduğunu" düşünür ve daha büyük hale getirmek için sundurmanın 3 tarafına eklemeler yapar, bölmeler arasındaki duvarı yıkar vb. Tabii ki, çatı sona erer. yukarı sarkma, çünkü doğru inşa edilmemiş.

Böylece müşteri artık o kadar etkilenmedi, ama hala daha fazlasını istiyorlar. Tamirciden tekrar tekrar bir oda daha eklemelerini ya da bu odayı değiştirmek için tekrar tekrar sormalarını istiyorlar. Sonunda The Burrow'a benzeyen ve mimari açıdan sağlam bir şeyle karşılaşıyorsunuz .

Artık çoğu insan bunu inşaat dünyasında deneyecek kadar saçma değil, ancak yazılım dünyasında her zaman oluyor, çünkü insanlar bu bağlantıları kurmuyor:

1. Gerçekten güzel bir bahçe barakası inşa etmek için nitelikli bir kişinin mutlaka bir ev inşa etmek için nitelikli olması gerekmez.

2. Önceden aşamalı olarak bir ev inşa edeceğinizi biliyorduysanız, ancak bu yalnızca bir bahçe kulübesi olarak başlayacaktı, işleri farklı bir şekilde yapardınız ve bahçe kulübesi çok daha pahalıya mal olacaktı ( Gerçekten kalın ped, bitmiş bir evin tam yükü için yeterince büyük bir iletken koştuğunuzdan emin olun).

3. Bir çok durumda, bir aşamadan diğerine yükseltme, daha önce yapılan çalışmaların çoğunun geri alınmasını gerektirir, olması gerektiği gibi olduğundan daha pahalı hale getirir.

4. İnşaat dünyasında, müşteriye tasarım aşamasında sonucun nasıl görüneceği konusunda iyi bir fikir verebiliriz, ancak yazılım dünyasında bu yeteneğe sahip değiliz. Bu noktaya ulaştıysanız, temel olarak yazılımın önemli bir bölümünü yazdınız.

Çevik Manifesto, yazılım / inşaat analojisinin bozulduğunu kabul etmenin bir sonucudur. Otomatik birim testleri ve yinelemeli serbest bırakma döngüleri gibi şeylerin yapımında hiçbir paralelliği yoktur. Bu şeyler tasarımdan prototipe gitmenin neredeyse sıfıra gitme maliyetinden faydalanıyor (biz buna derleme veya inşa diyoruz).

Finish iş ve Trim terimleri akla geliyor.

Ana yapısal kararların ne zaman alınacağı konusunda estetik tercihlerin ertelenmesinin uygun olmadığı fikri.

Eski bir atasözü: İki kez ölçün ve bir kez kesin.

Düzenleme: Atul Gawande'nin Kontrol Listesi Manifestosu'nda , büyük inşaat işlerinin yönetimi hakkında konuşan bir bölüm var . Gerçekten karmaşık bir noktaya geldiklerinde, sorunu yeniden gözden geçirmek ve proje sırasında herkesin bilmesi gereken bir şey olup olmadığını görmek için ilgili uzmanlarla bir toplantı yapıyorlar. Muhtemelen onları önceden planlayamayız.

Hem yapım hem de programlamada sınırlamalar vardır .

Bir müşteri olarak, bitmiş bir otel binasını bir haftasonu boyunca uzatacak ve bir havaalanını yeraltı katına ve penthouse'unda bir piste yerleştirecek kadar saçma taleplerde bulunamıyorsanız, neden tüm ayarların bitmemiş yazılım mümkün mü? 0'lı ve 1'li sihirli bir top değil, maddi olmasa da, kısıtlı olmasına rağmen, karmaşık bir yapı yapısı.

İnşaatta okulda çalıştım ve analojinin bile olmadığı yerler var, aynı konsept geçerli. Ancak, sık sık, karşılaştırma günaha çok ileri gidiyor.

Bir iş için bir tahminde çalıştığımda, bir şey yapmanın ne kadar süreceği konusunda kesin ortalamalar olduğunu biliyordum. Örneğin vitrin camlarını imal etmek için, çerçevelerdeki eklemlerin sayısını planlardan saydık ve bunun ne kadar süreceği konusunda oldukça iyi bir fikrimiz vardı. Tıpkı programlama gibi, sizdeki hayatı emebilecek olsa da, zamanlamadaki değişkenleri hesaba katmak zorunda kaldık. Örneğin: otoparkın asfaltlandığını ve binadaki sıcak asfalt nedeniyle binaya giremediğini bulmak için bir tesisat ekibine sahip olmak oldukça pahalıdır.

Ancak inşaatın yapması gereken binlerce yıllık tecrübesi var. Ticaretin temel kuralları, her zaman olduğu gibi aynı fizik yasaları tarafından yönlendiriliyor. Rüzgar yükü ve ölü yük hesaplamaları, slayt kurallarıyla yapıldıkları ile aynıdır. Araç ve tekniklerdeki gelişmeler ortaya çıkmıştır, ancak deneyimlediklerimizle karşılaştırıldığında bir buzul hızında.

Öte yandan, kalıp ve uygulamalarımızın birçoğunun iyileştirme için alana ihtiyaç duyduğunu hala keşfediyoruz. Singleton eskiden iyi bir fikirdi, şimdi çoğu düşünen IoC / DI modellerini tercih ediyordu.

Bizim de eksik olduğumuz yer anlamlı lisanslama ve sertifikalandırmadır. Pek çok alanda, sadece bir tesisatçı olsa bile bir tamirci olmak için bile, bir tesisatçının lisanslı olması veya çalışan birinin gözetimi altında çalışması gerekir. Bu lisansı almak için sahada çalışmak için belirli bir süre gerekir. Ruhsatlandırma için veya lisanslamaya karşı dava açmıyorum, sadece büyük bir fark olduğu için işaret ediyorum.

Tabii ki her iki alanda da bir mimar, uygulanamayan bir şey çizebilir.

İskele , "bina ve diğer büyük yapıların inşası veya onarımında insanları ve malzemeleri desteklemek için kullanılan geçici bir yapı." ^{[wikipedia'dan tanımı]}

Bu kavram işe yarıyor çünkü programlamada bir iskele hızla yaratılabiliyor ve asıl yapı mevcut olana kadar geçici işlevsellik sağlıyor.

Çiftlik yapan en düşük teklif sahibine iş yapan, özensiz iş yapan, garanti görevinin ne olması gerektiğinden kaçtığını, kaliteye odaklandığını ve daha sonra "bitmiş" ürün için saçma bir kar elde ettiğini biliyorum.

Ancak programcıların veya danışmanlık kurumlarının bu uygulamalardan bir şey öğrendiğini sanmıyorum.

Böcekler cehennem kadar pahalı olabilir, hatta insanları öldürebilir mi?

Herhangi bir disiplinin karmaşık mühendislik projeleri için temel kurallar vardır:

1. planlamanın önemi, mavi baskılar, tasarım vb.
2. temel matematiğin önemi
3. fikirleri yeniden kullanma / diğer benzer projelerden öğrenme
4. başka biri tarafından yapılmış hazır yapı taşları / bileşenleri kullanma
5. problemleri yaşam döngüsünün başında çok erken düzeltmek
   ,

Mimarlık, inşaat ve yazılım mühendisliği disiplinleri arasındaki ortaklıklar temelde montaj hatlarının olmamasından kaynaklanıyor gibi görünmektedir : her proje kendi isteğiyle benzersizdir.

Mesai

Ancak inşaat sektöründe işçilere fazla mesai ücreti ödeniyor.

Standartların, sözleşmelerin ve önceden oluşturulmuş bileşenlerin kullanımı. Bu tür bir sorunla karşılaşmanız muhtemel değildir.

Özel yapım prizlerimize uyan pazarda hiçbir şey bulamıyorum.

Sahip olduğun tek şey bir çekiç olduğunda, her şey bir çiviye benziyor. :)

Tekrarlayan gerilme yaralanmaları

Her iki sektörde de mesleki bir tehlikedir ve bunların önlenmesi için önlemler alınmalıdır. Bir kere başladıklarında, tedavisi zordur.