it-swarm.asia

İyi kod yazdığınızı nasıl anlarsınız?

Programlamayı seviyorum. Çocukluğumdan beri kodlarla uğraşıyorum. Profesyonel rotaya hiç gitmedim, ancak bir banka için dahili bir işlem yönetimi/raporlama sistemi kurduğum yere dahil olduğum bir proje de dahil olmak üzere çeşitli işverenler için birkaç şirket içi uygulama kodladım. Bir şeyleri çabucak alıyorum, birçok kavramı anlıyorum ve tüm kodlama süreci ile rahat hissediyorum.

Tüm bunlar söyleniyor, programlarımın iyi olup olmadığını asla bilmiyormuşum gibi hissediyorum. Tabii, çalışıyorlar - ama kod temiz, sıkı, iyi yazılmış şeyler mi, yoksa başka bir kodlayıcı ona bakar ve kafamı tokatlar mı? Stack Overflow'da sadece aklımı uçuran ve kodlama girişimlerimin tamamen zayıf görünmesini sağlayan bazı şeyler görüyorum. İşverenlerim yaptıklarımdan memnunlar, ama akran değerlendirmesi olmadan, aksi takdirde karanlıktayım.

Akran kodu incelemesine baktım, ancak NDAs veya gizlilik sorunları nedeniyle bir çok şey gönderilemiyor. Pek çok profesyonellerin omzunuzdaki şeylere bakmak ya da fikirleri sektirmek için takım arkadaşlarınız olabilir, ama oradaki benim gibi bağımsız ve yalnız adamlara ne olacak? En iyi uygulamaları nasıl öğrenirsiniz ve kodunuzun tam olduğundan emin olursunuz?

Yoksa beklendiği gibi çalıştığı ve iyi bir kullanıcı deneyimi sağladığı sürece "en iyisi" olup olmadığı önemli değil mi?

277
Jim

Benim için en büyük ipucu:

Geri dönüp bir özellik eklemeniz/değiştirmeniz gerektiğinde zor mu? Değişiklik yaparken sürekli olarak mevcut işlevselliği bozuyor musunuz?

Yukarıdakilerin cevabı "evet" ise, muhtemelen kötü bir tasarıma sahip olursunuz.

Değişime cevap vermesi gerekene kadar (en azından benim için) bir tasarımı yargılamak biraz zordur (elbette, bazı kodlar sadece kötüdür ve hemen söyleyebilirsiniz, ancak bu deneyim ile birlikte gelir.)

333
Ed S.

Bu kesinlikle çalıştığım yerde oldukça standart bir ölçü.

Code Quality = WTFs/minute

Hangi kapı kodunuzu temsil eder? Hangi kapı ekibinizi veya şirketinizi temsil eder? Neden o odadayız? Bu sadece normal bir kod incelemesi mi yoksa canlı yayına başladıktan kısa bir süre sonra korkunç bir sorun akışı mı bulduk? Panik içinde hata ayıklıyor muyuz, işe yaradığını düşündüğümüz kodun üzerinden mi bakıyoruz? Müşteriler sürülerden ayrılıyor ve yöneticiler boyunlarımızı soluyor mu ...

(Robert C Martin, Temiz Kod - yukarıdaki resimle açılan kitap)

179
Phil.Wheeler

Şu durumlarda iyi kod yazdığınızı biliyorsunuz:

  • İşler akıllı, ama çok akıllı değil
  • Algoritmalar hem hızda hem de okunabilirlikte optimaldir
  • Sınıflar, değişkenler ve işlevler çok fazla düşünülmeden iyi adlandırılmış ve mantıklı
  • Bir hafta sonu bittikten sonra geri dönüyorsunuz ve doğrudan atlayabilirsiniz
  • Yeniden kullanılacak şeyler tekrar kullanılabilir
  • Birim testlerinin yazılması kolaydır
104
Rich Bradshaw

Bunu yapmak için başka kodlayıcıların olmadığını söylemesine rağmen, bunu başkaları uğruna ekleyeceğim.

Kod kalitesi testi: Kodu hiç görmemiş olan başka bir programcının, omzunun üzerinden bakarken her modülün size ne yaptığını açıklamasını sağlayın. Zıplama ve bir şeyi açıklama isteğiniz ne kadar güçlü olursa, kodun daha kötü olması muhtemeldir. Sakin bir şekilde ağzı kapalı olarak oturabilirseniz ve çok fazla soru sormaları gerekmiyorsa, muhtemelen iyidir.

Yararınıza, kullanışlı bir arkadaşınız olmadığında bazı genel yönergeler. Bunlar mutlak değil, sadece "kokuyor".

İyi işaretler

  • Yöntemler, ideal olarak tek bir görevi yerine getiren çok kısa olma eğilimindedir.
  • Vücuduna bakmadan yöntemleri çağırmak için yeterli bilgiye sahipsiniz.
  • Birim testleri yazmak kolaydır.

Kötü işaretler

  • Diğer yöntemlere bölünmemiş 2-3 alt görevden oluşan uzun yöntemler.
  • Yöntemler, verileri arayüzleri dışındaki bazı yöntemlerle paylaşır.
  • Bir yöntemin uygulanmasını değiştirirseniz (ancak arabirimi değil), diğer yöntemlerin uygulanmasını değiştirmeniz gerekir.
  • Birçok yorum, özellikle uzun soluklu yorumlar.
  • "Gelecekte esneklik" sağlamak için uygulamanızda hiç çalışmayan kodunuz var
  • Büyük deneme/yakalama blokları
  • İyi yöntem adları bulmakta zorlanıyor veya "VEYA" ve "VE" kelimelerini içeriyor (ör. GetInvoiceOrCustomer)
  • Aynı veya neredeyse aynı kod blokları.

İşte kod kokuyor daha yararlı bir liste.

59
JohnFx

Şahsen benim için, kodu unuttuğumda sanırım. Başka bir deyişle:

  • Hatalar nadiren görülür
  • Gerçekleştiklerinde, diğer insanlar bana hiçbir şey sormadan çözüyor
  • Daha da önemlisi, hiç kimse hiç kodumla ilgili herhangi bir şey sormuyor
  • İnsanlar okurken yüksek WTF/dak oranına sahip değil
  • Sistemdeki birçok yeni sınıf sınıfımı kullanmaya başlar ( yüksek fan girişi , Steve McConnell'in dediği gibi)
  • Kodun, gerektiğinde/gerektiğinde, beni lanetlemeden değiştirmesi ve/veya yeniden düzenlemesi kolaydır (ben bile olsa - kendimi lanetliyor!)
  • Takımdaki herkese uygun görünen doğru miktarda soyutlamayı tahmin ettiğimde de seviyorum

Bir yıl önce yazdığınız bir dosyayı açıp bir sınıfa tüm Nice eklemelerini gördüğünüzde çok güzel bir duygu, ancak çok az değişiklikler , ve - çok yüksek fan girişi! :)

Tabii ki, bunlar bana iyi kod yazıyormuşum gibi hissettiren şeyler, ama gerçekte, bilmek gerçekten zor. Tahminimce, insanlar kodunuzla alay ettiklerinden daha fazla eğlenmeye başlarsa, endişelenme zamanı.

27

Üç altın kuralım var:

  1. Kod bloklarını kopyalamak/yapıştırmak zorunda kalırsam yanlış bir şey yapıyorum
  2. Tüm kodu kafamda alamazsam yanlış bir şey yapıyorum
  3. Birisi atlar ve kodumda kaybolursa yanlış bir şey yapıyorum

Bu kurallar, küçük, temiz ve bakımı kolay sınıflar/yöntemlerle sonuçlanan bazı gerçek mimari iyileştirmeler yapmamı sağladı.

20
dukeofgaming

Bu mükemmel bir soru ve ben bile sorduğun için alkışlıyorum.

İlk olarak, her seferinde zihninizi havaya uçurmak iyidir. Sizi alçakgönüllü tutar, her şeyi bilmediğinizi bilmenizi sağlar, orada bundan daha iyi insanlar vardır ve size daha iyi bir şey verir için çabalamak.

Şimdi, iyi kod yazdığınızı nasıl anlarsınız?

  • Sınıflarınızın her biri, diğer sınıflardan açıkça tanımlanmış diğer amaçlarla ayrılmış, çok açık bir şekilde tanımlanmış tek bir amaca hizmet ettiğinde.
  • Yöntemleriniz kısa olduğunda - ideal olarak 50 satırın altında ve kesinlikle 100'ün altında - ve adları tam olarak ne yaptıklarını açıkça tanımlarlar . Bir yöntem adından da anlaşılacağı gibi bir şey yapmamalıdır. 100 çizginin üzerine gidiyorsanız veya çok uzaklarda sekmeliyseniz, bir şeyi kendi işlevine çekebilirsiniz.
  • Kodunuz bir şey yapmanın bir yolunu sağladığında - zig veya zag seçeneği sunmadığında, bunun yerine kullanıcı olası her bir işlem için tek bir doğrusal yol sağladığında.
  • Her şeyi yaptıktan sonra, sınıflar arasındaki bağlantıyı azaltmak için makul şekilde yapabilirsiniz; böylece A Sınıfı B Sınıfına bağlıysa ve B Sınıfı kaldırılırsa ve C Sınıfı yerine konursa, A Sınıfında çok az değişiklik yapılmasına veya hiç değişiklik yapılmasına gerek kalmazsa, A Sınıfı dış dünya.
  • Sınıfınız, yönteminiz ve değişken adlarınız kodla karşılaşan herkes tarafından okunup hemen anlaşılabiliyorsa, 'packetSize' çok daha kolay okunduğunda 'pktSize' öğesine gerek yoktur.

Diğerlerinin söylediği gibi, aslında, Nesneye Dayalı Programlama yapıyorsanız ve bir şeyi değiştirmek için zaman geldiğinde, bir iplik yumağını çözmeye ve geri sarmaya çalışmak gibi bulduğunuzda, kod iyi Nesne Odaklı ilkelere uymuyor .

Kitabınızı tavsiye ederim "Temiz Kod", Eğer biraz daha bu konuyla ilgileniyorsanız. Hem acemiler hem de uzmanlar için iyi bir okuma.

11
trycatch

Ana noktalarımın şöyle olacağını söyleyebilirim:

  • Okunabilirlik (siz ve kodunuzu inceleyen herkes için)
  • Sürdürülebilirlik (değiştirilmesi kolay)
  • Basitlik (buna gerek olmadığında işleri karmaşıklaştırmaz)
  • Verimlilik (elbette kodunuzun hızlı çalışması gerekir)
  • Netlik (kodunuz açıklayıcı ise, çoğu zaman yorum yapmaya gerek yoktur, yöntemlerinizi/özelliklerinizi adlandırın vb. kod aşağı, asla bir kod bloğunu kopyalayıp yapıştırmayın)

Projenizde tutarlı olduğu sürece iyi bir kodun tasarım desenine yapışmadan yazılabileceğine inandığım için bu listeye Tasarım koymuyorum .

Bu konuda iyi MSDN makalesi: İyi Kodu İyi Yapan Nedir?

7
Грозный

En sevdiğiniz dilde iyi bir açık kaynak projesi arayın ve ne yaptıklarını görün.

Örneğin, sendmail yazıp yazmadığınızı görmek için bir yer spagetti kod . Gerçekten sendmail'in hatası değil; sadece 20 yaşında, bu yüzden içinde çok fazla şey var. Kodunuz sendmail koduna benziyorsa, muhtemelen yanlış yoldasınız demektir.

Ben son zamanlarda Postfix bakmadım, ve muhtemelen çok iyi tasarlanmış. Yani öğeleriniz postfix gibi görünüyorsa doğru yoldasınız demektir.

Çocukken programlamaya başladığımda internet yoktu ve karşılaştırılacak hiçbir şey yoktu. Ancak şimdi karşılaştırma için görüntülenmesi gereken bir bazilyon kod satırı ile, bunu doğru yapıp yapmadığınıza dair bir fikir edinmeye başlamalısınız.

Ve Linux çekirdeği Linux çekirdeği olduğu için iyi yazılmış olduğu anlamına gelmez. Bunu aklınızda bulundurun.

6
stu

Son beş aydır kolej programlama dünyasından sektöre geçiş yaptığımdan bu yana benim deneyimim:

  • Kullanım kolaylığı o kadar önemlidir ki insanlara sadece kullanıcı arayüzleri tasarlamaları için ödeme yaparız. Kodlayıcılar genellikle UI tasarımını emer.
  • İşe gelmenin yeterli olmadığını görüyorsunuz
  • Optimizasyonlar, gerçek dünya senaryolarında daha kritik hale gelir.
  • Bir soruna yaklaşmanın binlerce yolu vardır. Bununla birlikte, genellikle yaklaşım, veritabanı kimlik doğrulaması, işlemler, dosya G/Ç , yansıma gibi yaklaşımınızın performansını olumsuz etkileyebilecek biraz daha az bilinen faktörleri hesaba katmaz. rastgele birkaç.
  • Sürdürülebilirlik kodlamanın çok önemli bir yönüdür. Kodunuzun süper optimize edilmiş ve süper yoğun olması ... seksi olduğu anlamına gelmez. Bazen basitçe "Kahraman kodlaması" olarak etiketlenir.
  • Tasarım becerileri öğrenilir, doğal değildir. Eminim orada birkaç beyin çocuğu var, ama genel olarak konuşursak, gerçek dünya sorunlarına göre sağlam bir tasarım, zamanla, soruşturma ile ve en önemlisi, üstlerinizden bilgi verilmesi = P
  • Dokümantasyon kolaylık değil, bir zorunluluktur.
  • Aynı şey birim testi için de geçerlidir (bu şirketten şirkete kabul edilir)

Açık kaynak kodlu bir projeyle fırsat yakalamanızı öneririm. Diğer programcıların alt çizgisinde çalışıp çalışmadığınızı gerçekten ne kadar bildiğinizi görme şansınız olacak. Açık kaynak kodlu bir proje muhtemelen geçmişinize göre öğrenmenin en iyi yoludur.

6
Feisty Mango

İyi kodu okuyun ve neden iyi olduğunu anlayın. Kötü kodu okuyun ve neden kötü olduğunu anlayın. Vasat kodu okuyun ve hangi parçaların iyi, hangilerinin kötü ve hangilerinin iyi olduğunu belirleyin. Kendi kodunuzu okuyun ve aynısını yapın. Özellikle örneklere bakmak ve neden onları yazdıklarını anlamak için birkaç (saygın) ders kitabı alın. Çoğunlukla, kötü ve iyi arasındaki farkı söyleyene ve kendi "Wtf?" testleri.

Genel olarak iyi kodu tanıyana kadar iyi kod yazıp yazmadığınızı bilemezsiniz. Başının üstünde bir şey olması iyi yazılmış olduğu anlamına gelmez ...

("Diğer insanların kodlarını okuyun" bu konu hakkında birkaç yorumda ortaya çıktı, ama kendi postasını hak ettiğini düşündüm)

2
Beekguk

Kod ve tasarım açısından bakıldığında, diğerlerinin sürdürülebilirlik hakkında söylediklerini seviyorum.

Ayrıca, istikrara da bakıyorum. Üretim destek istatistiklerine bakın. Temel işlevsellik gibi görünen, ancak birçok insanın yazılımı nasıl kullanacağını anlayamadığını veya ihtiyaçlarını karşılamadığını fark ettiğinde yüksek bir destek yazışması alıyorsanız, bir sorun var demektir.

Tabii ki, gerçekten clueless bazı kullanıcılar var, ancak zamanla hala kırılma, karışıklık veya önemli özellik değişikliği istekleri raporları alıyorsanız, bu aşağıdakilerden birinin veya tamamının geçerli olduğunun bir göstergesidir:

  • Gereksinimler kırıldı
  • Kod bozuk
  • Uygulama sezgisel değil
  • Geliştirici kullanıcının ihtiyacını anlamadı
  • Birisi teslim tarihini kalite için zorladı
  • Birisi iyi test etmedi veya neyi test edeceğini bilmedi
2
Bernard Dy

Başka birisinden bir gün boyunca işinizi devralmasını isteyin ve günün sonunda ne kadar stresli olduğunu kontrol edin ;-)

Belgeleri belgeleme ve temizleme konusunda kötüyüm - işte böyle kontrol ederim.

2
Stefan Ernst

Nesir gibi okuyabildiğin zaman.

2
Klaim

Belirli bir kod parçası için:

Çalışıyorsa ve bakımı yapılabilirse (iyi uygulamalarınızı seçin), iyi bir koddur.

Zaman içinde geliştirici olarak sizin için:

İyi, dil alanı, sorun alanı, güncel eğilimler ve en önemlisi deneyiminiz için göreceli ve dinamik bir terimdir. Bu süreklilik için "İYİ" asit testi basitçe önceki çalışmanıza bakabilir ve "iç çek gerçekten böyle çözdüm mü?" o zaman hala büyüyor olabilirsiniz ve muhtemelen iyi kod yazmaya devam edersiniz.

Geriye bakıp mükemmel kodu görürseniz ya da - mükemmelsiniz ve durgunluk riski vardır ve yakında iyi kod yazmayı bırakabilirsiniz.

1
Stephen Bailey

İyi kod kişi için özneldir. Çok sayıda kitap okuyan ve seminerlere katılan ve farklı kodlama teknikleri kullanan profesyonel bir kodlayıcı muhtemelen kodunuzu parçalara ayırır ... Ancak, kodun gerçekten kodlayıcıların deneyim seviyesinin göstergesi olduğunu buldum. Bana göre bir tarih kitabı ya da oto-biyografi gibi. Kodlayıcının o sırada bildikleri şey veya sınırlı olduğu araçlar.

Kendinize bunu sorun ... Microsoft bir şeyi düzeltmek için neden 3 yazılım sürümü alıyor? Çünkü önceki versiyonlarda yaptıkları hataları sürekli düzeltiyorlar. Kodumun bir revizyondan sonra her zaman daha iyi olduğunu biliyorum. Tabii burada ilk kez mükemmel kod yazıyorum diyen insanlar olacak. Eğer inanıyorsan o zaman sana satacak bir bataklık arazim var ...

Kavramları anladığınız gibi işler kolaylaşıyor. Benim için, yeni bir şey öğrenmenin başlangıcı "işe alabilir miyim?" "nasıl daha hızlı yapabilirim" ...

Bir programcı olmak istiyorsanız, o zaman programa dalmanız ve yapmanız gerekir. Çok fazla iş gerektirir ve dürüst olmak gerekirse, asla bitirilemeyecek bir sanat eseri gibidir. Ancak, sadece sıradan bir hobi olmak istiyorsanız, o zaman çalışırsa, endişelenmeyin. Çevrenize uyum sağlamanız gerekiyor. Kod değerlendirmeleri yapmak için bir yolunuz yoksa, cehalet bliss =)

Ama ne olursa olsun ... Herkesin kendi fikri olacak. Tabii ki bir şeyler yapmanın doğru yolları ve yanlış yolları vardır ... Ama çoğunlukla şeyleri yapmanın çoğunlukla yanlış yollardan daha iyi yollarının olduğunu gördüm ...

1
webdad3

Tüm bunlar söyleniyor, programlarımın iyi olup olmadığını asla bilmiyormuşum gibi hissediyorum. Tabii, çalışıyorlar - ama kod temiz, sıkı, iyi yazılmış şeyler mi, yoksa başka bir kodlayıcı ona bakar ve kafamı tokatlar mı?

başka bir kodlayıcıya kodunuz hakkında ne düşündüklerini sormayı düşündünüz mü?

Bazı yerler, kod havuzuna kabul edilmeden önce kodun başka bir kodlayıcı tarafından kabul edilebilir olması gereken "akran denetimi" kullanır.

1
user1249

IMHO, kendi başına "iyi bir kod" yok, ama "iyi bir yazılım" var.

Bir şey üzerinde çalışırken, diğer birçok programcının "iyi kod" standardından düşen kodu üretmemizi sağlayan işimiz üzerinde birçok kısıtlama vardır.

Bazıları "iyi kod" bakımı kolay kod olduğunu söyleyebilir. Benim için bu ifadenin karşıtı, ne kadar kolay? "İyi kod" standardı uğruna bakım yapmayı kolaylaştırmak için kod parçasına% 200 çaba sarfetmemiz gerekiyor mu? Üzgünüm ama sanmıyorum.

Aslında, benim takımımda gerçekten kimsenin umurunda olmadığı "iyi kodu" tanıtan kişiyim. Kodlarına her baktığımda, mükemmel bir kod yazdıklarını hiç bulamadım. Ancak, işi gerçekten yaptıklarını kabul etmeliyim ve aynı zamanda şirketimizin ihtiyaçları için de yeterli düzeyde devam edebilmelidir. Tabii ki uygulama bazen buggy, ama biz sadece zaman içinde yaptı, müşterilerimizi ve kullanıcılarımızı mutlu etmek ve rakiplerimizin çok önünde pozisyonda firmamız güvenliğini sağlamak.

Yani, "iyi kod" ihtiyacınız olan şeyi üreten kod olduğunu söyleyebilirim. Sadece gerçekten neye ihtiyacınız olduğunu düşünmeniz, ardından bunu kodunuzu değerlendirmek için kullanmanız gerekir.

1
tia

Asla.

"İyi kod" yalnızca henüz bir gelişme yolu bulunmayan bir koddur. Jeff Atwood dedi ki :

Dünyada parlak, mükemmel kod üretebilen bir avuç programcı var. Geri kalanımızın yapabileceği tek şey, yazılımımızı zaman içinde daha az boktan yapmak - sürekli iyileştirme süreci

Ve bu arada, mükemmelliğe ulaşmak zorunda değilsiniz, çünkü bazen, " Yeterli Tasarım kötü tasarım anlamına gelir ".

0
David

Birinin deneyimli birisinin kodunuza bakmasını sağlayan hiçbir şey yoktur, ancak kodunuzu kendi başınıza değerlendirmenize ve geliştirmenize yardımcı olacak bazı kaynaklar vardır. Martin Fowler'in Yeniden Düzenleme (veya web sitesi ) adresine bakın. Sutter ve Alexandrescu'nun C++ Kodlama Standartları , C++ ile yazıyorsanız iyi olur. Buradaki önerilerin birçoğu dil agnostiktir, ancak diğerleri diğer diller için benzer kitaplar önerebilir. Test odaklı geliştirme, geliştiriciler için çok yararlı olabilir, çünkü gittikçe bir tür kalite kontrolü sağlar ve testlerin ne zaman yazılmasının zorlaştığını bilirsiniz, kodunuzun muhtemelen yeniden yapılandırmayı kullanabileceği anlamına gelir.

Diğer bazı işaretler daha süreç odaklı. Genellikle daha iyi koda yol açarlar, ancak doğrudan değiller. Bunlar arasında kaynak kontrolünün kullanımı, otomatik bir derleme işlemi, canlı sunucuda doğrudan gelişmeme, hata izleme yazılımının kullanımı vb.

0
Karl Bielefeldt

İyi kodlama çabasıyla, programın bu konuda son derece işlevsel ve hızlı olmasını sağlamayı hedefliyorum. Her şeyin bir yerde olduğundan emin olun, böylece dosya, veri, işlev ve soyutlamalar oldukça açıktır.

Bu noktadan sonra bir teste koydum: Genel olarak bilgisayarlarda oldukça açık bir kişiyi bulun, bazı ana kod desenlerini açıklamaya çalışın. Sorta-kinda okuyabilirlerse, vay canına. Aferin.

Çoğunlukla ÖPÜCÜK ve hiçbir şeyi çarpmadan yenilikçi olmaya çalışın. Ayrıca koda geri dönme ve onu geliştirmek ve sürdürmek için güzel bir zaman geçirme hakkında daha fazla not yapmak istiyorum, ama bu oldukça iyi kapsanmıştır.

0
Garet Claborn

FindBugs , PMD gibi kod analiz aracını kullanabilirsiniz. Bu, kodunuzun kalitesi hakkında bazı bilgiler sağlayacaktır.

0
nimcap

Kodunuzu bırakın, bazı kişilerin her zaman olması gerektiği şeyi yapmasını sağlamak için onunla uğraşmasına izin verin. Ya da isterseniz bir özellik tasarlayın ve tüm bu özellikleri karşıladığından emin olun. Bu testlerden birini veya her ikisini de geçerseniz, kodunuz "şu an için iyidir". Çoğu insan için, kodunuz asla harika olmayacaktır, çünkü bir yıl içinde geri dönüp "Neden daha iyi çalıştım o ne zaman çok daha iyi çalışırsa b yol mu? "

Daha fazla deneyim ile daha iyi kod elde edersiniz. Ancak sürekli olarak aynı alışkanlıkları uygularsanız, sürekli olarak aynı tuzaklara düşersiniz. Bu sadece "Alıştırma yapar kalıcı." İşleri sürekli olarak doğru şekilde yaparsanız (kodun her zaman yapması gereken şey için çalıştığından emin olmak için test etmek gibi), daha iyi olursunuz. İşleri sürekli olarak yanlış bir şekilde yaparsanız (kodunuzu hiçbir zaman belirli durumlar için test etmemek veya hataların nerede olabileceğini tanımamak gibi), kodunuzla inatçı olacaksınız.

0
Andrew Hays