Bir uygulamanın bölümlerinin yeniden yazılmasını önleme

Satış departmanları için bir projede bir şirkette çalışıyorum. Bu benim ilk profesyonel programlama işim, ama kendi başıma kod yazıyorum ve yıllardır öğreniyorum. Projenin bir kısmı, bazı verileri almayı ve bunları üretmek ve grafik oluşturmak için girdi ile birleştirmeyi içerir. Sonra verileri kaydedin ... vb. Bunun için kodu bir günden kısa bir süre içinde yazdım. Ertesi gün proje süpervizörümü gösterdim ve çok hoşuma gitti, ama "eğer buna sahip olsaydık" ve grafiğe bir şeyler eklememi istedi. Bu, programın görünümü veya işlevinde büyük bir değişiklik değildi, ancak veri depolamak, işlemek vb.

Yine, veritabanı tablosunu yeniden yapılandırmak ve bu yeni isteği desteklemek için kodu temelde sıfırdan yeniden yazmak bir günümü aldı. Tekrar ona geri götürdüm ve aynı şey oldu. O verileri işlemek için nasıl gerekli önemli ölçüde değişti başka bir şey istedi. Bu yüzden tekrar yazmak zorunda kaldım. Sonunda imzaladı ve umarım, tekrar yazmam gerekmeyecek.

Sadece açık ol, müdürümü ya da onun gibi bir şeyi dayamam. O harika bir adam ve talep ettiği şeyler bu dünyanın dışında değildi, daha önce yaptığımla uyumsuzdu.

Sadece tam yeniden yazmalardan kaçınmak için gelecekte yapabileceğim bir şey olup olmadığını merak ediyorum. Esnek kod oluşturmayı anlıyorum ve bunu yapmaya çalışıyordum, ancak bunu kolaylaştırmak için farklı yapabileceğim herhangi bir uygulama veya şey bilmek istiyorum, bu nedenle, gelecekte 3 gün harcamıyorum almalıydım 1.

Yorum yaptığım gibi, gereksinimlerin ilk kez net olmadığına dair güçlü bir his var ya da muhtemelen bazı önemli detayları kaçırdınız.

Her şey daha iyi kod, en iyi uygulamalar, tasarım modelleri veya OOP ilkeleriyle ele alınamaz. Uygulama yanlış varsayımlara veya yanlış binalara dayanıyorsa hiçbiri tüm uygulamayı yeniden yapmanızı engellemez.

Çözümü kodlamak için acele etmeyin. Tek bir LOC yazmadan önce gereksinimleri açıklığa kavuşturmak için biraz zaman ayırın. Gereksinimleri ne kadar derinlemesine araştırırsanız, soruların ortaya çıkması o kadar fazla olur . Yöneticinin bir sonraki ne olursa olsun sizi şaşırtmasını beklemeyin . İşleri kendiniz tahmin edin. Bu küçük egzersiz sürpriz faktörü önemli ölçüde azaltabilir .

İhtiyacınız olduğu kadar çok soru sormaktan korkmayın. Bazen ağaçlar (ayrıntılar) ormanı görmemize izin vermez (genel resim). Ve önce görmemiz gereken orman.

Gereksinimler açık olduğunda, tasarım aşamasında daha iyi kararlar almak daha kolaydır.

Son olarak, genel resmin bir hedef olduğunu unutmayın. Bu hedefe giden yol ne sade ne de açıktır. Değişiklikler olmaya devam edecek, bu yüzden çevik olun.

Verdiklerinize dayanarak bunu bilmenin bir yolu yoktur. O anda ihtiyacınız olan şey daha hızlı ve kirli. Ancak, o zaman birisi onu sevdi ve karmaşıklaşıyor, bu yüzden şimdi karmaşıklığın ortaya çıkmasına kadar birçok sorunun kendilerini göstermediğini görmeye başlıyorsunuz. Yapılması gereken çok farklı şey var, sadece ezici.

Eski "Gümüş Kurşun Yok" var ve bu doğru. Yine, tam spesifikasyonlarla (veya Agile için daha iyi devam eden spesifikasyonlarla) ne yapacağını ve iyi programlama prensiplerini ve iyi tasarımları kullanma yeteneğini bilmenin bir yolu yoktur. Programcılar tekrar tekrar yazmayı severler . Bu duruma mutlaka düştüğünüzü söylemiyorum, şu anda küçük.

Bu fırsatı bazı temel ilkeleri uygulamak için kullanın. Çalıştıklarını göreceksiniz, ancak birileri "Ah hayır, bu kötü" der ya da hoşunuza giden başka bir şey yaparsınız. Her şeyi şirketin parasında yapamazsınız, ancak keşfetmeniz için size zaman tanıyorlarsa, bir fırsat olarak kullanın. Her zaman bir şeyler, bir vakıf, bir kişi, “en iyi” ya da bir şeyler yapmanın “yeni” yoluna sahiptir.

Yöneticiniz büyük olasılıkla attığınız adımların her birinde haklıydı. Bunun nedeni, yönetici olması değil, sonuçları ve kullanılabilirliği ve muhtemelen müşteri veya müşteri talepleriyle önceki anlaşma sayısını dikkate almasıdır.

Kullanıcı arayüzü zor şeylerdir, genellikle 5 kişinin 15 farklı görüşü vardır. Ve veri ve veri yapılandırması ve veri analizi bunu faktör 10 ile çarpma eğilimindedir :). UI moda gibidir, bazı kombinasyonlar serin, bazıları korkunç veya sağduyu eksiktir.

Bahsetmemek gerekirse, örneğin LEAN işlemi sırasında hiçbir şey taşa konmaz. Yinelemeli değerlendirme gibi bir şey deneyimliyorsunuz ve her adımda biraz daha iyi ya da yanlış yoldan kaçınıyor.

Öyle basit bir cevap ki, yeniden yazma diye bir şey yoktur.

Yinelemeli gelişim (temel olarak bir günlük yinelemeler de olsa yaptığınız şey) genellikle böyle. Çözümlere yönelik erken teşebbüsler genellikle iz dışındadır ve geri bildirim toplayarak sistem bir çözüme dönüşür. Şekil 2.2'yi UML ve Tasarım Desenlerini Uygulama kitabı için Craig Larman'ın öğretim materyallerinden ödünç alacağım .

Bir projenin başlangıcında, görünen kararsız sürümlerle yaşamayı öğrenirsiniz. "Daha erken şartlar almak zorundasınız" diyen cevaplara katılmayacağım çünkü bu Şelale düşüncesidir. Gereksinimler açısından olabildiğince fazla almaya çalışmanız gerektiği doğrudur, ancak birçok nedenden dolayı tam ve doğru gereksinimlere sahip olmak mümkün değildir.

Bu, geri bildirim aldıktan sonra ne kadar yeniden yazmanız gerektiğini azaltamayacağınız anlamına gelmez. Çoğu zaman doğru olan bir şey, yazılımın insan-bilgisayar etkileşiminin değişme olasılığının çok yüksek olmasıdır, çünkü bu ilk seferinde doğru yapılması zor bir parçadır.

Microsoft Word ve veri formatının (.doc) yıllar içinde nasıl gerçekten gelişmediğini düşünün. Bunun nedeni, sorunlu bir alan olarak bir metin belgesinin çok fazla gelişmemiş olmasıdır (bir sayfa hala bir sayfa, bir paragraf hala bir paragraf vb.). Ancak, Word'ün kullanıcı arayüzü çok gelişti (ve devam ediyor). Sunum veya giriş kodu sürümler arasında kararsız olma eğilimindedir, bu nedenle sistemin diğer bölümlerinin kendileriyle doğrudan birleştirilmemesi en iyisidir (yeniden yazmaya karşı izole etmek için).

Sunumun altında yatan mantık ve problem hakkındaki verileri ayırabilen yazılım mimarileri, daha az yeniden yazma olanağı sağlar. Model-View ayrımı gibi birçok yazılım modeli , sizin gibi birçok yeniden yazma yüzünden acı çekti ve daha iyi bir yol istedi.

Bu kulağa çok Budist gelebilir, ama bu yeniden yazmalara maruz kaldığınız için şanslısınız! Pek çok insan, kalıplardan kaçınması gereken yeniden yazma kabuslarını "acı çekmeden" MVC kalıplarını veya diğer tasarım kalıplarını öğrenir.

Bir cevabım yok, bir alıştırma kadar - muhtemelen kendi zamanınızda yapmanız gerekecek, ancak kuruluşunuza bağlı olarak, çalışma saatleri içinde bunu yapmak için izin alabilirsiniz.

İlk çözümünüzü tam olarak ne yaptığını yeniden tasarlayın, ancak 2. veya 2. ve 3. adımları eklemeyi kolaylaştırın. Bu adımları eklemeyin, saplamayın. Tüm orijinal gereksinimleri karşılayan ancak yeni özelliği içerecek şekilde kolayca yükseltilebilen bir çözüm oluşturmanız yeterlidir. İkinci çözümünüz için de aynısını yapın.

Gereksinimler değişir, bu hayatın bir gerçeğidir. Geriye dönüp bakıldığında: Toplam çözüm süresi daha az olacak şekilde ilk çözüm farklı olabilir mi? Deneyimle nasıl yapılacağını öğrenirsiniz.

Bu ilk dik öğrenme eğrisidir. Bunu yönettiğinizde, ikinci zorluk olacaktır: Kullanıcılar atmak istemedikleri bir yıllık veri depoladığında değişen gereksinimleri nasıl ele alırsınız?

Hikayenizden, gereksinimlerin ve tercih edilen mimari kararların yeterince iyi iletilmediği açıktır. Dolayısıyla sizden biri, ya da belki ikisi de kötü iletişimcilerdir.

Aynı zamanda mimar da olabilir, çünkü bazı mimarlar sadece programlama yaparken iyi başarılar için yüksek statü kazanırlar veya büyük eğitim (aynı zamanda çoğunlukla yalnız çalışmakla ilgilidir) veya şirketteki ilk geliştirici (açıkçası yalnız) ve ekiple iletişimde gerekli değildir. Tasarımları belgelemekten ve takımı desteklemekten çok programlamaya odaklanmaya devam etmeleri nadir değildir.

Ancak bu durumda da daha uzun konuşarak, soru sorarak ve not alarak telafi etmeye çalışabilirsiniz. Hatta küçük bir şartname bile yazabilir ve mimardan onaylamasını isteyebilirsiniz.