1 yıllık deneyime sahip bir programcıyım, son zamanlarda nadiren doğru bir projeye başladığımı fark ettim (yan projemin çoğu), normalde proje döngüsü böyle devam eder

1. Birkaç kullanım durumuyla başlayın
2. Kodlamaya başla
3. İyi işlemediğim ve şu anki kod tabanına uymadığı birkaç şeyi fark et.
4. Kodun çoğunu yeniden yaz

ve bu birkaç kez gidebilir

Yani benim sorularım

1. Bu tür bir uygulama yaygın mı, yoksa yetkin olmadığım anlamına mı geliyor?
2. Kendimi bu konuda nasıl geliştirebilirim?

Tarif ettiğiniz döngü normal. Bir şeyleri iyileştirmenin yolu bu döngüyü önlemek değil, düzene sokmaktır. İlk adım şunu kabul etmektir:

1. Bir projenin ilk gününde her şeyi bilmek neredeyse imkansız .
2. Her şeyi bir şekilde biliyor olsanız bile, projeyi bitirdiğiniz zaman bir şey (müşterinin gereksinimleri, içinde bulundukları pazar, çalıştığınız teknoloji, müşterilerin istekleri) değişmiş ve geçersiz veya yanlış bildiğiniz şeylerin en az bir kısmı.

Bu nedenle, her şeyi önceden planlamak imkansızdır, ve yapabilseniz bile, bu planı takip etmek sizi kusurlu veya eski bir şey inşa etmeye yönlendirecektir. Bunu bilerek, değişimi planımıza dahil ediyoruz. Adımlarına bakalım:

1. Birkaç kullanım durumuyla başlayın
2. Kodlamaya başla
3. İyi işlemediğim ve şu anki kod tabanına uymadığı birkaç şeyi fark et.
4. Kodun çoğunu yeniden yaz

Bu aslında harika bir başlangıç ​​noktası. İşte nasıl yaklaşırım:

1. Birkaç kullanım durumuyla başlayın

İyi. "Kullanım durumları" derken, yazılımın ne olduğunu odaklanıyoruz için . "Birkaç" diyerek her şeyi keşfetmeye çalışmıyorsunuz; Yönetilebilir bir iş miktarına bağlı kalıyorsunuz. Buraya ekleyeceğim tek şey onları önceliklendirmek. Müşteriniz veya son kullanıcıyla, bu sorunun cevabını hesaplayın:

Durumunuzu iyileştirecek, size verebileceğim en küçük ve en basit yazılım nedir?

Bu, asgari uygulanabilir ürününüzdür - bundan daha küçük herhangi bir şey, kullanıcı için yararlı değildir, ancak çok daha büyük bir risk çok yakında çok fazla planlama yapar. Bunu oluşturmak için yeterli bilgi edinin, sonra devam edin. Bu noktada her şeyi bilemeyeceğinize dikkat edin.

2. Kodlamaya başlayın.

Harika. En kısa sürede çalışıyorsun. Kod yazana kadar, müşterilerinize sıfır avantaj elde edilmiştir. Planlamayı ne kadar çok zaman harcarsanız, müşteri geri ödemesiz beklemeye devam eder.

Burada iyi kod yazmak için bir hatırlatıcı eklerdim . SOLID Prensiplerini hatırlayın ve uygulayın , kırılgan veya karmaşık herhangi bir şeyin etrafına iyi birim testleri yazın, unutabileceğiniz veya daha sonra sorunlara neden olabilecek herhangi bir şey hakkında not alın. Kodunuzu, değişikliklerin soruna neden olmayacak şekilde yapılandırmak istiyorsunuz. Bunu yapmak için, her zaman bir şeyler inşa etmek bir karar bu yolu yerine o mümkün olduğunca az kod bu karardan etkilenecek şekilde siz kodunuzu yapılandırırken, yol. Genel olarak, bunu yapmanın iyi bir yolu kodunuzu ayırmaktır:

• Basit, ayrık bileşenler kullanın (dilinize ve durumunuza bağlı olarak, bu bileşen bir işlev, bir sınıf, bir montaj, bir modül, bir servis, vb. olabilir. çok işlevli bir sınıf veya çok sayıda sınıf içeren bir derleme.)
• her bileşen bir işi veya bir şeye ilişkin işleri yapar
• Bir bileşenin iç işleyişini yapma şeklindeki değişiklikler diğer bileşenlerin değişmesine neden olmamalıdır
• bileşenler edilmelidir verilen kullandıkları veya yerine bağlıdır şeyler getirme veya oluşturarak bunları
• bileşenler gerekir vermek diğer bileşenlere bilgileri ve yerine, işi yapmak için onlara sormak getirilirken bilgileri ve işi kendileri yapıyor
• bileşenler, diğer bileşenlerin iç çalışmalarına erişmemeli, kullanmamalı veya kullanımına bağlı olmamalıdır - yalnızca halka açık fonksiyonlarını kullanın.

Bunu yaparak, bir değişimin etkilerini izole edersiniz, böylece çoğu durumda bir sorunu bir yerde çözebilirsiniz ve kodunuzun geri kalanı fark etmez.

3. Tasarımda karşılaşılan sorunlar veya eksiklikler.

Bu olacak. Kaçınılmaz. Bunu kabul et. Bu sorunlardan birine çarptığınızda, bunun ne tür bir sorun olduğuna karar verin.

Bazı sorunlar, kodunuzda veya tasarımınızda yazılımın yapması gerekeni zorlaştıran konulardır. Bu problemler için geri dönüp sorunu çözmek için tasarımınızı değiştirmeniz gerekir.

Bazı sorunlara, yeterli bilgiye sahip olmamadan veya daha önce düşünmediğiniz bir şeyden kaynaklanır. Bu problemler için, kullanıcı veya müşterinize geri dönmeniz ve bu sorunu nasıl ele almak istediklerini sormanız gerekir. Cevabınız olduğunda, git ve onu ele almak için tasarımınızı güncelleyin.

Her iki durumda da, kodunuzun hangi bölümlerinin değişmesi gerektiğine dikkat etmelisiniz ve daha fazla kod yazarken, gelecekte hangi bölümlerin değişmesi gerektiğini düşünmelisiniz. Bu, hangi parçaların birbirleriyle çok fazla bağlantılı olabileceğini ve hangi parçaların daha fazla izole edilmesinin gerekebileceğini hesaplamayı kolaylaştırır.

4. Kodun bir kısmını yeniden yazın

Kodu nasıl değiştirmeniz gerektiğini belirledikten sonra, gidip değişikliği yapabilirsiniz. Kodunuzu iyi yapılandırdıysanız, bu genellikle yalnızca bir bileşenin değiştirilmesini içerir, ancak bazı durumlarda bazı bileşenler eklemeyi de içerebilir. Birçok yerde birçok şeyi değiştirmek zorunda kaldığınızı tespit ederseniz, bunun neden olduğunu düşünün. Tüm bu kodu kendi içinde tutan ve sonra da tüm bu yerlerin bu bileşeni kullanmasını sağlayan bir bileşen ekler misiniz? Yapabilir, yapabilir ve bir dahaki sefere bu özelliği değiştirmek zorunda kalırsanız, tek bir yerde yapabilirsiniz.

5. Test

Yazılımdaki sorunların yaygın bir nedeni, gereklilikleri yeterince iyi bilmemektir. Bu genellikle geliştiricilerin hatası değildir - çoğu zaman kullanıcı da neye ihtiyaç duyduklarından emin değildir. Bunu çözmenin en kolay yolu soruyu tersine çevirmektir. Her ne zaman bu adımlardan geçiyorsanız, kullanıcıya şu ana kadar ne inşa ettiğinizi verin ve onlara “Bunu yaptım - ihtiyacınız olanı yapar mı?” Sorusunu sormak yerine, “yazılıma ne yapmanız gerekiyor?” Evet derlerse, sorununu çözen bir şey yaptınız ve çalışmayı bırakabilirsiniz! Hayır diyorlarsa, o zaman size yazılımınızda neyin yanlış olduğunu daha belirli terimlerle anlatabileceklerdir ve o özel şeyi geliştirebilir ve daha fazla geri bildirim için geri dönebilirsiniz.

6. Öğrenin

Bu döngüden geçerken bulduğunuz sorunlara ve yaptığınız değişikliklere dikkat edin. Desenler var mı? Geliştirebilir misin

Bazı örnekler:

• Belirli bir kullanıcının bakış açısını gözden kaçırdığınızı bulmaya devam ederseniz, bu kullanıcının tasarım aşamasına daha fazla dahil olmasını sağlayabilir misiniz?
• Bir teknolojiyle uyumlu olacak şeyleri değiştirmek zorunda kalırsanız, kodunuzla o teknoloji arasında arayüz oluşturacak bir şey oluşturabilir misiniz?
• Kullanıcı, UI'daki kelimeler, renkler, resimler veya diğer şeyler hakkındaki fikrini değiştirmeye devam ederse, uygulamanın geri kalanına hepsini bir arada olacaklarını sağlayan bir bileşen oluşturabilir misiniz?
• Değişikliklerinizin çoğunun aynı bileşende olduğunu tespit ederseniz, o bileşenin yalnızca bir işe yapıştığından emin misiniz? Birkaç küçük parçaya bölebilir misiniz? Bu bileşeni, başkalarına dokunmadan değiştirebilir misiniz?

Çevik ol

Buraya doğru hareket ettiğiniz, Çevik olarak bilinen bir çalışma tarzı. Çevik bir metodoloji değil, bir sürü şeyi içeren bir metodoloji ailesidir (Scrum, XP, Kanban, birkaç isim) ama hepsinde ortak olan şey şeylerin değiştiği ve yazılım geliştiriciler olarak ortak olduğumuzdur. bunlardan kaçınmak veya görmezden gelmek yerine değişikliklere uyum sağlamayı planlamalıdır. Temel ilkelerinden bazıları - özellikle de durumunuzla ilgili olanlar - aşağıdaki gibidir:

• Güvenle tahmin edebileceğinizden daha ileride planlama yapmayın
• İşlerin ilerledikçe değişmesi için ödenek verin
• Bir seferde büyük bir şey inşa etmek yerine, küçük bir şey inşa etmek ve ardından adım adım iyileştirmek
• Son kullanıcının sürece dahil olmasını sağlayın ve düzenli ve düzenli geri bildirim alın
• Kendi çalışmanızı ve ilerlemenizi inceleyin ve hatalarınızdan ders alın

Bu normal.

İki yaklaşımdan birini alabilirsiniz:

1. Hoşgeldin Değişimi

Yanlış anlayacağınızı varsayarsanız, değişime açık bir kod tabanı oluşturmalısınız. Çoğunlukla bu, bir kitabın sonunda yeniden düzenleme ile ilgili kodu almayı ve kodunuzu baştan bu şekilde oluşturmayı içerir (ayrıştırılabilirlik, iyi test kapsamı, ...).

2. Değişimden Kaçının

Bu durumda bir BDUF (öndeki büyük tasarım) yapmanız gerekir. Çok sayıda kağıt prototipleme yapmak, potansiyel kullanıcılarla veya kendinizle lastik ördek avı ile görüşmek, prototiplerde veya maketlerde çeşitli şeyler denemek, tam bir şartname yazmak ve sadece bir kez çözdüğünüzü hissettikten sonra nihayet kodlamaya başlayabilir. Aslında beklenmedik değişikliklerden kurtulmayan her şeyi yapmak, ilk yılı ya da öylesine biraz azaltır. Bu yüzden, hala değişmesi kolay olması için kodunuzu oluşturmanız gerekir.

Yani, temel olarak, değişim bir verilir. Bunun olacağını varsayalım. Kodunuzu buna göre oluşturun. Uygulamada, analiz felsefesinde sıkıntı yaşamadan kaba değişikliklerden kaçınan ön tasarım ve tam başlangıç ​​kodlama yaklaşımları arasında bir orta yol bulabilirsiniz. Sadece biraz tecrübe ister.

Yazılım geliştirme, doğal olarak "kötü" bir dizi sorun olarak tanımlanmıştır .

Horst Rittel ve Melvin Webber, "kötü" bir sorunu yalnızca çözerek ya da bir kısmını çözerek açıkça tanımlanabilecek bir sorun olarak tanımladılar *. Bu paradoks, temel olarak, sorunu net bir şekilde tanımlamak için sorunu bir kez "çözmek" ve sonra çalışan bir çözüm oluşturmak için tekrar çözmek zorunda olduğunuz anlamına gelir. Bu süreç yıllardır yazılım geliştirmede annelik ve elmalı turta olmuştur.

Bu, karşılaştığınız sorunu mükemmel şekilde açıklar. Temel olarak, yaptığımız şey zor . "Rutin" olarak tanımlanabilecek bir parça varsa, zamanla onu izole edip otomatik hale getiririz. Yani geriye kalan tek şey ya yeni ya da zor.

Bu gibi sorunların üstesinden gelmenin başka yolları da var; Bazı insanlar sorunları önceden düşünerek çok fazla zaman harcıyor ve tasarım konusunda rahat olana kadar kod yazmıyor. Diğerleri, halihazırda bu gibi konularla uğraşan insanlardan, çift programlama yoluyla veya bunun gibi siteler aracılığıyla rehberlik istemektedir.

Ama kesinlikle senin yaklaşımın yetersizlik önermiyor. Tek sorun, geri döndüğünüzde, başlangıçta neden bu şekilde bir şeyler yapmayı seçtiğinizi ve “daha ​​iyi” bir yolu görmeden görüp görmediğinizi düşünmüyorsanız olabilir. yeniden yazmak.

Pek çok durumda, vardı ve bir dahaki sefere tasarım sürecinize dahil edebilirsiniz. Bazı durumlarda, (ya da maliyet, diğer yaklaşımınızın maliyetinden daha yüksek ya da daha yüksek olurdu) olmadı ve endişenizi giderebilirsiniz.

1. Evet, belki de " kodun çoğunu yeniden yaz " bölümü hariç, genel bir durumdur . Tüm gereklilikleri hiçbir zaman baştan itibaren asla alamayacaksınız, bu nedenle değişimle başa çıkmak önemlidir. “Kod muhafaza edilebilirliği” kavramının konusu budur. Tabii ki aynı zamanda gereksinimleri ve doğru tasarımı elde etmek için biraz daha zaman harcamak için yardımcı olur.
2. İlk olarak, geçmiş projelerde hangi değişikliklerin gerekli olduğunu ve bunları daha önce nasıl öngörebildiğinizi veya daha iyi hazırlayabileceğinizi düşünün. Bir projenin başlangıcında, kullanım durumlarının detayları hakkında daha fazla düşünün. Uygulamaya başlamadan önce bazı soyut tasarımları yapın (kodun ana bileşenleri nelerdir ve nasıl iletişim kurarlar, API'ları nelerdir). En önemlisi, kodu olabildiğince basit ve kolay tutmaya çalışın, SOLID, DRY, KISS ve YAGNI gibi kavramları okuyun.

Bu tür bir uygulama yaygın mı, yoksa yetkin olmadığım anlamına mı geliyor?

Bunlar birbirini dışlayan değil. Desen ortak olabilir ve hala yetersiz olabilir. Yetkinliğiniz, performansınızı hedeflerinize göre ölçerek belirlenebilir. Hedeflerine ulaşıyor musun?

Bu model ortak mı? Ne yazık ki evet. Pek çok insan hangi problemi çözdükleri, doğru bir çözümü nasıl oluşturacakları ve hangi ölçümlerin başarı oluşturacağı konusunda net bir fikre sahip olmayan projelere dalarlar.

Kendimi bu konuda nasıl geliştirebilirim?

Bir yere gitmeye karar verdiysen ve daha yeni yürümeye başladıysan, ve yapman gereken tek şey, Cape Town'dan New York'a bir fil nakletmek olduğunu, yürüyüşünü harcadığın zamanın tamamen boşa gitmesiydi. Yapmaya başlamadan önce ne yaptığınızı öğrenin.

Bunu yapmaya başladığınızda, aşağıdakileri göz önünde bulundurun: yeniden yazmak zorunda olmayan kodun neye benzediği? Bu kod:

• Yararlı bir şey yapar.
• Doğru mu.
• Yeterli performans ile yapar.

Yani: bu kodun ne kadar yararlı bir şey yaptığını ne kadar çok kod yazarsanız, doğru, iyi performansla, o kadar az kod yazmanız gerekecek.

Daha iyi bir çalışma yönteminden çok uzakta olmadığınızı ve bu gemide tek kişi olmadığınızı söylemenin güvenli olduğunu düşünüyorum.

Ne kaçırdığını düşünüyorum belirlemek rağmen, yani neyi istediğiniz, sizin için aynı işlemi yapmak bitmiyor nasıl bunu yapacağız.

Genel olarak problemin nasıl çözüleceği üzerine durmanın ve düşünmenin adımına tasarım denir, onun üzerinde sistemin yapısını veya mimarisini geliştirmek için biraz zaman harcamanızı sağlayan adımdır, böylece onlardan yaptığınız her şey nihai çözüme katkıda bulunur. kenarları çözdükten sonra parçaları bir bilmecenin içine yerleştirmek.

Birçok insan bu adımı atmaz, ancak kodlamaya başladığımda zorunludu. Farkın geliştirme araçlarında olduğunu düşünüyorum - bir metin editörüyle başladığımda, şimdi atlamanıza ve yazmanıza olanak sağlayan her türlü özelliğe sahipsiniz.

Bu nedenle, geniş alanları, bileşenleri ve bunlar arasındaki birlikte işlerliği anlamak ve kodlamaya başlamadan önce çözümünüzü oluşturacak nesneleri tanımlamak için biraz zaman ayırın. Büyük ayrıntılara sahip olmak zorunda değildir ve başlangıçta tam olarak doğru yapamayacağınızı anlayın, bu nedenle zamanla gelişecektir, ancak bunun yapılması gereken şeyleri gözden geçirme çabalarını boşa harcamanızı engellemeye yardımcı olmaktır. fazla değişmesine gerek yok.

Zaten bazı büyük cevaplarınız var ancak sorunuz, dokunmaya çalışacağımı düşündüğüm aklıma birkaç şey getiriyor.

1. Yolun aşağısındaki değişikliklerle karşılaşırken, projenizi nasıl etkilediğini ve tasarım / kodlama seçenekleriyle etkiyi nasıl en aza indirmiş olabileceğinizi düşünürken aynı zamanda insanların çoğu zaman geç değişiklik yaptıkları zihinsel bir harita oluşturmayı düşünmenizi öneririm. Tecrübeyle, önemli olacağını bildiğiniz şeyler için bir esneklik öngörebilir ve kodlayabilirsiniz - ancak sektörde bu kavramla ilgili bir anlaşmazlık olsa da, bazılarının özellikle talep edilmemiş bir alanda çaba harcamaya karşı çıkacağınız için .

2. Testlerden biri, proje paydaşınız için bir prototip hazırlamak, gereksinimleri geliştirmek için harika bir yol olabilir. Bununla birlikte, geliştirme sırasında, kodunuzda çok fazla karışıklık veya karmaşıklığa neden olmadan ne olduğunu “görmenin” yollarını arayabilirsiniz. Kesinlikle yardımcı olacak araçlar var ama eğer istersen onlarsız da çok şey yapabilirsin. Her iki durumda da, eleştirel bir gözle neler olup bittiğine bakmak için koddan çıkmanız çeşitli bilgiler sağlayabilir.

3. Ortak aktiviteler için arayın. Kendinizi aynı sorunları tekrar tekrar ele alarak bulacaksınız. Bir süre sonra, çeşitli seçeneklerin eksikliklerini veya takaslarını keşfetmeniz ve bunlardan kaçınmanıza yardımcı olacak bir metodoloji üzerine sıfır yapmanız gerekir. Elbette, eğer bir çerçevede çalışıyorsanız, bu sorunlardan bazıları halihazırda kullandığınız araçlara sarılabilir.

4. Bir çerçeve içinde çalışıyorsanız, zamanınızı harcarsanız, işleri baştan baştan nasıl yapacağınızı düşünmek için harcarsanız. Örneğin, kolayca bir istek mesajı toplayabilir, bir soket açabilir ve manuel olarak bir GET veya POST isteği yayınlayabilirsiniz. Dilerseniz XML mesajlarını elle ayrıştırabilirsiniz. Ne yaparsanız yapın, ürettiğiniz sorular ve bulduğunuz cevaplar yeteneklerinizi geliştirecektir. Elbette, hangi altta yatan sorunların önemli ya da ilgi çekici olduğunu seçersiniz. Bu kişisel gelişmeyi düşünürdüm ve burada çok fazla zaman harcamayı beklemiyordum.

5. Gümüş mermiler, metodolojiler ve yüksek vızıltı faktörü sorunları her yerde. Temel olarak, bilgi ile çalışmanın altında yatan gerçekler o kadar hızlı değişmiyor. Yerinde çerçeve, araç seti veya metodolojinin bir yardım mı yoksa çeşitli durumlarda bir engel mi olduğunu not edin. Büyük şirketlerde, şirket onları etkili bir şekilde uygulayamasa da, pek çok yöntem denemesinde bulundum. Tıpkı çerçeveler gibi, metodolojiler bazı yüksek fonksiyonel ekiplerin uygulamalarına dayansalar bile yüksek düzeyde işlev görmenin güvenli bir yolu değildir.

Deneyimi azaltmak ve erişilebilir kılmak zor. Sanırım bütün bunları koymak için kısa bir yol gözlerinizi açık tutmak, gördüklerinizi düşünmek ve öğrenmeyi asla bırakmamak.

Birkaç işaretçi eklemek istiyorum

1) Ben şahsen görselleştirme ile başlamak için inanılmaz yararlı buldum . Kutular, oklar, çizgiler çizin ... Kullandığınız modellik diline aldırma. İlk etapta KENDİNİZ İÇİN yapıyorsunuz. Düşünce akışına yardım etmeli.

2) Fikir tartışması yapan bir ortak bulun - yukarıdan bir kahve alın ve kağıtlı sunum tahtası / diyagram vb. Alın ve şehre gidin. IMHO, eşleşen teknoloji becerileriniz yoksa daha da iyi. Usecase uygulamak için fikir ileri geri sıçrama. Bir çıkmaz sokak bulursunuz ya da iki tane bulursunuz - bir çözüm bulursunuz. Çevik bir zihinle, bu aşamada harcanan zaman daha az olur, kod yazmanız, işe yaramazsa ve işinizin parçalarını öldürmeniz veya yinelemeniz gerekir.

3) Yazılı yazılımınızı geliştirmek için muhtemelen hiç bitmediğinizi anlayabilecek bir patron bulun . Masanıza her zaman yeni özellikler / gereksinimler eklerseniz ve yazılımınıza hiç önem vermezseniz , hatalar, bakım kolaylığı ve hatta birkaç yıl boyunca saç çekme ile size çarpacaktır. Bu yazılımın bakım süresini / bütçesini ayırın! İyi bir sihir rakamı, yazılımı geliştirmek için gereken zamanın yaklaşık% 20'sidir ve kullanım ömrü boyunca formda kalması için her yıl gerekli.

4) Bu artan öğrenme süreci asla durmaz (ve olmamalıdır)! 10 yıl sonra geriye bakacak ve gülümseyeceksiniz.

Umarım bu küçük bir parça ve iyi şanslar yardımcı olur!