Bir meslektaşın aşırı karmaşıklık ve soyutlama getirmesini nasıl önleyebilirim?

Çok zor zamanlar yaşıyorum çünkü meslektaşım sergiliyor

1. Erken / Gereksiz optimizasyon çabaları
2. Şüpheli soyutlamalarla erken veri tekilleştirme
   Örneğin, değiştirilmiş bir VIPER mimarisi kullanıyoruz. İlk yönlendirici yığınını diğer yönlendiricilerde tam olarak neyin kopyalanacağını bilmeden uygulamanın bir parçası olarak Yönlendirici bileşeni (jenerikler kullanarak) için bir temel sınıf tanıttı. Artık UseCasekullanım durumlarını tutan bir tür sağlamak zorunda kaldık , ancak yönlendiricilerin çoğunun birden çok kullanım durumu yok, sadece bir tane.
3. Spekülatif potansiyel gelecekteki özellikler
   için genel amaçlı çözümler icat Örneğin, uygulamada sadece böyle iki ekranımız olduğunda statik hücre tablosu görünümlerini doldurmak için bir yönetici yazdı ve tasarımın sıkıcı dikey formlardan daha fazla özelliğe geçeceğinin farkında değildi. Kullanıcı arabirimi yani yönetici işe yaramaz.
4. Arızi karmaşıklığı tercih etme

Berbat İngilizce ile bir dil engeli de sergilediğinde bununla nasıl savaşabilirim?

Açıklamanız 1990'larda yaptığım kodlamaya benziyor. Modern dünya için uygun performans göstermek kolay değildir. Aşağıdaki faktörlere odaklanmanızı öneririm:

• Eşleştirme. İki göz seti, bir kişiye karşı harika ama karmaşık bir uygulamaya karşı korunmaya yardımcı olabilir.
• Kod incelemesi. Modern mağazalar, tüm kod değişikliklerinin% 100'ünü birden çok kişi tarafından gözden geçiriyor
• Test kapsamı. Basit testler olduğundan emin olun. Aşırı karmaşık testler aşırı karmaşık kodu yansıtabilir
• Minimum uygulanabilir ürün hakkında çok fazla tartışma. Özellikleri mümkün olan en küçük bileşenlere ayırın. Veritabanını değiştirmek için bir bilet, referans tablolarını doldurmak için bir bilet ve ardından UI'yi (son kullanıcılar tarafından gerçekten görünecek olan bölüm) güncellemek için üçüncüsü olması sorun değil, ancak direnç olduğu gibi ilk olarak karşı sezgisel hissedecek muhtemel.
• Daha küçük biletlerin ve değişikliklerin nasıl yapılacağı hakkında sık sık tartışma.
• Karmaşıklık ve yaklaşım hakkında tartışmalar açmak için tüm ekip tarafından hikaye oyu.
• Eğitim. İnsanların iyi uygulamalara ve neden iyi olduklarına bakabilmeleri için Öğle Yemeği ve Öğrenim, Eğitim oturumları vb. Yaptığınızdan emin olun.

Yukarıdakilerden, ana iki odak noktam kod incelemeleri ve daha küçük hikayeler olacaktır.

Günün sonunda, mevcut davranışı değiştirmek için en iyi çözümün, değişime liderlik eden özel bir kişiye sahip olmak olduğunu düşünüyorum. Çevik organizasyonlarda (muhtemelen bugün çoğunluğu), scrum-master gibi özel bir kişinin sürekli olarak doğru soruları sorması ve geliştirme yaklaşımına rehberlik etmesi gerekir. Son organizasyonumda, bir takım düzinelerimiz vardı, her takımda birer kişi bu tür konularda rehberlik etmeye yardımcı oldu. Bu, bir takım üyesi geliştiricinin diğerlerini 'yollarının doğru' olduğuna ikna etmeye çalışma ihtiyacını ortadan kaldırır, bu da genellikle acımasız alışverişlere ve kötü kanlara yol açabilir.