Geliştirme yöntemleri bir geliştiricinin bireyciliğini ezmeli mi?

Üniversitenin son dönemindeyim ve bir yazılım mühendisliği kursu alıyorum. Sınıfta çeşitli yazılım geliştirme yöntemlerini öğreniyoruz. Odaklandığımız ve projemizi geliştirmek için kullandığımız şelale yöntemiydi.

Eğitmenin yanlış uyguladığını hissediyorum. Sınıf diyagramlarımızda, özel olanlar da dahil olmak üzere TÜM özellikleri ve yöntemleri listelemek zorunda kaldık. İşlevleri olabildiğince kısa ve odaklanmış tutmak için Temiz Kod adlı birkaç kitap okudum. Diğer geliştiricilere yardım etmezlerse, şemalarımızdaki her küçük işlevi listelemek sıkıcı görünmektedir (özeldir, başka kimse bunları kullanmaz). Ayrıca, programı tasarlarken her küçük işlevi düşünmeyebilirim, yeniden düzenlerken ortaya çıkabilirler.

Eğitmen her fonksiyonu listelememizi isteyerek bize yanlış mı söyledi? Ve bu tasarım yöntemleri, geliştiricinin bireyciliğini en iyi nasıl anlayabileceklerini kod yazmak için eziyor mu?

Eğitmene neden tüm yöntemleri listelemeniz gerektiğini sordunuz mu?

Bir sınıf ortamında istenenlerin çoğunda olduğu gibi, niyetiniz sınıf diyagramlarınızı geliştiriciler için daha yararlı hale getirmek değil, size ve sınıf arkadaşlarınıza sınıflarınızı nasıl tasarlayacağınızı düşünmelerine yardımcı olmaktı. Öğrenciler daha büyük problemleri daha küçük problemlere nasıl ayıracağını öğrenirken, muhtemelen hangi özel yöntemlere ihtiyaç duyacaklarını düşünmeleri yararlı olacaktır. Ve muhtemelen, birisinin tasarımı iyi düşünülmezse, sürecin erken aşamalarında müdahale etmek için öğrencilerin hangi yöntemleri uygulamayı düşündükleri hakkında daha iyi bir fikir edinmesi için eğitmen için yararlıdır. Bir sınıf ortamındaki dokümantasyon, gerçek dünyadaki dokümantasyondan çok daha fazla dahil olur çünkü eğitmen

Tabii ki, eğitmenin bu düzeyde dokümantasyonun gerçek bir projede yardımcı olduğuna inanması da mümkündür. Durum buysa, eğitmen muhtemelen güncel değildir veya bu planlama ve belgelendirme düzeyinin uygun olduğu belirli bir niş geçmişten gelmiştir. Örneğin, uzay mekiği için navigasyon sistemi oluşturuyorsanız veya tıbbi cihazlar tasarlıyorsanız, geliştirme sırasında kodu yeniden düzenlemek yerine, ön taraftaki tasarıma yatırım yapmak genellikle çok daha uygundur. Bir sosyal ağ sitesi geliştiriyorsanız, daha çevik bir yaklaşım daha uygundur.

Hayır, eğitmen size şelale yöntemini kullanıyorsanız tüm özellikleri ve yöntemleri önceden listelemeyi söyleme hakkına sahiptir. Wikipedia bir şelale eleştirisine dikkat çekiyor:

Birçoğu, şelale modelinin uygulamada kötü bir fikir olduğunu iddia ediyor - önemsiz olmayan herhangi bir projenin, bir sonraki aşamaya geçmeden ve onlardan öğrenmeden önce bir yazılım ürününün yaşam döngüsünün bir aşamasını mükemmel bir şekilde bitirmesinin imkansız olduğuna inanıyor. Örneğin, müşteriler çalışan bir prototipi gözden geçirmeden ve ona yorum yapmadan önce tam olarak hangi gereksinimlere ihtiyaç duyduklarını bilmeyebilirler. İhtiyaçlarını sürekli değiştirebilirler. Tasarımcılar ve programcılar bunun üzerinde çok az kontrole sahip olabilirler. Tasarım tamamlandıktan sonra istemciler gereksinimlerini değiştirirse, tasarım yeni gereksinimleri karşılayacak şekilde değiştirilmelidir. Bu, etkili bir şekilde çok sayıda çalışma saatini geçersiz kılmak anlamına gelir, bu da özellikle projenin kaynaklarının büyük bir kısmı Büyük Tasarım Önüne yatırılmışsa artan maliyet anlamına gelir.

Bu tasarım yöntemleri, tasarımın bireyciliğinin uygulayıcısını ezmez, çünkü hala yorumlanacak parçalar ve kişinin yapısına benzersiz dokunuşlar koymanın yolları vardır, örneğin bir iskelet verilen resim ve kas ve diğer dokuları ekleyerek ne kadar olduğunu merak eden bir hayvan yaratmak o hayvanı tasarlamak zorunda mıydın?

Şelalenin eksik olduğunu gördünüz, ama her şeyin güçlü ve zayıf yanları var.

Sınıfta çeşitli yazılım geliştirme yöntemlerini öğreniyoruz. Odaklandığımız ve projemizi geliştirmek için kullandığımız şelale yöntemiydi.

Muhtemelen başlangıçtan itibaren belirtilen yazılım geliştirme dünyasına tanıtmakla ilişkilendirilen klasik Şelale modelini öğrendiniz, büyük ölçekli yazılım sistemleri geliştirmek için uygun değildi. Muhtemelen birçok insanın Şelale modeli olduğunu düşündüğü sorunlarla ilgili daha fazla bilgi edinmek için Winston Royce'un Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme başlıklı makalesini okumak istersiniz .

Bununla birlikte, Şelale modeli, yazılım geliştirme yaşam döngüsünü ilerlerken öğretmek için iyidir ve mühendislik, mimari tasarım, ayrıntılı tasarım, uygulama, test ve bakım işlemlerini öğrenmek ve gerçekleştirmek için çok net, farklı aşamalarda zaman harcayabilir.

Sınıf diyagramlarımızda, özel olanlar da dahil olmak üzere TÜM özellikleri ve yöntemleri listelemek zorunda kaldık. İşlevleri olabildiğince kısa ve odaklanmış tutmak için Temiz Kod adlı birkaç kitap okudum. Diğer geliştiricilere yardım etmezlerse, şemalarımızdaki her küçük işlevi listelemek sıkıcı görünmektedir (özeldir, başka kimse bunları kullanmaz). Ayrıca, programı tasarlarken her küçük işlevi düşünmeyebilirim, yeniden düzenlerken ortaya çıkabilirler.

Bunların hepsi çok geçerli noktalar.

Şelale kullanılırken bile tasarım aşamasında tüm özelliklerin ve yöntemlerin listelenmesi muhtemelen aşırıdır. Temel özelliklerin yanı sıra halka açık olan her şeyi kesinlikle listelemelisiniz. Gerçekte, diğer her şey, uygulamanızı diyagramlara tersine çevirerek elde edebileceğiniz bir uygulama detayıdır.

Clean Code'un tavsiyesi (Hiç okumadım - sadece yayınladığınız şeyle gidiyorum) Şelale metodolojisini kullanırken bile adil ve uygulanabilir görünüyor. Sınıflarınızı ve yöntemlerinizi Tek Sorumluluk İlkesi , endişelerin ayrılması ve diğer SOLID ilkeleri doğrultusunda tasarlayabilirsiniz . Şelale size nasıl tasarlamanız gerektiğini söylemez. Bununla birlikte, uygulama sırasında bunu yapmanın daha iyi yollarını öğrendikçe ve düşündüğünüzde ön tarafta daha zor olduğunu söyledi.

Bence bu, tasarım ve uygulama arasında çok açık bir şekilde yinelemenin gerekli olduğu gerçeğine işaret ediyor - geleneksel Şelalenin açıklanmadığı bir sorun.

Diğer geliştiricilere yardım etmezlerse, şemalarımızdaki her küçük işlevi listelemek sıkıcı görünmektedir (özeldir, başka kimse bunları kullanmaz).

Bunun sıkıcı olduğunu düşünüyorsanız, gerçek bir iş programlama elde edene kadar bekleyin. Bir an için, bu yazılımın sizin için uygun bir kariyer olmadığını düşünün.

Ayrıca, programı tasarlarken her küçük işlevi düşünmeyebilirim, yeniden düzenlerken ortaya çıkabilirler.

Yani?

her fonksiyonu listelememizi isteyerek eğitmen bize yanlış mı söyledi?

Hayýr. Bu ortak bir gereklilik.

Ve bu tasarım yöntemleri, tasarımın (geliştiricinin) bireyciliğini en iyi nasıl anlayabileceklerini kod yazmak için eziyor mu?

Evet. Bireylerin ruh ezmesi, yazılım geliştirmenin önemli bir parçasıdır. Tüm bireysellik, tüm programcılardan mümkün olan her şekilde yenilecektir. “Tanrı'nın Programlama Kuralları” nda bir yerde bir dağdan bir peygambere teslim edildiğini söylüyor.

Hayýr. Sadece tediumda bađlýyorsun. Üstesinden gel ve işe geri dön.

Programlama, kısıtlar dahilinde çalışma sanatıdır. CPU sınırlı bir komut seti sağlar; IO, donanımın tasarımı ile sınırlıdır; OS API'leri belirli davranışları teşvik etmek ve diğerlerini kısıtlamak için oluşturulur; üst düzey diller genellikle bir dizi deyimi diğerleri üzerinde tanıtmak için tasarlanmıştır ...

Ve metodolojiler de kısıtlamak için hazırlanmıştır.

Gelişim sürecinizin her alanında karşılaştığınız zorluk, vizyonunuzu bu kısıtlamalar dahilinde gerçekleştirmektir . Kafanızı donanım, dil, API ve metodoloji tarafından atılan her duvara dayayacak mısınız? Yoksa ulaşmak istediğiniz şeyi izin verilen ve teşvik edilenle uyumlu hale getirmenin bir yolunu bulabilecek misiniz?

Sen gerçekten eğitmeninizin sonsuz minutia sayfasını okumak istediğini düşünüyor ? Sonra bu teoriyi test edin: bir programı parçalayın ve her atomu belgeleyin. Masasının ağırlığı altına düştüğünde, gerçek arzusunun beklediğinizden biraz farklı olduğunu göreceğinizden şüpheleniyorum.

Ya da belgeleri hazırlamak Eğer uyum bakın. Netleştirin, anlaşılır yapın, bir Dashiell Hammett romanı gibi okuyun. Sonra oturun ve onunla konuşun, ona ne yaptığınızı gösterin, onu liyakate ikna edin.

Eğitmen size bu projeyi yapmak ve böylece Şelale gelişiminin artılarını ve (çoğunlukla) eksilerini öğretmek için mükemmel olduğunu düşünüyorum.

Proje analizi karmaşıklığını ölçmek için basit bir kural şudur: "Geliştiricinin veya çalıştığı şirket, oluşturulan yazılımda meydana gelen yeterince dramatik bir şeyden (genellikle ölüm veya büyük miktarda para dahil) sorumlu tutulabilir mi?".

Bazı kurslarımda sizinle aynı deneyimi yaşadım. Askeri endüstride geçmişi olan insanlar bize analiz öğretirdi. Ve bu, projenin tüm seyrini, en küçük ayrıntılarda bile planlayarak, eksiksiz ve kapsamlı bir analiz olacaktır. Bu tür bir projeyle çok fazla iterasyon yapamazsınız (bomba patlaması da iyi olabilir, bütçe patlaması değildir), bu yüzden burada yaratıcılık için yer yok, plana gitmelisiniz.

Öte yandan, biraz okuduysanız, kesinlikle çevik metodolojileri okursunuz. Genellikle daha az dokümantasyon ve geliştiricinin karşılaştığı soruna bir çözüm geliştirirken yaratıcılığını kullanması için daha fazla alan vardır.

Sonuç olarak, ne kadar çok tecrübe ederseniz o kadar iyi ve eğitmeninizin size gösterdiği şey endüstrinin bir bölümünde geçerlidir. Bir projeyi yönetmenin ve tasarlamanın kesinlikle onları kodlayacak kadar çok yolu olduğunu unutmayın. Ve hepsi için savunucuları ve eleştirmenleri bulacaksınız. Okurken onları test edin ve mutlu olduğunuz birini seçin.

Sahip olduğum gibi bazı yazılım mühendisliği sınıfları, 'başarısızlık başarıdır', başarı başarısızlıktan öğrenmek için boşa giden bir fırsattır ve daha fazlası daha az ve daha fazla olduğu garip bir tarzda öğretilir. Bu onlardan biri ise, ödevlere sadık kalın ve tuhaflığın tadını çıkarın.

Bence eğitmeninizin bağlantısı kesildi. Ticari yazılım nadiren bu kapsamda tasarlanır veya belgelenir. Çok pahalı ve elde edilen belgeler daha fazla masraf olmadan sürdürülemez. IMO bu tür uygulamalar, kodlamanın genellikle montaj dilinde yapıldığı günlerden kalma bir miras. Daha çevik uygulamaları denemek için zamanınız daha iyi harcanırdı: test odaklı geliştirme, çift programlama, sürekli yeniden düzenleme.

Eğitmen "sana yanlış söyledi mi?"

Sanırım.

Fikri mülkiyet çalışanlarına sıkıcı iş atamak israftır. Okulda, belki de öğrencileri sıkıcı çalışmaya teşvik etmek dışında, sıkıcı işin pedagojik değeri çok azdır veya hiç yoktur. Bu tür egzersizlerin hem öğrenciler hem de endüstri için olumsuz sonuçları vardır. Zamanları boşa harcandığı için öğrenciler zarar görür. Endüstri zarar görüyor, çünkü bazı öğrenciler böyle bir tediumun gerekli ve yararlı olduğu sonucuna varabilirler. İkisi de değil. Yazılımda otuz yıl içinde, hem sıkıcı hem de yararlı olduğunu düşünebildiğim tek iş, yedekleme bantlarını değiştirmekti. Bunu yapabilen robotlar vardı, ama onlar çok pahalıydı.