Gelişirken iş arkadaşlarınızla uğraşmak, tavsiyeye ihtiyaç duyar [kapalı]

Mevcut proje mimarimizi geliştirdim ve kendi başıma geliştirmeye başladım (gibi bir şeye ulaşmak revision 40) .

Basit bir metro yönlendirme çerçevesi geliştiriyoruz ve tasarımım son derece iyi yapılmış gibi görünüyordu - birkaç ana model, karşılık gelen görünümler, ana mantık ve veri yapıları "olması gerektiği gibi" modellenmiş ve oluşturmadan tamamen ayrılmıştır, algoritmik bölüm de uygulanmıştır ana modeller dışında ve az sayıda kesişim noktası vardı.

Bu tasarımı ölçeklendirilebilir, özelleştirilebilir, uygulaması kolay, çoğunlukla "kara kutu etkileşimi" ne dayalı, ve çok güzel olarak adlandırıyorum.

Şimdi ne yapıldı:

• İlgili arayüzlerin bazı uygulamalarına başladım, bazı uygun kütüphaneleri taşıdım ve bazı uygulama parçaları için uygulama taslakları yazdım.
• Kodlama stilini ve bu kodlama stili kullanımının örneklerini (kendi yazılı kodum) açıklayan belgem vardı.
• Ben az çok çağdaş kullanımını zorunlu C++olmak üzere geliştirme teknikleri, no-deletekod (akıllı göstericiler üzerinden sarılmış) vb
• Somut arayüz uygulamalarının amacını ve nasıl kullanılması gerektiğini belgeledim.
• Birim testleri (çoğunlukla entegrasyon testleri, çünkü çok fazla "gerçek" kod yoktu) ve tüm temel soyutlamalar için bir dizi alay.

12 gün boyunca yoktu .

Şimdi elimizde ne var (proje ekibin diğer 4 üyesi tarafından geliştirildi):

• Projenin her yerinde 3 farklı kodlama stili (sanırım, ikisi aynı stili kullanmayı kabul etti :) , temelde bazı veri yapılarını bildiren başlıklar olan soyutlamalarımızın (örn CommonPathData.h. SubwaySchemeStructures.h) Adlandırılması için de geçerlidir .
• Yakın zamanda uygulanan parçalar için mutlak dokümantasyon eksikliği.
• Son zamanlarda ne diyebileceğim single-purpose-abstractionşu anda en az 2 farklı olayı ele alıyor, diğer bölümlerle sıkı bağlantıya sahip.
• Kullanılan arayüzlerin yarısı artık üye değişkenleri içermektedir (sic!).
• Hemen her yerde ham işaretçi kullanımı.
• Birim testleri devre dışı, çünkü " (Rev.57) They are unnecessary for this project".
• ... (bu muhtemelen her şey değildir) .

Taahhüt tarihi, tasarımımın aşırıya kaçma olarak yorumlandığını ve insanların onu kişisel bisikletler ve yeniden tekerleklerle birleştirmeye başladığını ve daha sonra kod parçalarını entegre etmede sorun yaşadığını gösteriyor .

Şimdi - proje hala yapması gereken şeylerin sadece küçük bir kısmını yapıyor, ciddi entegrasyon sorunlarımız var, bazı bellek sızıntıları olduğunu varsayıyorum.

Bu durumda yapılabilecek bir şey var mı?

Tüm çabalarımın herhangi bir faydası olmadığının farkındayım, ancak son tarih çok yakında ve bir şeyler yapmak zorundayız. Birisi benzer bir durum yaşadı mı?

Temel olarak, proje için iyi bir başlangıç ​​(iyi, yapabileceğim her şeyi yaptım) muhtemelen güzel bir şeye yol açacağını düşündüm, ancak yanlış olduğumu anlıyorum.

Refactor dağınıklıktan kurtulmak için acımasızca!

Kullanılabilir stilin büyük bir kısmını oluşturan kodlama stilini alın ve bu proje için kullanın.

En kötüsü, revizyon 40'a geri dönmeniz ve programcılarınızın 12 günlük bir eğitim oturumu geçirmeleri, bu da konuyu daha iyi anlamalarını sağladı.

Programcılarınızın temiz kodlama hakkında öğrenecek çok şeyleri varsa, oniki gün, sahip olacağınız gecikmelerin en azıdır.

Sorunuzu yorumlayarak - "Birkaç haftalığına gittim ve ekibimin ben gittiğimde ne yaptığına katılmıyorum, burada olmadığımda istediğim şeyi yapmalarını nasıl sağlarım?"

Size bunun teknik bir problem olmadığını, bir yönetim problemi olduğunu söyledim. Benim almam (Lütfen yanılıyorsam beni affet), teknik çözümü, bir nedenden ötürü çözümünüzü kabul edemeyen veya kabul edemeyen ya da anlayamayan köleler ordusuna dikte etmenizdir.

Tasarımınıza çok fazla zarar vermek için 12 Gün gerekiyorsa, bir nedeni olmalı. Tasarım kırılgan mı? aşırı mühendislik mi? ya da takım buna rağmen mi yaptı? Son teslim tarihleriniz ve teslimatlarınız nasıl? Sıkı? sadece biriyle tanışmaya mı çalışıyorlardı?

Bunu gördüğüm bir örnek, teknik geliştiricinin oyunun çok ilerisindeydi ve ortalama geliştirici (ben) devam edemedi. Teknik ipucu, onu koruyabilecek tek kişi olduğu için ticari olarak uygun kod tasarlayamadı. Bir grad geliştiricisi bunu koruyamazsa, ticari dünya için çok karmaşıktır. Diğer tüm vakalarda, yönetim tarafında insanların yönetim becerilerinin basit bir eksikliği vardı.

Takım dinamikleri bozuldu. (Başkaları tarafından önerildiği gibi) karışıklığı yeniden düzenleyerek zaman harcayabilir ve bir dahaki sefere izin aldığınızda hepsini tekrar yapmak zorunda kalabilirsiniz. Ekip üyelerinizi geliştirmeniz gerekebilir, ancak inanıyorum ki, ne kadar çirkin olduğuna inansanız da, işi yapmak için yeterli beceriye sahip oldukları için takım dinamiklerini düzeltmeniz gerekir.

Çift.

Açıkladığınız şey, doğru, teknik olarak solo yapmaktır . Evet, belgelemeye çalıştınız, standartlar koymaya çalıştınız - ama görünüşe göre iletişim kuramadınız.

Ekibiniz sizinle daha yeni iletişim kurdu. "Hey, Yippie - iletişim kurmuyorsun!" Dediler. Tanıdığım en güçlü iletişim şekli eşleşmedir. Çift. Anlaşana kadar ya da sizi farklı yapmaya ikna edene kadar.

Brooks bize son 30 yıldır söylediği gibi, kavramsal bütünlük herhangi bir projenin en önemli parçasıdır. Önemsiz ve eksiksiz bir alt sistem için, tasarımından ve uygulanmasını yönetme yetkisine sahip olan tam olarak bir kişi olmalıdır. Projenizin bu kısmında bir şeyler ters gitti. Her neyse, tek çözüm, depoda bundan önce var olan koda geri dönmektir. 12 günlük bir kayıp, kırık tasarımın bakım masraflarıyla karşılaştırıldığında hiçbir şey değildir. Ayrıca, yetersiz kaldıklarını kanıtladıkları için, bu srewup'a dahil olan kişileri proje üzerinde daha fazla çalışmadan çıkarmanın yollarını da düşünürdüm.

Yeni başlayanlar için yapacağım bir şey, kötü kodu işaretlemek ve neden kötü olduğunu ve (kavramsal olarak) nasıl yapılması gerektiğini belgelemek için kullanarak, iyi bir kod inceleme aracı elde etmektir. Şimdi, anladığım kadarıyla, bir sürü kötü şey yapıldı ve bu yüzden gözden geçirmek çok fazla iş olurdu; kodda yanlış bir şey gören tek kişi olduğunuzu varsayarsak, her şeyi kendiniz gözden geçirmek mümkün olmayabilir. Ancak en kötü suçları işaretleyebilir ve bunları ilgili izleme kodunu yazan kişiye atanan sorun izleme sisteminize girebilirsiniz.

Kalite kodu yazmak için en iyi teşvik, bilmiyorsanız gelecekte sizi rahatsız edeceğini bilmektir. İş arkadaşlarınız bununla ilgilenmiyor gibi görünüyor, bu yüzden en iyi ilaç onları yanlış kısımları yeniden gözden geçirip öğrenmek.

Zaman verildiğinde, kodun sorunlu olan diğer bölümlerini tekrar ziyaret edebilir ve orijinal (kötü) yazara yeniden atayabilirsiniz. Bir süre sonra ilk kez iyi bir iş yapmanın faydalarını anlayacaklar.

Orijinal sürümünüze bir geri dönüş düşünmediğinizi varsayıyorum - başka bir deyişle, iş arkadaşlarınızın yazdığı kötü koda rağmen bazı işlevler ekledi ve mevcut sürümün net değeri orijinal olandan daha yüksek. Ayrıca, durum böyle olmasa bile, bu geri dönüşü yapmak ve kodu yeniden yazmalarını sağlamak için siyasi sermayeye sahip olmadığınızı varsayıyorum (gezegendeki çok az insanın bu sermayeye sahip olması gibi). Bunlar ve daha pek çoğu, kendimi deneyimlemediğim bir durumu yargılamanın karmaşıklıklarıdır, ancak umarım iki sentim yardımcı olmuştur.

Bahsetmediğim ama son zamanlarda çalıştığım bir şey "geliştirici siloları" ve "satın alma" sorunları.

Mevcut projemin başında, temelde kendi başıma bir çekirdek kütüphane tasarladım. (Tıpkı rev. 40'a kadar yaptığınız gibi). Sonra bunu yaptığımda, ekibin geri kalanına sundum ve herkese kullanmaya başlayabileceklerini söyledim. Sonraki aylarda olanlar, başka yerlerde bu kütüphanede bulunanlarla aynı şeyleri uygulamaya devam ettiler. CTO (aktif olarak kodlayan), ekibin geri kalanından kütüphanenin mimarisi / tasarımı / genel arayüzleri üzerinde hiçbir zaman bir satın alma işlemi olmadığına dikkat çekiyor.

Şu anda yaptığımız şeye daha iyi uyacak şekilde genel tasarımı tartışmalı olarak geliştiren kütüphanenin büyük bir yeniden yazımından geçtik, ancak yine de bir geliştirici kütüphaneyi tek projesi olarak aldı, birkaç hafta boyunca çalıştı ve sonra sundu. "Voila! İşte burada! Güzel değil mi?"

Şimdi yeni sürümü kullanmak zorunda olduğum ve aynı sorun var - Yaptığı şekilde nefret ediyorum. Ve gerekli olan şeyleri dışarıda bıraktı çünkü üzerinde çalışırken başkalarıyla işbirliği yapamadı. Yine, aynı şeyleri başka yerlerde ve yapmaya ihtiyacım olan şey için çalışma yollarında uygulamaya başlıyorum.

Uzun lafın kısası - Kod kalitesinin artmasını ve tutarlı olmasını istiyorsanız, standartları, stilleri vb. Oluşturmak için tüm ekibi bir araya getirmenizi öneririm. Buna ek olarak, herhangi bir kişi, uygulama, ben sorumlu kişi tüm sınıflar, vb tasarımında lider böylece günün sonunda, tüm takım genel uygulama mimarisi içine almak zorunda öneririz. Ayrıca, diğer ekip üyelerinin kodunun nasıl çalıştığını biliyorlarsa, kodu kendileri için uygun şekilde tekrar uygulama olasılıkları daha düşük olacaktır.

Bu ekibin üst düzey geliştiricisi (veya kıdemli geliştiricilerinden biri) siz misiniz? Öyleyse, en iyi uygulamalar hakkında bazı eğitim seminerleri düzenlemeniz gerekiyor gibi görünüyor. Muhtemelen yapılan işlerin çoğunu geri almalı, ekibinizle bir toplantı yapmalı ve gerekli işlevselliği mevcut tasarımı koruyacak şekilde uygulamanın doğru yolunu açıklamalısınız.

Sıkı bir son teslim tarihiyle karşı karşıya kaldığınızda, kodu olduğu gibi göndermeniz ve serbest bırakıldıktan sonra refactor (yeniden yaz?).

Ayrıca, bazı yaygın kod uygulamalarını tanımlamanız ve uygulamanız gerektiği anlaşılır. İşinizde bir kod inceleme süreci var mı? Değilse, şu anki sesler bir tanesini uygulama zamanıdır. Kod incelemeleri bu arada, yeni geliştiricilere en iyi uygulamaları öğretmek için harika bir yoldur.

DÜZENLE:

Son zamanlarda benzer bir durumla karşılaştım. Şirketimdeki yönetim, uygulamamızın çoğunu yazmak için sözleşme geliştiricileri kullandığımızda ısrar etti. Ürettikleri kod korkunçtu (nazikçe söylemek gerekirse), ama onu kullanmak zorunda kaldık. Bugün itibariyle, yüklenicilerin bizim için yazdığı kodun% 80'ini yeniden yazdım. Hatalarla doluydu ve yeni özelliklerle genişletilmesi imkansızdı. Birkaç ay içinde ekibim hepsini yeniden yazmış olacak ve sözleşme geliştirmeye yatırılan parayı etkili bir şekilde israf haline getirecektir.

Kötü kod gerçekten paraya mal olur, bu muhtemelen yöneticilerinizle konuşmak isteyebileceğiniz bir şeydir, çünkü muhtemelen kodlama standartlarını uygulamak ve uygulamak için yardımlarına ihtiyacınız olacaktır.

Bir çaba gösterdin, ama gerçek şu ki kimse sorumlu değil . "Ama kodlama tarzımı tercih ediyorum", bok yok. Bütün gün kişisel projelerim üzerinde çalışmak ve hala ödeme almak istiyorum.

İnşallah, bunu mevcut güçlere sunabilir ve onlara iki hafta boyunca devam eden Vahşi Batı Şovuna karşı neler yapılabileceğini gösterebilirsiniz . Kapıdan bir şey çıkarmak zorunda kalacaksınız, ancak kontrol eksikliği ve tutarlılık sorununu takip etmeye devam edeceksiniz.

Planınızla birlikte gelen birkaç kişiye odaklanın ve bu karmaşayı düzeltmek ve gelecekteki projelerde ekibinize götürmek için elinizden geleni yapın. Eğer bir araya getiremezlerse geri kalanını reddetmeniz gerekebilir.