Biri size kodunuzun bir karışıklık olduğunu söylese nasıl tepki verirsiniz?


86

Ben iyi bir programcıyım ya da daha önce düşündüm. Programlamayı hep çok seviyorum. Ve beni daha iyi bir programcı yapmak için programlama hakkında birçok şey öğrenmek istiyorum. 1 yıl programlama okudum ve şimdi yaklaşık 2 senedir programcı olarak çalışıyorum. Kısacası, neredeyse 3 yıllık programlama tecrübem var.

Ekibimiz 5 programcıdan oluşmaktadır ve dördümüz yeniyiz, 1'inde 3 yıldan fazla deneyime sahibiz. Neredeyse bir yıldır bir program için çalışıyoruz ve hiç kimse kodumu incelemiyor ve çalışmam için bir sayfa verildi. Hiç bir kod incelememiz olmadı ve hepimiz yeniyiz, bu nedenle temiz bir kodun neye benzediğini bilmiyoruz. Bence programcılar kendileri mi öğreniyor?

Kapsamlı bir test yapmadan programımızı programa yerleştirdik. Artık çok sıkı ve kodda değişiklik yapmadan önce onay ve kod incelemesine ihtiyacımız var. İlk defa, birisi kodumu inceler ve bunun bir karışıklık olduğunu söylüyor.

Kendimi çok üzgün ve incinmiş hissediyorum. Programlamayı ve onlara gerçekten çok fazla zarar verdiğini söylemelerini seviyorum. Gerçekten kendimi geliştirmek istiyorum. Ama filmlerde olduğu gibi dahice bir programcı değilim gibi görünüyor. Bana nasıl daha iyi olacağına dair tavsiyede bulunabilir misin? Hiç kodunuzu eleştiren bir şey yaşadınız mı ve gerçekten incinmiş hissediyor musunuz? Bu olaylarda ne yaparsın?


51
"Ama filmlerdeki gibi dahice bir programcı değilim gibi görünüyor" . Hata, yazılım geliştiricileri, bilgisayar korsanları ve gerçek dünya teknolojisi ile ilgili diğer her şey hakkında filmlerde gördüğünüze inanmak.
Stephen C

160
Tebrikler! Bugünden itibaren, resmen gerçek bir programcısın! Korkunç olduğunu söylemek, bu mesleğin en önemli adım taşlarından biridir. Bunu anlayamıyorum: Her profesyonel programcıya, bir noktada ya da başka bir yerde çok kötü olan bir şey söylendi ve yeni olduğun zaman acı çekiyor, ama doğru ve kursta daha çok duyacaksın. Kariyerin Buck up, mesleğe yeni katıldın. İyi programcılar bu sıkıntıları alıp aynı hataları yapmamayı öğrenirler (bunun yerine her seferinde farklı şeyler yaparlar!)
Jimmy Hoffa

15
@newbie yeniyken ve biraz ego ürettin ve kötü olduğunu anlayacak kadar batırmadın, ben kötüyüm, bu işte hepimiz kötüyüz çünkü gerçekten zor. Eğer hiç bir egonuz kalmadıysa, daha fazla hata yaptıktan sonra bu arada gider. Cidden, eğer profesyonel bir mühendisseniz ve elinizi kaldırmadan
Jimmy Hoffa

14
Hüsrana uğramış? Neden bu kadar hayal kırıklığına uğradın? Benim eski CTO (o özellikle beni adını vermedi, ama bizim takımda herkes bahsediyor kim biliyordu) yazdığı bir makalede beni aradı ve aldığım ilk şans Benim burada cevapları birinde makaleyi alıntı . Ayrıca, ben bu soruda açıklanan şeytani geliştiriciyim .
OP'yi

19
Milleti hatırlayın, çünkü birileri kodun kötü olduğunu söyledi çünkü bunu doğrulamaz. "Kodunuz bir karışıklıktır" diye duyduktan sonra "OP hak ediyor" ve işte neden. " Ardından, analiz başlayabilir.
Tony Ennis,

Yanıtlar:


175

Gerçek şu ki, muhtemelen 2 yıl içinde mevcut kodunuzu göreceğiniz zaman bunun bir karışıklık olduğuna katılacaksınız. Programlamayı öğrenmek hiç bitmeyen bir süreçtir ve her zaman bu konuda sizden daha iyi olan biri olacaktır.

Bu nedenle, kodunuzun bir karışıklık olduğunu söyleyen kişi yalnızca bir anlam ifade etmez ve programcılar arasında yaygın olan "Ben daha iyi yaparım" hastalığının başka bir örneği değilse, ona kodunuzda tam olarak neyin yanlış olduğunu sormalısınız. iyileştir.


27
Haklısın! 2 yıl önce koduma gülüyorum. Sanırım bundan iki yıl sonra da koduma güleceğim. Sadece biraz duygusallaştı. Her neyse, daha iyi bir olmaya çalışacağım.
acemi

5
@newbie: İşte gidiyorsunuz. Gerçekten bilmek istediğin şey bu. Benim sloganım, on yıldan fazla bir süredir "asla iki yıl olacağım kadar iyi olamam" olmuştur. Ve henüz yanılmamıştım. Bunu kariyerimde sizinkinden daha ileriye dek öğrenmedim. Meslektaşın sana büyük bir iyilik yaptı.
pdr

27
Bence altı ay, kodunuzdan nefret etmek için bol bol vaktiniz olmalı. Bir gün, altı ay önce yazdığım ve bu konuda nefret ettiğim bir şey bulamadığım kodları bulabileceğimden endişeleniyorum . Programcı olarak yetişmediğimin bir işareti olurdu.
zzzzBov

37
2 yıl! Öğleden sonraları, sabahları yazdığım kodla gülerim.
dan_waterworth

9
Ayrıca kod incelemelerinin inanılmaz derecede yararlı süreçler olduğunu söyleyebilirim. Bu cevabın belirttiği gibi, eğer iyi bir programcıysanız, zamanla bunun da korkunç bir kod olduğunu düşüneceksiniz - bu doğaldır. Yine de, kod gözden geçiricinizin inceleme sürecine doğru yaklaşmadığını da söyleyebilirim. Bilginin aktarıldığı yapıcı bir eleştiri süreci olmalı, gözden geçirilen programcının önemsiz hissetmesi için yapılan olumsuz bir ceza süreci değil. Bu, incelemeden gelebilecek olan malların çoğunu olumsuz etkiliyor.
Mattygabe

68

Ne kadar iyi kodladığınızla gurur duymayın. Ne kadar iyi öğrendiğinizle gurur duyun. Sonra, kodunuzun iyileştirilmesi gerektiğini öğrenmek, bir programcının ne kadar kötü olduğunun eleştirisi olarak karşılaşmak yerine, öğrenmede ne kadar iyi olduğunuzu gösterme fırsatı sunar.

Neden bahsettiğim hakkında hiçbir fikriniz yoksa http://www.perlmonks.org/?node_id=270083 adresini okuyun .


güzel makale. :) yani ben sadece egomla ilgileniyorum.
acemi

2
@newbie Kesinlikle. Kodunuzu eleştirdiğinizde, yalnızca egonuz bu kodun kalitesine bağlıysa sizi üzebilir. Egodan koddan boşan, ve problem ortadan kalkar.
btilly

5
Ne kadar iyi öğrendiğinizle gurur duymayı kabul ediyorum, ancak kodlama şeklinizle de gurur duymalısınız. Nasıl kodladığınızla gurur duymazsanız, daha iyi olmaya yönlendirilmeyeceksiniz.
Bryan Oakley

1
Öğrenmede gurur duyma konusunda da dikkatli olmalısınız, çünkü eğer öğrenme konusunda gerçekten iyi değilseniz, aynı sorunlara yol açabilir.
Nico Burns

Gururun 7 ölümcül günahtan biri olduğunu sanıyordum? Bugünlerde bunu öneren herkesin nesi var? İyi bir iş çıkardığın içeriği hissetmeye ne dersin?

40

20 yaşından sonra kendi kodumun bir kısmının hala bir karışıklık olduğunu biliyorum. Asıl sorun, mümkün olan en iyi kodu yazmak ile işin yapılması için gerekenleri yazmak arasında bir karar vermek. Kararlaştırılmış bir zaman diliminde işin yapılması, her gün teknik mükemmellik için hiç bitmeyen bir arayışa dayanıyor.

İşin püf noktası, kabul etmeyi öğrenmek. Daha iyisini yapabileceğini kabul etmeyi öğren. Kusurlarla yaşamayı öğrenin. Bu sefer ve muhtemelen bir sonraki seferde mükemmel olamayacağınızı ve alternatifin sunmadığı için bilinçli bir seçim olduğunu kabul etmeyi öğrenin. Ve bu daha kötü.

Uyarı: Bunların hiçbiri "hatalı kod tamam" olarak okunmamalıdır.


2
"İşi bitirmek" için çabalamak vasat için çabalıyor. Haklısın, işe yarıyor ve etkili olabiliyor - sadece Çin ürünlerine bak. Ancak işleri daha iyi yapmak için çabalamak, arkadaşlık yaparken 20 yıllık programlamayı değerli kılan şeydir. 20 yıl geriye bakın, ne ortaya çıkıyor - işi bitirmek mi yoksa işi gururla yapmak mı?
kingdango

9
Garip kod tabanlı bir sanat projesi yazmıyorsan, her zaman "işi bitirmek" ile ilgili. "İyi kod" ile "vasat kod" yazılması, acil görevi tamamlama ve gelecekte işi yapmak için kodun daha bakımlı hale getirilmesi arasında bir denge kurar. Bunu gözardı etmek mükemmeliyetçiliğe yol açar, bu da hiçbir şey yapmamayı sağlar. Hızlıca yazılmış sıradan kod, bir kerelik komut dosyası için yavaş yazılmış iyi koddan daha iyidir.
Steven Burnap

8
Parasal borçlar gibi, teknik borç da kısa sürede artmakta ve teknik borçların nasıl yönetileceğini öğrenmek gerçek dünyadaki bir programcının temel becerilerinden biridir. Her seferinde mükemmel bir iş yapmak için yeterli zamanı olan herkes , inanılmaz derecede iyi, ciddi şekilde çalışmakta ya da kendilerini kandırıyor.
Mark Booth,

1
Doğru dengeyi belirlemek zor olabilir, özellikle vasat bir tasarımla ilerlemenin etkileri, vasat bir ömrünün tamamıyla yeterli olduğu kanıtlandığında, bir tasarımı rafine etmek için çok fazla zaman harcamaktan çok daha fazla görülebilir.
Supercat

1
Bu, beni “işi halletmek” ve “teknik mükemmellik” olarak tasvir ettiğiniz dünyalar olmak zorunda olmadığı için üzüyor. Şahsen, tamamen kısıtlı olan ve zaman kısıtlamaları nedeniyle ve bu şekilde "işi bitirmek" nedeniyle serbest bırakılan bir parça kodum için büyük bir memnuniyet duymuyorum. .
crmpicco

39

Herkesin kodu bir karışıklık ve iyi programcılar yok.

Var:

  • hızlı gemi programcıları,
  • Her zaman anlamsal olarak doğru kod gönderen programcılar,
  • Her zaman en uygun çözümü ve en hızlı algoritmayı sunan programcılar,
  • gözü kolay olan programcılar.

Neredeyse hiç kimse aynı kişi olmuyor.

Ve büyümesi gereken butthurt programcıları var ve:

  • neyin yanlış olduğunu sor
  • kişisel olarak yorum yapma, bir insan olarak değerlerinin bir ölçüsü olarak;
  • Orada takım halinde sözdizimi kuralları vardır ve bunlar takip edilmelidir lazım ve onlar farkında olan keyfi, bu yüzden tartışılmak içindir değiliz bıktıracak hiçbir optimal çözüm ne de nihai kelime var gibi;
  • kodlarını yorumlarken daha iyi olsun;
  • kodlarını yorumlarken daha iyi olsun; (sic)
  • hata ayıklamak daha kolay, daha az akıllıca, basit, sıradan görevlere çözümler;
  • SQL’de ders
    al

Bu sanat değil, bir zanaat.
Zeki olduğun için verdik: bilgisayarları programlıyorsun, kahretsin.
Hala AMD64ve x86senin nesir gücüyle mecbur değildir. İşleri basit tutun.


3
Kelimenin tam anlamıyla yüksek sesle gülüyor. çok iyi. roflcopters
kingdango

1
AMD64 ve x86, nesirinizin gücüyle zorlanmaz. - Tamamen harika.
Sam Brinck

SQL'de ders almak için +1
19'da HLGEM 19/12

28

Eh, kodunuzun bir karmaşa olduğunu söyleyen bir kişi, haklı olsa bile yapıcı değildir. Neden bu karışıklık nedenleri size verdiler mi? Gibi, yöntemler çok uzun, sorumluluklar birbirine karışmış, çok fazla dallanma vs. Bu yüzden üzülmeyin. Uzun zaman önce yazdığınız kodu okumayı hala seviyorsanız daha çok endişeliyim.

Kod tabanınız ne kadar temiz olursa, belirli bir sorunu çözmek için kod tabanıyla mücadele etmeye o kadar az zaman harcarsınız. Bir yıl, projede daha önce verdiğiniz tasarım kararlarının acısını hissedebileceğiniz için olması gereken harika bir nokta.

Şu andaki projemde, teknoloji yığınımızla daha da rahatlaştıkça birkaç kez yeniden canlandık. Bu teşvik edilmeli ve mevcut kod temelinden dolayı olması gerekenden daha uzun süren görevleri not almalısınız.

Yazdığınız kodun eski bölümlerinden bazılarını gözden geçirdiniz mi? Muhtemelen şimdi farklı bir şekilde yapmak isteyeceğiniz şeyleri veya yeniden değerlendirmeyi görebilirsiniz.

Ayrıca test eksikliğinden bahsettiğinizde, bu her zaman bakmak için bir şeydir. Projemizde otomatik bir test yapmadık ve bunun sonucunda bir çok yüksek oranda kod geldi. Birim / entegrasyon / hangi testleri düzenli olarak yazmasanız bile, kısa bir süre için yapmanız, kodunuzu daha modüler hale getirme alışkanlığınıza (ve sonuç olarak karışıklığın daha azına) neden olur.


26

Kendimi çok üzgün ve incinmiş hissediyorum. Programlamayı ve onlara gerçekten çok fazla zarar verdiğini söylemelerini seviyorum. Gerçekten kendimi geliştirmek istiyorum.

Bu iyi. Bu, "eleştirmenimin ne hakkında konuştuğu hakkında hiçbir fikri yok", "eleştirmenim çok seçici" veya sadece "eleştirmenim benden hoşlanmadığı" gibi bir tepki vermekten çok daha iyidir. Bu tutum iyi bir şey.

Ama filmlerde olduğu gibi dahice bir programcı değilim gibi görünüyor.

Ne tür filmler izleyeceğinizden emin değilim, ancak filmlerdeki programcıların% 90'ı o kadar sahtedir ki, dizinin sonunda gözyaşlarım var.

Bana nasıl daha iyi olacağına dair tavsiyede bulunabilir misin?

Oku ve pratik yap. Code Complete veya Pragmatic Programmer gibi kitapları inceleyin . Benzer kitaplar için Amazon'a bakın.

Hiç kodunuzu eleştiren bir şey yaşadınız mı ve gerçekten incinmiş hissediyor musunuz? Bu olaylarda ne yaparsın?

Neden canın yanıyor? En başta böyle bir moron olduğum için kendimi hayal kırıklığına uğrattığımı hissediyorum. Bu motivasyonu kodumu temizlemek ve aynı hatayı tekrar yapmadığımdan emin olmak için kullanıyorum . Yapmak istediğim son şey , ondan öğrenmek değil. Bir kere düşürüldün, aynı sebeple tekrar olmasına izin verme.

Hiçbir programcı kusursuz, hatta yakın doğmaz. Daha kod yazma, daha fazla Alacağınız yorumları ve değerlendirmeleri sağlamak , bir çok yönlü iyi programcı yapacaktır.


2
Birlikte ekleme ve +1 için reviews you provideçünkü başkaları için eleştirel olmak, daha iyi kaliteyi ortaya çıkarmak için kendi kodunuzu eleştirmede daha iyi bir uygulama olabilir.
Jimmy Hoffa

2
"Filmlerdeki programcıların% 90'ı o kadar sahte ki dizinin sonunda gözyaşlarım var." % 90? Hangi filmlerde mi sen izle? : PI , yaptığımız işi tam olarak gösteren bir film izlemedim. Sonra "Kılıçbalığı" ve "Bağımsızlık Günü" vardı ...
Nik Bougalis

İyi ve kısaca öyle!
kingdango

16

Bir geliştirici olmak konusunda benim için en iyi şeylerden biri, her gün bir öğrenme süreci olmasıdır. Dışarıda daima sizin yaptığınız bir şeyi bilmeyen biri olacak ve her zaman bilmediğiniz bir şeyi bilen biri olacak. Kesinlikle kendimi bir yer olarak düşünmüyorum ama giriş / gençlik düzeyinde, ancak hem haklı hem de saygı duyulduğu sürece alabileceğim herhangi bir eleştiriyi takdir ediyorum.

Uygun olabilecek bir benzetme, bir üniversitede yazma öğretmeni olduğum süre ile yaratıcı yazma kurslarına katıldığım dönemle ilgilidir. Kod yazma, tüm amaç ve amaçlar için, bir şiir, deneme, kısa hikaye veya roman yazmak gibi bir şeydir. Her bireyin kendi yolunda gitme yolu vardır, ancak aynı zamanda en iyi yazarlar bile (veya bu durumda geliştiriciler) hata yaparlar veya işlerin çatlaklara girmesine izin verirler. Bunları fark etmekte sık sık başarısız olabiliriz çünkü kendi sesimize o kadar alışırız (ya da bu durumda kod stiline).

Her alanda olduğu gibi, uzman olarak kabul edilenler de var. Bu insanlar olmasaydı, öğrenecek kimsemiz olmazdı. Söz konusu bu bireyin gerçekten bir uzman olduğunu varsayarsak, söylediklerini dinler ve kodunuzu geliştirmek için size ne önereceğini sorardım. Asla unutma, yardımını verebilecek tek kişi o değil; SE / SO gibi kaynakların bir bolluğunun mevcut olduğu için iyi bir servete sahibiz.


9
" Orada her zaman senin yaptığın bir şeyi bilmeyen biri olacak ve her zaman senin bilmediğin bir şeyi bilen biri olacak " - harika; +1.
Maximus Minimus

Evet ve öğrenebildiğim her şeyi öğrenmek istiyorum
acemi

mh: Bilge bir insanın genellikle yanlış olmaktan, haklı olmaktan çok daha fazlasını öğreneceğini eklerdim. Bu, kişinin şeyler hakkında yanılmaya çalışması gerektiği anlamına gelmez, ancak birinin öğrenme şansından faydalanması koşuluyla, bu konuda cesareti kırılmaması gerektiği söylenemez.
Supercat

10

Karışıklık oldukça özneldir. Yapabileceğiniz en iyi şey aslında o kişiye (veya inceleme raporuna) sormak: neden dağınık? (onların bakış açısına göre)

Size cevap vermeye mecburlar ve ikisini de yapabilirsiniz:

  • Buna karşı argüman (elbette bunu yapmak için iyi bir nedeniniz varsa)
  • Çok mutlu hissediyorum, çünkü yeni bir şeyler öğrendiniz ve gelecek kodunuz onların önerileri sayesinde nasıl daha az karmaşık hale geleceğini bildiğiniz için daha harika olacak.

Yorum yapmadı :( Ama işte benim kodum -> codereview.stackexchange.com/questions/18719/…
newbie

neden dağınık olduğunu düşünüyorsun?
acemi

7
@newbie: O zaman gözden geçiren çok iyi değil. Bir kodlayıcının sorunun ne olduğunu bilmeden bir şeyi nasıl geliştirmesi beklenir (bir ipucu bile değil!)?
Omega

1
Tamam teşekkür ederim ... Ben de bir jquery programcısı değilim. Ben bir java programcısıyım ....
newbie

1
O zamanlar sadece benim kodum kullanabiliyor. Neyse, haklısın, bunun hakkında daha fazla bilgi isteyeceğim. Thank you :)
newbie

8

Endişelendiğiniz gerçeği iyi bir işarettir. Bununla başlayalım. Programlamayı sevdiğini söylüyorsun, ama profesyonel bir programcı olmayı seviyor musun? Bir meraklı ve bir profesyonel arasında büyük bir fark var. Bir profesyonel olarak iş ürününüz için sürekli inceleme altında olacaksınız.

Our team is composed of 5 programmers, and 4 of us are new

İki yıl boyunca herhangi bir sorun yaşamadan çalıştığınız gerçeği, çok profesyonel bir işte çalışmak istemenizin gerçekten iyi olmayan bir işte çalıştığınızı söylüyor. Unutmayın, dünyadaki en iyi programcılardan bazıları Linux temeli için çalışıyor ve marjinal hatalar yaptıklarında kibar davranılmayacaklarından emin olun ... çok daha az 'karışık kod'.

Bazı oldukça standart kodlama kurallarının hızlıca gözden geçirilmesi için, Linux Community Contributors Standardı size ürününüz için istekli olmanız gereken sorumluluk düzeyi hakkında bir fikir vermelidir. KOD SAĞINI ALMA.

Bu iddiayı daha da ileri götürmek için, en iyi yazılım tamamen incelendiğinden incelemeyi benimsemeyi öğrenmelisiniz. Bu Linus Yasasını belirtir ...

"Yeterli sayıda eleştirmen varsa, tüm sorunları çözmek kolaydır."

Şahsen, son derece yetenekli, sorumlu ve güvenilir geliştiriciler, yorum bırakmayı unutmak kadar basit bir şey için baltayı ele geçirdi ... bu yüzden eğer biri size kodlarınızı bir karışıklık çıkarırsa muhtemelen ... yeniden düzenleme. Konserin bir parçası.

I feel so sad and hurt. 

Kendinizi uygulamadığınızda ne kadar sinirlendiğinizi ölçmek için bir üzüntü uygulaması yapın.

Sorunu cevapladın ... Test Etme!

Bir java geliştiricinizin belirttiği bir yorum gördükten sonra neredeyse üzülmüştüm. Sizi doğru anlarsam, siz ve geliştirme ekibinizin bir java mağazasında çalıştığını ve uygulamalarınız için bir test çerçevesinin bulunmadığını söylerseniz ...

Ovmak Yalanlar

"Programımızı kapsamlı testler yapmadan programa yerleştirdik."

Beşik UML Creator Grady Booch ...

Amatör yazılım mühendisi her zaman sihir, uygulaması yazılım geliştirmeyi önemsiz kılacak vaat eden bazı sansasyonel bir yöntem veya araç arayışı içindedir. Böyle bir derde deva bulunmadığını bilmek profesyonel yazılım mühendisinin işaretidir.

Alistair Cockburn , siz ve ekibiniz için performansı ve kaliteyi arttırmak için çevik metodolojileri kullanma konusunda zengin bir bilgi sunuyor.

Programlamanın {ve yaşam} en önemli yönlerinden biri güçlü ve zayıf yönlerinizi bilmektir. Zayıf yönleriniz üzerinde çalışmazsanız, çok yönlü bir beceri setine sahip olmazsınız.

Outro ... İyisin - Sadece sızlanma. Zanaatınızı geliştirmede ilerleyin ve programlama tutkunuzun sizi sürdürmesine izin verin. İyi şanslar :-)


5

Duygularınızın, kodunuzu iyileştirme yoluna girmesine izin vermeyin. Bir kod incelemesinin amacı sorunları bulmaktır, bu yüzden eğer varsa çok da şaşırmamalısınız. Bu da onların bir kodlayıcı brifing oturumu olması gerekmediğini söyledi.

Ayrıca, sadece 'Ewwww' dememeli ve onu bırakmamalılar. Programlamada bir şeyin yanlış olmasının her zaman bir nedeni vardır. Örneğin, her yere bir sürü yorumlanmış kod bırakmak yanlış, ancak birisinin bir kitapta söylediği için değil, kodu toparladığı ve okunmasını zorlaştırdığı için yanlış.

Kodun sen değilsin. Bunu hatırla.


4

Burada dick olacağım ve temelinde ... tavsiyede bulunacağım. Açıkçası, kodunuz bir karışıklık veya sormak isteyeceğiniz soru "Niye birisi kodumun bir karışıklık olduğunu söylüyor?" Ama varsayımı zorlamıyorsun. Sen sadece acı çekiyorsun ve açıkçası ağlıyor olabilir ama programlamaya gerekçe gösterildiğinde hiçbir his yok.

Ama gerçekten neden soruyorsun? Kodunuzun berbat olduğunu biliyorsunuz veya farklı bir soru soruyorsunuz. Biri bana arka uç web kodumun stank olduğunu söylese, ben gülüp "tamam onun nesi var?" Derdim. Bana JavaScript desteğimi söyleselerdi, onlara sosyal programcıya yağ dudağının eşdeğerini verirdim ve nasıl tepki göstereceklerini asla sormam; çünkü küçük sürtükler açıkça!

Neyin iyi olduğunu biliyorsun. Ve bunun sorumluluğunu almayı gerçekten kastediyorum. çünkü sadece bir twitin seni ikinci kez tahmin etmesi için bir goof alır. İyi olmak için izin istemeyin. Sadece eşyalarını bil. Son.


Amin. Ve eşyalarını bilmek ... eşyalarını bilmeni sağlamak için ... gayret gösterir. Ama yakanı da patlattığından emin ol, seçkin çocukların bugünlerde yaptığı şey bu. : /
kingdango

Evet, sanırım yanlışı kabul eden ilk kişi olan daha tecrübeli dev'ler hakkında tavsiyelerde bulundum. Birden fazla kişiliği tehlikeye atabilirim.
Erik, 04:13

4

Bunu hatırlayın: Göreceğiniz en kötü kod sizindir!

Codinghorror.com'dan Jeff Atwood konuyla ilgili çok şey yazdı, buradan başlamak isteyebilirsiniz: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Geliştirmek istiyorsanız, kodlama stili, desenler, iş akışları, temelde parmaklarınızı alabileceğiniz her şey hakkında bilgileri okumaya başlayın. Ayrıca, daha fazla programlama dili öğrenin, nasıl iş yaptıklarını görün. OOP yapıyorsanız şunu okuyun: http://en.wikipedia.org/wiki/Design_Patterns

Ayrıca diğer programcılarla konuşun ve çift programlama yapın veya başkalarının kodunu izleyin.

Hata yapmak kaçınılmazdır, tekrarlanmasıdır.


Onun iyi bir duygu (benim için en sevdiğim şey, her zaman bir uygulamadaki sorunun benim suçum olduğunu farz ederek başladığımla ilgilidir) ama ne yazık ki, hayır, şimdiye kadar gördüğünüz en kötü kodun kendinize ait olmayabileceği ortaya çıkıyor. Burada olmak ve ilk etapta sormak için yeterince zeki değilseniz ...
Murph

4

Bunu size söyleyen kişiye çoğu zaman "Teşekkürler" demelisiniz.

Muhtemelen mesleğini önemsiyorlar, işlerini önemsiyorlar, ekiplerini önemsiyorlar ve sizi önemsiyorlar.

Eleştiri almak zor olabilir. Buna kızma. Size ne anlatmaya çalıştıklarını düşünün ve duygularınızın sizi iyileştirmesine izin vermeyin.

Uzun zamandır (30 yıldır) programlama yapıyorum ve tarzım ve kodum her zaman gelişiyor (umarım). Gelişmesini bilmenin tek yolu, başkalarının bana söylediği zaman veya geri dönüp kodumu gözden geçirmemdir.

Kariyerinizin başında yazdığınız koda bakmayı deneyin. Şimdi sana nasıl benziyor? Yazarken düşündüğünüz kadar iyi görünüyor mu;)


3

Öncelikle, programlamanın bir makale veya kitap yazmak gibi yinelemeli bir süreç olduğunu anlamalısınız. İlk önce, programın çalışmasını sağlamak için "kaba bir taslak" yazıyorsunuz. Bu aşamada, kodunuz bir karışıklık olacak. Bu yüzden kodu temizlemeye karar verdin. Ardından, profili hızlandırıp hızlı hale getirmek için neye ihtiyacınız olduğunu görün. İşin püf noktası sürekli refactor yapmaktır, aksi takdirde karışıklık büyür. Kodunuzu düzenli olarak temizlemelisiniz, tıpkı evinizi temizlemeniz gerektiği gibi.

Kod incelemeleri kesinlikle önemlidir. Kodunuzu en az bir başka göz tarafından incelemeniz gerekir. Kodunuza bakmak için sayısız saat harcadığınızda, buna alışırsınız ve iş arkadaşınızın anında fark edebileceği bir hatayı veya kod kokusunu kolayca özleyebilirsiniz.

Ayrıca, kodunuzu bir başkasına açıklama eylemi, bir şeyi kaçırıp kaçırmadığınızı görmenin harika bir yoludur. Bu yüksek sesle yazdığınız bir kağıdı okumak gibi. Beyniniz görsel ve işitsel bilgiyi farklı şekillerde işler ve modaliteyi değiştirerek aklınızdaki kusurları bulabilirsiniz. Ayrıca, kodunuzu bir iş arkadaşınıza açıklarsanız ve bir şey ona bir şey ifade etmezse, kodunuzu yeniden gözden geçirmeniz gerektiğini gösteren iyi bir göstergedir.

Bir kod incelemesi yaparken, hem yazar hem de hakem için kapıdaki egolarını kontrol etmek çok önemlidir. Amaç kodu daha iyi hale getirmektir. Bu yüzden eleştirmen saygılı olmalı ve yazar açık fikirli olmalıdır. Unutmayın, iş arkadaşlarınız, kodunuzu korumak zorunda kalacak olanlardır, bu nedenle onlar için açık olması gerekir. Gözden geçiren kişi bir değişkenin ne yaptığını anlamıyorsa, yeniden adlandırın. Gözden geçiren kişi bir kod bloğunun ne yaptığını anlayamıyorsa, açıklayıcı bir ada sahip bir işleve yeniden uygulayın. Ne düşünürseniz düşünün, meslektaşlarınız kodunuzu anlayamıyorsa, bu iyi değildir.

Yeniden düzenlemeden bahsetmişken, kesinlikle bir birim test çerçevesine sahip olmalısınız, çünkü o olmadan düzeltemezsiniz.

Son olarak, Robert C. Martin tarafından "Temiz Kod" yazmanızı şiddetle tavsiye ederim. Kodunuzun neden bir karışıklık olduğunu ve onu temizlemek için ne yapabileceğinizi söyleyecektir.


3

Bana nasıl daha iyi olacağına dair tavsiyede bulunabilir misin?

Jay'in kitapları öneren cevabı iyi bir cevap, ancak iş yerinde bir dönüm noktasında gibisiniz.

Geçmiş:

Ekibimiz 5 programcıdan oluşmaktadır ve dördümüz yeniyiz, 1'inde 3 yıldan fazla deneyime sahibiz. Neredeyse bir yıldır bir program için çalışıyoruz ve hiç kimse kodumu incelemiyor ve çalışmam için bir sayfa verildi.

Mevcut:

Artık çok sıkı ve kodda değişiklik yapmadan önce onay ve kod incelemesine ihtiyacımız var.

Programın yanı sıra proje / ekip yönetimi ve proje açısından firmanızın / ekibinizin / bölümünüzün bir bütün olarak öğrendiği anlaşılıyor. Kodu incelemeye başlamak, uygun özen gösterilmesi durumunda hemen hemen tüm alanlarda iyileştirmek için mükemmel bir fırsattır.

Bunu bir fırsat olarak kullanın; Akran değerlendirmeleri yaptığınızı varsayalım (ekibinizdeki diğer geliştiricilerle birlikte) onlara bu sürecin önemli olduğunu ve herkesin ondan öğrenebileceğini öne sürün.

Temel çizgide, sonuç "evet iyi görünüyor" olmakla birlikte hızlı bir gözden geçirme olacaktır. Biraz daha odaklanmış bir çaba ile fikirlerinizi birbirinizden uzaklaştırabilirsiniz, "evet işe yarar, ancak hedefinize daha net bir şekilde ulaşması için bu şekilde yaklaşmış olabilirsiniz." Kodun dağıtılması uygun görünse bile gelecek için not alın.

Bu başarılı olacaksa, ekibinizi ve yöneticinizi yanlara almanız gerekir; bu, genellikle faydalarını açıklamak anlamına gelir. Diğer geliştiricilere bu öğrenme fırsatıdır. Yöneticiniz için bu, takımı düşük maliyetle geliştirme becerisidir, bu nedenle a) değeri daha yüksek veya b) daha hızlı c) daha az bakım maliyeti ile (genellikle büyük sorun!).

Bu, kendi başınıza zorlayamayacağınız bir kültür değişikliğidir, ancak olayları doğru yönde dürtmek için yardımcı olabilirsiniz!

Unutma, bu bir çeşit kültür değişimi organizasyonlar için çok faydalı olabilir; iyi yöneticiler tüm takımı daha iyi hale getirmeye çalıştığınızı, ödüllendirmeye değer bir şey olduğunu anlayacaklardır.


3

Bana nasıl daha iyi olacağına dair tavsiyede bulunabilir misin? Hiç kodunuzu eleştiren bir şey yaşadınız mı ve gerçekten incinmiş hissediyor musunuz? Bu olaylarda ne yaparsın?

Bunun cevabı yeni nesil şirketlerde bulunabilir. Google ve FaceBook gibi şirketlere gittim ve görüyorum ki, Çevik / Scrum sürecini dini olarak izlerseniz, daha iyi kod yazabilir ve her süratte geliştirebilirsiniz.

How to be better? 

Cevap sürekli refactoring. Visual studio gibi modern geliştirme araçları, bu süreçte size yardımcı olacak birçok araca sahiptir. Scrum yazılımı geliştirme sürecini izlerseniz, eski için söylediğiniz takdirde, sprint döngüsü 1'de kötü kod yazdınız ve inceleme sırasında biri kötü olduğunu belirtti, sonra sprint 2'de kodu yeniden gözden geçirme şansına sahipsiniz.

Bu meseleler, iyi bir süreç olmadığından ilk etapta ortaya çıkmaktadır. Bu nedenle çözüm, ekibiniz için iyi bir yazılım geliştirme süreci bulmak ve sürekli yeniden düzenleme yapmaktır.


3

Onlara geri bildirim için teşekkür eder, sonra da neyin kötü olduğunu ve nasıl iyileştirilmesi gerektiğini açıklamalarını isterim.

Geri bildirimde bulunan kişinin mantıklı olduğunu kabul ediyorsanız, gelecekte değişiklik yapmayı düşünün. Ama unutmayın, çünkü birileri bunun doğru olduğu anlamına gelmediğini söylüyor.

"Dağınıklık" olarak adlandırılan şeyin özel örneklerini verebilir misiniz?


Duygular bazen zor olabilir, ama kesinlikle böyle tepki vereceğimi umuyorum.
Thomas Padron-McCarthy

3

İlk önce kodunuzun bir karışıklık olduğunu söyleyen biri çok belirsiz ve özneldir. Farklı insanlar için farklı şeyler ifade edebilir. İşte nedeni; dikkate alınması gereken iki farklı şey var.

yapı

Kodunuzun yapısı, birkaç isim için dil, endüstri standartları ve şirket standartlarına tabidir. Açıkçası başka faktörler de var.

Bunlar tüy bırakan hata türleri, test araçları ve benzeri ürünleri tanımlamak için tasarlandı. İyi tanımlanmışlardır ve siz veya araçlarınız geçerliliği / doğruluğu konusunda nesnel kararlar verebilirsiniz.

stil

Standart kodlara / kod kurallarına rağmen, her geliştiricinin bir soruna veya göreve yazma ve yaklaşma biçiminde belirli bir stili vardır. Herhangi bir ekip ortamında kod bakımını yapın ve zamanla, stili temel alan kodu kimin yazdığı hakkında bilinçli bir tahminde bulunabilirsiniz. Ayrıca kendi tarzınızı geliştireceksiniz ve deneyim kazandıkça ve zanaatınızı öğrendikçe değişecektir.

Birisi kodunuzun bir karışıklık olduğunu söylediği her zaman , yapı veya stil hakkında mı konuşurlarsa anlamanız gerekir . Onlar iki çok farklı şeylerdir; yapı nesneldir, üslup kesinlikle özneldir.

Bu, diğer programcılardan yapıcı herhangi bir geri bildirim almanız sizin için çok değerli olabilir. Hepsi size ve eleştiriyi nasıl ele aldığınıza bağlı. Zamanla kimin kime karıştıracağına karşı bir fikir alacağını öğreneceksiniz.

Kariyerinizde ilerledikçe kendi kodunuza bakacak ve farklı, daha iyi, daha temiz ve daha hızlı yapabileceğiniz şeyleri göreceksiniz. Hepsi öğrenme sürecinin bir parçası ve geçmiş hatalarınızı görmek zanaatınızı geliştirdiğiniz ve geliştirdiğinize dair gerçek bir göstergedir.

Biraz eleştirinin moralinizi bozmasına izin vermeyin. Elinizden ne geldiğini alın ve anlamlı ve değerliyse, bilginizi depoya ekleyin.


3

Kendi kodunuzun ne zaman bir karmaşa olduğunun farkına varmak önemli olmakla birlikte (programcılar arasında, özellikle daha deneyimli hale geldiklerinde ve önceki kod yaşları arasında çok tipik bir his) , diğerlerinin size söylediği zaman dinlemek daha da önemlidir.

Şu anki programlama bilginizin kısıtlamaları nedeniyle üretildiği için kendi kodunuzda tanıyabileceğiniz birçok sorun var.

Kod incelemesi, önemli bir öğrenme fırsatıdır, çünkü kod üzerinde çalışırken sahip olmadığınız yeni bilgilere ( muhtemelen onu kullanırsınız ve karışıklık olmaz) ortaya çıkarır .

Olumsuz geri bildirimleri işlemenin iki parçası olduğunu düşünüyorum.

1. Ortaya çıkan sorunların doğasını ve ondan ne öğrenmeniz gerektiğini belirleyin

Kodumu incelediğimde veya incelediğimde, kabaca bu tür kovalardaki kod sorunları hakkındaki bilgileri sıralarım:

  • zor teknolojik gereksinimleri ihlal ediyor
    • düz yanlış (işlev veya şartlara yerine getirme)
    • diğer durumlarda başarısız olacaktır (çevre / konfigürasyon değişikliği)
    • kullanımdan kaldırılmış işlevler kullanır ve öngörülebilir gelecekte kırılacak
  • gibi şeylerden yoksun olan sektördeki en iyi uygulamaları ihlal eden
    • belirli bir probleme kanıtlanmış yaklaşım kullanarak
    • verim
    • geriye uyumluluk
    • Bakım kolaylığı
    • kodlama stili
    • belgeleme
  • işyerinde en iyi uygulamayı ihlal ediyor
    • Endüstri ile aynı, ancak şirket / iş arkadaşlarına daha özel ve ayrıntılı olarak sektörden farklı olabilir
  • kişisel uzmanlığa uygun değil
    • kişinin yorumuna göre bir şekilde iyileştirilebilir

Bunun çok nesnel şeylerden ("üretim sunucumuza konuşlandırıldığında kırılacağı") çok öznel şeylere ("değişkenleri nasıl adlandırdığınızı sevmiyorum") kadar farklı olduğunu unutmayın.

2. Kodda (eğer varsa) değişikliklerin inceleme sonucu olarak belirleneceğini belirleyin.

Bilgi işlendikten sonra, uygulanabilir olup olmadığına ve kodun değiştirilip değiştirilmeyeceğine karar verilir. Bu mutlaka sizin kararınız değildir, fikriniz ilgili taraflara ve durumunuzun özelliklerine (kıdem vb.) Bağlı olarak önemli olabilir veya olmayabilir. Ancak kabaca olası sonuçlar:

  • tam olarak adres sorunu
    • kırılmış tamir
    • istenen kodlama stiline formatlama
    • ve bunun gibi
  • Sorunun tamamen veya kısmen ele alınması gerekiyorsa, uzlaşmaya varmak, çünkü
    • kaynak yok (zaman veya bütçe gibi)
    • Gerek yok (yalnızca önemsiz bir gelişme sağlayacak, istikrarı tehlikeye atacak, vb.)
  • ortaya çıkan sorunun geçersiz olduğunu anlamaya gelmek
    • geri bildirim (özellikle öznel görüş kategorisinden), tamamen zararsız olabilir ve kör davranmamalı

Olumsuz geri bildirim almanın acı verici olduğunu ve gelecekte her zaman çok acı verici olabileceğini öğrendiniz. Ancak, bunun önemli bir öğrenme fırsatının nasıl olduğunu ve sürecin profesyonelliği ve iş yerinizi daha iyi kod temeli elde etmek için nasıl geliştirmenize yardımcı olduğunu öğrendiniz.


1

Kendini kırılmış hissetme. Sonunda hataları öğreneceksiniz. Konuyla işiniz bittiğinde adamla konuşabilirsiniz böylece onu geliştirmek istediğinizi hissetmesini sağlayabilirsiniz. Daha fazla dinlemeye çalış ve daha az tartış.

Bu durumdan geçti ve anlayabiliyorum.


0

TL; DR

Biri size kodunuzun bir karışıklık olduğunu söylese nasıl tepki verirsiniz?


Açıkçası, "çok uzun zaman okumadım (tüm cevaplar - özür dilerim, umarım daha sonra okumak ve gerekirse düzenlemek / değiştirmek için zaman bulurum") cevap / ipucu:

  • İyi yaşlı Akran Değerlendirmesi. Kodunuzu gözden geçirmek için farklı kolektif zihniyetlere, uzmanlık seviyelerine ve / veya saldırganlık seviyelerine sahip farklı ekiplerden sorun .
  • Sadece "farklı" akran grupları ile neyi kastettiğimi biraz detaylandırmak için: Stackdit'in diasporası, Reddit'e kıyasla bir parçası olmanın göreceli zorluğundan dolayı muhtemelen en açıklamalı, profesyonel ve saygın gruptur. Reddit, en popüler alt redditlerde çok agresif olma eğilimindedir - ancak garip bir şekilde programlama alt dizinleri (benim yaşadıklarımdan) oldukça arkadaş canlısıdır.

En iyi, belki de en agresif, gangsta klibe zihniyetinin en iyi örneği, XDK Forumları topluluğudur ve CyanogenMod for Android forumları / IRC kanal popülasyonuna verdiğim en kötü kupanın en kötüsüdür.

Bu istediğimden biraz daha uzundu; Amacım, farklı yorumlar almaktı, ancak ticaretini bilen ve yapıcı eleştirinin ne olduğunu bilen insanlardan dürüst eleştiriler almaya odaklanmam gerekiyordu . Oh, ve sizi üzmesine izin vermeden herhangi bir eleştiri yapabileceksiniz. Temel kural: Yorumlarla ortak olabilecek bir şeyle ilgili benzer yorumları duymaya başlarsanız, daha ayrıntılı bir inceleme yapın.

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.