Kodlamadan önce anlayış ve tasarım: bu ne kadar doğru? [kapalı]

Okulda ve diğer her yerde iyi kodlamadan önce iyi bir geliştirme metodolojisinin anlayış ve tasarıma ihtiyaç duyduğunu öğrendim.

Bu yeni başlayan bir programcı için bile yeni bir bilgi değil. Ancak, bunun iyi bir tavsiye olup olmadığını merak ediyorum çünkü birkaç programlama dilinde gelişmeye başladığımdan beri, başlangıçtan beri her şeyi tasarlamayı ve tasarlamayı başaramadım.

Yani tasarımı, anlayışı ve programlamayı her zaman erittim. Dünyanın en kötü geliştiricisi miyim, yoksa okulda öğrendiğimiz fikir sadece eski anlamsız bir dini dogma mı?

Daha önce hiç deneyimlemediğimiz ve programlamadığımız bir şeyi nasıl tasarlayabilir ve tasarlayabiliriz? O kadar saçma değil mi? Programlama bunun yerine anlayışı ve tasarımı yönlendirmez mi?

Bence cevap şu olmalı: Mümkün olduğunca plan yapın, ancak bundan fazlasını değil

Planlamanın erdemlerine karşı çok az insan konuşurdu, ancak tartışma çoğunlukla önemli bir konuya bakmaktadır. Planlama, sadece iyi bir plan yapma yeteneğiniz olduğu sürece çalışır, bu beceri deneyim ile birlikte gelir. Çok fazla deneyiminiz yoksa, oluşturduğunuz herhangi bir plan muhtemelen makul miktarda sorun yaşayacaktır, bu, toplam bir felaket olmayan bir ürün yapmak için, planın geliştirme sırasında yoğun bir şekilde revize edilmesi gerektiği anlamına gelir. plan ayrıntılıysa, bu muhtemelen birçok ayrıntıyı geçersiz kılacaktır veya daha da kötüsü, planı takip edebilmek için düzenlemeleri minimumda tutmaya çalışacaksınız.

Bazı şeyler kesinlikle planlama gerektirir ve gerekli plan seviyesini yapma yeteneğiniz yoksa, hayal edebileceğim tek yol prototipleme, sadece yeterli bir plan yapmak için gerekli görevle ilgili deneyimi kazanmak için kod yazmaktır. .

Üretim kodunu yazmaya hazır olun ya da olmayın, maksimum planlama seviyenize ulaştıktan sonra kodlamaktan başka yapacak bir şey kalmaz. Belki bir felaket olacak, ama bunlar iyi öğrenme deneyimleri ve gözden geçirilmiş bir plan yapmak için çok daha donanımlı olacaksınız.

Kesinlikle doğrudur. Gereklilik ne kadar büyük ve karmaşık olursa, bu o kadar doğrudur.

Küçük bir konsol uygulamasının Fibonacci sekansını hesaplaması için, algoritmanın ve kullanıcı arayüzünün nasıl yapılandırılacağı hakkında birkaç dakikadan fazla düşünmenize gerek olmayabilir (evet, sadece stdin ve stdout olabilir).

Peki, küresel olarak dağıtılan ve 99.9999 çalışma süresi ve% 100 doğruluk gerektiren milyonlarca işlemin saniyede milyonlarca işlem yapması bekleniyor. Sadece kodlamaya atlar mısın?

Bu iki uç arasında başka seçenekler de var.

Euler projesine bir göz atın . Sunulan sırayla bazı sorunları çözün. Bazı problemleri makul bir sürede çözmek için, koda girmeden önce düşünmeniz gerektiğini öğreneceksiniz.

Kodlamaya başlamadan önce programınızı düşünmek ve tasarlamak için zaman ayırmanız gerekmiyorsa, önemsiz şeyler üzerinde çalışıyorsunuz veya daha büyük bir şeyi kaçırıyorsunuz.

Başından beri her şeyi tasarlamayı ve tasarlamayı başaramadım

Hiç kimse en önemsiz sorunlardan başka bir şey yapmaz. Yine, proje ne kadar büyük ve karmaşıksa, bu o kadar doğru - tasarımların hataları olacak, gözden kaçan şeyler vb.

Sanat, büyük parçaların uygun olup olmadığını görmek için önce yüksek seviyede tasarım yapıyor. Sonra önceliklerin bir listesini alın - önce en önemli / altyapı üzerinde çalışmaya başlayın. Sonra gidip daha büyük parçaları daha küçük parçalara ayırırız, her büyük parçanın mantıklı olan parçalardan oluştuğundan emin oluruz.

Bu zaman ve çaba gerektirir - ve başlangıçta tam veya tam doğru olmayabilir.

Denir sebebi budur yumuşak eşyalar ve değil sert -Ware. Dövülebilir ve değiştirilebilir.

Okulda ve diğer her yerde iyi kodlamadan önce iyi bir geliştirme metodolojisinin anlayış ve tasarıma ihtiyaç duyduğunu öğrendim.

Bu doğru.

Ancak, bunun iyi bir tavsiye olup olmadığını merak ediyorum çünkü birkaç programlama dilinde gelişmeye başladığımdan beri, başlangıçtan beri her şeyi tasarlamayı ve tasarlamayı başaramadım .

Ve senin sorunun var.

Önemsiz sorunların çoğunda, işlerin nasıl işleyeceğini - işlerin nasıl birbirine uyacağını anlamak için biraz düşünmeniz gerekir. Paradoksal olarak, önemsiz olmayan çoğu sorun için, her şeyi planlayabilmenin hiçbir yolu yoktur . Hesabınız için bilinmeyen çok fazla şey var, geliştirme sırasında gerçekleşecek çok fazla değişiklik var. Agile, çekişmeyi elde etti çünkü anlaşmanın bu ikinci yarısını kabul ediyor: insanlar her şeyi bilen değil ve değişim sürekli.

Bu nedenle, önceden tasarım yapmanız gerektiği kesinlikle doğrudur, ancak aynı zamanda yalnızca önceden tasarlamanın imkansız olduğu da doğrudur .

Kodlamadan önce mutlaka bir tasarıma sahip olmalısınız .

Nedeni oldukça açıktır - herhangi bir tasarımınız yoksa , ne yaptığınızı bilmiyorsunuzdur .

Tasarım tamamlanmadan önce mutlaka bazı kodlara sahip olmalısınız .

Nedeni oldukça açıktır - tasarım değişecek ve tasarımın parçalarını geliştirmek, çözüm üzerinde çalışmaya başlamadan tahmin edilmesi zor soruları, fırsatları ve zorlukları ortaya çıkaracaktır.

Geliştirme yinelemelidir.

İster planlı olsun ister olmasın, ekibin fark edip etmediği, her yazılım projesi yinelemeli olarak yapılır - işin bir kısmı tamamlanır ve değerlendirilir ve değerlendirme, işin geri kalanının nasıl yapıldığına dair değişikliklere yol açar.

Birden fazla yaklaşım deneyin.

Ön tasarımı kod oluşturmaya karşı dengelemenin en iyi yolunu bilmek pratik ve deneyim gerektirir. Neredeyse hiç kimsenin hakim olmadığı ve her projenin farklı idealleri olacağı bir beceridir (büyük bir video oyunu gibi büyük, tek sürümlü bir ürün yaratan bir takıma karşı kendi kullanımınız için küçük bir araç tasarlamayı düşünün).

Başkalarının geçmişte birden çok sistem tasarladığını ve gözlemlediğini gördüm ve sürecin birçok farklı şekilde geliştiğini gördüm, ancak ortak bulduğum şey, başlangıç ​​mimarisinin en azından büyük özelliklerin varlığını planlaması gerektiğidir .

Örneğin, bina, zemin, oda vb. Kavramların bunlarla sonradan donatılmadığı bir HVAC kontrol sistemi gördüm ve sonuç geldikleri kadar çirkindi. Ya da (akıllı olmayan) cep saatiniz için daha uygun bileşenlerden yapılmış bir mobil müzik cihazı. Her iki durumda da nihai ürünlerin müşterilerin favorisi olmadığını söylemeye gerek yok.

"Anlayış" dediğinizde bu "fikir" den sadece bir adım ötede ve bir kavram çok bulanık olabilir. İş dünyası genellikle kavramları önemsiyor. Müşteriler genellikle UX'i önemser - kullanımı kolay ve hoş bir şekilde gerçeğe getirilen ve kullanımı sayesinde bir miktar değer getiren bir kavram.

Herhangi bir programlama önce "kavram" yapmak zorunda, kendimi nereye gider görmek için görsel stüdyo (veya seçtiğiniz IDE) açılış ve rastgele yazma, hayal edemem.

Kodlamadan önce tam bir tasarım yapamayabilirsiniz (ve yapmamalısınız), ancak kullanıcının iş akışının ne olacağına dair kaba bir taslak olmalıdır.

UX tasarımı ve kodlaması birbirini sık sık besler, muhtemelen bu gerçeği işe yaklaşma biçiminize dahil etmenin bir yolu olarak en küçük projeler dışında herhangi bir şey için bazı Çevik bir yaklaşım kullanmak zorunda kalacaksınız. Bu yüzden, hepsini bir anda göremiyorsanız programcıların en kötüsü olduğunuzu düşünmeyin - kimse yapamaz ve yapabileceğini düşünen insanlar, problemi yeterince görmezden gelen kişilerdir, böylece eksiksiz olduklarını iddia edebilirler resim.

Büyük bir şey için bir boyut koymak için bir örnek. Konsept: "İşletmelerin yazılım platformlarını entegre etmelerine olanak tanıyan görsel bir bulut tabanlı araç oluşturun". Bu harika görünüyor ve pazarlama materyali yazmaya başlayabilir ve orada olmadan önce satabilir. Kodlamadan önce buna sahip olmalısınız.

Ön tasarım: "Mantığı tanımlamak için Visio'daki gibi şekiller ve oklar var; çeşitli platformlara (SAP, SF, veritabanları ...) bağlantılara izin veren eklenti özelliklerine sahip; sistemi görsel olarak tanımlamak ve bir formatı diğerine dönüştürmek için bir yola sahiptir. Başka bir büyük pazarlama blob. Ayrıca, kodlamadan önce neyin önemli olduğu, böyle kaba bir taslağa sahip olması gerektiği hakkında bazı fikirler verir.

Tasarım / Kod: "Bu tür ve benzeri özelliklere sahip bir tarayıcı barındırılan HTML tasarımcısı bulundurun; Java'yı arka uçta mevcut herhangi bir sunucuda çalışabilmesi için kodlayın; veri yapılarını ve gerektiğinde sorgulamak veya değiştirmek için UX tanımlayın; olağanüstü durum kurtarma planı, hata raporlama, denetim günlüğü; plan sürümü kontrolü; plan erişim kontrolü; .... "- liste ne kadar ince olursa, hepsini öngörmek o kadar gerçekçi olmaz.

... şeyler nelerdir ancak bir en az bilmelidir olabilir benzeyen sonunda kabaca veya başka büyük sondaj kavramını öldürmüş sonu bazı gerçekten işe yaramaz uygulamaları ile sona erebilir son ürün - söylemek görsel tasarımcı 40" gerektirir herhangi bir gerçek dünya iş akışını göstermek için ekranı veya günlükteki 20 alandan biriyle sınırlı tam bir dize eşleşmesi dışında günlükleri aramanın bir yolu yoktur. Bunun, uygulamanızı yürütmekten başka olmasını önlemek için iyi bir yol yoktur. - bazıları başarılı olacak, diğerleri başarısız olacak.

Her zaman aşağıdaki gibi ayırıyorum:

1. 1/3 Tasarım
2. 1/3 Geliştirme
3. 1/3 Test

Tasarım: Sadece görsel değil, aynı zamanda kavramsal. Görsel ve mantıkla parçalara ayırın. Yeniden kullanılan ve kendi içinde bir tasarım deseni olan ortaklıkları arayın.

Geliştirme: Parçalarınızı öğrendikten sonra kodlayın. Sonra onları entegre edersiniz.

Test: Sadece kodun düzgün bir şekilde entegre edildiğini ve yazıldığını test etmekle kalmaz, sürekli olarak tespit edilen ve öğrenilen dersler olacak ve etkileşim için yeni yollar yaratacak, yeni yetenekler tasarlanacak ve istenecek. Kapsam sürünmesine dikkat edin.

Bu hususlara ek olarak, bir projenin de bu aşamaların üstünde 3 aşaması olduğunu unutmayın.

1. Düşük mühendislik ilk denemesi
2. 1. denemeden çıkarılan derslerden aşırı tasarlanmış ikinci deneme.
3. Uygun şekilde tasarlanmış 3. deneme.

Tasarım aşamasını ne kadar iyi yaparsanız, ek girişimleri en aza indirdiğini gördüm. Her şeyi yeniden yapmak yerine, yeniden işlenen bir alt sisteminiz olabilir.

Şirket içi, dış kaynaklı ve açık deniz geliştirme projeleri için yazılım geliştirici ve yazılım geliştirme yöneticisiyim.

Burada temel bir yanlış varsayım var. Önce kod yazmadan asla iyi bir tasarım bulamazsınız (okul size bunu asla öğretmeyecektir). Yine de okul, tasarım olmadan iyi bir kod alamayacağınız konusunda haklı.

Çözüm şudur:

1. Sorunu çözebileceğini düşündüğünüz bazı kodları yazın.
2. Koddan öğrendiklerinizi temel alan bir tasarım geliştirin.
3. Tüm kodu atın ve tasarıma göre sıfırdan yeniden yazın.
4. Gerektiği kadar tekrarlayın.

Tüm kodu atmadan olduğunu değil bu süreçte isteğe bağlı bir adımdır, ama küçük projeler için resmen olabilir tasarım kadar yazma. Büyük projeler için, " tüm kodu atma " adımını tekrarlama olasılığınız daha yüksektir, ancak yeterli modülerliğe sahipseniz, bu yalnızca kod tabanının bir kısmı için geçerli olabilir.

Çok fazla proje eski kod üzerinde duruyor çünkü onu değiştirmek istemiyorlar - ya da çok karmaşıklar, çünkü asla atılmak üzere tasarlanmamıştı . İlk denemenizin başarısız olacağını kabul etmek hayatınızı daha iyi hale getirecektir.

anlayışı her zaman değiştirilebilir anahtar tasarım programlama tamamen tasarlanmış app gereksinimlerini karşılamak zorunda kalacak.

1. nokta nedir, 2. nasıl erişilmesi gerekiyor, 3. kullanıcı kimdir, 4. işin tam bir SOW kapsamını belirli uygulamalarla tanımlamak tüm bu uygulamanın yapmak olduğunu. ve eklediğiniz her işlevin nasıl çalışacağı.

web uygulamanızın mimarisi ile ilgili herhangi bir seçim yapılmadan önce, tamamen planlayın ve düşünün.

sonra en iyi yığını seç

Ben bir LAMP geliştiricisiyim

Bu yüzden hangi php framework kullanacağım soruyu daraltmaya eğilimliyim. ve ön uç komut dosyaları, ideal bir şekilde yapmak için ihtiyacım olan her şeyi yapmam gerekecek

bunu eklemek için MVC çerçevelerini kullanmayı öğrenin, ZEND ve CAKEPHP en hızlı geliştirme çerçeveleri (PHP)