Sürekli olarak değiştirilmesi gerekmeyen bir yazılım yazmak mümkün mü?

Birçok farklı dilde birçok yazılım yazdım ve ayrıca Verilog ve VHDL kullanarak FPGA'larla kullanmak için donanım "yazdım".

Donanımdan yazılımdan daha çok zevk almak eğilimindeyim ve bence başlıca nedenlerden biri, "yapılan" donanımın yazılmasının mümkün olması ve hiçbir zaman değiştirilmemesi gerektiğidir: arayüzleri ve işlevselliği tanımlarsınız, bir test tezgahı yazarsınız. , donanım modülünü uygulayın, daha sonra bir simülatör kullanarak heck'i test edin. Daha sonra daha büyük ve daha iyi bir şey oluşturmak için o donanım modülüne yapı taşı olarak güvenebilirsiniz: o modüle bir özellik eklemeniz gerekirse, ikinci bir modül oluşturup orada işlevselliği eklemeniz gerekir. Orijinal modülü hiç bir zaman atmazsınız çünkü iyi çalışıyor ve hala faydalı olabilir.

Yazılım konusundaki en büyük sıkıntılarımdan biri, bunun asla "yapılmaması". Eklemek için her zaman başka bir özellik vardır. Genellikle bir özellik eklerken, daha önce iyi çalışan başka bir yerde bir hata ortaya çıkarır. Arayüz ihlal edilmediği sürece bu donanımda olmaz.

Açıkçası, bir özellik listesi içeren bir şeyin bir versiyonunu inşa etmeyi savunmuyorum ve sonsuza kadar sürecek: Yeni özellikler eklemek için zaman içinde yinelemelerden ve birden fazla sürümden yanayım. Ben sadece soldaki kodu dürtmek ve sağda bir hata bulmak istemiyorum ve bu yeni bir özellik ekledikten sonra olmuş gibi görünüyor.

Yazılımın donanımın "yazıldığı" şekilde benzer şekilde yazılması mümkün mü? Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Belki donanım gibi iyi tanımlanmış arayüzler ve testlerle ilgisi vardır?

Kesinlikle düşüncelerim!

Net arayüzlü, iyi tasarlanmış modüller temelde mükemmel olma eğilimindedir. StringJava sınıfı gibi bir şey düşünün . Bu bir bilgisayar programı, ancak çok net bir arayüze sahip. Bilinen bir hata yok. Yapması gerekeni mükemmel yapıyor. Elbette, son 15 yılda kapsamlı bir şekilde test edildi ve neredeyse tüm programlar Stringtemel yapı taşları olarak kullanıldığından, içindeki herhangi bir hata hızla farkedilirdi. Herhangi bir "tuhaflıklar" - kesinlikle hatalar değil, ancak dikkat edilmesi gereken tasarım detaylarını - burada açıklananlar gibi: http://www.jwz.org/doc/java.html şu ana kadar iyi bilinir ve hesap.

Buggy yazılımı kısmen kültürel bir meseledir: insanlar buggy yazılımlarına alışmakta ve donanımın aksine, yazılım genellikle daha sonra kolayca düzeltilebilir, bu nedenle başlangıçta mükemmelleşmek zorunda kalmaz (veya şimdi, çünkü hey, şimdi göndermeliyiz, düzeltelim. sonraki sürümde). Ancak büyük bir kısmı için bu gerçek bir karmaşıklık sorunudur: Yazılım karmaşıklığı son 50 yıldır sürekli olarak artmaktadır, ancak insan beyni aynıdır. Mükemmelliğe ulaşma konusundaki artan zorluk ve daha sonraları (hızlı, otomatik kurulumlar, internet dağıtımı) sabitleme kolaylığının artması, program baskısı ve disiplin eksikliğiyle birleştiğinde, sonuç budur.

Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Gümüş kurşun yok muhtemelen, ancak bunlarla sınırlı olmamak üzere, en iyi uygulamaların iyi bir kombinasyonu:

• Basit, otonom modüller. Başka bir deyişle, düşük bağlanma ve yüksek uyum.
• Değiştirilemezlik. Büyüyen eşzamanlılık ile özellikle önemlidir.

Her iki noktanın da karmaşıklığı azaltmayı hedeflediğine dikkat etmek önemlidir. Anahtar nokta budur. Entropi her zaman artma eğilimindedir ve bununla savaşmazsak, yakında karmaşıklıkta boğuluruz. Ayrıca son birkaç yıl boyunca, programlama dillerinin yukarıda belirtilen uygulamaları teşvik etme ve hatta uygulama yönünde geliştiğini görmek ilginçtir. Özellikle, işlevsel dillerin yükselişi şudur: saf işlevler her zaman aynı girdi için aynı değeri döndürür, içinde hiçbir durum yoktur . O zaman sadece değişmez değerleri alan ve döndüren saf işlevler oluşturur ve kaçınılmaz değişkenliği etrafa yaymak yerine küçük iyi tanımlanmış yerlerle sınırlarsınız. Şunlara göz atın: http://clojure.org/state

Aradaki fark, yazılımı donanıma kıyasla değiştirmenin ne kadar kolay ve ucuz olduğu. Donanımın değiştirilmesi ve müşterilere gönderilmesi kolay ve ucuz olsaydı, onlar olurdu.

Kötü ifade edilmiş bir sorumu özetleyebilirsem, "Çalışma koduna hataları girmeyerek ve daima ilerleme kaydettirerek nasıl daha eğlenceli bir yazı yazabilirim?" Gibi bir şey olur. Belki donanım gibi iyi tanımlanmış arayüzler ve testlerle ilgisi vardır?

Teste dayalı gelişimi kesinlikle kontrol etmelisiniz .

Bu yorumlardan cevabını almanızı umarak bazı düşüncelerinize yorum yapacağım.

Yazılım konusundaki en büyük sıkıntılarımdan biri, bunun asla "yapılmaması".

Bunun nedeni çözüm şartnamesinin eksik olması veya donanım geliştirme planının doğru olmamasıdır. Bu, herhangi bir proje yazılımı, donanım veya başka herhangi bir şey olabilir.

Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Elbette, bağımsız modüller oluşturmak bağımlılığı büyük ölçüde azaltmalıdır. Yazılımı tasarlarken bunun dikkate alınması gerekir. Endişelerin, katmanların, katmanların, denetleyici nesnelerinin, arayüzlerin vs. ayrılmasını dikkate almanız gerekir.

"Çalışma koduna hataları girmeyip her zaman ilerleme kaydettirerek daha eğlenceli yazma yazılımını nasıl kullanabilirim?"

1-Gereksinimleri dikkatlice anlayın. Tasarımdan önce gereksinimleri kapatmayı düşünmeniz gerekebilir. Yinelemeli bir gelişim yaparsanız, bunu yapma şansınız yoktur. Bazı metodolojiler bunu teşvik eder, ancak şahsen, bunun tüm proje türleri için iyi olmadığını düşünüyorum. Sağlam gereksinimler üzerine yazılım oluşturmak, daha iyi bir tasarım sağlar.

2-Kullanıcınızın bu uzun vadeli felsefeyi anlamasını sağlayın.

3-Uygulamayı dikkatlice planlayın

4-Kod öncesi tasarım.

5-Uygun olduğunda genel tasarım kullanın.

6-Prototipleri tasarım onay aracı olarak kullanın.

İnsanlar genellikle hızlı bir şekilde belirtmek için hızlı olduklarından, yazılımın yararlarından biri, donanıma kıyasla değiştirmenin kolay ve nispeten ucuz olması gerektiğidir. Bu, özellikle geç bir şeyin yanlış gittiğini fark ettiğinizde önemlidir. Aynı şeyi donanımla da yapın ve bir milyon dolar kaybedersiniz, dediğiniz gibi, simülatörlerinizi vb. Kullanırsınız ve bazingayı test edersiniz. Sanırım bu, paradigmanın, yazılıma geçtiğinizde bir şekilde başarısız olduğu yerdir.

Ortalama bir yazılım geliştiricisinin başının içine girin ve sahip olduğunuz şey inanılmaz derecede sıkı bir son teslim tarihi olan çok meşgul bir insan. Onun menajeri, birkaç hata bırakmanın sorun olmadığını söylüyor çünkü daha sonra düzeltebilirsiniz. Testler genellikle bir düşüncedir, ancak teste dayalı bir senaryoda bile, testler minimum düzeyde tutulur ve testlerin minimumunda yazılı olan kod ve çoğu durumda kısayollar alınabilir, böylece çoğu sınır vakası kaçırılabilir. Sistem tamamen ünite testine tabi tutulabilir, ancak nadiren bir bütün olarak titizlikle test edilir ve nadiren herhangi bir derecede stres testi yapılır. Buna sıfırdan bir yazılım yazdığınızı ve yazmayı taahhüt etmeden önce yazılımı simüle etmek için çok az fırsat bulunduğunu, çünkü donanımda bulabileceğiniz aynı tür ince taneli yapı taşlarından nadiren yazılım yazdığımız için ekledik.

OP'nin sorusuna geri dönün. Tüm yazılımlarınızı türetmek için bir yapı taşları sistemi tanımlayabilir misiniz ? Muhtemelen. Çok uygun maliyetli mi? Muhtemelen hayır, çünkü zaman zaman bu ideali destekleyecek kadar sağlam bir bileşen, test ve diğer gereçler sistemi geliştirmeye başladınız.Programlama sisteminde, rekabetinizin sizi zaten piyasaya sürdüğünü ve hatta daha da kötüsü, ortalama programcının bakış açısına göre muhtemelen çok sınırlayıcı ve daha muhtemel bir "çerez kesici" tarzı bir sistem bulacağınızı keşfedeceksiniz. sıkıcı. Şahsen, modül kodunun büyük bölümünün tamamen tamamen standartlaştırıldığı ve standartlaştırıldığı bir API üzerinde çalışıyorum, şu an yaptığım tek şey bir kod şablonu oluşturmak ve boşlukları doldurmak. Benim zamanımın çoğu basit bir bağlayıcı kod yazarak ve modülleri mümkün olduğunca hızlı bir şekilde kapıdan çıkarmakla geçirilebilir. Cidden akılda uyuşma. Aynı şeyleri tekrar tekrar kodlamaktan daha fazlasını yapmak için çok az fırsat var, bu yüzden başka bir proje fırsatı ortaya çıktığında, başka bir şey yapma şansına atlarım.

Öyleyse, yüksek kaliteli ve iyi faktörlü yazılımlar sunmayı nasıl başarırsınız, ancak aslında bunu yapmaktan zevk alırsınız? Bunun sizin seçtiğiniz araç ve metodoloji ile ilgili olduğuna inanıyorum. Benim için cevap iyi bir BDD API kullanımıydı, çünkü okuması çok kolay, fakat çok ayrıntılı bir kod oluşturmamı sağladı. Çok az sayıda yeniden kullanılabilir yöntemden bir test takımı oluşturabilir ve testlerimi şartnamelerin dilinde açıklayabilirim. Bu şekilde, yapı taşlarının tasarlanmasından ve kontrol edilmesinden sorumlu olduğum gerçeği dışında, daha bileşenlere dayalı bir geliştirme yaklaşımına yaklaşıyorum. Ek olarak, test çıktısı, hatanın oluştuğu yerde testin tam bölümünü belirtir, böylece hataların kurulumda mı yoksa iddiada mı olduğunu tahmin etmeme gerek kalmaz.

Metodolojinizi ayarlamak da yardımcı olur. Yalın kalkınma ilkelerini uygulamak ve bunları Çevik hareketin yıllardır patladığı birçok teknik ve ilkeyle birleştirmek için büyük bir savunucuyum. Bu kadar sinir bozucu bulmaya çalıştığım savurgan uygulamaların çoğunu elimine almak, gelişimi daha eğlenceli bir faaliyet haline getirmek için çok yardımcı oldu. Hala kodumda hatalar ortaya çıkacak - ancak umarım çok sık değil - hatalar ortaya çıkıyor, ancak şimdi kendimi daha fazla zaman ve daha sağlam testler yazmak ve 100'ü hedeflemek için daha fazla zaman harcamak için daha fazla teşvik buluyorum. % test kapsamı. Daha da iyisi, bütün bu yeşil ışıkların günümün sonunda göründüğünü görmek gerçekten güzel hissettiriyor.

Yazılım konusundaki en büyük sıkıntılarımdan biri, bunun asla "yapılmaması". Eklemek için her zaman başka bir özellik vardır.

Bu sizi sinirlendirirse, farklı bir kariyer düşünün. Ciddi anlamda.

Nokta yazılımın özellikler eklemek mümkün olmaktır. İlk olarak "yazılım" ı icat etmenin bütün nedeni, özellikleri ekleyebilmemizdi.

Genellikle bir özellik eklerken, daha önce iyi çalışan başka bir yerde bir hata ortaya çıkarır.

Bu bir QA problemi.

Arayüz ihlal edilmediği sürece bu donanımda olmaz.

Bu aynı zamanda yazılım için de geçerli.

Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Evet. Aslında Kalite Güvencesi uygulamanız gerekir.

Yazılımın donanımın "yazıldığı" şekilde benzer şekilde yazılması mümkün mü? Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Tasarımların ve yazılımların doğruluğunu doğrulamak için " resmi yöntemleri " incelemenizi öneririz . Donanım tasarımı için kullandığınız simülatör araçları yakın bir şey yapmaya çalışıyor. Biçimsel yöntemler için araçların şu anda endüstride yararlı olmaya yakın herhangi bir yerde olduğuna inanmıyorum ve hatasız olmak için güçlü teşvikleri olan tek sanayi aviyonik ve tıptır (ilginç bir şekilde, FDA açıkça "yazılımın farklı olduğunu söylüyor) donanımdan "bu bağlantıda). Ayrıca, eğer Verilog / VHDL ile geliştiriyorsanız, o zaman ikili mantığa bağlı kalıyorsunuz. Bu, karmaşıklığı büyük ölçüde azaltır. Y2K sorununa eşdeğer bir donanım olmayacak.

En büyük sorun şeylerin karmaşık olmasıdır. Ve karmaşıklığı ortadan kaldıramazsınız, sadece hareket ettirebilirsiniz.

"Tamamlandı" ve asla değiştirilmemesi gereken donanımlar yazmak mümkündür: arayüzleri ve işlevselliği tanımlarsınız, bir test tezgahı yazar, donanım modülünü uygularsınız, sonra bir simülatör kullanarak kontrol edin. Daha sonra daha büyük ve daha iyi bir şey oluşturmak için o donanım modülüne yapı taşı olarak güvenebilirsiniz: o modüle bir özellik eklemeniz gerekirse, ikinci bir modül oluşturup orada işlevselliği eklemeniz gerekir. Orijinal modülü hiç bir zaman atmazsınız çünkü iyi çalışıyor ve hala faydalı olabilir.

Yazılım dünyasında, bu "modül" e bir kütüphane diyoruz ve aynı şekilde kullanıyoruz. Pek çok kütüphane, iyi işledikleri noktaya inşa edilir ve daha sonra önemli bir şey bir sonraki revizyona yol açana kadar mutlak bir şekilde işlerini yaparken değişiklik yapmaksızın oturur. Bunları epoksi ile saklanmış bir yazılım olarak düşünün :-)

Yazılım konusundaki en büyük sıkıntılarımdan biri, bunun asla "yapılmaması". Eklemek için her zaman başka bir özellik vardır. Genellikle bir özellik eklerken, daha önce iyi çalışan başka bir yerde bir hata ortaya çıkarır. Arayüz ihlal edilmediği sürece bu donanımda olmaz.

Hogwash. Belki de kişisel olarak diğer pek çok havya demiri olmayan "donanım " insanından daha iyisin, ama herhangi bir hatalı devre tasarımı gördüm, hatalı cipsler ( örneğin , ünlü Intel "f00f" sorunu), ama bu alanla bir bütün olarak konuşun. Sahte donanımlar "daha yumuşak" hale geldikçe, problemlerin önlenmesi zorlaşır.

Yazılımın donanımın "yazıldığı" şekilde benzer şekilde yazılması mümkün mü? Her zaman ileriye doğru ilerleme kaydedilmesini ve mevcut kodu yeniden yazmaya ve yeni hatalar ortaya koymaya gerek kalmadan yeni işlevsellik eklenmesine izin veren iyi bir yazılım geliştirme metodolojisi var mı?

Evet. Biz sadece bu metodolojileri pek kullanmıyoruz. Kullanımları oldukça pahalı olma eğilimindedir ve çoğu programcı kısıtlamaları dahilinde çalışmaktan hoşlanmaz. Fakat insan yaşamına karıştığında, örneğin, evet, kullanıcıları öldürmemeye çalışırız.

Son bir nokta: Yazılım, programlanmış donanımdan bile donanımdan farklı bir finansal modele sahiptir. Tüketici olmayan çoğu yazılım ve bazı tüketici yazılımları da değişimi teşvik edecek şekilde satılmaktadır. Bir işletmeye "Şimdi bize 10.000 $ artı yıllık% 18 ödeme yapın" deyince, ürünü esas olarak birkaç yılda bir yeniden satabilirsiniz. Ancak bu ücreti haklı çıkarmak için, müşteriye istedikleri değişiklikleri vermeniz gerekir. Hmm ... Apple’ın donanım eskimesi eğrisini düşünmek, belki de sonuçta bu bir fark değil - donanım gerçekten onu yeniden almanızı sağlar !

Çalışma koduna hataları girmeyerek ve daima ilerleme kaydettirerek nasıl daha eğlenceli yazma yazılımına sahip olabilirim?

Sorunuza son bir cevap bulmayı çok isterim. Ancak gerçek şu ki, bunu yapmanın kolay bir yolu yok, bu yüzden aşırı programlama ve TDD teknikleri bu kadar popüler hale geliyor. Değişimi kucaklaman gerekiyor, çünkü olacak. Bunun daha komik olup olmadığını bilmiyorum, ama daha az stresli olduğu kesin ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Donanımla etkileşim kurduğunuzda, donanım x değerine ve hepsine (teoride) ihtiyaç duyar, ancak bugün insanlarla etkileşim kurduğunuzda x'e ve yarın da y'ye ihtiyaç duyabilir. Vb. İşler ve insanların gereksinimleri değişiyor. . Çünkü Persons! = Makineler, çoğu zaman ASLA değişmeyecek kod mümkün değildir.

Ayrıca önceki / silinen cevabımda söylediğim gibi, insanların kodlamaya başlamadan önce düşünmelerini sağlayarak önemli olmayan değişikliklerden kaçınmaya çalışın. Kullanıcıları karar verme, vb. Hakkında daha fazla dahil edin. Değişikliklerin maliyetlerini netleştirin, daha fazla plan yapın, vb. Bunlar "kodlama yolu" değildir, "kodlama" değildir, çünkü gereksinimler hakkında daha fazla değişiklik olsa da, daha az değişiklik ve daha eğlenceli olacaktır.

Benzer şekilde yazılım yazmak mümkün mü?

Evet öyle. Donanım geliştiriyormuş gibi dikkatli olun, elinizden gelen her şeyi test edin ve yazılımınız benzer kalitede olacaktır.

Bu arada, HW hatalarını duymadın mı? Çok nastier sonra herhangi bir SW hata ve düzeltmek daha zor (sadece yazılımı yükseltme değil)

Ayrıca donanımdaki yazılım hatalarının çoğu zaman insanları öldürebileceğini de belirtirdim. Bu nedenle, gereklilikleri eksiksiz bir şekilde belirlemek ve kapsamlı bir şekilde test etmek için daha fazla özen gösterilmektedir. Ve bu gereksinimlerin donanım gelene kadar değişmesi gerekmez. Ve yeni donanımın yeniden yazılması gerekebileceği için, sanığın da fazla bir şey oluşturmadığından şüpheleniyorum.

Öte yandan iş gereklilikleri sürekli değişiyor, bazen bir değişiklik talep edilmeden önce bir gereksinimi üretime zor giriyorsunuz. Bazen, üretime geçmeden önce gereksinimimi defalarca değiştirdim. Bu birkaç şeyin sonucudur. Öncelikle, iş tarafındaki proje paydaşı ne istediğini tam olarak tanımlamak için zaman harcamakla daha az ilgileniyor çünkü “meşgul” ve “önemli” ve insanlar ölmeyecek ve aileler onu dava edecek ya da hapse atmış olacak sürecin bir kısmını mahvetti. İkincisi, proje paydaşları gerçekte donanımın ne yapmasını istedikleri konusunda daha az soyut oldukları için daha iyi bir fikir edinme eğilimindedir. Gerçekten görene kadar ne istediklerini bilmiyorlar. Hangi Donanım ile daha az problemdir.

Uygulamalarda birleştirebileceğiniz çok sayıda “tuğla” bitmiş çok sayıda araç var. Tuğlaları kullanmanız için parçalar tamamlandı, onları birleştirmek zorundasınız. Belki de bunun daha kolay olduğunu düşünüyorsunuz ... müşteriniz sizden bazı garip ve beklenmedik değişiklikler isteyene kadar.