Sözde kodlama ile yazılım tasarımı?

Sözde kod tabanlı bir yöntemle yazılım tasarlamak (yani yazmak) için iyi bir yol biliyor musunuz?

Yazılım tasarımında yeniyim ve UML hakkında bazı bilgileri okudum. Mütevazı sınıf hiyerarşilerim şu ana kadar iyi, ancak karmaşık hale geldikten sonra, "bütünü görmek" resmiyle gelecekteki daha fazla genişletilebilirlik için farklı bir yapı kullanabileceğimi fark ettim. Python prototiplemede iyi olduğundan, yazmaya başlamakla neredeyse iyiyim, ama tam olarak değil.

Bu yüzden UML sınıf diyagramlarını denedim, ama bana pek yardımcı olmuyorlar. Orada çözdüğüm sorunlar önemsiz bir şekilde kafamda yapabilirim. Ancak, gerçek yöntemleri sözde kodlamaya başladığımda ek tasarım gereksinimlerini fark ediyorum.

Pseudocode ile tasarım yapmak istiyorsanız, bunu nasıl yapardınız? Bana göre kabaca 1-1 kod ile bir yöntem en iyi çalışır inanıyorum. Ancak çoğu UML yazılımı, yöntemin kodunu bile göstermez (örneğin, GoF'deki resimlerin aksine).

Birisi UML'nin sadece dokümantasyon ve sunum için olduğunu ve tasarım için harika olmadığını iddia etti? Bu duyguyu da anlıyorum. Envision APDT'yi bulana kadar saf UML ve bazı basit beyaz tahta taslaklarının yazılım tasarlamanın yolu olduğunu düşündüm.

Çevik gelişme dikkat etmem gereken bir şey mi yoksa rasgele bu çevik olarak mı adlandırıyorlar - çevikliğin yalnızca programla ilgili olduğunu düşündüm? Yoksa yanlış mı tasarlıyorum (UML ile) - pseudocode ile tasarım yapan var mı? Bunun için nasıl iyi bir araç bulabilirim?

 I thought agile is about schedule only?

Sadece planlama değil. Çevik yazılım geliştirme, daha çok ürün sahibi tarafından talep edilen değişikliklere esnek yanıt vermeyi teşvik eden uyarlanabilir planlama ile evrimsel bir gelişme ve zaman kutulamalı yinelemeli dağıtım olmakla ilgilidir.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Deneyimlerime göre, bir müşteri stand perspektifinden grafikleri anlamak çok daha kolay. Görsel olarak çekici ve birçok kez çok renkli ve takip edilmesi kolay. Bununla birlikte, gerçek uygulama koduyla bağlantı kesilmesinin doğası nedeniyle grafikleri korumak çok zordur. Uygulamada her değişiklik yapıldığında, geliştirici grafikler de dahil olmak üzere tüm belgeleri güncellemek için zaman ayırmalıdır. Ancak, ekipte veya şirkette müşteri iş sürecini iyi anlayan ve UML diyagramlarını yönetebilen bir BA olduğunda bu sorun kolayca ortadan kaldırılabilir.

UML gibi araçlar bu işlemi kolaylaştırabilir, ancak yalnızca nesne yönelimli programlama ile iyi çalışır. Sözde kod teknik ekipler için çok daha kolaydır. Bu kodu oluşturma süreci, gerçek programlama dili geliştirme aşamasının hızını büyük ölçüde artırır.

Bakabileceğiniz başka alternatifler de var:

• Veri Akışı Diyagramları
• Durum Diyagramları
• Proses Akış Şemaları

Bakmak için iyi referanslar: Yazılım Tasarım Dersleri . Buna ek olarak, ben şahsen Pseudocode veya Code iyi bir blog okumak için tavsiye ediyorum ? Şu kişi tarafından gönderildi Coding Horror - benim favori blog okumak :)

Sonuç olarak, dikkate almanız gereken bazı ödünleşmeler vardır.

Montaj dilinde programlama yaparken sözde kod yazmak çok mantıklıdır. Algoritma, montaj diline manuel olarak çevrilmesi ve daha sonra çeviri hatalarının ayıklanması için harcanmadan önce doğrulanabilir. Tek kontrol yapısının GOTO olduğu, tüm değişkenlerin (resmi argümanlar hariç) küresel olduğu ve değişken adlarının altı karakterle sınırlı olduğu FORTRAN IV gibi birinci nesil derlenmiş diller için hala bir anlam ifade ediyordu.

Bugün montaj dilinde çok az programlama yapıyoruz ve sadece kod yazmak yerine sözde kod yazarken çok az değer görüyorum. İyi bir dilde, gerçek kod sözde kodu neredeyse kelime kelimesini takip eder ve sözde kod sadece zaman kaybıdır.

Ancak, altta kodlamaya başlamıyorum. TDD'yi takip ediyorum ve bir testle başlıyorum. Sonra üstte kodlamaya başlıyorum ve testleri geçebilmek için yavaş yavaş aşağıya doğru çalışıyorum.

Sahte kodun alternatifi 1000 satır alt düzey sınıf yazmak değildir. Bunun yerine, alan adınız için ideal ancak var olmayan API'yı çağırarak üstten başlayın. Ardından API'yi oluşturun.

Tüm yöntemleri listelemeyi ve kalıtım hiyerarşisini gösterdiğinizde bile, sınıf diyagramlarının çabaya değmeyeceğini düşünüyorum. Dizi diyagramları iyidir, ancak onları çizerken garip hissediyorum (muhtemelen sadece ben).

Veri akış diyagramlarının ve yapı grafiklerinin daha yararlı olduğunu düşünüyorum (yapı grafikleri genellikle BDUF ile ilişkilidir ve bu nedenle şu anda lehte değildir). DFD'ler fonksiyonel ayrışma için özellikle yararlıdır. Bir DFD'deki her "kabarcık" istediğiniz ayrıntı düzeyine ulaşıncaya kadar kendi DFD'sine bölünebilir.

Grafik araçları sözde kodlamadan daha iyi olduğunu düşünüyorum, ancak UML sadece bu yöntemlerde kötü birleştiren çok fazla karmaşık.

Biraz daha açık olmak gerekirse: Programlamanın çoğunlukla belirli bir sorunu analiz etmenin, daha küçük bileşenlere ve etkileşimlerine ayırmanın bir yolu olduğunu düşünüyorum. Bu "bir hedef değil, bir yolculuk", sorun hakkındaki bilginizi sürekli olarak geliştirirsiniz, bu nedenle bileşenlerin grafiği değişir: katmanlar görünür ve kaybolur, işlevler ve veri öğeleri yukarı ve aşağı hareket eder, vb.

Bu süreci takip etmenin doğal aracı, mümkün olduğunca basit bir taslak tahtasıdır, ancak hızlı anlaşılmasına yardımcı olmak için yeterince karmaşıktır (aynı renkler, şekiller, aynı mantıksal anlam için oklar). Gümüş mermiyi bulamadım ve belki de bir gün kendim yazacağım, ama şimdi gliffy kullanıyorum ; prezi yakınlaştırma özelliği ile birlikte neredeyse mükemmel olurdu.

Neden yalancı kodlama? Sözde kodlama, henüz fikirlerinizi şekillendirdiğinizde "bileşen grafiğinin serileştirilmiş bir formu" olan uygulamaya yönelik bir adımdır. İyi değil, başınızı sınırlar. Deneyimlerime göre, daha sonra kodlamaya başladım, daha az kod atmam gerektiğini buldum ...

Ama belki de bu atılan tüm kodları yazdığım için, şimdi bunları yazmak zorunda değilim, onlardan kazandığım deneyim sistemi tasarlarken benimle mi? İfadeyi değiştirmek zorundayım.

Grafiğinizle kaybolursanız ve birçok eşdeğer olası çözüm görürseniz, sahte kodlara gidin veya bu kodu sahte nesnelerle yazın - Java'da, bu neredeyse hiçbir fark değildir. Kodu görün, bu bileşenlerin yapısını ve kullanılabilirliğini hissedin, grafiğinizi düzeltmenize ve karar vermenize yardımcı olacaktır. Ama bu SADECE kötü olduğunu düşünüyorsanız bu kodu atmaya hazırsanız çalışır. Bence bu sahte kodun avantajı: Çalışırken saklamak için daha az cazip, ama yapıda yanlış (ve her zaman olduğu gibi, yeterli zamanınız yok). :-)