Koddaki soyutlamayı anlama ile nasıl başa çıkıyorsunuz?

Yeni bir kod tabanına bakarken aşağıdan yukarıya bir yaklaşımla başlamak istiyorum.
Burada bir dosyayı anlıyorum ve sonra bir sonraki soyutlamaya geçiyorum.
Ama çoğu zaman kendimi daha düşük seviyeli soyutlamanın ne yaptığını unuturken bulurum.

Bu noktada kendimi daha önce tam olarak anladığım dosyalara geri dönüp sonra onları yeniden öğrenmeye çalışan neredeyse sonsuz bir döngüde bulacağım; kafamda birbirine bağlanan sayısız soyutlamayı dengelemeye çalışırken.

Bu durumla başa çıkmak için daha iyi bir strateji var mı?

Sadece alt düzey ayrıntıları unutmalı ve verilen gibi mi almalıyım? Ancak o zaman bile, mevcut soyutlamanın ne yaptığını anlamak için daha önce alt düzey soyutlamanın daha iyi anlaşılması gerekir.

Somut olarak programlama, ayrıntıları size doğru çekme dürtüsüdür, böylece hepsini tek bir yerde çivileyebilirsiniz. Hepimiz bu şekilde başlıyoruz ve bırakmak zor.

Soyut programlama kesinlikle “alt düzey detayları unutmak” tır. Bazen üst düzey ayrıntılar bile. Ayrıntıları uzağa itiyorsunuz ve onlarla başka bir şeyin baş etmesine izin veriyorsunuz. Sinsi şey, bunu başından beri yapıyor olmanız. Tüm bunların arasında ne olduğunu print "Hello world"ve ekranınızda göründüğünü gerçekten anlıyor musunuz ?

Bu detayları bırakmak için uğraşırken talep edilecek bir numaralı şey iyi isimler. İyi bir isim, içeriye baktığınızda şaşırmamanızı sağlar. Bu yüzden printekranınıza bir şey koymak şaşırmadı ve nasıl gerçekten umurumda değildi. foo "Hello world"farklı bir hikaye olurdu.

Ayrıca, soyutlama düzeyleri tutarlı olmalıdır. Pi hesaplamakla ilgili bir düzeydeyseniz, pi'nin nasıl görüntüleneceği konusunda da endişelenmemelisiniz. Bu detay ait olmadığı bir soyutlamaya sızdı.

Bu yerde düşündüğüm tek şeyle ilgili olmayan daha alçak, daha yüksek ya da yanlamasına ayrıntılar ya tamamen yok olabilir ya da en azından iyi bir ismin arkasına saklanabilir.

Yani eğer gerçekten dosyadan dosyaya sıçramakta zorlanıyorsanız, birinin sizi kötü isimlerle veya sızdıran soyutlamalarla sıkıştırabileceği ihtimallerini söyleyeceğim.

Bunu parmaklarımla okuyarak düzeltiyorum. Bu karmaşa etrafında iyi testler yaptıktan sonra sorumlulukları birbirinden ayırıyorum, sürprizlerden kaçınan açık isimler veriyorum ve bir fantezi dünyasında yaşamadığımdan emin olmak için başka birine göstereceğim.

Görünüşe göre bu şekilde çalışmak söz konusu olduğunda yalnız değilim:

Bildiğim kod üzerinde çalıştığımda yöntemleri çıkarmaya başlıyorum. Bunu yaptığımda, adlandırabileceğim kod parçalarını ararım - sonra ayıklarım. Daha sonra çıkardığım yöntemleri satır başı yapsam bile, en azından genel yapıyı görebilmem için ayrıntıyı geçici olarak gizleme yolum var.

Michael Tüyler - Turuncu Kod

En altta, bunun yılın her çeyreğinde benim için nasıl bir şey olduğuna dair bazı güncellemeler var, bence bunlar değerli.

İyi adlandırma. Ya da başka birinin kodu ise, o sistemin sınıfları / işlevleri üzerindeki kötü isimlere bile iyi isimler / sorumluluklar atfetmeye çalışmak, böylece kafamda mantıklı. Bir kez, düşük seviyeli uygulamaları hatırlamak daha kolay hale gelir.

Tüm sahip olduğum bu. Bu sitede, hangi türden olursa olsun hangi desenleri veya nesneleri tanıyacağına tanrı tarafından yemin edecek birçok safkan var, ancak iyi adlandırma sizi uzaklaştıracaktır. Çok az belgelenmiş / iyi adlandırılmış / iyi ayrılmış kod oluşturarak kendimden daha fazlasını yaptım ve kodum birçok yerde, birçok insan tarafından kullanılsa bile beni ısırmaya geri dönmedi, ancak doğru yaptığım bir şey, kodumun akışını açıklayan iyi adlandırma, iyi yorumlar ve şemalar üzerinde çok zaman harcamaktı. Kodumu derinlemesine genişletmek isteyip istemediğinizi anlamak için düşük seviyeli uygulama gereklidir. İyi yazılmış kod makul yollarla genişletilebilir, bu nedenle birisinin veya düşük seviyeli uygulamaları anlamaması / hatırlamaması uygundur.

Orijinal alanımdaki insanların yanı sıra benim için gerçek olduğunu bildiği konusunda biraz tartışmayla ilgileniyorsanız, ancak burada yazılanları dinlerseniz, bu yanıtı hem kabul etmeyi hem de katılmama öğreneceksiniz. , okumaya devam edin:

Ama burada başka bir sorun daha var - saflar. Makul ve tamamen mantıklı olan iyi ifade edilmiş cevapları ve ideolojileri duyacaksınız, aslında, onlarda yanlış bir şey yok. Ama onları takip etmek zorunda değilsiniz, aslında, dezavantajınızda oynuyor olabilirler.

Arkadaşlarım büyük sistemlerle çalıştılar ve sadece sözleşmeler ve kalıplar hakkında biraz fazla önem veren insanlara gülüyorlar ve iyi bir sebeple ben de yapardım - bunun için akıl yürütme veri analizimin ana alanından bulabilirim, çünkü çok deneyimli bir geliştirici değilim: Düşündüğün şeylerin çoğu önemli değil, bu anlamda egonla güçlü bir korelasyon var.Çoğu zaman, bir kişi, egosu nedeniyle, "benimle aynı şeyi" söylediğini düşündüğü bir otorite tarafından yeniden uygulanan önyargılar nedeniyle büyük olasılıkla yanlış anladığı bilgisini edinmiş olacaktır. Bu, asla girmemeniz gereken çok iyi bilinen bir tuzaktır. Bu, onu doğru bir şekilde ya da daha iyisi için kullanmadığı anlamına gelmez, ancak çoğu zaman, bu insanların yapacakları şey söylediklerinin altın ödül olacağına dair sözdür.

Ne yapabilirsin?

Kodunuzu bir iş arkadaşınıza açıklayın ve üst düzey bir bakış açısından mantıklı olup olmadığını sorun.

Önemli olan bu. Tabii ki başka birinin kodunu okuyan herkes, belirli şeylerin uygulanmasını görmek için her zaman bir alt-tab fiesta'ya sahip olacaktır, ancak kodunuzu okuyan her kim sisteminizin üst düzey anlayışına sahipse ve "şeylerin neden olduğunu anlarsa, bu önemli değil. "(yine, mutlaka bilmeden, tamamen" nasıl olduklarını "), o zaman altınsın.

Bu devam edip performansa sahip olmayan veya hiçbir şeye saygı duymayan bok kodu yazıyorum demiyorum, ama söylediğim şey:

1) Unutmak sorun değil. Zamanla, birlikte çalıştığınız kodu okuma konusunda daha iyi olursunuz. Okuduğunuz kod, düşük seviyeli uygulamaları iyi düzeyde bilmenizi istiyorsa, kod kötü yazılmıştır ve daha önce söylediğimle oynar: bir meslektaş sizi anlıyor mu?

2) Dünya çok zeki olmayan çok zeki insanlarla dolu. Ayrıca çoğu zaman çok duygusaldırlar ve dış güçlerden önyargıyı güçlendirmeye eğilimlidirler. Yaptıkları işte çok iyidirler, ancak bilgiyi yaymanın aktörleri olarak unuttukları şey: "mantık" tarafından desteklense bile fikirler / bilgiler, onları gönderenin bağlamına sahiptir; bu, bilgi de sizin için yararlıdır. Sizin için mantıklı olan başkaları için mantıklı olabilirdi ve bunu seveceklerdi, ancak bilgi mutlak olarak alınmamalı ve bir kez daha, geldiği bağlamı anlamaya çalışmalı ve en azından onun nereden geldiğini anlamaya çalışmalı ve eşleşip eşleşmediğini görmek için kendi içeriğine bakın. Bize "ilerlemek için bu bilgi parçalarını" veren milyarderlerle gerçekten aynı

Kısacası: anlaşılabilir bir kod yazın ve bazılarının söylediği kadar desen / sınıf ve rafineriye ihtiyaç duyduğumuzda hala tartışmalı olduğunu anlayın. Argümanın her iki tarafında çok akıllı insanlar var ve bu sadece ekibiniz için işe yarayan her şeyi makul bir şekilde yapma fikrini güçlendirmelidir - önemli olmayan küçük detaylara yapışmayın, onları anlayacaksınız daha sonra, zamanlamanın en önemli şey olduğu son derece rekabetçi bir dünyada yaşadığınızı unutmayın:

Başlangıçta zamanlama başarısı.

Zamanınızı ve kaynaklarınızı anlamlı, açgözlü bir şekilde tahsis edin.

İşte 6 ay sonra bir düzenleme:

Bu çılgın bir yolculuktu. Ben sadece ayırma / iyi adlandırma ve dokümantasyon temelde kod tabanı içine ve dışında bir şey takmak için izin verebilir asla düşündüm. Yeni değişikliklerle hızlandırmak için çok fazla kod yazmak zorunda kaldım ve 2-3 gün içinde iyi bir yığın yaptım. Bilgi eksikliğinden veya en iyi uygulamalardan dolayı SOLID'i her yerde takip etmediğimi güvenle söyleyebilirim ve teknik borcumda olduklarını söyleyebilirim, ancak çok fazla değil. Ayrı, iyi adlandırın ve belge, eninde sonunda ne kadar aptal olduğunuzu fark ettiğinizde kodu değiştirmenize izin vermez.

Beni yanlış anlamayın: Kodunuzu sıkıca bağlarsanız, SOLID'den nefret edip etmemeniz için çok fazla acı çekersiniz, taban seviyesinde anlamak ve uygulamak bile dürüstçe, OOP'un gerçekten yardımcı olduğu tek şey. OOP'un da kodun yeniden kullanımı ile ilgili olması gerekiyordu ve bu orada ve orada gerçekleşirken, oluşturduğunuz pek çok nesneyi gerçekten tekrar kullanamazsınız, bu nedenle sisteminizin iyi ayrılmış olduğundan emin olun. Bir kez olgunluğa ulaştığınızda ve Bob Amca'nın projenize geldiğini ve öncülük ettiğini varsayalım, "Tamam, bu cehennem kadar aptal ama en azından her şey ayrıldı, iyi adlandırıldı ve belgelendi." " (Umuyorum). Benim için çalışıyor. LOC'm sürekli değişiyor, ancak yazma sırasında 110k kod satırı, tek bir kişi için uyum içinde çalışan 110k kod gerçekleştirme satırı çok fazla.

İşte 3 ay sonra, 8 ay kodda yeniden düzenleme yaptığım bir düzenleme:

Hepsi mantıklı. Şimdi yazdıklarımı kavramsal olarak alıp kodu yeni fikirlerle yeniden biçimlendirebilirim, çünkü neler olduğunu ve neden şematik / iyi adlandırma ve yorumlar nedeniyle çalıştığını mükemmel bir şekilde anlıyorum. Uzun zaman önce iyi isimlendirme ve böyle bir şey umursamadığım bir kod yazdım ve bu acıdan geçmesi acı çekiyor. Şimdi kodumu açıklamanın bir sonraki adımının ne olabileceğini düşünüyorum.