Bagaimana seharusnya seseorang yang terbiasa dengan pemikiran FP membaca kode penting?

Saya lulus dari universitas sekitar lima bulan lalu, dan telah bekerja di startup lokal selama empat bulan terakhir. Sementara di universitas, saya belajar Haskell, F # dll sendiri. Kami diajarkan Java di universitas, tetapi saya terkena pemrograman fungsional segera, dan telah menghabiskan lebih banyak waktu dengan itu daripada yang saya lakukan dengan pemrograman imperatif. Akibatnya, otak saya terhubung dengan pemikiran fungsional. Perusahaan tempat saya bergabung menggunakan Python, dan kode ini sangat penting. Saya mengalami kesulitan membaca kode imperatif. Saya tidak dapat melacak mutasi. Ketika sarang untuk-jika-lain-untuk-... berjalan lebih dari empat tingkat, saya benar-benar kehilangan jejak apa yang terjadi dalam kode. Untuk menambahkannya, Python adalah bahasa yang dinamis, jadi tidak ada jenis dalam kode. Itu' Sudah berminggu-minggu sejak saya mencoba memahami bagian dari basis kode kami (yang seharusnya 'cukup kompleks'), tetapi sejauh ini saya belum membuat kemajuan berarti dalam memahaminya. Tolong tawarkan saya beberapa teknik praktis tentang bagaimana saya harus memahami kode itu. Terima kasih sebelumnya!

Sunting:
Mungkin saya juga harus menyebutkan bahwa tidak ada banyak komentar dalam kode, dan namanya juga tidak terlalu intuitif.

Memahami kode warisan itu sulit. Ini hampir tidak ada hubungannya dengan fungsional vs prosedural.

1. Buat semacam peta. Diagram komponen dari paket dan modul Python. Untuk setiap modul, Anda harus membuat diagram kelas.

2. Gunakan juru bahasa Python. Anda harus dapat mengimpor modul, membuat objek, dan melatihnya secara interaktif. Itu sebabnya Python populer. Anda dapat mencetak type(x)untuk melihat jenis variabel apa ( x ) sebenarnya.

3. Jika ragu, pastikan untuk membaca kode tes unit. Jika tidak ada kode uji unit, Anda memiliki masalah besar yang menjulang di samping mempelajari basis kode baru.

4. Tulis barang-barang. Mulai dengan dokumen sampingan. Kemudian, ketika Anda berpikir Anda tahu apa yang sedang terjadi, tambahkan komentar docstring ke fungsi, metode dan kelas. Tambahkan ini lebih awal dan sering.

5. Gunakan Sphinx dengan 'autodoc' untuk mengumpulkan apa yang Anda pelajari.

Bagian terpenting adalah ini. Sulit untuk menyimpan hal-hal di kepala Anda. Lebih mudah menyimpan segala sesuatu di file dokumentasi.

Saya mengalami kesulitan membaca kode imperatif. Ketika sarang untuk-jika-lain-untuk-... berjalan lebih dari empat tingkat, saya benar-benar kehilangan jejak apa yang terjadi dalam kode.

Tunggu ... siapa pun yang benar-benar kehilangan jejak kode dengan level bersarang yang dalam. Atau seperti yang dikatakan oleh Linus Torvalds:

Jika Anda membutuhkan lebih dari 3 level indentasi, Anda tetap kacau, dan harus memperbaiki program Anda.

Mungkin saya juga harus menyebutkan bahwa tidak ada banyak komentar dalam kode, dan nama-namanya juga tidak terlalu intuitif.

Ini tidak terdengar seolah-olah perusahaan Anda mematuhi praktik terbaik umum.

Jika saya jadi Anda, saya hanya akan mencoba memahami basis kode dengan disiplin dan kekerasan. Gali ke dalamnya, lagi dan lagi dan lagi. Mungkin seperti apa pun. Saat ini Anda merasa seperti berada di bawah air dan tidak bisa bernapas tetapi terus memeriksa basis kode dan segera Anda akan berenang ke permukaan.

Saya khawatir pertanyaan Anda tidak memiliki rincian teknis untuk menawarkan saran yang baik tentang bagaimana memahami basis kode, tetapi tidak pernah salah untuk membahasnya dengan rekan yang berpengalaman dalam beberapa sesi. Biarkan mereka menjelaskan arsitektur keseluruhan dan bagaimana komponen yang berbeda berinteraksi satu sama lain, bersama dengan keputusan implementasi yang mereka buat.

Sulit untuk memberikan saran umum untuk transisi dari bahasa fungsional ke bahasa imperatif / OO. Tentu, saya bisa menyebutkan beberapa frase berbunga-bunga seperti "Anda perlu memikirkan keadaan dan perilaku objek", tetapi ini tidak akan banyak membantu Anda, saya pikir ini adalah sesuatu yang harus Anda alami.

Jika (besar jika dari praktik buruk yang Anda gambarkan) ada tes unit, maka Anda dapat melihatnya untuk melihat bagaimana kode diuji. Ini dapat menawarkan wawasan yang baik tentang apa yang dilakukan kode.

Kalau tidak, saya akan menyarankan membaca kode python yang lebih umum agar terbiasa dengan cara itu ditulis.

Anda dapat mencoba menerjemahkan beberapa fragmen dari Python ke pseudo-Haskell atau apa pun yang Anda suka. Itu bisa memberi Anda rasa untuk apa konstruksi imperatif longgar memetakan ke dalam konstruksi fungsional apa. Ketika Anda mendapatkan lebih banyak pengalaman, konstruksi imperatif akan mulai terasa lebih asli.

Saya beralih dari pemrograman OCaml dan Haskell ke pemrograman Java dan Python, dan pengalaman saya adalah bahwa pemrograman imperatif tidak sebesar lompatan mengetik dinamis, yang hingga hari ini terasa asing.

Saya sarankan Anda meletakkan breakpoints dan mulai menggunakan perintah Next (seolah-olah Anda sedang men-debug), ini akan membantu Anda memahami aliran (mungkin pada cabang, ada jalur yang lebih mungkin diambil, pada jalur yang harus Anda konsentrasi untuk mendapatkan ide umum kode).

(Saya mendapat hasil yang baik dengan Eclipse bersama dengan PyDev sebagai plugin Eclipse)