Geçmişte SoftwareEngineering.SE üzerine bu konuda çok şey yazdım ve benzer durumlarda kendimdeydim. Bu nedenle, sorunuzu okurken birkaç ipucu vermeye ve not ettiğim birkaç konuyu vurgulamaya çalışacağım.
Ama önce önemli bir konu hakkında konuşalım: şirketteki rolünüz.
Rolün
Patronunuzdan bir şeyler geliştirmek için açık bir yetkiniz olabilir ve hiyerarşide diğer geliştiricilerin siparişlerinizi dinlemek zorunda olduğu bir yer olabilir . Ya da aynı rol ve aynı otoriteye sahip olan akranlarınız arasında olabilirsiniz, seçeneğiniz sadece ... iyi ... bir fikirdir .
Her iki durumda da, önemli olan hiyerarşideki yeriniz ve daha fazlasıdır:
Diğer geliştiriciler senin hakkında ne düşünüyor. Sana aptalca şeyler soran sinir bozucu bir adam gibi davranırlarsa, uzaklaşamazsın. Teknik liderlerin ve proje yöneticilerinin ekip üzerinde kesinlikle bir etkisi olmadığı birçok durum gördüm, çünkü ekip bu “liderlerin” aldıkları kararları almak için gerekli teknik altyapıya sahip olmadığını biliyordu (veya düşündü). Öte yandan, akranları tarafından gerçekten dinlenmiş birkaç geliştirici gördüm, çünkü bu geliştiricilerin yetenekli ve deneyimli olduğunu biliyorlardı.
Ekibiniz ne kadar sağlam ve onları motive eden şey. Her geliştiriciye KLOC / ay için ödeme yapılan bir şirket düşünün. Stil hakkında söylediğiniz her şey iş arkadaşlarınız için önemli mi? Muhtemelen hayır, çünkü nadir olarak daha az ödeme yapmak isteyen kişilerdir. Genel olarak, eğer bu bir takım değil, aynı proje üzerinde çalışan bir grup insan ise, hiçbir şeyi geliştiremezsiniz.
Buna bağlı olarak, herhangi bir değişiklik yapmanın çabalarına değip değmeyeceğine karar verebilirsiniz. Eğer sesiniz yoksa ve takım uyumu yoksa gidip başka bir iş arayın. Yetenekli, saygın bir geliştirici olarak biliniyorsanız ve güçlü bir takım hissi varsa, patronunuzdan veya diğer takımlardan gelen düşmanlıkla karşı karşıya kalsanız bile işleri nispeten kolay bir şekilde iyileştirebilirsiniz.
Her durumda, ekibinize baskı yapmamak önemlidir. Onlarla çalışın , onlara karşı değil. Onlara emir vermeyin, ama onları hedefe doğru yönlendirin.
Şimdi, ipuçları.
stil
Bir keresinde güzelce kodlama stilini ve mevcut kodun çoğunun biçimlendirmesini takip etmeyi istedim (ne yazık ki resmi bir kodlama stili belgesi yok). Ama işe yaramadı ...
Tabii ki olmadı, çünkü yapılması gereken bu değil.
Stil sıkıcı .
Aşağıdaki stil sıkıcıdır .
Kodlama stili belgesi yazmak sıkıcıdır ( ve çok zordur ; on yıldan fazla bir süre dil ile çalışmadığınız sürece bunu bile denemeyin).
Okuma tarzı belge sıkıcı .
Stil hataları için kodu gözden geçirmek sıkıcıdır .
Tarzımın sizinkinden daha iyi olduğunu söylemek heyecan vericidir , özellikle de bir stilin diğerine göre kesinlikle nesnel bir yararı olmadığında. Cidden, her aklı başında insan, yazmanın if (x)doğru yolunun onu yazdığım yol olduğunu bilir , if(x)ya da değil if ( x )!
Bu nedenle:
Stil değerlendirmeleri yapmayın. Bu stil dama işidir. Bu sevimli uygulamaların beyninize birkaç faydası vardır: tüm projeyi saat veya gün değil, milisaniye içinde kontrol ederler ve hata yapmazlar ve stil hatalarını kaçırmazlar.
Kendi stil standardınızı yazmayın. Yine de yanlış yapacaksınız ve iş arkadaşlarınız sizi kötü seçimler yaptığınızı söyleyecek.
Geliştiricileri 2.000 stil hatasını düzeltmeye zorlamayın.
Taahhütte stili otomatik olarak zorla. Stil hataları olan kodun sürüm kontrolünde yeri yoktur.
Projenin başından itibaren yapın. Mevcut bir projede stil kontrolü kurmak imkansızdır.
Bununla ilgili daha fazla bilgi için SE.SE'deki bu cevabın ilk bölümünü okuyun .
Ayrıca:
- Çok katı olma. Örneğin,
jslintkod uyumlu kod yazmak oldukça can sıkıcı bir durumdur, bu yüzden kesinlikle ihtiyaç duyulduğunda (veya ekibinizin tüm üyeleri bunu kullanmaktan memnunsa) yapılmalıdır. Aynı durum statik kontrol araçları için de geçerlidir; örneğin, .NET'in maksimum düzeyde Kod Analizi, çok az fayda sağlarken çok baskıcı ve iç karartıcı olabilir; orta seviyede ayarlanan aynı takım ise çok yardımcı oluyor.
Kod incelemeleri
Artık kod incelemeleri sırasında stil hakkında endişelenmenize gerek yok, daha ilginç şeylere odaklanabilirsiniz: kaynak kodunu geliştirmek (düzeltmek vs.).
Farklı kişiler kod incelemelerine farklı tepki verirler. Bazıları bunu bir fırsat olarak görür. Diğerleri bundan nefret eder. Bazıları onlara söylediğiniz her şeyi dinler, notlar alır ve doğru bile olsa tartışmazlar. Diğerleri her konuda tartışmaya çalışır. Kişiliğine göre her geliştiriciyle başa çıkmanın bir yolunu bulmak size kalmış. Genellikle aşağıdakilere yardımcı olur:
Özellikle geliştirici küçükken ve gerçekten kötü bir kod yazarken, kod incelemelerini özel olarak yapın.
Kişisel bir şey olmadığını gösterin: kodu inceliyorsunuz, kişinin becerilerini değil.
Bir kod incelemesinin asıl amacını gösterin. Amaç, bir geliştiricinin ne kadar kötü olduğunu göstermek değildir. Amaç, iyileştirme fırsatları sağlamaktır.
Asla tartışma. Burada ikna etmek için değil, uzmanlığınızı sağlamak için buradasınız.
Gözden geçirenin, incelemeden bir şeyler öğrenebilecek tek kişi olduğunu asla varsaymayın. Hem kodu okuyarak hem de anlamadığınız kısımlar hakkında açıklama sorarak öğrenmeye buradasınız.
Kod incelemesi tamamlandığında, kişinin kodunu gerçekten geliştirdiğinden emin olun. Geliştiricilerin gerçek toplantı sona erdiğinde kod incelemesinin sona erdiğini düşündükleri birkaç durumum vardı. Yalnızca yeni kod için onlarla paylaştıklarınızı uygulamaya çalışarak yeni özelliklerine geri dönüp geri dönerler. Kod incelemesi için iyi bir izleme aracının olması yardımcı olur.
Şirketteki özel rolünüzden ve diğerlerine kıyasla uzmanlığınızdan bağımsız olarak, kodunuzun da incelemeye tabi olması gerektiğini unutmayın. Başkalarının kodunu da inceleyen tek kişi sen olmamalısın.
Teknik bir lider olarak çalıştığım yeni bir projede, iş arkadaşlarıma, benim de dahil olmak üzere birbirlerinin kodlarının incelemelerini yapmanın rollerinin olduğunu açıklamakta zorlandım. Teknik liderinin kodunu gözden geçirmek üzere olan bir stajyer korkusu, koddaki ilk sorunları bulur bulmaz ortadan kaybolur ve aramızda kim kusursuz kod yazar?
Eğitim
Kod incelemeleri, programlama ve yazılım tasarımının bazı yönlerini öğretmek ve öğrenmek için harika bir fırsattır, ancak diğerleri eğitim gerektirir.
Eğer iş arkadaşlarınızı eğitebiliyorsanız, bunu yapın. Yönetiminiz eğitim fikrinde düşmansa, gayri resmi olarak yapın. Bu tür eğitim oturumlarını resmi olmayan toplantılar şeklinde yaptım, hatta bazen basit bir tartışma olarak bile, bazen yönetim tarafından kesintiye uğradım ve daha sonra izledim.
Doğrudan eğitimin yanı sıra, McConnel'in Code Complete gibi kitapları yeterince iyi bildiğinizden emin olun ve bu kitaplar hakkında iş arkadaşlarınızla konuşun. Onlara açık kaynaklı projelerin kaynak kodlarını okumalarını, yüksek kaliteli kodlara özel örnekler vermelerini önerin. Ve tabii ki, yüksek kaliteli kodu kendiniz yazın.
Kişilere değil bağlama odaklanın
Bu durumu sadece 'kötü şirket kültürüne', 'deneyimsiz mezunlara' vb. Odaklanmadan nasıl çözebilirim?
Bu mezunların bir amacı var: deneyim kazanmak, bir şeyler öğrenmek, daha yetenekli olmak. Yıllar sonra, boktan kod yazarlar ve programlama hakkında hiçbir şey bilmezlerse, muhtemelen ekibiniz veya şirketiniz bu fırsatı vermiyordur.
Ekibinizin deneyimsiz mezunlara sahip olmasına odaklanıyorsanız, bu yardımcı olmaz. Bunun yerine, onlar için ve onlarla neler yapabileceğinize odaklanın. Kod incelemeleri ve eğitim durumu iyileştirme tekniklerinden ikisidir.
Kötü şirket kültürü farklı bir canavardır. Bazen değiştirilebilir. Bazen olamaz. Her durumda, sen hatırlamak olan bu şirketin bir parçası, bu nedenle şirket kültürünün bir parçasıdır. Er ya da geç, onu değiştiremez ve doğal olarak kötü bulursanız, gitmeniz gerekir.
Metriklerinizi doğru yapın
Şu anda tam olarak nasıl ölçüm yapıyorsunuz? Geliştirici başına günlük taahhüt sayısını ölçüyor musunuz? Veya programcı başına aylık KLOC? Ya da kod kapsamı? Yoksa bulunan ve düzeltilen hataların sayısı? Veya regresyon testlerinde yakalanan potansiyel hataların sayısı? Yoksa Sürekli Dağıtım sunucusu tarafından yapılan geri dönüşlerin sayısı?
Ölçtüğünüz şeyler önemlidir, çünkü ekip üyeleri çalışmalarını ölçülen faktörlere uyarlar. Örneğin, birkaç yıl önce çalışmak zorunda olduğum bir şirkette ölçülen tek şey , kişinin ofiste geçirdiği zamandı. Söylemeye gerek yok, bu daha iyi kod sunmayı veya daha akıllıca çalışmayı ya da hiç çalışmamayı teşvik etmedi.
Olumlu ve olumsuz pekiştirmeyi bulmak ve ölçülen faktörleri zaman içinde ayarlamak esasen ekip üyelerinde kaldıraçtır. Düzgün yapıldığında, basit hiyerarşi ile elde edilemeyecek sonuçlar elde etmeyi mümkün kılar.
Sizi rahatsız eden şeyler onları ölçülebilir kılar. Onları ölçün ve sonuçları herkese açık hale getirin. Ardından sonuçları iyileştirmek için diğer ekip üyeleriyle birlikte çalışın.
Örneğin, takım üyelerinin sınıflar, sınıf üyeleri ve değişkenler adına çok fazla yazım hatası yaptığını düşünelim. Bu sinir bozucu. Bunu nasıl ölçebilirsin? Bir ayrıştırıcı ile koddaki tüm kelimeleri çıkarabilir ve bir yazım denetleyicisi kullanarak, hata ve yazım hataları içeren kelimelerin oranını belirleyebilirsin (% 16,7).
Bir sonraki adımınız, hedef oran konusunda ekibinizle anlaşmaktır. Bir sonraki sprint için% 15, bir sonraki sprint için% 10, altı haftada% 5 ve iki ayda% 0 olabilir. Bu metrikler her taahhütte otomatik olarak yeniden hesaplanır ve ofiste büyük bir ekranda görüntülenir.
Hedef orana ulaşmazsanız, ekibiniz yazım hatalarını düzeltmek için biraz daha zaman harcamaya karar verebilir. Veya ekibiniz, geliştirici başına oranı hesaplamanın ve bu bilgileri büyük ekranda görüntülemenin daha iyi olduğunu düşünebilir. Veya ekibiniz hedefin çok iyimser olduğunu ve onu gözden geçirmeniz gerektiğini görebilir.
Hedef orana ulaşırsanız, bir sonraki adım hata ve yazım hatası sayısının zamanla artmayacağından emin olmaktır. Bunun için derlemenizde yazım hatalarını kontrol eden ve en az bir hata bulunursa derlemeyi kaldıran ek bir görev oluşturabilirsiniz. Artık bu sorundan kurtulduğunuza göre, büyük ekranınız yeni ilgili istatistikleri göstermek için yeniden kullanılabilir.
Sonuç
Sorunuzda belirtilen her yönün cevabıma eklediğim tekniklerle çözülebileceğine inanıyorum:
Diğer geliştiriciler projeye katıldıklarında, farklı bir kodlama stili kullandıklarını fark ettim (bazen tamamen farklı bir stil)
Taahhütte stili otomatik olarak uygulamak zorundaydınız .
ve genellikle mülk erişimcileri gibi modern dil özelliklerini kullanmazlar (bu, Objective-C'de nispeten yenidir).
Hem kod incelemeleri hem de eğitim , dil bilginizi aktarmak için burada.
Bazen çerçevenin benzer özelliklerini kullanmak yerine kendi bisikletlerini icat ederlerdi
Hem kod incelemeleri hem de eğitim , çerçeve bilginizi aktarmak için burada.
ya da öğrendikleri diğer programlama dillerinden ya da kalıplardan kod tabanımıza aktarabilirsiniz.
Bu mükemmel bir şey. Onlardan öğrenmeniz için bir fırsat gibi görünüyor.
Çoğu zaman kötü İngilizce nedeniyle yöntemleri veya değişkenleri düzgün bir şekilde adlandıramazlar
Kod incelemeleri aynı zamanda uygun adlandırmaya da odaklanmalıdır. Bazı IDE'lerin de yazım denetleyicileri vardır.
Bazen IDE olmasaydı bence herhangi bir girinti veya biçimlendirme olmadan tüm kodları yazacaklarını düşünüyorum.
Tabii ki ederlerdi. Stil sıkıcıdır ve otomatikleştirilmelidir.
Temel olarak, yazdıkları koddan nefret ediyorum.
Kod incelemeleri bölümünden hatırlayın: “Amaç, bir geliştiricinin ne kadar kötü olduğunu göstermemek. Amaç, iyileştirme fırsatları sağlamak. ”
Kötü biçimlendirilmiş / organize edilmiş ve bazen projenin geri kalanından kökten farklı.
Otomatik stil kontrolü.
Spagetti'lerini sanat eserlerime eklediklerinde çok üzülüyorum
Bir dakika ne?! Sanat eseri?! Bil bakalım ne oldu? Bazı kişiler (altı ay içinde sizler de dahil), kodunuzu bir sanat eseri olmaktan uzak bulabilir. Bu arada, çalışmanızı bir sanat eseri olarak ve onların saçmalık olarak düşünmenin kimseye yardımcı olmayacağını anlayın . Sen de dahil.
Öğrenmeye zahmet etmeyecekleri veya umursamayacakları gibi gittikçe daha fazla hissediyor: sadece onlardan gerekli olanı yapıyorlar ve eve gidiyorlar.
Elbette onlardan istediklerini yapacaklar. Unutmayın: bağlam değil, kişiler değil ve ölçümlerinizi doğru yapın . Bağlam onların yaptıkları işte en iyi olmalarını gerektiriyorsa, yapacaklardır. Bağlamın ayda mümkün olduğunca çok KLOC üretmesi gerekiyorsa ve başka bir şey yapmıyorsa, bunu da yapacaklardır.