Bazı programcılar neden teori ile pratik arasında bir kontrast olduğunu düşünüyor? [kapalı]

Yazılım mühendisliğini inşaat mühendisliği ile karşılaştırarak, farklı bir düşünce biçimini gözlemlememe şaşırdım: herhangi bir inşaat mühendisi, bahçede küçük bir kulübe inşa etmek istiyorsanız, sadece malzemeleri elde edip inşa etmeye devam ederken inşa etmek istediğini bilir. 10 katlı ev (veya, örneğin, gibi bir şey bu ) oldukça bazı matematik yapmak gerekir hiç ayrılacak olmayacağından emin olmak için.

Buna karşılık, bazı programcılar ile konuşmak veya blog ya da forum okumak çoğu zaman aşağı yukarı formüle edilebilecek geniş çapta bir görüş buluyorum: teori ve biçimsel yöntemler, programlama işlerin yapılmasıyla ilgili olarak matematikçiler / bilim adamları içindir .

Burada normal olarak ima edilen şey, programlamanın çok pratik bir şey olduğu ve biçimsel yöntemler, matematik, algoritma teorisi, temiz / tutarlı programlama dilleri, vb. İlginç konular olsa da, eğer herkes isterse bir şeyler elde etmek için sık sık gerekli olmadıklarıdır. bitti .

Tecrübelerime göre, 100 satırlık bir senaryo (kulübe) oluşturmak için çok fazla teoriye ihtiyacınız olmasa da, karmaşık bir uygulama (10 katlı bina) geliştirmek için yapılandırılmış bir tasarıma ihtiyacınız olduğunu söyleyebilirim. tanımlı yöntemler, iyi bir programlama dili, algoritmaları arayabileceğiniz iyi bir kitap, vb.

Yani IMO (doğru miktarda) teorisi işlerin yapılmasında kullanılan araçlardan biridir .

Sorum şu: neden bazı programcılar teori (biçimsel metotlar) ve pratik (bir şeylerin yapılması) arasında bir kontrast olduğunu düşünüyorlar?

Yazılım mühendisliği (bina yazılımı) , örneğin inşaat mühendisliği (bina evleri) ile karşılaştırıldığında çok kolay algılanıyor mu?

Yoksa bu iki disiplin gerçekten farklı mı (kritik görev yazılımı dışında, yazılım arızası bina arızasından çok daha kabul edilebilir)?

Şimdiye kadarki cevaplardan ne anladığımı özetlemeye çalışıyorum.

1. Yazılım mühendisliğinin aksine, inşaat mühendisliğinde belirli bir görev için ne kadar teoriye (modelleme, tasarım) ihtiyaç duyulduğu çok açıktır.
2. Bu, kısmen inşaat mühendisliğinin insanlık kadar eski olması ve yazılım mühendisliğinin yalnızca birkaç on yıl civarında olması nedeniyledir.
3. Diğer bir neden ise, yazılımın daha değişken bir eser olması, daha esnek gereksinimler (çökmesine izin verilebilir), farklı pazarlama stratejileri (piyasaya hızlı bir şekilde ulaşmak için iyi tasarım feda edilebilir).

Sonuç olarak, yazılım mühendisliği için doğru miktarda tasarım / teoriye uygun olanı belirlemek çok daha zordur (çok az -> dağınık kod, çok fazla -> asla bitiremiyorum) çünkü genel bir kural yoktur ve sadece (çok) deneyim yardımcı olabilir.

Bu yüzden cevaplarınızı doğru yorumlarsam, ne kadar teoriye ihtiyaç duyulduğuna dair bu belirsizlik, bazı programcıların teoriye karşı duydukları karma aşk / nefret duygularına katkıda bulunuyor.

Bence asıl fark inşaat mühendisliği ile gerçek dünya fiziğinin teoriyi akılda tutan ve aynı zamanda kötü uygulamaları sınırlayan sabit, güçlü bir gerçeklik kontrolü gibi davrandığı, yazılım mühendisliğinde ise pratik fildişi kule kavramlarını koruyacak kadar güçlü bir kuvvetin olmadığını düşünüyorum. kontrol altında ayakkabılı işçilik olarak.

Çoğu programcı, kaçak teoriyle ilgili şeylerin yapılmasında aktif bir engel teşkil eden kötü deneyimler yaşamıştır (örneğin, "uygulanabilir UML", süper bürokratik gelişim süreçleri). Tersine, kirli kesmeler ve yamalar, sonunda yavaş da olsa, sizi oldukça uzaklara götürebilir. Son paragrafınızda da gözlemlediğiniz gibi: başarısızlıklar genellikle nihai değildir ve bu nedenle problemli değildir.

Yazılım mühendisliği ve inşaat mühendisliği arasında ortak bir nokta yoktur. İnşaat mühendisliği çalışmaları, malzemelerinin fiziksel özellikleri ve çevre ile sınırlıdır. İnşaat mühendisleri, toprak ve malzeme özelliklerini öğrenmek için çok zaman harcıyorlar. Yazılım geliştirme fiziksel olarak yalnızca işlemcilerin hızı ve mevcut depolama ile sınırlıdır. Bunların her ikisinin de anlaşılması kolaydır ve onları incelemek için fazla zaman harcamayız. Yazılım geliştirmedeki en büyük kısıtlama insan zekasıdır. Ve hiçbir iki geliştirici aynı değildir. Bu kod korunabilir mi? Kim tarafından? Haskell'deki üç hatlı bir quicksort uygulaması, bazıları için açıkça doğru olabilir ama diğerleri için anlaşılmaz olabilir. İki kişilik bir ekip, bir ay içinde bir başvuruyu tamamlayabilirken, on yıllık bir ekip ise bir yılda teslim etmek için mücadele edebilir.

Yazılım geliştirme tamamen tasarımdır, tasarlanan eserler, üretilen tüm eşyalardan daha karmaşık büyüklükteki emirlerdir ve her biri benzersizdir.

Daha doğrusu dürüst olmak gerekirse, bir makine mühendisi (bazı sivillerle birlikte) programcı oldu, sonra CS (AI) Doktora, sonra öğretmen, sonra tekrar programcı (afedersiniz, Yazılım Mühendisi ), bu genel konu.

Geleneksel mühendislikte

• matematik ve biliminizi bilmelisiniz çünkü yaptığınız her şey buna bağlı
• Alandaki "kahramanlar" yeni şeyler icat eden, yeni fikirler keşfeden, çözülemeyen sayılan sorunları çözen kişilerdir.

Yazılım - bilgi teorisi için geçerli bir "fizik" vardır, ancak yazılım mühendisleri buna çok az maruz kalır ve kesinlikle hiçbir şey uygulanmaz. Aldıkları en teori hesaplanabilirlik ve büyük O'dur.

Ayrıca ben bilerek programlama yeterli olduğunu düşünüyorum insanlara sürekli şaşırıyorum ve onlar anlamak gerekmez konu onların programları hakkında neler olduğu.

Dahası, yaratıcılık teşvik edilmez. "Okunabilirlik" olarak kılık değiştiren, en az yaygın payda olan grup-düşünce yöntemlerinin lehine önerilmemektedir. (Havacılık veya nükleer mühendislerin küçük yaştaları için anlaşılması zor olabilecek bir şey yapmamaya teşvik edilip edilmediğini düşünün.)

Web uygulamalarını nasıl programlayacakları gibi öğrendikleri şeyler de çok değerli. Yani bir tesisatçı veya elektrik teknisyeni yeteneği, ancak mühendislik değildir.

Çoğu yazılımda bir köşe kesersem ve en iyi tasarım olmayan, ancak işi halledecek bir şey yaparsam kimse ölmeyecek. Bahçedeki bir kulübenin 10 katlı bir bina ile aynı standartlara ihtiyaç duymaması aynı sebep. Bununla birlikte, facebook gibi çok büyük bir uygulama oluşturabilirim ve eğer bazı verileri mahvedip kaybederse, ya da her neyse, o kadar da önemli değil. Ayrıca, büyük bir uygulamanın temelini kurduktan sonra düzeltmek, 10 katlı bir binanın temelini değiştirmekten daha kolaydır. Her şey bağlamda ve risk hesaplamada ortaya çıkıyor.

Ayrıca, güvenle ve basitçe bir uygulamaya eklemeye devam edebilirim. 10 katlı bir binanın üçüncü bir katına kolayca giremezsiniz (11 yaparak). İstersem her gün yeni bir özelliğe büyük bir uygulamaya geçebiliyorum.

Şimdi, iyi tasarım programlamada tüm bunları kolaylaştırır. Ama kötü tasarım ile imkansız değil ve riskleri de ... buggy yazılımı. Genelde ölüm değil.

Bu konuda benimle ayı. Benim bir noktam var.

Bir keresinde bana bir zamanlar ertelemenin daha fazla ertelemeye yol açtığını söylemiştim, çoğu kişi bir geceden sonra harcanan kâğıt yazma / tıkınma / programlama bir geceden sonra kendilerine söylese de, "Bunu bir daha asla yapmayacağım. Bir dahaki sefere erken başlayacağım ve erken bitir. " Tüketici erteleme uzmanı olarak tecrübelerime göre, bunu doğru buldum ve işte profesörün açıklaması: Neden erteleme deneyiminin ne kadar nahoş olursa olsun, çoğu durumda, göreceli başarı elde etmiş olursunuz. Bu yüksek risk / yüksek ödül davranışıdır. Bir süre sonra, bütün talihsizlikleri unut ve sadece ödülü hatırla. Böylece, ertelemek için bir sonraki günaha daha cazip geliyor, çünkü geçen sefer başardınız.

Bence burada çok sık gördüğümüz "işleri halletmek" programlama tekniğine bir benzetme yapılabiliyor. Bir programcı veya programcı ekibi, belki de cehaletten, tembellikten ya da belki de gerçek bir zaman kısıtlamasına sahip değil, tüm teorilerinizi ve matematiğinizi ve iyi uygulamalarınızı pencereden fırlatarak, programlama için "yapılması gerekenler" yaklaşımını kullanır. Ve ne biliyor musun? İşleri hallederler. Zarif, hoş veya bakım gerektirmez, ancak işi halleder. Belki bir semafordan noktalı virgül bilmeyen, teknik olmayan bir üst, "işleri halletmek" için onlara büyük övgü verir. Böylece, bir sonraki programlayıcı programlamaya bu gevşek yaklaşımı benimsemeye karar verdiğinde, bu daha kolay olur çünkü hey, son sefer çalıştı, değil mi? Fakirlerin olmadığı sürece, "kolay" bir çıkış yolu.

O kadar fakir, talihsiz bir ruh oldum ve muhtemelen çoğunuz da var. Hepinize yalvarıyorum. Kolay yolu seçmeyin! :)

Senin öncülün hatalı. İnşaat mühendislerinin büyük binalar, köprüler, tüneller vb. Tasarlarken mühendisliği kullanmasının temel nedeni, gerekli güvenlik standartlarını karşılayan asgari miktarda malzeme (beton, yapı çeliği vb.) Kullanmalarını sağlamaktır. Materyal ve emek masrafları nesne değil, ancak bir kez inşa edildiğinde, genellikle değişiklik yapmanın bir anlamı yoksa, matematiğin olmadığı kadar yüksek bir bina inşa etmek (örneğin, eski Mısır ve Maya medeniyetlerinin piramitleri) tamamen mümkündür. Materyali daha verimli kullanmalarını sağlamak için.

Büyük yazılım sistemlerinin tasarlanmasında biraz farklı bir dinamik var. Eğer bir şey varsa, bunlar genellikle yetersiz tasarlanmışlardır, ancak bunun nedeni tasarımın iş ilerledikçe dinamik olarak değiştirilebilmesidir, bu inşaat mühendisliği projeleriyle kolayca yapılamaz.

Ortak faktör maliyettir. Geleneksel bir inşaat mühendisliği projesinde tasarım, maliyetleri (hem malzeme açısından hem gerçek, hem de sorumluluk açısından potansiyel) azaltırken, tasarım maliyetinin geri getirilen değerin ötesinde arttığı yazılım geliştirmede bir nokta vardır.

Ayrıca, insanoğlunun “inşaat mühendisliği” ne eşdeğer olduğu diğer mükemmel yanıtlara ek olarak, Mısırlılar zamanından beri kolayca kabul ettiğimi, bu yüzden işlerin nasıl olması gerektiğine dair genel teoriyi mükemmelleştirmek için çok zamanımız oldu. yapıldı. Yaklaşık 70 yıldan fazla bir süredir yazılım üretiyoruz (ilk "yazılımı" düşündüğünüze bağlı olarak); Yani, aynı tecrübe bedenini geliştirmek için aynı zamana sahip olmadık.

Bir mimarın / inşaat mühendisinin planları neredeyse hiçbir zaman "inşa edilen" planlar ile aynı değildir. Her zaman bir şeyler değişir. Neden? Çünkü “bilinmeyen bilinmeyenler” vardır ve her zaman olacaktır. Bildiğiniz ve planlayabildiğiniz şeyler vardır, bildiğiniz şeyler bilinmezdir ve böylece araştırma ve tahminde bulunabilirsiniz, ve sonra bilmediğiniz, bilmediğiniz şeyler vardır; "Sürprizler". Bunları çoğu sistemde elinizden geleni öğrenerek elemeyi hedefliyorsunuz, ancak tek gereken küçük bir bina kodu ihlali (binanız kavramsallaştırılırken 2 yıl önce bulunmayan bir kurala dayanarak olabilir) ve - İç içe geçmiş ana planın, bazen oldukça sert bir şekilde değişmesi gerekir.

Yazılım buna çok benzer; her zaman bilinmeyen bir bilinmeyen vardır. Bununla birlikte, inşaat mühendisliği veya yapısal mühendislikten farklı olarak, yazılım geliştirme, bilinmeyen bilinmeyenlerin yarattığı sorunlara dayanarak değişime karşı daha toleranslıdır. 10 katlı bir bina inşa ediyorsanız ve tasarımınıza koyduğunuz vakfın taşıma kapasitesini abartıyorsanız, ya binayı 10 kata inşa edemezsiniz ya da önemli miktarda çalışmayı ayırmanız gerekir. temele geri dönün ve pekiştirin ya da yeniden inşa edin. Bununla birlikte, yazılımda, genel çözüm yapısının belirli bir katmanındaki talepleri hafife alıyorsanız, diğer tüm işleri geçersiz kılmayan bu katmanı düzeltmek için birçok seçenek vardır. Tek bir DB sunucusunu daha güçlü bir sunucuyla veya bir çoğaltma / yük devretme kümesiyle değiştirebilirsiniz, veya bir yük dengeleme / dağıtılmış küme. Web sunucusu için aynı. Girdi boyutunun hatalı varsayımlarına dayanarak verimsiz fakat basit bir algoritmayı kodladıysanız, algoritma hakkında bilgisi olan diğer kodları etkilemeden, uygulamayı nispeten cerrahi bir şekilde hemen hemen kaldırabilir ve yeniden yazabilirsiniz (girişi çağırır ve iletir. o, ya da ondan bir çıktı bekliyor).

Bu göreceli değişim kolaylığı, bir yazılım mühendisine bilmediklerinden endişelenmeden bildiklerini temel alarak kodlama olanağı sağlar. Bu, teori ve önceden kavramsal tasarımın daha gevşek uygulanmasına izin verir; dalıyor ve yaptırıyorsunuz, ve kodlama sırasında değişmesi ve değişmesi gereken şeyleri buluyorsunuz. Yine de kavramları ve teoriyi bilmelisiniz, çünkü bir problem ortaya çıkarıldığında, sebebi tanımlamanıza ve bir çözüm yaratmanıza yardımcı olacak şeylerdir. Ancak, “analiz felsefesi” ni kabul etmeden hızlı bir karar vermenize izin verilir, çünkü ortaya çıktığında, bilmediğiniz veya "hesaplamalarınızı" hesaba katmadığınız bir şeyi temel alarak yanlış bir karar verdiniz. hata düzeltmek daha kolaydır.

Fark, öncelikle bilinen gereksinimlerden kaynaklanmaktadır:

• Teori tarafında, her şey önceden tanımlanmıştır, böylece başlamadan önce tam olarak neye ihtiyacınız olduğunu bilirsiniz.
• Uygulamada, çoğu zaman hepsi orada değildir veya uygulamanın ortasında bir şeyi yeniden tasarlamanıza neden olan bir şey keşfedersiniz. Bu yüzden en azından ilkel tasarımlarla atlamak çok daha iyi, bu yüzden bu sorunları daha erken keşfedebilirsiniz.

Ek olarak, "teori" hakkında konuşurken, genellikle yazılım mühendisliği yerine bilgisayar biliminin teori tarafı anlamına gelir. Bu, bilgisayar biliminin büyük ölçüde daha iyi ve daha verimli algoritmalar bulma, bir şeyin mümkün olup olmadığının (örneğin P ve NP gibi) ispatlanmasıyla ilgili bir parçasıdır. Bunları zihninizin arkasında tutmak iyi olsa da, yazılım geliştirmede çok sık karşılaşmazlar.

Kütüphaneleri mümkün olan bu tür şeyler için kullanıyoruz.

Yapmakta olduğunuz yazılımın ne yaptığına bağlı olarak, aslında birkaç tane yazılım mühendisliği seviyesi vardır.

NASA uzayda insanlı mekikleri kontrol etmek için yazılıma ihtiyaç duyuyor, bu yüzden doğal olarak mühendislik sürecinin seviyesi roket resimlerini göstermek için bir web sitesi inşa etmekten çok daha katı.

NASA için çalışan iş arkadaşlarımdan biri daha önce yazılım mühendisliği sürecini, tek bir kod satırı yazmayı haklı çıkarmak için yüzlerce sayfa gerekçesiyle ve yüzlerce saat boyunca yapılan toplantılar olarak tanımladı!

Beni yanlış anlamayın çünkü bunu söylediğimde saygısız görünmeye çalışmıyorum, fakat zamanın maliyeti, kaynaklar ve milyarlarca dolar sonra bile uzay mekiği hala patladı.

İnşaat mühendisleri bile, bir tasarıma ne kadar teori koydukları önemli değil, sonunda bir şeyi kıracağını biliyor, bu yüzden de acil durum planları geliştirmeleri gerekiyor.

Yazılım geliştirirken, maliyetinin düşmesi nadiren can kaybına neden olur, bu yüzden hızlı bir şekilde oraya bir şeyler atmak ve test sürüşünü yapmak çok daha kolaydır. İşlerin hızlı bir şekilde yapılmasının zayıf kodlarla sonuçlanacağına katılalım. Bu her zaman böyle olsa bile, yazılımı hareket halinde görmek, geliştiricinin zayıf olduğu yeri görmesi için en iyi yoldur ve zayıf olduğu yere karşı daha güçlü yapılması ve yine de devam etmesi gerektiğinden çok daha güçlü olması gerekir yük.

Özetlemek Premature optimization is the root of all evil ya da patronum her zaman söyleyeceği gibiShipping is a feature!

Burada birçok iyi cevap var, ancak Bilgisayar Bilimi ve İnşaat Mühendisliği arasındaki karşılaştırmanın hatalı olduğunu düşünüyorum.

Açıkçası, profesyonel yazılım geliştiricilerin yaptığı şey, Bilgisayar Bilimleri'nden çok Yazılım Mühendisliği gibidir. Daha iyi bir benzetme Bilgisayar Bilimi Yazılım Mühendisliği için Fizik olmasıdır. Benzer şekilde, İnşaat Mühendisliği pratikte inşaat malzemeleri için basitleştirmeler ve Fizik yaklaşımlarının bir koleksiyonudur.

İnşaat Mühendislerinin nadiren işlerini yaparken genel göreliliği dikkate almaları gerektiğini hayal ediyorum. Newton mekaniği ile inşaat mühendisliğinin büyük bir kısmı güvenle yapılabilir. Benzer şekilde, Yazılım Mühendisliği kabaca yaklaşık bir teorik bilgisayar bilimi anlayışı ile çok başarılı bir şekilde gerçekleştirilebilir.

Büyük fark, köprüler, gökdelenler ve diğer İnşaat Mühendisliği ürünlerinin makul derecede iyi anlaşılmış olmalarıdır. Yazılım mühendisleri genellikle yeni yapılar inşa ediyor veya iyi anlaşılan şeyler yapmak için yeni yöntemler kullanıyorlar. Yazılım Mühendisliği, FAR'ın İnşaat Mühendisliğinden daha az olgunlaşmış halidir ve bu öngörülebilir gelecek için doğru olmaya devam edecektir.

TL; DR : Teori ve pratik, Yazılım Mühendisliği'nde her yerde olduğu gibi farklı. Doğru benzetme Yazılım Mühendisliği: İnşaat Mühendisliği :: Bilgisayar Bilimi: Fizik. Fakat pratikte, bundan biraz daha karmaşık :)

Öyleyse sorum, neden bazı programcılar teori (biçimsel yöntemler) ile pratik (bir şeylerin yapılması) arasında bir kontrast olduğunu düşünüyor?

Bina yazılımı, köprü inşa etmekten farklıdır. Yazılımda, başlangıçta tanımlanabilecek ya da tanımlanmayacak birçok nesne vardır. İsteğe bağlı matematiksel formüller veya bu gibi diğer ideallere uymamak için bakım ve geliştirici işbirliğini kolaylaştırmak için standartlar mevcuttur. Örneğin, bir değişkeni temel alan davranış seçerken, bazen bir anahtarın kullanılması, diğer zamanlarda fabrika düzeninin kullanılması mantıklı olur. Bakım kolaylığı ve performans sorunları gibi belirlenmiş ağrı noktalarına bağlıdır.

Veri manipülasyonu ile başka bir örnek yapılabilir. Delegelerin .NET bağlamında kullanılması genellikle mantıklıdır. Java'da o kadar kolay değildir, çünkü .NET'in sahip olduğu işlevsel programlama stili için çerçeve desteğine sahip değildir. Başka bir deyişle, genel durumda, Y durumunda X yapmak kesinlikle mümkün değildir. Bu, X ve Y'nin N değişken değişken faktör sayısına bağlı olmasından kaynaklanmaktadır.

Yazılım mühendisliği (bina yazılımı), örneğin inşaat mühendisliği (bina evleri) ile karşılaştırıldığında çok kolay algılanıyor mu?

"Kolay" ın doğru terim olduğundan emin değilim. Somut delil eksikliği, hiçbir iş yapılmadığı algısına neden olabilir. Veya, benzer şekilde, mevcut iş kolayca değiştirilebilir.

Yoksa bu iki disiplin gerçekten farklı mı (kritik görev yazılımı dışında, yazılım arızası bina arızasından çok daha kabul edilebilir)?

Geleneksel Mühendislik ve Yazılım Mühendisliği, daha önce belirttiğim nedenlerden dolayı çok farklı.

Buradaki algınız yanlış olabilir veya yeterince karmaşık bir yazılım yazmayan insanlardan birçok kaynak içeriyor olabilir.

Deneyiminiz, tanıdığım çoğu insanın (yeterince karmaşık bir yazılım tasarlayan ve yazan) söyleyeceği şeyle aynı çizgide.

Bu, çoğu programcıya gelince, bir şey yazma görevi onlara ulaştığında, tasarıma (“yazdığınız matematik”) mimar / kurşun / etc tarafından yapıldığını söyledi. yazma görevinden önce onlara ulaşır. Bu yüzden cephe seviyesinden bu şekilde görünebilir.

Bu kontrastın nedeni, bir yazılım projesinin ve donanım ya da mimari projenin yaşam döngüsünün farklı olmasıdır. Çoğu yazılım yavaş yavaş gelişir, baştan sona planlanmamıştır. Yazılım geliştiriciler gelişime yinelemeli bir yaklaşım uygulayabilir: geri bildirimleri planlayın, uygulayın ve dinleyin. Geri bildirim olumlu ise, devam edin, değil - geri adım atın ve stratejinizi yeniden gözden geçirin. Bu nedenle yazılım geliştiricilerin çevik geliştirme, minimum uygulanabilir ürün vb. Gibi şeyleri vardır.

İnşaat mühendislerinin bu kadar lüksü yok. Onlar için, bir şey planlandıktan sonra, yazılımda olduğu gibi kolayca değiştiremezsiniz, çünkü bu tür değişikliklerin maliyeti korkunç olabilir. Yazılım geliştirme için, diğer taraftan, bu kadar maliyetli değil ve bu avantajları için kullanılabilir.

Ancak, yazılım geliştirmenin her kolu bu yaklaşımı karşılayamaz. Örneğin, havacılık veya sağlık hizmetleri için yazılım yapmak çok dikkatli bir planlama ve çok sayıda önceden hesaplama gerektirmektedir.

Bana aynı görünüyor. Standart bloklardan, standart betondan, standart çelikten büyük bir bina inşa ediyorsunuz. Standart kütüphanelerden büyük bir uygulama oluşturuyorsunuz.

Denemeyin ve matematiksel olarak büyük bir uygulamanın, 100 katlı bir bina için dalga fonksiyonunu yazdığınız gibi doğru olmadığını kanıtlayın.

Yeteneklerimin yazılımda yattığını 20 yıl önce keşfetmeden önce bir makine ve imalat mühendisiydim. Ortaya koyduğunuz birçok unsura sempati duyuyorum.

Sorunun gerçek doğasının işleri nasıl hallettiğimizle ilgili olduğundan şüpheleniyorum . Kolektif kayışlarımız altında on yıllarca süren çevik gelişimimiz var ve mesaj açık. Katmanlar halinde ilerleme; özelliklere göre ilerleme. Tabii - katmanlara göre ilerlemeniz gerektiğinde projeler olacak (örneğin, ağ destenizi web sunucunuzdan önce inşa etmek) ama gerçek dünyadaki projelerin büyük çoğunluğu için, bir veya birkaç Bir zamanlar, test edilmemiş dev teorileri inşa etmek ve daha sonra bunları uygulamaya çalışmak çok daha etkilidir.

Öyleyse, kulübe örneğinizi ele alalım (genelde bir kilometreye uzanan uzun bir asma köprüye bir kütük fırlatıp atmak suretiyle köprü yapmaktan bahsediyorum… her neyse!) Ve yazılım mühendisliği dünyasına getirin. Gördüğüm en büyük fark, yazılımda, çalışmanın çoğunun başarılı olmak için büyük ön modellemeye ihtiyaç duymayacağı bir ölçekte olmasıdır. Aceminin hatası genellikle işlerin aslında onlardan daha fazlasına ihtiyaç duyduğunu varsaymaktır ve çoğumuz için, bu hatayı birkaç kez yaptıktan sonra, tekrar sık ​​sık yapmaktan gurur duyuyoruz.

Tartışma yok - 17 yazılım mimarından oluşan bir komite ile başlaması gereken projeler var. Gerçekte, 20 ayar pırlanta kadar nadirdirler.

Ben analojinin hatalı olduğunu düşünüyorum. Bildiğim kadarıyla inşaat mühendisliği bilgisayar bilimi ile aynı teorik temele sahip değil; bilgisayar bilimi teorik matematikten doğdu - Turing makineleri gibi. İnşaat mühendisliği, ana doğaya direnen ve belki de güzel görünen yapılar oluşturmakla ilgilidir. Yine, inşaat mühendisliği hakkında pek bir şey bilmiyorum, ama bence P'NP, seyahat eden satıcı ve beyninizi zorlamak için kullanılabilecek diğer eğlenceli şeyler olduğunu düşünüyorum. Ve kesinlikle bilgisayar bilimleri teorimiz için bir yer var - eğer birisi seyahat eden satıcıyı ya da durma problemini çözerse, müthiş yeni gelişmelere katılıyoruz. Fakat işi yazılım mimarlığı yapan bir yazılım mühendisi için, bu tür problemler gerçekten sadece eğlence ve oyun.

Şimdi, bunun "teori" ile ne demek istediğine bağlı olduğunu da düşünüyorum. Tasarım kalıplarından mı bahsediyoruz yoksa lemma mı pompalıyoruz? Çünkü tasarım kalıplarını iyi bir şekilde anlamak, iyi bir yazılım mühendisi olmak için kesinlikle çok önemlidir. Bununla birlikte, büyük bir yazılım sistemi tasarlarken, P / NP problemleri hakkında teorileşmek kullanışlı değildir. Bu anlamda, yazılım mühendisliği ve teorik bilgisayar bilimi arasında çok keskin bir kontrast olduğuna inanıyorum.

Yoksa teori algoritmaları mı ifade eder? Algoritmalar sınıfınızda öğrendiğiniz çok fazla zamanlama yazımı algoritması harcamazsınız. Neden? Çünkü genellikle sadece belirli durumlarda onlara ihtiyaç duyarsınız (ve sonra araştırır ve araştırırsınız) veya zaten sizin için yazılmış bir kütüphaneyi kullanıyorsunuz. Başka bir bayes sınıflandırıcısı yazmaya gerek yok. Soyutlama bilgisayar bilimlerinde önemli bir ilkedir. Yazılım mühendislerinin bir algoritmanın ihtiyaç duyuncaya kadar nasıl çalıştığını öğrenemediğini düşünüyorum.

Başka bir neden, şu anda etkili olan birçok popüler "halletmek" olan yazılım geliştirme yöntemleridir. Örneğin, çevik gelişimde, önceden tüm bir sistemi inşa etmiyorsunuz. Bunun sebebi, henüz neyi inşa ettiğinizi tam olarak bilmemenizdir - esnek olmak ve yeni bilgi ve gereksinimlere uyum sağlamak için yaptığınız şeyi. Her şeyi baştan sona tasarlayıp sonra sadece onu inşa etmek her zaman en iyi yazılımı üretmiyor. Ancak, her şey için çözüm değil. Örneğin, bazı dağınık bilgisayar-küme-çılgın-yeni bir şey tasarladığınızı varsayalım. Peçete çizimleri yapıp SCRUM'una başlayamazsın.

TL; DR. Bence "teori" kelimesinin etrafında bir denklik var. Geleneksel olarak, teori bilgisayar biliminin teorik matematiksel yönlerini ifade eder. Daha yeni hesaplama yollarını araştırmıyorsanız, çoğu teorik bilgisayar bilimi, bir yazılım mühendisinin günlük hayatında hiçbir rol oynamaz. Yazılım mühendisleri tasarım desenlerine ve sistem mimarisine önem veriyor. Bazı algoritmaların özel uygulama detayları önemli değildir. Çoğu zaman daha az karmaşık fikirlerle, çok fazla tasarım yapmamak ve sadece kodlamaya başlamak uygun olur. Ve bence bu, fikrin programcılardan geldiği ve teoriden hoşlanmadığıdır.

Teori ve pratik arasındaki boşluk şu anda çok büyük. Teori yaparken, size üç aksiyom verilir ve daha sonra bir satır teoreminin bin sayfalık bir kanıt olduğu veya hiç kanıtı olmadığı gösterilir. Yazılım mühendisliğinde, size belirsiz bir özelliği uygulama konusunda sayısız (kötü) davranış şekli veren binlerce fonksiyonun tutarsız API'leri verilir.

Gerçek yazılım mühendisliği, resmi alandakilerin çoğunu çılgına çevirir ve gerçek matematiksel yazılım geliştirme mühendisliği çılgına çevirir. Her iki alan da farklı yeteneklerden insanlar gerektiriyor ve ben yeteneklerin sık sık üst üste geldiğini sanmıyorum.

Resmi teori, üretilmiş bir ürün gibi her şeyi önceden doğru bir şekilde planlayabileceğinizi, bu yazılımın aynı ortamda süresiz olarak varolduğunu ve genel bir soyut problem çözmenin her zaman amaç olduğunu varsaymaktadır. Ürün olarak bir 4D yazılım yaşam döngüsü olduğunu varsayar: tasarla, geliştir, dağıt, yap. Örgün teori, analiz, soyutlama, genelleme ve gelecekteki değişimi tahmin etme kullanarak yazılım tasarımı problemini çözme ile ilgilidir. Kolayca analiz edilebilir, öngörülebilir ve oldukça statik olan basit bir alanda iyi tanımlanmış bir probleminiz varsa bu iyidir.

Pratik programlama şu anda doğru problemi (yazılım tasarımında değil) doğru şekilde çözmekle ilgilidir, böylece iş arkadaşlarınız işlerini daha iyi / daha hızlı / daha iyi yapabilir ya da gelirlerin şirkete akması sağlanır. Bir çok yazılım bir ürün gibi değildir, asla 'yapılmamıştır', ancak daha çok bir ekolojik niş için uzmanlaşmaya başlayan ve daha yeni, öngörülemeyen sorunları çözmek için ihtiyaç duyduğu çok değişken bir ömre sahip olan bir canlı gibi sürekli değişen ortamlarda çok çeşitli. İş dünyasında, politika ve yasallıklar ile rekabet ve sürekli değişen organizasyonlar, yapılar ve eğilimlerle birlikte, gereksinimler genellikle belirsizdir, her türlü özel durumla sarsılmış, kötü tanımlanmamış ve hızlı bir şekilde beklenmedik değişime tabidir. Analiz edilebilir, tahmin edilebilir veya statik değillerdir. ve genellikle mantıklı veya makul değildir. Yazılımın 2 haftada 20 yıldan beri kullanımda olmasıyla alakasız olması muhtemeldir. Çok fazla şey bilmeyen veya yapamayan dünyaya geliyor ve güçlü, esnek ve sürekli değişen çevrelerine ve yeni sorunlarına uyum sağlayabilmek için yaşamı boyunca beslenmesi, bakımı ve eğitilmesi gerekiyor. Eğer doğumdan sonra onu ihmal ederseniz, yeterince uzun süre hayatta kalırsa ve acıya ve acı çekmeye neden olur, künt güçle problemleri çözerse vahşi olur.

Resmi teori, gerçek dünyadaki iş yazılımlarının ihtiyaçlarını karşılamıyor. Yazılımın tasarlanıp yapılabileceğine inanmamız bizi kandırır. Bu, zaman zaman sabit tutulabilen, cilalanabilen ya da dokunulan şeylere sahip olan ancak ömrü boyunca sürekli özen ve dikkatle düzgün şekilde yetiştirilmesi gereken canlı bir ürün değildir. Bu yüzden gerçekten çirkin vahşi miras kurallarına uyuyoruz, ancak biçimsel teori muhtemelen bu konuda yardımcı olmazdı.

Kulağa oldukça olumsuz geliyor ama gerçekte biçimsel teori kullanmayı seviyorum. Güzel bir tasarım her zaman yüzüme bir gülümseme getiriyor. Ancak, çoğunlukla hobisi programımda işin mağduriyetine maruz kalmayan bir program var. İşyerinde çoğunlukla organik kodlarla uğraşıyorum ve sadece doğru şekilde büyümesine, beni gururlandırmasına ve kendisiyle uğraşması gereken diğerlerine karşı iğrenç ve kaba olmamaya dikkat etmeyi umuyorum.

Bahisler daha düşük, iş daha kolay ve yönetim tasarımın değerini nadiren görüyor. Sistem kararsızlığı, sürdürülebilirliği ve bütünlüğü bir "BT" problemidir - "İşletme" problemi değil. Tüm yöneticilerin ortak bir yönü var. Ya% 95'i paraya odaklanmış ya da birisine rapor veriyorlar.

Savaşın geri kalanı diğer programcılar ile birlikte. Birçoğu, kodlama başlamadan önce bir problem hakkında düşünmeyi taahhüt edemez veya etmeyecektir. Yukarıdakilerden dolayı, bu insanların önemli bir kısmı kıdemli geliştiricilerdir ve üretime iyi bir tasarım getirmeyi daha da zorlaştırmaktadır.

Projelerin boş zamanlarını geçici özellikler ekleyerek ve başlaması zor olan projelere düzelttiklerini ve ardından "çok karmaşık" veya "boşa harcanan" gibi ifadelerle kaosa düzen getirme çabalarını azalttığını gördüm. Büyük bir proje sarmalını kaçınılmaz kıyametine izlemek hoş değil çünkü yönetim, günlük olarak kendi cezaevlerini inşa ettiklerini kabul etmeyecek; Ancak, birçok geliştiricinin tanık olduğu ve - daha iyi ya da daha kötüsü için - öğrendiği talihsiz bir gerçeklikten korkuyorum.

İşimde bir ortam bulmaya çalışıyorum. Ben kesinlikle gerekli olandan "kusurlu" projelerinde artık kod yazmak ve ben işlevselliği taşımak için her fırsatı dışarı onlardan. “Projeler arasında,” Gerçekten kontrolüm altındaki projelerde tasarıma ve temizlemeye zaman harcıyorum.

Sonunda, dünyadaki programcıların% 75'inin midesi olmadığı büyük bir politika ve kişisel bütünlük dağınıklığıdır. Kendime zar zor dayanabiliyorum.

Her şeyden önce bu soruyu seviyorum. Üç 1000 kelimelik cevap gibi yazdım ve bunların sonuna geldiğimde hepsi çok yanlıştı.

İkisini benzer olarak karşılaştırmaya çalışmakla ilgili sorun, bence, programlama, istediğiniz kadar soyut veya sıkıca somut olarak bağlanabilen bir modelleme işlemidir.

Yapısal mühendislik teorisi ise, uymanız gereken çok spesifik gerçeklik temelli yasalara sıkı sıkıya bağlıdır. Sadece içeriği veya yasaları değiştiremezsiniz. Sorunun kendisi bu yasalara dayanıyor. Ancak programlamada bazen çözüm aslında sorunun yapısını değiştiriyor ya da basitçe farklı bir bağlamda yerleştiriyor.

Örneğin, MVC modelinin mükemmel bir uyum olup olmadığı, bu bağlamla çok ilgili. Bir masaüstü uygulaması genellikle yapılandırma dosyalarını saymaz, yalnızca bir dilde ve bir dilde çalışır.

Öte yandan, bir web uygulamasının ön ucu temel olarak iki bildirici (programlama dışı) dil ve JavaScript'ten oluşur. Tamamen soyutlayamayacağınız tek fiziksel şey, sunucu ve tarayıcı arasında işleri engellemek için her zaman bu http duvarının mevcut olmasıdır. Kodları nasıl gömdüğünüzden bağımsız olarak, bu zaman ve asenkron tasarım gerektirir.

Açıkçası, web üzerinde ön uç endişelerini ele almak için MVC gibi popüler ve saygın bir modeli, yalnızca bir masaüstü uygulaması bağlamında idare etme şeklinizi değiştirmeden kullanamazsınız. Aslında, tartışacak olursak, MVC'yi neyin kullanışlı kıldığının farkında olmalısınız, ancak özellikle titiz ya da toptan bir şekilde uygulamaya çalışmamaya çalışmalısınız. Web uygulaması paradigması, tüm bana bakma şeylerinin kullanıcının tarayıcısı tarafından ele alınması ve tüm veri / model-ish işlerinin genellikle bir yerde sunucuda olması nedeniyle benzersizdir. Ama bu denetleyiciyi nerede bırakıyor? Hepsi sunucuda mı yoksa ön tarafta mı? Birinin buna sahip olması gerekiyor. Ya da belki MVC% 100 senaryoya uygun değildir. .NET arka uç şeyler için fena değil. Belirli UI widget'ları bağlamında korkunç değil.

Bir ev inşa etmek problemi çözer. Bununla birlikte, tipik programlama problemleri çoğu zaman problemler içindeki problemleri çözmeyi içerir ve bazen çözüm dış problemi yeniden tanımlamaktır. Gerçek maalesef özellikle bu fikir istekli değil.

Glenn Vanderburg, yazılım mühendisliği ve daha geleneksel mühendislik disiplinleri arasındaki farklar hakkında harika bir görüş sunuyor: http://www.youtube.com/watch?v=NP9AIUT9nos

Eğer bir inşaat mühendisi tasarımlarını herhangi bir masraf olmadan test edebiliyorsa, son şeyi inşa etmeden önce teorisini daha az kullanırdı. Saniyeler içinde, ne zaman kırılacağını test etmek için ücretsiz olarak binlerce kez bir köprü kurabilseydi, teorik olarak ne zaman frenleneceğini hesaplamak için aylar harcamak yerine bunu yapardı ...

Yazılım geliştirmede tam olarak yaptığınız şey bu. Algoritmanızın teoride ne kadar hızlı olduğunu hesaplamak yerine sadece test edebilir ve cevabı saniyeler içinde öğrenebilirsiniz.

Aslında, günümüzde çoğu yazılım artık bilgisayar gücü veya bellek gibi fiziksel kısıtlamalarla sınırlı değil. Yazılımın sınırlandırılması, daha büyük ve daha büyük sistemlerde ortaya çıkan karmaşıklıktır. Bu karmaşıklığı, sistemi insanlar tarafından anlaşılabilir hale getirerek yöneterek günümüzde programlamada büyük zorluk yaratan şeydir.