Şu anda 5.000'den fazla kod satırına ulaşmak üzere bir proje üzerinde çalışıyorum, ancak tasarımı gerçekten hiç düşünmedim. Kodumu yapılandırmak ve düzenlemek için hangi yöntemleri kullanmalıyım? Kağıt ve kalem? UML diyagramları? Başka bir şey?
Yanıtlar:
Muhtemelen cevaplar kadar farklı görüşe sahip olursunuz. Ama işte benim bakış açım.
Yeni başlayanlar için 5000'den fazla kod satırı çok küçük bir projedir. Şimdi, büyüyen projeler tasarlamaya nasıl gidiyorsunuz? Öncelikle sisteminizi bir kod değil, tasarlarsınız. Kod aslında mimariye ikincil. Minimum akım gereksinimlerini destekleyerek başlayın. Bazı bileşenlerin basit çizimini yapın. Şahsen UML'yi seviyorum, ancak görsel olan her şey iyi olacak. İdeal olarak, burada iyi tasarım uygulamalarına (arayüzler, endişelerin ayrılması vb.) Bağlı kalmak istersiniz.
Tasarımınızda minimum gereksinimleri destekledikten sonra kodlayın. Yine, iyi kodlama uygulamalarına uymaya çalışın.
Bundan sonra, yeni gereksinimler ortaya çıktıkça tekrarlı olarak daha fazla işlevsellik ekleyin. İdeal olarak tasarımınızı da güncellemek istersiniz.
Deneyimlerime dayanarak önemli olan, sisteminizi mevcut olmayan gereksinimleri öngörerek tasarlamamaktır. Aksi takdirde projeniz çok hızlı büyür ve kısa sürede çok karmaşıklaşır. Yine - iyi uygulamalara uyun ve mevcut somut gereksinimlerle başlar.
Akış Diyagramı, Sınıf Diyagramı, Kullanım Durum Diyagramı büyük projeler için olmazsa olmaz diyagramlardır. Hangi harici kütüphanelere ihtiyacınız olduğunu arayın ve seçin ve kullanabileceğiniz benzer açık kaynak kodlarını arayın (geliştirme zamanını öğrenmek ve azaltmak için).
Bir beyaz tahta ve bazı renkli mıknatıslar ve Post-It satın almanızı öneririm. Görevlerinizi tanımlamanıza yardımcı olacaktır.
ps 5000+ kod satırı "büyük" değildir. Bir CMS / Forum yazılımı 5000'den fazla kod satırına sahiptir.
Paket ve sınıf diyagramları oluştururdum. Paket şemasında, sınıfları ve arayüzleri mantıklı bir şekilde gruplandırmak istiyorum. Ayrıca iç paketler vs oluşturmak istiyorum ...
Ama önce programın ne yapması gerektiğini düşünmelisiniz. Usecase diyagramları oluşturabilir veya manuel olarak yapabilirsiniz. Sınıf diyagramı ile manuel olarak yapıyorum çünkü kodu hemen almayı tercih ediyorum ve daha sonra sınıf diyagramlarına takas etmek daha kolay. Sınıf diyagramını kullanmak bana java'mı verir. Eğer beğenmediysem manuel olarak değiştiririm. Yeni kod diyagramlarıma otomatik olarak güncellenir. Kodumun görsel yüksek düzeyde güncellenmiş bir temsili var. Gerçekten yararlı çünkü kodlasam bile projemin grafiksel yoluna bakmak için her zaman birkaç dakika alabilirim. Düzenlemek için doğru paketteki objeleri manuel olarak sürükleyip bırakıyorum. Kodumun daha yüksek düzeyde soyutlama paketi ve sınıf diyagramları kullanarak daha iyi olduğunu düşünüyorum.
(kaynak: ejb3.org )
Meslektaşlarımdan bazıları çalışma şeklimin saçma olduğunu söyledi ... ama hoşuma gitti :-)
Kesinlikle. Bu tür bir şey için kullanmak için küçük bir "tablet" kuru silme kartı var, ama ne olursa olsun rahat kullanın. Önemli olan, düşüncelerinizi kolayca düşürebilmeniz ve her şeyin birbirine nasıl uygun olduğuna dair büyük resmi görebilmenizdir.
Bazı insanlar UML diyagramları gibi daha resmi planları tercih ederler, ancak her yöntemin neye benzemesi gerektiği konusunda mikro yönetime yakalanmanın çok kolay olduğunu hissediyorum. Yine de, rahat ettiğiniz her şeyi kullanın.
EDIT: Okuryazar programlama ile de ilgilenebilirsiniz . Fikir, her şeyi planlayabilmeniz ve yavaş yavaş daha spesifik olmanızdır. Örneğin, programınızın aşağıdakilerden oluştuğunu söyleyebilirsiniz:
Ardından, metni bir resme dönüştürme fikrinizi hassaslaştırabilirsiniz. Yani bu şöyle görünebilir:
O zaman rastgele renkler seçme fikrini geliştirebilirsiniz ve yakında sadece normal kod yazıyorsunuz.
Benim için, yazılım geliştirmenin faaliyeti, belirli bir sorunu çözmek için aşamalı olarak daha ince taneli bir dizi tasarımdır. Ne yaptığınıza dair üst düzey bir fikriniz olduğunda, tasarımınız çok yüksek bir şey olabilir, örneğin "bir SQL veritabanıyla ve birden çok web hizmetiyle konuşan bir web uygulaması olacak" veya bunun gibi bir şey olabilir. Daha sonra, her parçanın detaylarını incelerken tasarımda daha ince taneli olursunuz. Çözümün karmaşıklığına bağlı olarak, tasarım çabasının az ya da çok yinelemesi olacaktır. Son yineleme, tasarımın daha yüksek düzeylerini uygulayan gerçek kodu oluşturmayı içerir.
Benim için, mimari ve tasarım arasındaki fark minimaldir ve bunlar yukarıda tarif ettiğim sürecin sadece farklı iterasyonlarıdır. İkisi arasındaki çizgi bulanık ve farklı insanlar için farklı.
Hangi düzeyde tasarım detayının girileceğine, uygulamanın hangi bölümlerine ve proje yaşam döngüsünün hangi noktalarına gidileceğine karar verme sanatı vardır. Yüksek riskli, yüksek karmaşıklıkta projeler için, bir kod satırı yazmadan önce çok ayrıntılı bir tasarıma sahip olmak isteyebilirsiniz. Daha küçük projeler için, çok az ön tasarım yapmak ve sadece bazı kodları patlatmak ve neyin işe yaramadığını görmek ve bu alanları yeniden tasarlamaktan kurtulabilirsiniz. Burada sadece bir cevap yok. Genellikle bu iki uç arasında bir yerdedir.
Mimariye yaklaşırken kullandığım bazı ilkelerden bahseden bir blog yayınım var. Bu çizgileri düşünürken size yardımcı olabilir. Makalenin bazıları .NET'e özgüdür, ancak çoğu değildir.
Aynı soruyu kendime soruyordum. Şimdi sadece test odaklı geliştirme uyguluyorum ve bunun için endişelenmeyin. Seçilen mimarinin standartlarına uymak dışında kodu hiç "planlamıyorum". Bir projeye başladığımda neye ihtiyaç duyulacağına dair bir fikrim var, ancak geliştirme ilerledikçe açık fikirli olmaya çalışıyorum. Test güdümlü gelişimi takip ederek ve kodu sürekli olarak yeniden düzenleyerek, kodu "planlamak" zorunda değilim. Bir test senaryosunu birbiri ardına tatmin ediyorum ve tasarım yeniden düzenlemeden ortaya çıkıyor. Bu her zaman kodlamadan önce yapabileceğim tüm planlardan daha iyi bir tasarımdır.