Diğer kişi aşırı karmaşık bir çözüm ürettiğinde kod incelemesinde ne diyorsunuz? [kapalı]


37

Geçen gün kodumu incelediğimde ekibimden birinin yazdığı. Çözüm tamamen işlevsel değildi ve tasarım çok fazla karmaşıktı - yani gereksiz bilgiler depolandı, gereksiz özellikler inşa edildi ve temelde kod, altın kaplama gibi pek çok gereksiz karmaşıklığa sahipti ve var olmayan sorunları çözmeye çalıştı.

Bu durumda “neden bu şekilde yapıldı?” Diye soruyorum.

Cevap, öteki kişinin böyle yapmak gibi hissettiğidir.

Sonra, bu özelliklerden herhangi birinin proje spesifikasyonunun bir parçası olup olmadığını veya son kullanıcıya herhangi bir kullanımı olup olmadığını veya ilave verilere herhangi birinin son kullanıcıya sunulup sunulmayacağını sordum.

Cevap hayır.

Öyleyse gereksiz tüm karmaşıklığı silmesini öneriyorum. Genelde aldığım cevap “zaten bitti”.

Benim görüşüme göre bu yapılmıyor, buggy, kullanıcıların istediğini yapmaz ve bakım maliyeti önerdiğim kadar basit yapılsa daha yüksek olacaktır.

Eşdeğer bir senaryo şudur:
Meslektaşım, 10 saat içinde Resharper'da otomatik olarak yapılmış olabilecek 8 saatlik yeniden düzenleme kodunu elle geçirir. Doğal olarak, yeniden yapılanmaya, şüpheli kalitede olduğu ve tamamen test edilmediği için elle güvenmiyorum.
Yine aldığım cevap “zaten bitti”.

Bu tutuma uygun bir cevap nedir?



47
"Aşırı karmaşık bir çözüm inşa ettiniz"
Dante

2
Bu sorunun odağı hangi konu: programcı zihniyeti / tutumu, proje yönetimi (özellikle zaman yönetimi) veya beceri düzeyi?
rwong,

6
Bu muhtemelen işyerine aittir - bu bir programlama sorusu değildir.
GrandmasterB

Yanıtlar:


25

Zihniyet / tutum

  • Örnek olarak kurşun
  • Özel olarak uyar (bire bir, kod incelemesinin dışında)
  • Ekip üyeleri arasında basit bir basitlik anlayışı teşvik edin

Takım yönetimi

  • Bir iş öğesinin özelliklerine daha fazla zaman harcayın (örneğin mimari, algoritma taslağı, kullanıcı arayüzü tel kafes vb.)
  • Ekip üyelerini, bir iş öğesinin kapsamı hakkında netlik aramaya teşvik edin
  • Ekip üyelerini bir iş öğesini uygulama yollarını tartışmaya teşvik edin
  • Başlamadan önce her iş öğesi için makul tahminler yapın ve bunları karşılamak için en iyi çabayı gösterin
  • Ekip üyelerinin "gelişimini" izleyin.
    • Tavsiye edildikten veya bir şeyler yapmanın doğru yolu gösterildikten sonra, ekip üyesinin gelişip iyileşmediğine bakın.

Yetenek seviyesi

  • Geliştirici araçlarını en iyi şekilde kullanmak için çift programlama oturumları veya bire bir eğitim oturumları için biraz zaman ayırın (yeniden düzenleme, kod inceleme)

Proje (risk) yönetimi

  • Zaman uyumsuz olarak daha sık kod incelemesi yapın (Not)
    • "Eşzamansız" hakkında not
      • Kod gözden geçiricisi, değişiklikleri en kısa sürede gözden geçirmek üzere bildirimler / davetiyeler almalıdır
      • Kod inceleme uzmanı, geliştiriciyle herhangi bir toplantı yapmadan önce kodu inceleme şansına sahip olmalıdır.
      • Geliştiriciden açıklama gerekiyorsa, olumsuz bir görüş bildirmeden IM / e-posta yoluyla gayri resmi olarak yapın

69

Diğer kişi aşırı karmaşık bir çözüm ürettiğinde kod incelemesinde ne diyorsunuz?

Diyorsunuz: "Aşırı karmaşık bir çözüm inşa ettiniz."

Öyleyse gereksiz tüm karmaşıklığı silmesini öneriyorum. Genelde aldığım cevap “zaten bitti”.

Bir şeyi değiştirmek için çok geç ise, neden kod incelemesi yapıyorsunuz?


Temel olarak kod incelemesinin sadece hoş, her zaman makul ve rasyonel karakterlerle çalıştığını söylüyorsunuz. Gerçek dünya farklı görünüyor ...
Philip

3
Bazen hoşunuza gitmeyen şeyleri yapmak zorundasınız, örneğin tam bir günlük çalışmayı "işe yaramaz, geriye döndür ve baştan başla" ya da bu satırlar boyunca baştan başa çevirecek karmaşık bir kod yazmaya zorlamak. Berbat ama yaptığın için minnettar olacaksın.
joshin4colours

3
Durumu tam olarak özetleyen basit bir cevap. “Halihazırda yapılmış” olarak diğer cevabınız, aşırı karmaşık bir çözümün bakımda zaman kaybına neden olacağını ve yeniden çalışmanın uzun vadede zaman kazandıracağını açıklamaktır.
DJClayworth

30
+ ∞ "Herhangi bir şeyi değiştirmek için çok geç ise, neden kod incelemesi yapıyorsunuz?"
mskfisher

16

“Zaten yapıldı” tatmin edici bir cevap değil. Tamamlandı, test edilmiş ve çalışıyor demektir. Yararlı bir şey yapmayan her ekstra kod uygun şekilde korunmalıdır (silinmiş).

Yeniden görevlendirmek ve çözümünü optimize etmek isteyen bu görevi ona atayın. Bunu yapmazsa, ona bir çift programcısı atayın ve meslektaşından bir şeyler öğreneceğini umalım.


Eğer ekstra koddan kurtulmak gerçekten bir savaşsa, çalışmaya devam etmesini sağlamak için tam ünite test paketi üretebiliyorsa, SADECE VE SADECE TUTMASI halinde, onun kalmasına izin verebilirsiniz. Her iki durumda da, işi gerçekten tamamlaması gerekiyor.
Michael Kohne

Basit bir gerçek için +1, kodun (açık) hatalara sahip olması nedeniyle test edilmedi.
Ramhound

8

Öyleyse gereksiz tüm karmaşıklığı silmesini öneriyorum. Genelde aldığım cevap “zaten bitti”.

Bu kabul edilebilir bir cevap değil:

  • Değiştirmek için gerçekten çok geç ise, kod incelemesi büyük ölçüde zaman kaybı olur ve yönetimin bunu bilmesi gerekir.

  • Bu gerçekten "değiştirmek istemiyorum" demenin bir yoluysa, daha sonra ortaya çıkacak sorunların / maliyetin kod temeli BECAUSE için ekstra karmaşıklığın BAD olduğu pozisyonunu almanız gerekir. Ve gelecekteki problemler için potansiyeli azaltmak ilk etapta kod incelemesini yapmanızın gerçek nedenidir.

Ve ...

... çözüm tamamen işlevsel değildi ...

Bu muhtemelen gereksiz karmaşıklığın doğrudan bir sonucudur. Programcı o kadar karmaşık hale getirdi ki, artık tam olarak anlayamıyor ve / veya karmaşıklığını uygulamak için zamanını işlev noktalarından ziyade boşa harcıyor. Programcıya, karmaşıklığı ortadan kaldırmanın aslında onu daha hızlı çalışan bir programa götürebileceğini belirtmek faydalı olacaktır.

Şimdi, bu konuda "zorla geri dönme" gücünüz (veya belki de güveniniz) yok gibi geliyor . Fakat öyle olsa bile, rahatsız edici kodlayıcının bir dahaki sefere daha iyi bir iş çıkarması umuduyla (kişiselleştirme olmadan) bu konuda biraz gürültü yapmaya değer.

Bu tutuma uygun bir cevap nedir?

Sonuçta, kendiniz tamir etme gücünüz yoksa, yönetimin dikkatine verin. (Elbette, bu seni popüler yapmaz.)


7

Haklıydın, yanılıyorlardı:

  • YAGNI prensibi kırıldı
  • KISS ilkesinin kırılması
  • kod tam olarak test edildi mi? Hayır ise, o zaman yapılmaz

Bu tutuma uygun bir cevap nedir?

Doğru kod incelemesini yapın. Önerilen değişiklikleri bir neden olmadan uygulamayı reddederlerse, bir kod incelemesinde zamanınızı boşa harcamayı bırakın. Sorunu patronlarına da iletebilirsiniz .


5

Ekibimizin attığı, bu gibi durumlarda durumu önemli ölçüde iyileştiren bir eylem, daha küçük değişiklik gruplarına geçiş oldu .

Bir gün veya daha fazla bir görev üzerinde çalışmak ve sonra (büyük) bir kod incelemesi yapmak yerine, çok daha sık kontrol etmeye çalışırız (günde 10 kereye kadar). Elbette, bu aynı zamanda bazı dezavantajlara sahiptir, örneğin, gözden geçirenin çok duyarlı olması gerekir, bu da kendi çıktısını azaltır (sık sık kesintilerden dolayı).

Bunun avantajı, büyük miktarda yanlış iş yapılmadan önce sorunların erken tespit edilip çözülebilmesidir.


Tek bir günde 10 kez biraz fazla olduğunu söyleyebilirim. Gerçekten zorlamak istersen, 3 veya 4 checkin yoluna girecek, bunun anlamı normalde 8 saatlik bir gün veren her 2 saatte bir check-in yapmak. Ancak 10 checkin aslında hiçbir şeyi gözden geçirmenin, rapor vermenin ya da incelemeye dayanan değişiklikleri uygulamanın vakti gelmediği anlaşılıyor.
Ramhound

@Ramhound Evet, 10 checkin aşırı bir durum, 3-4 kat daha tipik. Ve buna alışmak için biraz zamana ihtiyacı var ...
stefan.s

2

Sorunun kök nedenine odaklanmalısınız:

  1. Programcıların eğitimi, programcılara verilen karmaşıklığın artmasına odaklanmaktadır . Bunu yapabilmek okul tarafından test edildi. Bu nedenle birçok programcı basit bir çözüm uygularlarsa işlerini doğru yapmadıklarını düşüneceklerdir.
  2. Eğer programcı üniversitedeyken yüzlerce kez yaptığı aynı kalıbı izlerse, programcılar tam olarak nasıl düşünürlerse - daha fazla karmaşıklık daha zordur ve dolayısıyla daha iyidir.
  3. Bu nedenle, bunu düzeltmek için, programcı eğitiminde normalde gerekli olana kıyasla şirket gereksinimlerinizin karmaşıklıkla ilgili olarak ne olduğunu kesin olarak ayırmanız gerekir. İyi plan, "en yüksek karmaşıklık seviyesi yalnızca becerilerinizi geliştirmek için tasarlanan görevler için ayrılmış olmalıdır - ve üretim kodunda kullanılmamalıdır" gibi bir kuraldır.
  4. Birçok programcının en çılgın tasarımlarını önemli üretim kodu ortamında yapmasına izin verilmemesi şaşırtıcı olacaktır . Programcıların deneysel tasarımlar yapmaları için zaman ayırın ve tüm karmaşıklığı çitin bu tarafında tutun.

(kod incelemesinde, onu değiştirmek için zaten çok geç)


2

Kod yazıldıktan sonra çalışan hiçbir şey bilmiyorum.

Kod yazılmadan önce, insanlar bunu yapmanın alternatif yollarını tartışabilirler. Kilit nokta, fikirleri birbirine katkıda bulunmaktır, bu yüzden umarım makul bir fikir seçilecektir.

Müteahhitlerle çalışan başka bir yaklaşım daha var - sabit fiyatlı sözleşmeler. Çözüm ne kadar basitse, programcı o kadar fazla tutulur.


1

Dünyayı düzeltemezsin.

Projenizdeki tüm kodu bile düzeltemezsiniz. Muhtemelen projenizdeki geliştirme uygulamalarını düzeltemezsiniz, en azından bu ay değil.

Ne yazık ki, kod incelemesinde yaşadığınız şeylerin hepsi çok yaygın. Kendimi sık sık bulduğum birkaç kuruluşta çalıştım, kendimi on taneyle yazılmış olabilecek 100 kod satırını incelerken buldum ve yaptığınız cevabı aldım: "Çoktan yazıldı ve test edildi" ya da "Biz arıyoruz böcek, yeniden tasarlanma değil. "

Bazı meslektaşlarınızın sizin kadar iyi programlayamadığı bir gerçektir. Bazıları bu konuda oldukça kötü olabilir. Endişelenme. Kötü uygulamalara sahip birkaç sınıf, projeyi yıkmaz. Bunun yerine, çalışmalarının başkalarını etkileyecek kısımlarına odaklanın. Ünite testleri yeterli mi (varsa)? Arayüz kullanılabilir mi? Belgelenmiş mi?

Kötü kodun arayüzü tamamsa, sürdürmek zorunda kalana kadar endişelenmeyin, sonra yeniden yazın. Herhangi biri şikayet ederse, yeniden arama diyoruz. Hala şikayet ediyorlarsa, daha sofistike bir organizasyonda bir pozisyon arayın.


0

Projede, teslim edilebilir kalite kontrol prosedürlerini ve kullanılan araçları kontrol eden standart bir politika olmalıdır.

İnsanlar ne yapmaları gerektiğini ve bu projede kullanılmak üzere hangi araçların kabul edildiğini bilmelidir.

Bunu henüz yapmadıysanız, düşüncelerinizi düzenleyin ve yapın.

Kod incelemesinde standart öğelerin kontrol listesi bulunmalıdır. "Zaten yapıldı" alırsanız ve kişisel olarak değilse, bu geliştiricinin proje yöneticisi veya üst düzey geliştirici olarak çalışmasından sorumlu olmak istemem. Bu tutuma tahammül edilmemelidir. Bir şeyi nasıl yapabileceğimizi, hatta her şeyi nasıl yapabileceğimizi tartışmayı anlayabiliyorum, ancak bir çözüm kabul edildikten sonra yalan söylemeye tahammül edilmemeli ve açıkça belirtilmelidir.


0

Mağazanızın bazı tasarım metodolojilerini uygulaması gerekiyor.

  • Gereksinimlerin açıkça tanımlanması gerekiyor.
  • Gereklilikleri destekleyen kullanım durumları geliştirmelisiniz.
  • Kullanım durumlarını uygulamak için gereken işlevleri belirlemeniz gerekir.
  • İşlevsel olmayan gereksinimleri belirtmeniz gerekir (yanıt süreleri, kullanılabilirlik vb.)
  • Her bir sistem işlevini tekrar kullanım durumuna ve gerçek bir gereksinime eşlemek için bir RTM'ye (Gereksinimler Tracabilty Matrix) ihtiyacınız var.
  • Gerçek bir gereksinimi desteklemeyen herhangi bir işlevi bırakın.
  • Son olarak, kod incelemenizde, tanımlanmış işlevleri doğrudan uygulamayan veya desteklemeyen herhangi bir kodu işaretleyin.

0

Muhtemelen aşırı karmaşık olmasından değil, çünkü bu çoğu insanı daha sonra kötü hissetmesine neden oluyor. Bu zaten gerçekleştiğinde, bunun hakkında bir kelime bile söylemeden çok sayıda kod yazıldığını varsayıyorum. (Neden böyle? Çünkü bu kişi yetkisine sahip, bu yüzden kodunun gerçekte gözden geçirilmesi gerekmiyor mu?)

Aksi halde kod incelemesini daha az resmi ancak daha sık yapacağımı tahmin ediyorum. Ve büyük modüller yazmadan önce belki de hangi yaklaşımı uygulayacağınızı hızlıca tartışmalısınız.

"Bu çok karmaşık" demek sizi hiçbir yere götürmez.


0

Bu talihsiz bir durum, ancak Kod İncelemeleri, gelecek için şimdiki zamandan daha fazla. Özellikle kurumsal / kurumsal bir ortamda, gönderilen kod her zaman gönderilmeyen koddan daha değerlidir.

Bu, elbette, kod incelemesinin ne zaman tamamlandığına bağlıdır. Geliştirme sürecinin bir parçası ise, o zaman şu anda bir miktar fayda elde edebilirsiniz. Fakat eğer CR, ölüm sonrası bir tedavi olarak daha fazla muamele görürse, o zaman gelecekte daha iyi neler yapılabileceğine dikkat çekiyorsunuz. Sizin durumunuzda (diğerlerinin söylediği gibi), genel olarak YAGNI ve KISS ve belki de bu ilkelerin uygulanabileceği belirli alanlardan bazılarını belirtin.


0

Aşırı karmaşık ne demektir? Belirsiz bir ifade verirseniz, cevap olarak belirsiz / tatmin edici bir cevap alırsınız. Bir kişiye aşırı karmaşık olan, bir başkası için mükemmeldir.

Gözden geçirmenin amacı, "aşırı karmaşık" ifadesinin ifade ettiği şeyden hoşlanmadığınızı söylemekten değil, belirli sorunları ve hataları belirtmektir.

Eğer bir sorun görürseniz (aşırı karmaşık), daha somut bir şey söyleyin:

  • X bölümünü Y olarak değiştirmek, kodu basitleştirmez veya anlaşılmasını kolaylaştırmaz mı?
  • Burada X bölümünde ne yaptığını anlamıyorum, bence yapmaya çalıştığın şey bu. Bunu yapmanın daha temiz bir yolunu sunun.
  • Bunu nasıl test ettiniz? Bunu test ettin mi? Aşırı karmaşık ise, bu genellikle boş bakışlara yol açar. Testler istemek, sık sık kişinin orijinal kodu nasıl test edeceğini bulamadığında kodlarını kendi kendine basitleştirmesini sağlayacaktır.
  • Burada bir hata var gibi görünüyor, kodunu değiştirmek sorunu çözecektir.

Herkes sorunları, özellikle de belirsizleri gösterebilir. Çözüm sunabilecek çok daha küçük bir altküme var. Yorum yorumlarınız olabildiğince spesifik olmalıdır. Bir şeyin aşırı karmaşık olduğunu söylemek pek bir şey ifade etmiyor, hatta başkalarının kodu anlamadığınız için SİZ'in beceriksiz olduğunu düşünmesine neden olabilir. Çoğu geliştiricinin iyi veya kötü tasarım arasındaki farkın bir ipucuna sahip olmadığını unutmayın.


Kodun açık hataları var. Yazarın çözümün kendisinin de yanlış olduğunu düşünmesi gerçeği vurgulamaktadır, hatalar vardır. Kodunuzda hatalar varsa ve tam regresyon testi olmadan yakalayamadığınız açık olmayan hatalardan söz etmiyorum, söz konusu kodla ilgili bir sorun var.
Ramhound

@Ramhound: Eğer böcek varsa, o zaman belirli böcekleri işaret edin. Eğer hataların giderilmesi, gözden geçirme sürecinin bir parçası değilse, gözden geçirmeyi gerçekleştirmenin amacı nedir? Dediğim gibi, aşırı karmaşık bir hata değildir. Bu kesinlikle kısa bir gelecek, ancak aşırı karmaşık olduğuna inanan tek kişi OP ise ve başka kimse o zaman iyi yapmıyor. Sıkı çalışın, o sırada standartlarınızda öncü ve kararname haline gelin. OP'ye sempati duyabilirim, aynı sorunları yaşadım, şimdi insanları istediğim değişiklikleri yapmaya yönlendirme yetkisine sahibim, başka şeylerin daha yüksek önceliklere sahip olduğunu görüyorum.
Dunk

0

Bazen, bazı "Çevik" ilkelere odaklanmak bir grup olarak buna değerdir - biraz kursun düştüğü görünen bir gruba veya bireye yardım edebilirler.

Odaklanma, ekibinizin büyük bir yeniden çalışması anlamına gelmek zorunda değildir, ancak hepiniz oturmalı ve size en çok hangi uygulamaların takım olarak ithal edileceğini tartışmalısınız. En azından bunları tartışmayı önerebilirim (ve muhtemelen bir kaç tane daha):

  • İşe yarayabilecek en basit şey mi?
  • İhtiyacınız olmayacak (teknik özelliklerde olmayan sorunları mı çözüyorsunuz)
  • Kodlamadan önce testi yazın (Kodunuzu odaklamanıza yardımcı olur)
  • Kendini tekrar etme

Ayrıca neyin işe yarayıp neyin işe yaramadığını ve hala neye ihtiyaç duyulduğunu da gözden geçirmek (Haftalık?) Gerçekten yararlı olabilir ... Eğer başka bir şey yoksa, neden ekip değerlerini ve uygulamalarını tartışmak için haftada bir saat iş yapmıyorsunuz?


0

Eskalasyon, teknik fikirli bir yöneticiniz varsa. Bu kırılması gereken bir alışkanlık gibi geliyor.

Kod spesifikasyona göre oluşturulmamışsa, tanım gereği kod incelemesinde başarısız olması gerekir. "Hiç kimsenin istemediği bir şeyi yaptık, işe yaramadığı için oraya bırakacağız" kavramını anlamıyorum.

Bu, herhangi bir geliştiricinin girmesi için kötü bir alışkanlıktır. Eğer bir tasarım uzmanı için çalışıyorsa, iyi bir sebep olmadan eşleştirmemek hayır demek değildir.


0

Bir kelime: çevik

Kesinlikle her şeyi çözmez. Ancak yinelemelerinizde hüküm sürerek (örneğin 1-2 hafta), devam etmekte olan çalışmayı sınırlandırın ve sprint planlamasını / incelemesini kaldırarak, bu şelale benzeri hatalardan kaçınmalısınız. Gerçekleşmekte olan şeyle ilgili daha iyi bir görünüme ihtiyacınız var - bu yapılırken.

Proje bazlı normal gelişim için, Scrum yaklaşımını benimsemeyi tavsiye ederim . Sürekli gelişim / entegrasyon ortamları için ve özellikle aynı veya ilgili projeler üzerinde çalışan birçok geliştiriciniz varsa, Kanban'ın unsurlarını eklemeyi düşünün . Bir başka etkili yaklaşım ise , Extreme programlama için tanımlanmış bir uygulama olan çift programlamanın kullanılmasıdır .

Durumunuz pek benzersiz değil. Küçük ekiplerde bile, süreç şu an içinde bulunduğunuz durumdan kaçınmanıza yardımcı olmak için uzun bir yol kat edebilir. Uygun görünürlük ve makul bakımlı bir birikim ile, bunun gibi sorular sprint planlama kararları olur - sizi teknik borç yönetiminden kurtarır .


-1

Geçmişte söylediklerim "bu kod karmaşık ve ne yapmaya çalıştığından emin değilim, ya basitleştirmek ya da daha net bir şekilde yazmak mümkün mü?"


-2

Kodlarını sildikten / geri döndürdükten sonra kodlama yapacaksınız: "Hata! Kodunuz gitti. Lütfen tekrar yazın. Zaten bir kez yazmış olduğunuzdan, YALNIZCA spec tarafından istenen kodu sağlamak için yirmi dakikadan az bir süreye ihtiyacınız olacak.

"Bir sonraki yorumum 20 dakika sonra.

"İyi günler."

Herhangi bir argümanı kabul etmeyin!

Tamam, IMHO

Chris


Patronumun bu şekilde çalışmamasına sevindim.

@Jon: İnsanlar "iyi zaten yapıldı" da olduğu gibi profesyonelce yanıt verdiklerinde, altı yaşındaki çocuğumun dediği gibi, onlara çocuk gibi davranmak zorundasınız.
cneeds

2
Katıldığımı söyleyemem. Eğer "onlara çocuk gibi davranıyorsanız", halkınızdan ne gibi sonuçlar elde etmeyi bekliyorsunuz? IMHO'nun daha yapıcı olduğu başka yaklaşımlar da var.

Çocuk gibi profesyonellere davranmayı savunmuyorum. Verilen örnekte, işlevsellik için çağrılmayan buggy kodunu yazan ve meşru sorulara çocukça cevaplar veren inatçı, alçakgönüllü birine sahibiz. Dan bununla başa çıkmanın en iyi yolunu istiyor. En popüler yol değil.
cneeds

Neyse ki ekibimde "çocuklarım" yok, bu yüzden onlara oldukları gibi profesyonellerden başka bir şey olarak bakmaları gereksiz. İşlevsellikten hoşlanmadıkları bir şey eklemiyorlar (zamanımı ve paramı boşa harcıyorlar), oldukça sağlam bir kod yazıyorlar ve bir şeyi tekrar ziyaret etmeleri veya gözden geçirmeleri istendiğinde bunu yapıyorlar ve deneyimlerden öğreniyorlar.
cneeds
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.