Android

Bob Amca ile Birlikte Daha İyi Bir Dünyayı Kodlamak

Bob Amca’dan tüm bu “Birlikte Daha İyi Bir Dünyayı Kodlamak” derslerinden öğrendiklerimin kendi sözleriyle özeti bunlar. Yalnızca benim için yararlı olan bilgileri çıkarırım.

yorumumu ekledim gözü pek Onunla tam olarak aynı fikirde olmadığım veya benim için önemli olan herhangi bir şey için.

Temiz Kod – Bob Amca (1. Ders)

  • Doğası gereği temiz kod yazmıyoruz. Sorunu çözmek ana önceliktir. Bu nedenle, yeniden düzenlememiz gerekiyor.

İşlev

  • İşlevi küçük tutun, bir şey yapın.
  • Bir şey, artık yapamayana kadar çıkardığınız anlamına gelir.
  • İşlev doğru şekilde adlandırılmalıdır (fonksiyonun ne yaptığını söyler)
  • İşlev fiil olmalıdır.
  • İşlevin 3’ten az argümanı olmalıdır.
  • geçme Boolean dallanma amaçlı bir fonksiyona dönüştürülür.
  • Kaçınmakswitch ve if Beyan. Polimorfizm kullanın (açık-kapalı prensibi).

Yan etkiler

  • Yan etki işlevi sistemin durumunu değiştirir.
  • Kullanmak lambda çift ​​ile birlikte gelen yan etki işlevi için (örn. open bir dosya ve close bir dosya). Geri arama uygulamasını şu şekilde işlemeyi iletin: lambda bir işleve dönüştürülür.
  • Takip edilecek kural – komut, hiçbir şey döndürmeyen bir işlevdir, yan etkileri olmalıdır. Sorgu, değer döndüren bir işlevdir, yan etkisi OLMAMALIDIR.
  • Hata kodlarını döndürmek için istisnaları tercih edin. Try bloğu, istisnayı oluşturan yalnızca bir işlev çağrısını içermelidir. [I made this mistake. Most of my try block contains unnecessary stuff that can be pulled out.]

Diğerleri

  • Kendinizi Tekrar Etmeyin, yinelenen kodlardan kaçının.
  • Yazılım, doğruluğu kanıtlanamayan bilim gibidir.

Temiz Kod – Bob Amca (Ders 2)

  • Yorum, açıklamak için kodu kullanamayacağınız kodu açıklamaktır.
  • Yorum yalandır, zamanla bozulur ve kimse bunu sürdürmez.
  • Yoruma değil, koda çaba gösterin.
  • kontrol etme TODObir kez kontrol edildiğinde, yapma [I disagree. Having TODO in code is quite useful. It is developer’s responsibility to implement the TODO]
  • Zorunlu, günlük, gürültü, konum işaretçisi, kapanış ayracı, nitelik (yazar tarafından) yorumlarından kaçının.
  • Yorumlanmış koddan kaçının
  • Başka bir yerde olan kodu yorumlamayın. [I do not fully agree because sometimes we need to do that in oder to clearly explain the intention of the code. I would say avoid this if possible.]
  • Yasal yorum (telif hakkı)
  • Bilgilendirici yorum (gerçek niyeti yansıtamayan tasarım deseni kuralı adlandırma, karmaşık düzenli ifade)
  • Amplifikasyon (belirli kodun neden orada olduğunun önemini vurgulayın)

Değişken ve Fonksiyon Adlandırma

  • niyetini ortaya koymalı
  • Değişken adının uzunluğu, onu içeren kapsamın boyutuyla orantılı olmalıdır.
  • İşlev tam tersidir, kapsam ne kadar büyükse işlev o kadar küçüktür.

Kod İncelemeleri

  • Kod incelemelerinde harcanan süre, kod yazma süresiyle aynı olmalıdır.
  • Kod incelemelerinden daha iyi bir alternatifle eşleştirme

Temiz Kod – Bob Amca (3. Ders)

Kalite

  • Kodu yayınladığınızda, çalıştığını bilirsiniz.
  • Her yinelemede dağıtılmaya hazır (sevk edilebilir) (örn. 2 haftalık yineleme)
  • Kod zamanla daha iyi olmalı
  • Korkusuz yeterlilik – yeniden düzenleme yapmaktan veya koda dokunmaktan korkmayın. Koda dokunduğunuzda kırıyorsunuz, kod sizin oluyor. Böylece koda dokunmaktan kaçınırsınız. [This sounds so familiar! However, practically this is subjective. Sometimes you do want to minimize the risk with minimum code changes]
  • KG’nin hiçbir şey bulamamasını bekleyin.

İstikrarlı Verimlilik

  • Sistem büyüdüğünde yavaşlamazsınız (özellik üretim hızı yavaşlamaz).

Ucuz Uyarlanabilirlik

  • Yazılım, tasarım gereği değiştirilebilir olmalıdır. Bu yüzden “Yumuşak” eşyadır.
  • Değişikliğin maliyeti, değişikliğin kapsamı ile orantılı olmalıdır.

Dürüst Tahmin

  • Daima en iyi durumdan en kötü senaryoya kadar bir aralıkta tahminde bulunun.

Temiz Kod – Bob Amca (4. Ders)

  • Onlarca yıldır yazılım programlamasında hiçbir yenilik yapılmadı. Yazılan tüm kodlar hala dizi, seçim ve etkileşimdir.
  • Ancak donanım, yazılıma kıyasla çıldırdı.
  • Kıdemli yazılım mühendisi, cevap açıkça hayır olduğunda “HAYIR” demelidir. [This is subjective. In software, you do not have definite answer, so you shouldn’t say no in my opinion. “NO” is also a negative word where people often think you’re defensive. I will rephrase it with more convincing bullets]

Test Odaklı Geliştirme (TDD)

  • TDD disiplindir ve keyfidir.
  • 3 TDD Kuralları
    1. Üretim kodu olmadığı için başarısız olan bir test yazmadan önce herhangi bir üretim kodu yazmanıza izin verilmez.
    2. Tüm testler geçene kadar daha fazla test yazma izniniz yok
    3. Yalnızca testin derlenmesini veya geçmesini sağlayan minimum üretim kodunu yazabilirsiniz.
  • TDD, muhasebede çift girişli defter tutma gibidir (örneğin bilanço)
  • TDD önemli bir beceridir. İşe başlamadan önce iyi öğrenin.

Temiz Kod Bob Amca (Ders 5)

  • Yazılım mimarisi gelişir, sabit değildir.
  • Yazılım mimarisinin amacı, sistemi kurmak ve sürdürmek için gereken insan kaynağını en aza indirmektir.
  • Temiz kod yazmak sizi yavaşlatmaz. Tüm bu disiplinlerden dolayı yavaş hissediyorsunuz.
  • Yazılımın 2 değeri vardır:
    1. Yaptığı işin değeri
    2. Yapısının değeri (genellikle göz ardı edilir)
  • İkinci değer, yazılımı esnek hale getirdiği için birinciden daha önemlidir. Böylece değiştirme maliyeti en aza indirilir.
  • Yazılım mühendisi, ikinci değeri paydaşlara (sadece gereksinimle ilgilenen) iletmekten sorumludur ve bu kolay bir iş değildir.
  • İyi bir mimari, büyük kararların ertelenmesine izin verir

Temiz Kod Bob Amca (Ders 6)

  • Yaptığınız herhangi bir projenin temel kanunu. Üçünü seç…
    1. İyi kalite)
    2. Hızlı (Pazara Çıkış Zamanı, Program)
    3. Ucuz (Maliyet Etkinliği, Personel)
    4. Bitti (Kapsam)
  • Verilere dayalı olarak projeleri mümkün olan en iyi sonuca göre yönetin (yukarıdaki dört özelliğin tümünü en üst düzeye çıkarın)
  • Çevik, yinelemeli geliştirmedir (küçük ekibin küçük şeyler yapması için) ve verileri sağlamayı amaçlar (örneğin, hız ve tükenmişlik çizelgeleri)
  • Son tarih, iş nedeniyle sabittir, ancak sürekli değişen gereklilik değil
  • Gereksinimler değişmeye devam ediyor çünkü müşteri ne istediğini görene kadar bilmiyor. Böylece “Şelale Modeli” artık uygulanamaz.
  • Hızlı gitmenin, iyi iş çıkarmanın, hızlı gitmenin tek yolu kalitedir. Personelin ve programın sabit olduğunu varsayarsak, yalnızca kapsamla oynayabiliriz.
  • Sürekli olarak yeniden düzenleme yaptığımız için yeniden düzenlemeyi asla programa dahil etmeyin. Paydaş bunu umursamıyor.
  • [In my opinion, Agile is a good tool ONLY IF it is “properly” used by the project management. It is often being misused, for example, Garbage in, garbage out.]

Özet

Bu video dizileri izlemek için motive edici ama biraz fazla uzun. Ondan bir şey öğrendim ama önemli değil. Pek çok şey oldukça sağduyuludur ve şirketin kültürüne göre öznel olabilir.

Şahsen, daha önce hiç test odaklı Geliştirme (TDD) yapmadım ve minimum düzeyde eşleştirme deneyimim oldu. Bir şansım olursa, TDD’yi denemek isterim.

İlgili Makaleler

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.

Başa dön tuşu