Başarısız olan bir yazılım geliştirme fikrine veya tekniğine iyi bir örnek nedir?

Özellikle kitlelerin fikirlerinin nerede yanlış olduğu konusunda bazı örnekler vardır. Neden insanlar fikirleri ilk etapta tuttular? Ve fikirler neden reddedildi? Ya da belki de fikirler hala canlı ve iyi ve öyleyse neden?

Örneğin, CORBA'yı (ve diğer benzer teknolojileri) yazılım bileşenleri arasındaki iletişim sorununu çözmeye çalışan bir şey olarak tanımlayabilirim . Birçoğu, çeşitli bileşenler arasındaki sözleşmeleri tanımlamanın gerekli olduğunu düşünüyordu. Nihayetinde, HTTP + JSON kitleler için sorunu çözdü ve Thrift ve Proto-bufs gibi diğer çeşitli RPC mekanizmaları ortaya çıktı.

Temel olarak, tıpkı dünyanın dışındaki bilgisayarlarda olduğu gibi, fikirler ve teknolojiler dikkat, kaldıraç vb. İçin rekabet eder. Bazıları kazanır, bazıları kaybeder; ve bazıları bir süre Kazanan gibi görünebilir, sonra Bir Sonraki Büyük Şey'in ortaya çıkmasıyla belirsizliğe bürünebilir. Aslında daha iyi olan bir şeyle ilgisi olabilir ya da olmayabilir. VHS'ye karşı Betamax'a veya çeşitli DVD formatları arasındaki daha yeni savaşa tanık olun.

CORBA çok büyük, garip ve kullanımı zordu, ancak o zaman bazı insanların icat edebileceği en iyisiydi (Dünya Çapında Ağ - ve HTTP, Java, XML, ... - yaygın olarak bilinmeden önce tasarlandığını unutmayın). Ve aynı zamanda komitenin tasarımına klasik bir örnekti , burada herkesi tatmin etmek için her fikirde sıkıştılar, sonunda işe yaramaz bir şekilde şişirildi (en azından bugünün gözleri tarafından görüntülendi). FOSS'un ortaya çıkmasıyla yakında yasaklayıcı olan fiyatından bahsetmiyorum.

Sonuçta, HTTP + JSON kitleler için problemi çözdü

En azından benzer bir "nihai çözüm" görmeyen ve nihayetinde düşüş görmemiş biri için ... Zamanında CORBA hakkında benzer bir duygu olduğunu akılda tutmak iyi ;-)

CORBA'nın Yükselişi ve Düşüşünden alıntı yapmanın uygun olduğunu hissediyorum :

CORBA'nın geçmişi, bilgi işlem endüstrisinin birçok kez gördüğü bir tarihtir ve mevcut ara katman yazılımı çabalarının, özellikle de Web hizmetlerinin benzer bir geçmişi yeniden canlandırması muhtemel görünmektedir. [...]

Genel olarak, OMG'nin teknoloji benimseme süreci CORBA'nın düşüşünün temel nedeni olarak görülmelidir. Süreç, teknik mükemmelliği bir yana, teknik sıradanlık elde etmenin zor olduğu noktaya kadar komite tasarımını ve politik manevraları teşvik eder. Ayrıca, ayrık özelliklerin eklenmesi, mimari vizyonun kademeli olarak aşınmasına neden olur. [...]

OMG'ler gibi demokratik bir süreç, iyi yazılım yaratmak için benzersiz bir şekilde uygun değildir. Bilinen prosedürel sorunlara rağmen, endüstri teknoloji üretmek için büyük konsorsiyumlara güvenmeyi tercih ediyor. Orta katman yazılımlarının mevcut gümüş mermisi olan web hizmetleri, OMG'lere çok benzer bir süreç kullanıyor ve birçok hesapta da kavga, parçalanma, mimari tutarlılık eksikliği, komite tasarımı ve özellik şişkinliği çekiyor. Web hizmetlerinin CORBA'lara oldukça benzer bir tarih çıkarması kaçınılmaz görünüyor.

Şimdi farklı bir açıdan: "kitlelerin fikirleri" teriminizi okuduktan sonra, CORBA veya diğer standartlardan çok farklı şeyler düşündüm; bunlar tipik olarak bir kişi veya küçük bir grup fikridir. "Kovboy kodlama", "kod ve dua", "makinemde çalışıyor" gibi kötü niyetli uygulamaları / bakış açılarını düşündüm. Bunlar IMHO'nun gerçek "kitlelerin fikirleri" dir, çünkü bu hemen hemen her şekilde geliştirici içgüdüsel olarak kod yazmaya başlar. Ve onlar ne uzayda ne de zaman içinde ölçeklenmediklerinden yanlıştırlar - kişi bu şekilde büyük, sürdürülebilir, genişletilebilir programlar oluşturamaz. Yine de insanların maalesef dünyanın dört bir yanındaki profesyonel mağazalarda bu şekilde çalışmaya çalışmasının istisnadan ziyade norm olduğunu hissediyorum.

Bunun diğer uç noktası, CMM, RUP, Şelale vb. Gibi büyük-M Metodolojilerinde ortaya çıkan, SW gelişimine "doğru yaklaşım" ile ilgili birçok yöneticinin ve teorisyenin fikirleri. Doğru Süreç ve geliştiricilerin gerçekte kim olduklarından bağımsız olarak kaliteli yazılımları belirleyici bir şekilde otomatik olarak üretmeye başlayacaktır. Aynı oyunun Agile yöntemleri kullanılarak da oynanabileceğine dikkat edin - bu sadece bir etiket değişikliği. Geliştirme ekibi için doğru üyeleri seçmenin (ve tutmanın) geliştirme sürecinden daha az önemli olduğuna inanan her yönetici, hangi süreç olursa olsun başarısızlığa mahkumdur. Ancak Sürece olan bu inanç hala yaygın görünmektedir - belki de hala yönetim okullarında öğretilmektedir?

Yanlış giden insanların sık görülen bir örneği şelale modelidir. Bu, Winston Royce'un "Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme" belgesinde de yer alan stereotipik şelale modelinin bir diyagramıdır .

Bu resmin ardından şu metin gelir:

Bu konsepte inanıyorum, ancak yukarıda açıklanan uygulama risklidir ve başarısızlığı davet eder ... Geliştirme döngüsünün sonunda meydana gelen test aşaması, zamanlama, depolama, giriş / çıkış, transferler vb. analizlerden farklı deneyimlerdir. Bu fenomenler tam olarak analiz edilemez. Örneğin, matematiksel fiziğin standart kısmi diferansiyel denklemlerinin çözümü değildir. Ancak, bu fenomenler çeşitli dışsal kısıtlamaları karşılayamazsa, değişmez bir şekilde büyük bir yeniden tasarım gereklidir. Basit bir sekizli yama veya bazı yalıtılmış kodların yinelenmesi, bu tür zorlukları düzeltmeyecektir. Gerekli tasarım değişiklikleri, tasarımın dayandığı ve her şeyin gerekçesini sağlayan yazılım gereksinimlerini ihlal edecek kadar büyük olasılıktır. Gerekler değiştirilmeli ya da tasarımda önemli bir değişiklik yapılması gerekmektedir. Gerçekte geliştirme süreci başlangıç ​​noktasına döndü ve program ve / veya maliyetlerde yüzde 100'e kadar taşma beklenebilir.

Makalenin ilerleyen bölümlerinde Royce, mevcut faz ile bir önceki faz arasında tekrarlama ve gereksinimler-analiz-tasarım ile tasarım-kod-testi arasında bir başka döngü arasında tekrarlayan alternatif süreç modelleri sunar. Ayrıca bir dizi dokümanı ve hangi aşamalarda tamamlanmaları gerektiğini tanımlar ve ilgili tüm eserlerin analizini, test edilmesini ve kullanımını dahil etmek için müşteri katılımını ve her aşamada birden fazla şelaleyi savunur. Gerçekte, Royce'ın tartıştığı şey, çevik yöntemlere erken bir yaklaşım olarak düşünülebilir - yine de çok plan odaklı, ancak çevik hareket için bir temel olabilir.

İnsanlar neden ilk şelaleye takıldılar, bilmiyorum. Sanırım risk almayı ve başarısızlığı davet etmeyi seviyorlar.

Daha yüksek bir soyutlama seviyesinden otomatik kod oluşturma veya otomatik programlama .

Wikipedia makalesinde tarihsel bilgiler biraz eksik, ancak programcılar bilgisayarlardan daha pahalı hale geldiğinden beri bu bir yönetici rüyası oldu.

Fortran ve Cobol gibi daha üst düzey dillerin geliştirilmesinden sonra, rapor yazma gibi özel alanlar için dillerin geliştirilmesi geldi. Easytrieve ve SAS birkaç örnekti.

1980'lerin CASE araçları öfke idi. CASE bilgisayar destekli yazılım mühendisliği anlamına gelir. Mühendislik ilkelerinin titizlikle uygulanmasının yazılım geliştirmeyi daha hızlı hale getireceği düşünülmüştür. Bu araçların masrafın yanı sıra yakalamamasının ana nedeni, araçların etkili bir şekilde çalışması için gereken yüksek düzeyde veri standardizasyonu idi.

İnternet 1990'larda ön plana çıktı. İnternetin kolaylaştırdığı programlama türleri patladı. Programcılar, illüstrasyonları, haritaları, fotoğrafları ve diğer görüntüleri ve basit animasyonu, daha önce hiç görülmemiş bir oranda, iyi bilinen birkaç yöntemle ele almaları gerekiyordu. Bu nesneleri üreten teknolojilerin sayısı çoğaldı. Otomatik programlama hayalleri azaldı.

Programlamayı daha ucuz yerlere dış kaynak kullanımı, programcı maliyetlerini azaltmak için kalan birkaç yöntemden biridir. Dış kaynak kullanımı ile ilgili problemler arasında iletişim problemleri ve şartname problemleri bulunmaktadır.

Biçimsel Yöntemler

Bir zamanlar, yazılımın doğru olduğu kanıtlanabilirdi. (Testin, hata olmadığını gösteremediği, ancak kanıtların yapabileceği fikri.) Ne yazık ki, bir program için kanıt oluşturmanın bazı önemli dezavantajları vardır:

• Programı yazmaktan daha zor ve zaman alıcıdır.
• Tüm programı kapsamalıdır, yani herhangi bir kütüphane, işletim sistemi vb.İçin kanıtlara ihtiyacınız vardır ...
• Böceklerin olmadığını kanıtlamaz, çünkü bu böcekler kazayla ortaya çıkabilir.

Bu kavram 70'lerde çok popülerdi.

Bağlantı: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods