İyi Kodun Altı Emri: Zamana Dayanan Kod Yazın

İnsanlar yaklaşık yarım yüzyıldır bilgisayar programlama sanatı ve bilimi ile sadece boğuşuyorlar. Çoğu sanat ve bilim ile karşılaştırıldığında, bilgisayar bilimi birçok yönden hala sadece bir çocuktur, duvarlara girer, kendi ayaklarına takılır ve ara sıra masaya yemek fırlatır.

Göreceli gençliğinin bir sonucu olarak, “iyi kodun” doğru tanımının ne olduğu konusunda henüz bir fikir birliğine sahip olduğumuza inanmıyorum, çünkü bu tanım gelişmeye devam ediyor. Bazıları "iyi kodun" %100 test kapsamına sahip kod olduğunu söyleyecektir. Diğerleri, süper hızlı olduğunu ve olağanüstü bir performansa sahip olduğunu ve 10 yıllık donanım üzerinde kabul edilebilir bir şekilde çalışacağını söyleyecektir.

Bunların hepsi yazılım geliştiriciler için takdire şayan hedefler olsa da, karışıma başka bir hedef daha eklemeyi göze alıyorum: sürdürülebilirlik. Spesifik olarak, "iyi kod", bir kuruluş tarafından (sadece yazarı tarafından değil!) kolayca ve kolayca bakımı yapılabilen ve yazıldığı sprint'ten daha uzun süre yaşayacak olan bir koddur. Aşağıda keşfettiğim bazı şeyler var. ABD'de ve yurtdışında büyük ve küçük şirketlerde mühendis olarak kariyer, sürdürülebilir, "iyi" yazılımlarla ilişkili görünüyor.

Emir 1: Kendi Koduna Nasıl Davranmak İstiyorsan Başkalarının Yasasının Sana Davranmasını İstiyorsun

Kodunuzun birincil hedef kitlesinin derleyici/bilgisayar değil, kodu okuması, anlaması, sürdürmesi ve geliştirmesi gereken kişi olduğunu yazan ilk kişiden çok uzaktayım (bundan altı ay sonra mutlaka siz olmayacaksınız). ). Ücretini hak eden herhangi bir mühendis “çalışan” bir kod üretebilir; Mükemmel bir mühendisi diğerlerinden ayıran şey, bir işi uzun vadede destekleyen, sürdürülebilir kodları verimli bir şekilde yazabilmeleri ve sorunları basit, açık ve sürdürülebilir bir şekilde çözme becerisine sahip olmalarıdır.

Herhangi bir programlama dilinde iyi kod veya kötü kod yazmak mümkündür. Bir programlama dilini iyi kod yazmayı ne kadar kolaylaştırdığına göre yargıladığımızı varsayarsak (en azından en azından en önemli kriterlerden biri olmalıdır), nasıl kullanıldığına (veya kötüye kullanıldığına) bağlı olarak herhangi bir programlama dili “iyi” veya “kötü” olabilir. ).

Pek çok kişi tarafından "temiz" ve okunabilir olarak kabul edilen bir dile örnek Python'dur. Dilin kendisi bir düzeyde beyaz boşluk disiplini uygular ve yerleşik API'ler bol ve oldukça tutarlıdır. Bununla birlikte, konuşulamaz canavarlar yaratmak mümkündür. Örneğin, bir sınıf tanımlayabilir ve çalışma zamanı sırasında o sınıftaki her yöntemi tanımlayabilir/yeniden tanımlayabilir/tanımını kaldırabilir (genellikle maymun yaması olarak adlandırılır). Bu teknik doğal olarak en iyi ihtimalle tutarsız bir API'ye ve en kötü ihtimalle hata ayıklaması imkansız bir canavara yol açar. Safça “tabii, ama kimse bunu yapmaz!” diye düşünebilir. Ne yazık ki yapıyorlar ve maymun yamalarını API'lerinin çekirdeği olarak yoğun bir şekilde kullanan (ab) önemli (ve popüler!) kitaplıklarla karşılaşmadan önce pypi'ye göz atmak uzun sürmüyor. Geçenlerde, bir nesnenin ağ durumuna bağlı olarak tüm API'si değişen bir ağ kitaplığı kullandım. Örneğin, client.connect() 'i çağırdığınızı ve bazen HostNotFound veya NetworkUnavailable yerine MethodDoesNotExist hatası aldığınızı düşünün.

Emir #2: İyi Kod Kısmen ve Bütün Olarak Kolayca Okunur ve Anlaşılır

İyi kod, kısmen ve tamamen başkaları tarafından kolayca okunur ve anlaşılır (aynı zamanda yazar tarafından gelecekte “Bunu gerçekten ben mi yazdım?” sendromundan kaçınmaya çalışır).

"Kısmen" derken, kodda bir modül veya işlev açarsam, kod tabanının geri kalanını da okumak zorunda kalmadan ne yaptığını anlayabileceğimi kastediyorum. Mümkün olduğunca sezgisel ve kendi kendini belgeleyen olmalıdır.

Kod tabanının diğer (görünüşte alakasız) bölümlerinden gelen davranışı etkileyen küçük ayrıntılara sürekli atıfta bulunan kod, her cümlenin sonunda dipnotlara veya bir eke başvurmanız gereken bir kitap okumak gibidir. İlk sayfadan asla geçemezsiniz!

"Yerel" okunabilirlik hakkında bazı diğer düşünceler:

• İyi kapsüllenmiş kod, her düzeyde endişeleri ayırarak daha okunabilir olma eğilimindedir.

• İsimler önemlidir. Beynin düşünceleri oluşturduğu ve bazı gerçek, dikkatli düşünceleri değişken ve yöntem adlarına koyduğu Hızlı ve Yavaş Düşünme Sistemini 2 etkinleştirin. Birkaç ekstra saniye, önemli temettüler ödeyebilir. İyi adlandırılmış bir değişken kodu çok daha sezgisel hale getirebilirken, kötü adlandırılmış bir değişken kafa karışıklığına ve kafa karışıklığına yol açabilir.

• Zeka düşmandır. Süslü teknikler, paradigmalar veya işlemler (liste kavramaları veya üçlü operatörler gibi) kullanırken, bunları kodunuzu yalnızca kısaltmakla kalmayıp daha okunaklı hale getirecek şekilde kullanmaya dikkat edin.

• Tutarlılık iyi bir şeydir. Hem parantezleri nasıl yerleştirdiğiniz açısından hem de işlemler açısından stildeki tutarlılık, okunabilirliği büyük ölçüde artırır.

• Endişelerin ayrılması. Belirli bir proje, kod tabanındaki çeşitli noktalarda sayısız sayıda yerel olarak önemli varsayımları yönetir. Kod tabanının her bir bölümünü bu endişelerden mümkün olduğunca azına maruz bırakın. Bir kişi nesnesinin bazen boş bir soyadına sahip olabileceği bir kişi yönetim sisteminiz olduğunu varsayalım. Kişi nesnelerini gösteren bir sayfada kod yazan biri için bu gerçekten garip olabilir! Ve “Kod tabanımızın sahip olduğu garip ve bariz olmayan varsayımlar” el kitabını tutmadığınız sürece (bilmediğimi biliyorum) görüntüleme sayfası programcınız soyadlarının boş olabileceğini bilmeyecek ve muhtemelen boş gösterici ile kod yazacaktır. soyadı boş durumda göründüğünde istisna. Bunun yerine, bu durumları iyi düşünülmüş API'ler ve kod tabanınızın farklı parçalarının birbiriyle etkileşim kurmak için kullandığı sözleşmelerle ele alın.

Emir #3: İyi Kod, Durumu Yönetmek İçin İyi Düşünülmüş Bir Düzene ve Mimariye Sahiptir

Devlet düşmandır. Niye ya? Çünkü herhangi bir uygulamanın en karmaşık kısmıdır ve çok kasıtlı ve düşünceli bir şekilde ele alınması gerekir. Yaygın sorunlar arasında veritabanı tutarsızlıkları, yeni verilerin her yere yansımadığı kısmi UI güncellemeleri, sıra dışı işlemler veya her yerde if ifadeleri ve dallar içeren, okunması zor ve kodun bakımının daha da zor olmasına neden olan, uyuşturacak kadar karmaşık kodlar yer alır. Durumu büyük bir özenle ele alınacak bir kaide üzerine koymak ve duruma nasıl erişildiği ve değiştirildiği konusunda son derece tutarlı ve kasıtlı olmak, kod tabanınızı önemli ölçüde basitleştirir. Bazı diller (örneğin Haskell) bunu programatik ve sözdizimsel düzeyde zorunlu kılar. Hiçbir dış duruma erişmeyen saf işlev kitaplıklarınız ve ardından dış saf işlevselliğe başvuran küçük bir durum bilgisi kodlu yüzey alanınız varsa, kod tabanınızın netliğinin ne kadar gelişebileceğine şaşıracaksınız.

Emir #4: İyi Kod Tekerleği Yeniden İcat Etmez, Devlerin Omuzlarında Durur

Bir tekerleği potansiyel olarak yeniden icat etmeden önce, çözmeye çalıştığınız sorunun veya gerçekleştirmeye çalıştığınız işlevin ne kadar yaygın olduğunu düşünün. Birisi, yararlanabileceğiniz bir çözümü zaten uygulamış olabilir. Uygun ve mevcutsa, bu tür seçenekleri düşünmek ve araştırmak için zaman ayırın.

Bununla birlikte, tamamen makul bir karşı argüman, bağımlılıkların herhangi bir olumsuzluk olmadan “ücretsiz” gelmediğidir. Bazı ilginç işlevler ekleyen bir üçüncü taraf veya açık kaynak kitaplık kullanarak, o kitaplığa bağlılık ve bağımlı hale geliyorsunuz. Bu büyük bir taahhüt; dev bir kitaplıksa ve yalnızca küçük bir işlevselliğe ihtiyacınız varsa, örneğin Python 3.x'e yükseltirseniz tüm kitaplığı güncelleme yükünü gerçekten istiyor musunuz? Ayrıca, bir hatayla karşılaşırsanız veya işlevselliği geliştirmek istiyorsanız, düzeltmeyi veya geliştirmeyi sağlamak için yazara (veya satıcıya) bağımlısınız veya açık kaynak ise, kendinizi bir ( potansiyel olarak önemli) kod tabanı, belirsiz bir işlevi düzeltmeye veya değiştirmeye tamamen aşina değilsiniz.

Elbette, bağımlı olduğunuz kod ne kadar iyi kullanılırsa, bakım için kendinize zaman ayırmanız o kadar az olasıdır. Sonuç olarak, kendi araştırmanızı yapmanız ve dış teknolojiyi dahil edip etmemeniz ve bu teknolojinin yığınınıza ne kadar bakım sağlayacağı konusunda kendi değerlendirmenizi yapmanız faydalı olacaktır.

Aşağıda, modern çağda projenizde muhtemelen yeniden icat etmemeniz gereken şeylerin daha yaygın örneklerinden bazıları verilmiştir (bunlar sizin projeleriniz OLDUĞU sürece).

veritabanları

Projeniz için hangi CAP'ye ihtiyacınız olduğunu belirleyin, ardından doğru özelliklere sahip veritabanını seçin. Veritabanı artık sadece MySQL anlamına gelmiyor, aşağıdakiler arasından seçim yapabilirsiniz:

• “Geleneksel” Şema'lı SQL: Postgres / MySQL / MariaDB / MemSQL / Amazon RDS, vb.
• Anahtar Değer Depoları: Redis / Memcache / Riak
• NoSQL: MongoDB/Cassandra
• Barındırılan DB'ler: AWS RDS / DynamoDB / AppEngine Datastore
• Ağır kaldırma: Amazon MR / Hadoop (Kovan/Domuz) / Cloudera / Google Big Query
• Çılgın şeyler: Erlang'ın Mnesia'sı, iOS'un Temel Verileri

Veri Soyutlama Katmanları

Çoğu durumda, kullanmayı seçtiğiniz veritabanına ham sorgular yazmamalısınız. Büyük olasılıkla, DB ile uygulama kodunuz arasında, eşzamanlı veritabanı oturumlarını yönetme endişelerini ve şema ayrıntılarını ana kodunuzdan ayıran bir kitaplık vardır. En azından, uygulama kodunuzun ortasında asla ham sorgular veya SQL satır içi olmamalıdır. Bunun yerine, onu bir işleve sarın ve tüm işlevleri gerçekten bariz bir şey (örneğin, "queries.py") adlı bir dosyada merkezileştirin. Örneğin, users = load_users() gibi bir satırın okunması, users = db.query(“SELECT username, foo, bar from users LIMIT 10 ORDER BY ID”) den çok daha kolaydır. Bu tür bir merkezileştirme, sorgularınızda tutarlı bir stile sahip olmayı çok daha kolaylaştırır ve şemanın değişmesi durumunda sorguları değiştirmek için gidilecek yerlerin sayısını sınırlar.

Yararlanmayı Düşünülecek Diğer Ortak Kitaplıklar ve Araçlar

• Kuyruk veya Pub/Sub Hizmetleri. AMQP sağlayıcılarından istediğinizi seçin, ZeroMQ, RabbitMQ, Amazon SQS
• Depolamak. Amazon S3, Google Bulut Depolama
• İzleme: Grafit/Barındırılan Grafit, AWS Bulut İzleme, Yeni Kalıntı
• Günlük Toplama / Toplama. Loggly, Splunk

Otomatik Ölçeklendirme

• Otomatik Ölçekleme. Heroku, AWS Beanstalk, AppEngine, AWS Opsworks, Dijital Okyanus

Emir #5: Akarsuları Geçmeyin!

Programlama tasarımı, pub/sub, aktörler, MVC vb. için pek çok iyi model var. Hangisini en çok seviyorsanız onu seçin ve ona bağlı kalın. Farklı veri türleri ile ilgilenen farklı mantık türleri, kod tabanında fiziksel olarak izole edilmelidir (yine, bu endişelerin ayrılması kavramı ve gelecekteki okuyucu üzerindeki bilişsel yükün azaltılması). Kullanıcı arayüzünüzü güncelleyen kod, örneğin, kullanıcı arayüzüne ne girdiğini hesaplayan koddan fiziksel olarak farklı olmalıdır.

Emir #6: Mümkün Olduğunda Bilgisayarın İşi Yapmasına İzin Verin

Derleyici, kodunuzdaki mantıksal hataları yakalayabilir ve kötü davranışı, hataları veya doğrudan çökmeleri önleyebilirse, bundan kesinlikle yararlanmalıyız. Elbette, bazı dillerde bunu diğerlerinden daha kolay hale getiren derleyiciler bulunur. Örneğin Haskell, programcıların çabalarının çoğunu yalnızca derlemek için kod almak için harcamalarına neden olan ünlü katı bir derleyiciye sahiptir. Yine de derlendiğinde, “sadece çalışır”. Hiçbir zaman güçlü bir şekilde yazılmış işlevsel bir dilde yazmamış olanlarınız için bu saçma veya imkansız görünebilir, ancak bunun için söze inanmayın. Cidden, bu bağlantılardan bazılarına tıklayın, çalışma zamanı hataları olmayan bir dünyada yaşamak kesinlikle mümkündür. Ve gerçekten bu kadar büyülü.

Kuşkusuz, her dilde, derleme zamanı denetimine çok fazla (veya bazı durumlarda herhangi bir!) olanak tanıyan bir derleyici veya sözdizimi yoktur. Yapmayanlar için, projenizde hangi isteğe bağlı katılık kontrollerini etkinleştirebileceğinizi araştırmak için birkaç dakika ayırın ve sizin için anlamlı olup olmadıklarını değerlendirin. Esnek çalışma zamanlarına sahip diller için son zamanlarda kullandığım bazı yaygın dillerin kısa, kapsamlı olmayan bir listesi şunları içerir:

• Python: pylint, pyflakes, uyarılar, emacs içindeki uyarılar
• Ruby: uyarılar
• JavaScript: jslint

Çözüm

Bu, hiçbir şekilde “iyi” (yani, bakımı kolay) kod üretmek için eksiksiz veya mükemmel bir emir listesi değildir. Bununla birlikte, gelecekte almak zorunda olduğum her kod tabanı bu listedeki kavramların yarısını bile takip ederse, çok daha az gri saçım olur ve hatta hayatımın sonuna fazladan beş yıl daha ekleyebilirim. Ve işi kesinlikle daha zevkli ve daha az stresli bulacağım.