Bir projeyi nasıl planlamalı ve başlatmalıyım?

Bir projeye her başladığımda, çekirdek sınıfları tamamen değiştirmek ve belirsiz hatalara kapılmak için önemli anlarda karar veririm. Önceden planlama yapmaya çalışıyorum ve genellikle iyi bir ayakla başlıyorum ama sonra başka bir güne gidiyorum ve bunu 'başka bir şekilde' yapmak istediğime karar veriyorum.

Sınıfları haritalamak ve birim testleri ile başlamak gibi bir projeye başlarken standart bir tür var mı? Orta ölçekli bir projeyi planlarken ve başlatırken iyi bir sözleşme nedir?

Son proje başlatılan bir mermi hareket simülatörüdür - biliyorum, tahmin edilebilir.

Planlarken, uygulama hakkında mümkün olan her şeyi önceden planlamayın. Bebek adımlarla planlayın. Uygulamayı kullanmaya başlamak için gereken minimum işlevsellik nedir ? Oradan başlayın.

Projenize başladığınızda, yalnızca mutlak minimum işlevselliği kodlayın. Kod yazarken , akıllı kapsülleme ile iyi ve temiz bir kod yazdığınızdan emin olun . Bu, daha sonra değişiklik yapmaktan kaynaklanan hataları en aza indirir.

Memnun olana kadar bu minimum işlevselliği yineleyin . Ardından, birer birer yeni işlevler ve geliştirmeler eklemeye başlayın. Yine akıllı kapsülleme ile iyi, temiz kod yazmaya odaklanın.

Bebek adımlarında plan yapar ve temiz kod yazarsanız, gerçekten yapmanız gereken değişiklik sayısını en aza indirir. Bu ilk özelliği yazmayı bitirdiğinizde, uygulamanızın temelinin oturacağı kalıpları benimsemiş olmalısınız. Bu temel ile ilgili sorunlar varsa, bir sonraki özellikleriniz sorunu hızla ortaya çıkarmalıdır. Parçanın nasıl birleştiğini görmek daha kolay olacaktır. Yaptığınız değişiklikler bu noktada asgari aksamalara neden olmalıdır.

Planlamanıza yardım etmiyor gibi görünüyor. Bu sürpriz değil çünkü uygulanabilir bir plan yapmak için yeterli deneyime sahip değilsiniz. Çözüm basit. Planlamayı çok bırak. Sadece kodu yazıp kabul edeceğinizi kabul edin. Tamam, çünkü zamanın dışında kod ücretsiz. Bir UI uygulaması yazıyorsanız, boş bir pencereyle başlayın ve bitene kadar her seferinde biraz ekleyin. Daha fazla deneyiminiz olduğunda, projeleriniz daha hızlı ilerleyecektir. Kod değiştirdiğiniz için endişelenmek, pratikte boşa harcanan tüm notlar için endişelenen bir müzik öğrencisi gibidir.

Hiç kimse, belirli bir miktarı kodlayana kadar en iyi tasarımın ne olacağını bilmiyor. Bu nedenle, iyi tasarımın sırrı, ilk taslağınızın kaçınılmaz olarak yetersiz olduğunu kabul etmektir ve ve daha küçük kısımları daha erken ve daha sık yeniden yazmayı . Neredeyse eksiksiz bir programı kazımak yerine, eksiklerini fark ettiğiniz anda satırları veya işlevleri veya sınıfları yeniden yazın.

İyi deneyimli programcılar da genellikle ilk taslakta doğru yapmazlar. Tecrübe ile gelen şey, kötü bir tasarımı daha erken tanıma ve daha hızlı bir şekilde yeniden yazma yeteneğidir.

Benim deneyimime göre, biraz daha deneyiminiz olduğunda bu sorun ortadan kalkar - neyin işe yarayıp neyin yaramadığını hissedersiniz. Buna ek olarak, iyi bir kapsülleme tasarımı değişen tasarım maliyetlerini düşürebilir. Modülleriniz ne kadar sıkıca kapsüllenirse, daha sonra değiştirmek o kadar ucuz olur. Sınıflarınızı ayrı tutmak için mükemmel bir motivasyon olarak düşünün.

http://nathanmarz.com/blog/suffering-oriented-programming.html

Bu sorununuzu giderir. Yazılımın mümkün olduğundan emin olarak, prototip oluşturup oluşturarak başladı. Sonra kodu alıp parçalamaya başlar. Sonra onu optimize eder.

Uygulama tasarlamanın iki yönü vardır. Birincisi, uygulamanızın neler yapabileceğine karar vermektir. İkincisi, nasıl yapılacağını tasarlamak. Yaptığı değişiklikler oldukça önemlidir ve başvurunun olgunluğuna (ve başvurunun yönüne kaymasına) bağlı olarak en iyi şekilde yeniden çalışmak yerine yeniden yazma olarak düşünülür.

İkinci yönü nasıl. Birim testi ve çevik geliştirme uygulamalarını kullanarak, yeniden düzenleme yoluyla belirli bir işlevin nasıl gerçekleştirildiğini değiştirmenin etkisini en aza indirebilirsiniz. Bu tekniklerden nasıl yararlanacağınızı öğrenmenin bir kısmı pratik uygulama pratiğidir.

Tekrar tekrar verdiğim tavsiyeyi vereceğim. Bir evcil hayvan projesi seçin. Yeteneklerinize en iyi şekilde yazın. Yeni bir şeyler öğrenin ve öğrendiklerinizi bu projeyi geliştirme yaklaşımınızı geliştirmek için uygulayın.

Örneğin, bir Yapılacaklar listesiyle başlayın. Basitleştirin ... ilk başta veritabanı depolama konusunda endişelenmeyin. Sadece çalıştır. Şimdi bu temel üzerine inşa etmeye başlayın. Belki MVVM ve WPF öğrenmek istiyorsunuz ... zaten bellek yapılacaklar listesinin nasıl uygulanacağını biliyorsunuz, bu yüzden çözmek için daha az sorun var. Artık birden çok kullanıcının yapılacaklar listelerini bir veritabanından yükleyebileceği bir yer haline getirmek istiyorsunuz. Bellek ve ayrı sunumda çözdünüz, böylece veri erişimini öğrenmeye odaklanabilirsiniz. Buradan uygulamayı daha karmaşık bir etki alanı modeline (örneğin, bir Yapılacaklar listesinden bir proje yönetimi çözümüne geçmek için), bir web arayüzüne, hatta bir mobil cihazda çalıştıracak şekilde genişletebilirsiniz. Bu işi yapmanın anahtarı, ilerlemenizi işaretleyebileceğiniz ve zamanla büyüyebileceğiniz sizin tarafınızdan ulaşılabilecek bir şey seçmektir.

Deneyimlerime göre, sistem tasarımı genellikle gerçek kodlamadan daha uzun veya daha uzun sürer. "Önceden planlama" derken aslında ne planlıyorsunuz? Belki eski okula gidin ve denenmiş ve test edilmiş tasarım yöntemlerinden birini kullanın. Veya eski okula gidin ve gerçek kodu yazmadan önce sözde kodu yazın.

Orijinal plana sadık kalmaktan ziyade neden önemli anlarda bazı şeyleri değiştirdiğinizi kendinize sormanız gerektiğini düşünüyorum. Orijinal plan kusurlu muydu? Yoksa bir şeyler yapmanın daha iyi bir yolunu gösteren anlayışlı bir anınız oldu mu? Aslında daha iyi miydi yoksa sadece farklı mıydı?

Deneyim kazandıkça, daha az sıklıkta yeniden yazmanız / çizmeniz ve baştan başlamanız gerekir. Çözmeye çalıştığınız sorunu yazın. İhtiyacınız olacağını düşündüğünüz belirsiz sınıf tanımlarını yazın, nasıl etkileşim kurmanız gerektiğini yazın. Her şeyin nasıl çalışacağına dair bir fikir edinin ve kodlayın. Sınıflarınızın her bir özelliğini, yöntemini yazmak için tonlarca kez harcamayın. Bu aşamada ne yapmanız gerektiği konusunda 50K ayak görünümü elde etmeye çalışıyorsunuz. Kodlamaya başladıktan sonra daha fazla ayrıntı yazmanız gerekiyorsa bunun için gidin. Değilse sadece kodlamaya başlayın.

Bunu bu kadar zor bulmanızın nedeni bir fikriniz olması, ancak ne yapmasını istediğiniz konusunda tam bir fikriniz yok. Kendi projenizi yapıyorsanız ve size ne istediklerini söyleyecek bir müşteriniz yoksa, kendi müşteriniz olmak size bağlıdır. Kendinizi müşterinin yerine koyun ve imkansız bir istek listesi oluşturmaya başlayın.

Başka bir deyişle, başladığınızda HER ŞEY tasarlamayın !!!.

Sistemin yapmasını istediğiniz şeylerin büyük bir listesine sahip olduğunuzda, her şeye öncelik verin ve temel bir sistemin çalışması için minimum işlevselliğin ne olacağına karar verin. Bu, tek bir temel işlev veya tüm bir ekran olabilir, ancak müşterinin test etmek için yeterince yararlı olacağı için, hissettiğiniz bir şey olması gerekir.

Yani, özellik listesi + temel öncelikler = Gereksinimler .

Tüm bunlara sahip olduğunuzda, çok yüksek seviyeli bir tasarım yapın. Sadece oturun ve sisteminizin ilk birkaç önceliği çalıştırmak için neye ihtiyacı olacağını düşünün. İsterseniz fikrinizi değiştirin, ancak burada nelerin mümkün olduğu hakkında daha fazla bilgi edinmek için bazı kodlara veya bir sistem yapılandırmasına hız vermek isteyebilirsiniz. Temel tasarım fikrinizi doğrulayacak kadar ileri gidin.

Yani: ŞİMDİ tasarımcılarınızın dürtülerini şımartın .

İşiniz bittiğinde, özelliklerinizi uygulamaya başlarsınız. Her özellik için temel bir işlevsel özellik oluşturun. Bu, özellik ifadelerinin toplanması kadar basit olabilir. İsterseniz hikaye kartları. Bu, fikrinizi biraz geliştirmenize ve uygulamanızı test edeceğiniz ve uygulayacağınız şartname haline gelecek bir dizi ifade oluşturmanıza olanak tanır .

Cry Havoc, köpeklerin ... Kod !!

Oradan, testlerinizi özelliklerinize uyacak şekilde uygulayın, ardından her test için kodunuzu yazın. Oluşturun, "serbest bırakın" ve sonra projenin yeterince tamamlanmasına karar verene kadar bir sonraki özellik ile tekrarlayın.

Gerçekten deneyimleniyor, ancak bulduğum bu yaklaşım, çok fazla şey yapmaya çalıştığınız için sonsuz bir erteleme döngüsüne kilitlenmek yerine zihninizi ne yapılması gerektiğine odaklamanıza yardımcı olacak basit bir formül. bir Zamanlar.

Projelerin hedeflerini belirlemek, ihtiyaç listenizi almak ve harici sistemlere herhangi bir arabirimi kilitlemek gibi temelleri yaptıktan sonra.

O zaman her kullanıcı etkileşimi için bir kullanım durumu veya "hikaye" yapmanız gerekir. "İyi" bir kullanım örneği veya hikayesi oluşturan şeyler üzerine ciltler yazılmıştır ve birçok varyasyon vardır. Kullanım örnekleri, karşılaştığım en etkili tasarım aracıdır. Gereksiz gereklilikleri ortadan kaldırırken aynı zamanda eksik işlevsellikleri almaya yardımcı olurlar ve tasarımınızı esaslarına göre düzenlerler. Dediğim gibi metodolojiler değişiklik gösterir ancak uygulayıcıların çoğu aşağıdakileri kabul eder:

• özlü düz İngilizce metin.
• "Hedef Odaklı" en iyi şekilde çalışır "Maymun bir üzüm alır", "Maymun Kırmızı düğmeye basar" dan daha iyidir.
• teknik terimleri yasakla. Hiçbir "açılan", "metin kutuları". İyi bir kullanım durumu herhangi bir arayüz teknolojisinden bağımsız olmalıdır. HTML tabanlı bir sistem için bir kullanım durumu alabilmeli ve bunu, kullanım senaryosunda herhangi bir değişiklik yapmadan sesle etkinleştirilen bir sistem için kullanabilmelisiniz. (bu çok zor ama buna değer!).
• İlk taslağınızın kelime sayısını% 50 azaltmayı, gereksiz adımlardan ve ayrıntılardan kurtulmayı hedefleyin.

Daha sonra ana sınıflarınızı belirtmeye hazırsınız:

UML- Evrensel Modelleme Dili. Sınıf tasarımı için standart araçtır. Her sınıfın herkese açık üyelerini ve yöntemlerini belirtir ve bunları açık ve özlü bir grafik modelde birbirine bağlarsınız.

Dizi diyagramları, veri modelleri ile birlikte, herhangi bir kodlama yapılmadan önce tasarımınızı doğrulayabilir ve geliştirebilirsiniz.

Elde etmek istediğiniz sonuca odaklanın ve yeni uygulamaları öğrenmenin / denemenin potansiyel kazanımlarını, sizi ilk kareye geri götüren bir yola inme riskiyle değiştirin.

Birinci kareye geri dönmeniz durumunda, deneyim kazandığınız için her şey kaybolmaz.

Eğer bir son teslim tarihiniz varsa (belki eğlence için programlamışsınız gibi geliyordu) o zaman bu gerçekten zor. Sürekli bir şekilde giderseniz, zaman geçtikçe eski yöntemleri kullanma riskiniz vardır. Sürekli olarak başka yollara giderseniz, çıktı üretmenin sonuçlarını daha yavaş bir oranda (öğrenme maceralarınızın sonuçlarına bağlı olarak değişken bir şekilde daha düşük bir oranda) riske atarsınız.

İşten alev alıyordum, her yıl hızlıca işler yapıyordum ve bir gün yetenek setimde güncel olmadığımı fark ettim.