Bagaimana Anda berurusan dengan memahami abstraksi dalam kode?

Ketika melihat basis kode baru saya suka memulai dari pendekatan bottom-up.
Di mana saya memahami satu file dan kemudian naik ke abstraksi berikutnya.
Tapi sering kali saya lupa apa yang dilakukan abstraksi tingkat bawah.

Jadi saya akan berada pada titik ini di mana saya menemukan diri saya dalam lingkaran yang hampir tanpa akhir untuk kembali ke file yang sebelumnya saya pahami sepenuhnya, dan kemudian mencoba mempelajari kembali file-file itu; sambil mencoba menyulap berbagai abstraksi lain yang terhubung satu sama lain di kepalaku.

Apakah ada strategi yang lebih baik untuk menghadapi situasi ini?

Haruskah saya melupakan detail level bawah dan menganggapnya sebagai pemberian? Tetapi bahkan kemudian, berkali-kali diperlukan pemahaman sebelumnya tentang abstraksi tingkat rendah untuk memahami apa yang dilakukan abstraksi saat ini.

Memprogram secara konkret adalah dorongan untuk menarik detail ke arah Anda sehingga Anda dapat memakukan semuanya di satu tempat. Kita semua memulai dengan cara ini dan sulit untuk dilepaskan.

Pemrograman secara abstrak jelas "melupakan perincian tingkat bawah". Terkadang bahkan detail level tinggi. Anda mendorong detail dan membiarkan yang lain berurusan dengannya. Hal yang licik adalah Anda telah melakukan ini selama ini. Apakah Anda benar-benar mengerti apa yang terjadi di antara semua print "Hello world"itu dan itu muncul di layar Anda?

Hal nomor satu yang harus Anda tuntut saat Anda berjuang untuk melepaskan detail-detail ini adalah nama-nama baik. Nama yang bagus memastikan Anda tidak akan terkejut ketika melihat ke dalam. Inilah mengapa Anda tidak terkejut printmenempatkan sesuatu di layar Anda dan tidak terlalu peduli bagaimana. foo "Hello world"akan menjadi cerita yang berbeda.

Juga, level abstraksi harus konsisten. Jika Anda berada pada level tentang menghitung pi, Anda juga tidak perlu khawatir tentang cara menampilkan pi. Detail itu telah bocor ke dalam abstraksi yang bukan miliknya.

Rincian yang lebih rendah, lebih tinggi, atau menyamping, yang bukan tentang satu hal yang saya pikirkan di tempat yang satu ini, dapat pergi sama sekali atau setidaknya bersembunyi di balik nama baik.

Jadi, jika Anda benar-benar berjuang memantul dari satu file ke file lainnya, saya akan mengatakan bahwa seseorang telah menjebak Anda dengan nama-nama buruk atau abstraksi yang bocor.

Saya memperbaikinya dengan membaca dengan jari saya. Setelah saya menjalani tes yang layak di sekitar kekacauan ini saya memisahkan tanggung jawab, memberi mereka nama yang jelas yang menghindari kejutan, dan menunjukkannya kepada orang lain untuk memastikan saya tidak hidup di dunia fantasi.

Tampaknya saya tidak sendirian dalam hal bekerja dengan cara ini:

Setiap kali saya bekerja pada kode asing saya mulai mengekstraksi metode. Ketika saya melakukan ini, saya mencari potongan kode yang dapat saya beri nama - kemudian saya ekstrak. Bahkan jika saya akhirnya menguraikan metode yang telah saya ekstrak nanti, setidaknya saya memiliki cara untuk menyembunyikan detail sementara waktu sehingga saya dapat melihat keseluruhan struktur.

Michael Feathers - Orange Code

Di bagian bawah, ada beberapa pembaruan tentang bagaimana ini bagi saya setiap kuartal tahun ini, saya pikir mereka berharga.

Penamaan yang bagus. Atau, jika itu kode orang lain, mencoba mengaitkan nama baik / tanggung jawab berdasarkan bahkan nama buruk pada kelas / fungsi sistem itu sehingga masuk akal di kepala saya. Setelah itu terjadi, implementasi tingkat rendah menjadi lebih mudah diingat.

Itu saja yang saya miliki. Ada banyak puritan di situs ini yang akan bersumpah demi Tuhan tahu pola atau objek apa pun, tetapi penamaan yang baik akan membuat Anda jauh. Saya telah melakukan lebih dari itu sendiri dengan membuat kode yang didokumentasikan / dinamai / dipisahkan dengan baik dan tidak pernah kembali menggigit saya, bahkan jika kode saya digunakan di banyak tempat, oleh banyak orang, tetapi satu hal yang saya lakukan dengan benar adalah membuang banyak waktu untuk penamaan yang baik, komentar yang baik dan skema yang menjelaskan aliran kode saya. Implementasi tingkat rendah diperlukan untuk memahami jika Anda ingin memperluas kode saya secara mendalam. Kode yang ditulis dengan baik dapat diperluas dengan cara yang masuk akal, jadi, boleh saja seseorang atau Anda tidak memahami / mengingat implementasi tingkat rendah.

Jika Anda tertarik pada sedikit kontroversi yang orang-orang di bidang asli saya dan saya tahu kebenarannya, tetapi, jika Anda mendengarkan apa yang tertulis di sini, Anda akan belajar untuk setuju dan tidak setuju dengan jawaban ini , baca selanjutnya:

Tapi ada masalah lain di sini - puritan. Anda akan mendengar jawaban dan ideologi dengan kata-kata yang masuk akal dan sepenuhnya logis, pada kenyataannya, tidak ada yang salah dengan mereka. Tetapi Anda tidak harus mengikuti mereka, pada kenyataannya, mereka mungkin bermain merugikan Anda.

Teman-teman saya bekerja dengan sistem besar dan mereka hanya menertawakan orang-orang yang terlalu peduli pada konvensi dan pola dan untuk alasan yang baik, saya akan melakukannya juga - saya dapat menemukan alasan saya untuk ini dari bidang utama analisis data saya, karena saya bukan pengembang yang berpengalaman: Sebagian besar hal yang Anda anggap penting, tidak masalah dan ada korelasi kuat dengan ego Anda dalam hal ini.Sering kali seorang individu, karena egonya, akan memperoleh pengetahuan bahwa ia kemungkinan besar disalahpahami karena biasnya yang sekarang kembali dikuatkan oleh otoritas yang menurutnya hanya mengatakan "hal yang sama yang saya lakukan". Ini adalah jebakan yang sangat terkenal yang seharusnya Anda tidak pernah jatuh. Ini tidak berarti dia tidak menggunakannya dengan benar atau untuk kebaikan yang lebih besar, tetapi sering kali, apa yang akan dilakukan orang-orang ini adalah janji bahwa apa pun yang mereka katakan adalah hadiah emas.

Jadi apa yang bisa kamu lakukan?

Jelaskan kode Anda kepada rekan kerja dan tanyakan apakah masuk akal dari sudut pandang tingkat tinggi.

Itu yang terpenting. Tentu saja siapa pun yang membaca kode orang lain akan selalu memiliki alt-tab fiesta untuk melihat implementasi hal-hal tertentu, tetapi itu tidak masalah, jika siapa pun yang membaca kode Anda memiliki pemahaman tingkat tinggi tentang sistem Anda dan memahami "mengapa sesuatu terjadi "(lagi, tanpa harus tahu, sepenuhnya" bagaimana mereka terjadi "), maka kamu adalah emas.

Ini bukan saya katakan maju dan menulis kode omong kosong yang tidak berkinerja atau tidak menghargai apa pun, tetapi apa yang saya katakan adalah:

1) Tidak apa-apa untuk dilupakan. Pada waktunya, Anda akan lebih baik dalam membaca kode yang sedang Anda kerjakan. Jika kode yang Anda baca menuntut Anda tahu implementasi tingkat rendah pada tingkat yang baik, maka kode itu ditulis dengan buruk dan memainkan apa yang saya katakan sebelumnya: apakah rekan kerja memahami Anda?

2) Dunia dipenuhi dengan banyak orang yang sangat cerdas yang tidak terlalu pintar. Mereka juga sering kali sangat emosional dan mereka cenderung memperkuat bias dari kekuatan luar. Mereka sangat baik dalam apa yang mereka lakukan, tetapi apa yang mereka, sebagai pelaku penyebaran informasi lupakan adalah: ide / informasi, bahkan jika didukung oleh "logika" memiliki konteks yang mengirim mereka, yang sangat penting dalam memahami apakah atau tidak itu informasi juga berguna bagi Anda. Apa yang masuk akal bagi Anda bisa masuk akal bagi orang lain dan mereka akan menyukainya tetapi informasi tidak boleh dianggap mutlak dan satu, sekali lagi, harus mempertimbangkan, atau setidaknya mencoba untuk mencari tahu konteks dari mana asalnya dan mengeceknya. konteks sendiri untuk melihat apakah itu cocok. Ini benar-benar sama dengan para miliarder memberi kita "sedikit pengetahuan untuk maju"

Singkatnya: tulis kode yang dapat dimengerti dan sadari bahwa masih dapat diperdebatkan di mana kita membutuhkan banyak pola / kelas dan kilang seperti yang dikatakan beberapa orang. Ada orang-orang yang sangat pintar di kedua sisi argumen dan itu hanya akan memperkuat gagasan melakukan apa pun yang bekerja untuk tim Anda dengan cara yang masuk akal - jangan terjebak pada detail kecil yang tidak masalah, Anda akan menemukan mereka nanti, ingatlah, Anda hidup di dunia yang sangat kompetitif di mana waktu adalah hal yang paling penting:

Pengaturan waktu dalam kesuksesan startup.

Alokasikan waktu dan sumber daya Anda dengan cara yang bermakna dan serakah.

Berikut hasil edit, 6 bulan kemudian:

Ini merupakan perjalanan yang gila. Saya tidak pernah berpikir bahwa hanya pemisahan / penamaan yang baik & dokumentasi pada dasarnya dapat memungkinkan Anda untuk memasukkan sesuatu masuk & keluar dari basis kode Anda. Saya harus menulis ulang banyak kode untuk mempercepatnya dengan perubahan baru dan saya melakukannya dalam 2-3 hari. Saya dapat dengan aman mengatakan bahwa saya tidak mengikuti SOLID di mana-mana karena kurangnya pengetahuan, atau praktik terbaik dan saya bisa mengatakan mereka dalam hutang teknis saya, tetapi tidak banyak. Terpisah, beri nama dengan baik & dokumen, itu akan memungkinkan Anda untuk mengubah kode dalam waktu singkat ketika Anda akhirnya menyadari betapa bodohnya Anda.

Jangan salah paham: jika Anda menulis kode Anda dengan erat, Anda akan kesakitan, apakah Anda membenci SOLID atau tidak, bahkan memahami & menerapkannya pada tingkat dasar memungkinkan decoupling hebat yang, jujur, adalah satu-satunya hal yang sangat membantu OOP. OOP seharusnya juga tentang penggunaan kembali kode dan sementara itu terjadi di sana-sini, Anda tidak benar-benar bisa menggunakan kembali banyak objek yang Anda buat, jadi, fokuslah untuk memastikan sistem Anda terpisah dengan baik. Setelah Anda mencapai kedewasaan dan mari kita asumsikan Paman Bob datang dan memimpin proyek Anda, dia akan berkata "Oke, ini bodoh sekali, tapi setidaknya semuanya terpisah, diberi nama & didokumentasikan dengan baik sehingga setidaknya saya tahu apa ini semua tentang " (Saya harap). Bagi saya, ini berhasil. LOC saya terus berubah, tetapi pada saat penulisan, ini adalah 110k baris kode, 110k baris kode kinerja yang bekerja secara harmonis untuk satu orang.

Inilah hasil edit, 3 bulan kemudian, pada kode 8 bulan yang saya refactoring:

Itu semua masuk akal. Sekarang saya dapat mengambil apa yang saya tulis saat itu, secara konsep dan memperbaiki kode lagi, dengan ide-ide baru karena saya sangat memahami apa yang terjadi dan mengapa ia bekerja karena skema / penamaan yang baik dan komentar. Saya menulis beberapa kode lama yang lalu bahwa saya tidak peduli tentang penamaan yang baik dan semacamnya dan itu sulit untuk dilalui. Saya sekarang berpikir apa langkah selanjutnya untuk menjelaskan kode saya.