“Yazılım mühendisliği” yerine hangi özel uygulamalar “yazılım işçiliği” olarak adlandırılabilir? [kapalı]

Her ne kadar yeni bir fikir olmasa da , son birkaç yıldır yazılım işçiliğine olan ilgide büyük bir artış görülüyor (özellikle önerilen kitap Clean Code'un tam başlığı Clean Code: Agile Software Craftsmanship'in El Kitabı ).

Şahsen yazılım işçiliğinin, nihai sonucun çalışmak için bir zevk (hem son kullanıcı olarak hem de yazılımı koruyan biri olarak) sağlamaya yönelik ilgi ile iyi bir yazılım mühendisliği olduğunu ve odağının daha fazla kodlama düzeyinde olduğunu düşünüyorum. şeyleri daha üst düzey süreçlerden daha fazla.

Bir benzetme yapmak için - 50'lerde ve 60'larda çok modern bir tarzda inşa edilmiş olan çok sayıda bina vardı, bu binalarda yaşayan insanları veya bu binaların zaman içinde nasıl yaşlandığını çok az dikkate aldı. Bu binaların birçoğu hızla gecekondu bölgelerine dönüştü veya beklenen ömürlerinden çok önce yıkıldı. Eminim ki kemerleri altında birkaç yıl süren çoğu geliştirici benzer kod tabanlarına sahip olacaktır.

Bir yazılım ustasının bir yazılım mühendisinin (muhtemelen kötü bir yazılım) yapamayabileceği özel şeyler nelerdir?

Bir profesyonel ile bir zanaatkar arasındaki tek farkın, biraz tutkuyla karıştırılmış olduğunu söyleyebilirim . Birini zanaatkar olarak sınıflandıracak özel, gözlemlenebilir bir uygulama yoktur, daha ziyade bir nitelikler koleksiyonu vardır:

• Bir usta, sadece algılanan kaliteyi değil, çalışmasının gerçek kalitesini önemsiyor.
• Bir zanaatkar, işini yapmanın ötesine geçen zanaatına ilgi duyar ve doğal olarak zanaatına yönelir.
• Bir usta, sadece kariyerini geliştirmekle kalmayıp , becerilerini geliştirmek isteyen mesleğini de önemsiyor .
• Bir usta, tartışmak, öğrenmek, hatta düşünmek gibi, zanaatıyla bir şeyler yapmak için ücretli çalışma saatlerinin dışında (biraz zaman olsa bile) biraz zaman harcıyor.
• Bir usta gerçekten ne kadar az şey bildiğini biliyor ve onun tarafından alçaltılıyor.
• Bir usta, öğrenmek isteyenlere rehberlik arayanlara rehberlik etmek ve ihtiyaç duyduklarında kendileri aramak isteyenlere öğretmeye isteklidir.

Biraz tutku, ter dökmeden tüm bunları kapsar.

Şahsen yazılım işçiliğinin, nihai sonucun çalışmak için bir zevk (hem son kullanıcı olarak hem de yazılımı koruyan biri olarak) sağlamaya yönelik ilgi ile iyi bir yazılım mühendisliği olduğunu ve odağının daha fazla kodlama düzeyinde olduğunu düşünüyorum. şeyleri daha üst düzey süreçlerden daha fazla.

Bir profesörümün bir keresinde söylediği gibi (başka kelimelerle yazılmış): "Bir yazılım mühendisi olarak, sadece yazılım sunmak sizin işiniz değil. Müşterilerinizi mutlu eden yazılımlar sunmak sizin işiniz."

Bir yazılım ustasının bir yazılım mühendisinin (muhtemelen kötü bir yazılım) yapamayabileceği özel şeyler nelerdir?

Hiçbir şey - bir mühendis zanaatkâr ... ama daha fazlası. Mühendislik işçilik üzerine kuruludur.

Bir zanaatkar ve mühendis olarak, eğitim ve deneyimin bir kombinasyonuyla yetenekli kişilersiniz. Yerleşik prosedürleri takip edersiniz. Ayrıca pragmatiksiniz ve neyin kırıldığını ve daha iyi olması gerektiğini fark edersiniz.

Bununla birlikte, mühendis bunun üzerine ekonomi, teori ve bilim kaygılarını da ekler. En düşük maliyetle en fazla faydayı elde etmekle ilgileniyorsunuz. Sorunlarınızı (kişiler arası ve teknik) çözmek için psikoloji, sosyoloji, yönetim, insan-bilgisayar etkileşimleri ve bilgisayar bilimleri teorilerini uygulamak istiyorsunuz. Ve kesinlikle deneyimlerinizi destekleyecek bir eğitiminiz var.

Yazılım işçiliği hareketi, (bazı geliştiricilerin dikkatsizliğiyle birlikte) bugün paydaşlardan ve kullanıcılardan mesleğimize güvensizliğe yol açan "geleneksel" yazılım mühendisliğinin başarısızlıklarına ve tatmin edici sonuçlarına tepki olarak başlatılmıştır.

Amacı iki yönlüdür: programcılara olan güveni geri kazanmak ve bunu yapmak için yazılım kalitesi ve geliştirici becerileri çıtasını yükseltmek.

Sw işçiliği aşağıdaki gibi teknik uygulamaları teşvik eder:

• SOLID tasarım ilkeleri
• Tasarım desenleri
• TDD ("çift giriş muhasebesi" metaforu)
• ...

Ve ekip / organizasyon uygulamaları:

• Çiftler programı
• Mentorluk
• Kod katasları
• Dojos / kod geri çekmeleri
• ...

Bu yüzden 2 arasındaki farkın açık olduğunu söyleyebilirim: yazılım işçiliği, bugün 40 yılı aşkın bir süredir yazılım mühendisliğinin sahip olduğu sorunların büyük bir kısmını ele almaya çalışıyor ve bu da bugün disiplinimizi güvenilmez ve sakat bir tarihle sakatlaştırıyor.

Kullanmasinizi http://manifesto.softwarecraftsmanship.org/ ben aşağıdakileri türetmek istiyorum.

Bir usta, geleneksel bir "mühendis" algısından farklıdır, çünkü

• Sadece gereksinimleri karşılamaya değil, değere odaklanırlar.
• Sadece gereklilikleri karşılamakla kalmaz, kod tarzında bile kaliteye odaklanırlar.
• Sadece iş yerlerine değil, daha geniş yazılım geliştirme topluluğuna katılırlar.
• Sadece günümüz sanatının yarının önemsiz olduğunu anlamıyorlar, onu bir seviyeye getirmekte aktifler.
• Bu onlar kim, sadece bir iş değil bulunmaktadır .

Bob Amca, bir şekilde programlamanın, hükümetler tarafından tanınan henüz istikrarlı bir yasa ya da kurallara sahip olmayan çok genç bir disiplin olduğunu ima etti (ya da Frederick Brooks muydu?). Burada sözlü bir alıntı yapmıyorum.

Yanlış uygulama nedeniyle kimsenin programlama iznini iptal edemezsiniz. Programlama, bir “mesleğe” uyan mevzuat tarafından yasal olarak yürürlüğe konulan yasa ve kurallardan yoksundur. Bir doktor yetersizlik nedeniyle bir hastayı öldürür ve doktor unvanını veya ondan alınma iznini riske atar.

Bir programcı buggy program yapar veya yetersizlik nedeniyle bir projeyi başarısız yapar ve programlamaya devam etmekte özgürdür.

Bence programlamayı bir zanaat yapan da bu. Bir kil çömlek üreticisi iki özdeş tencere yapmaz. Ayrıca, saksıları hatırlamak zorunda kalan bir kil çömlek üreticisi de duymadınız. Programlama hala çok manuel ve kişisel bir çalışmadır. Bazen kimin tarzına göre bir parça kod yazdığını bile söyleyebilirsiniz.

Desenlere Yeniden Bakmak.

Yani, yazılım gereksinimlerinin% 90'ını karşılayan bir şey oluşturun, ardından tüm projeyi temiz, zarif bir tasarıma yeniden düzenleyin.

Normalde, yazılım mühendisliği bunu yapmanızı engelleyecektir, çünkü gereksinimlerin% 90'ını karşılamak, yazılımın müşteri için önemli bir şekilde değiştirilmemesi için (yüksek öncelikli hata düzeltmeleri hariç) yeterli iş değerine sahip olduğu anlamına gelir.

Yazılım mühendisliği bunun yerine yazılımı bu noktada stabilize etmenizi önerir .

Ayrıca, bir proje en başından beri bu zarif tasarımla başlamazsa , yazılım mühendisliğine göre, kötü yürütülen bir proje (projenin sonucuna bakılmaksızın) olarak kabul edilir .

Spike Çözümü.

Spike çözümünden esinlenen bir tasarım, mevcut yazılım mühendisliği metodolojisine göre normalde kabul edilemez.

Hangi nedenle olursa olsun, kullanımdan kaldırılıyor .

Yazılım mühendisliğinde, herhangi bir kullanımdan çıkarılmanın ancak yazılım sisteminin yaşam döngüsünün sonunda gerçekleşmesine izin verilir. Bu SDLC'nin bir parçası olarak planlanmalıdır.

Uygulamada, yazılım arayüzünün belirli bir kısmının eksikliklerinin birkaç yıl boyunca üretilmesinde keşfedilmesi ve söz konusu kısmın, yazılımın geri kalanını geçersiz kılmadan, yaşam döngüsünün ortasında kullanımdan kaldırılması oldukça yaygındır. Yazılım mühendisliğine göre, kullanımdan kaldırıldıktan sonra tüm yazılım sisteminin yeniden sertifikalandırılması gerekirdi.

Sonunda, yazılım işçiliği bireylerin iyi yargıları için kişisel bir çaba, yazılım mühendisliği ise muhafazakar bir bilgi kaynağıdır. Yazılım işçiliğini yazılım mühendisliğinden ayıran şey, projenin karar verme sürecine iyi bir muhakemenin tanınmasıdır.

Kodun% 100'ünü kapsayan birim testlere sahip olmanın iyi olacağını söyleyebilirim. Bu, fazla şeylerin soyulmasına izin verir.

Bazen yazılım geliştirmeyi heykel ile karşılaştırıyorum. Eklediğiniz şey değil, aldığınız şey bu.

Açıkçası bunu çok ileriye götürebilirsiniz. Kimse küçük, parlak bir çakıl taşının iyi bir heykel olduğunu söyleyemez: S