Bekerja pada kode orang lain [ditutup]

Saya hampir tidak memiliki pengalaman satu tahun dalam coding. Setelah saya mulai bekerja, sebagian besar waktu saya akan bekerja pada kode orang lain, baik menambahkan fitur baru di atas yang sudah ada atau memodifikasi fitur yang ada. Orang yang telah menulis kode sebenarnya tidak lagi bekerja di perusahaan saya. Saya mengalami kesulitan memahami kodenya dan melakukan tugas saya. Setiap kali saya mencoba memodifikasi kode, entah bagaimana saya telah mengacaukan fitur yang berfungsi. Apa yang harus saya ingat, saat mengerjakan kode orang lain?

Apakah kode memiliki tes unit? Jika tidak, saya sangat menyarankan Anda mulai menambahkannya. Dengan cara ini, Anda dapat menulis perbaikan fitur / bug baru sebagai tes gagal dan kemudian memodifikasi kode yang lulus tes. Semakin banyak yang Anda bangun, semakin Anda percaya bahwa kode tambahan Anda tidak merusak yang lain.

Tes unit penulisan untuk kode yang Anda tidak sepenuhnya mengerti akan membantu Anda memahami kode tersebut. Tentu saja, tes fungsional harus ditambahkan jika belum ada. Kesan saya adalah bahwa mereka yang sudah ada membentuk pertanyaan OP. Jika saya salah tentang hal itu, maka tes fungsional ini harus menjadi langkah pertama Anda.

Eagle76dk membuat poin bagus tentang mendapatkan manajer Anda untuk melakukan pekerjaan ini - lebih detail di posting Eagle76dk.

Selain itu saat Anda menulis tes ini, saya mendorong Anda untuk mencoba menulis tes sehingga mereka memverifikasi perilaku bisnis yang mungkin telah dicapai metode ini, bukan perilaku kode. Juga, jangan sekali-sekali menganggap perilaku bisnis yang Anda lihat dalam kode adalah yang benar - Jika Anda memiliki seseorang yang dapat memberi tahu Anda apa yang seharusnya dilakukan aplikasi yang dalam banyak kasus lebih berharga daripada apa yang mungkin diberikan oleh kode tersebut kepada Anda.

Selain jawaban lain yang menyebutkan tes unit, saya sarankan agar Anda memastikan semuanya ada dalam kontrol versi sehingga Anda dapat mengembalikan perubahan dengan mudah. Dan melakukan perubahan kecil untuk membuat kode lebih mudah dikelola.

Menurut pendapat saya, cara tercepat untuk mempelajari kode orang lain, (terutama ketika perubahan memicu perilaku yang tidak terduga seperti yang Anda jelaskan) adalah dengan menelusuri kode menggunakan debugger .

Mulailah dengan melangkah melalui apa yang tampaknya menjadi loop utama / metode utama program. Gunakan fungsi step into dan step out untuk melihat apa yang dilakukan berbagai metode. Ini akan mengajarkan Anda struktur umum kode.

Setelah itu, bagilah dan taklukkan dengan melangkah melalui dan mempelajari bagian-bagian berbeda dari program pada tingkat yang lebih dalam. Di sebagian besar debuggers, Anda dapat mempelajari variabel dan nilainya saat ini . Pelajari bagaimana mereka berubah dan kapan.

Tetapkan breakpoints pada metode yang memicu perilaku yang mengkhawatirkan Anda. Misalnya jika Anda mencoba untuk mengubah teks dalam program, dan teks terus berubah kembali ke nilai aslinya, atur breakpoints di semua tempat di mana teks diubah, atau cobalah untuk memindahkan semua perubahan ini ke satu metode tunggal. Gunakan tumpukan panggilan untuk melihat dari mana metode ini dipanggil, dll.

Jika mengubah satu baris kode menyebabkan perubahan tak terduga di tempat lain, letakkan breakpoint pada baris itu, dan lihat apa yang terjadi di sana, misalnya dengan memeriksa nilai variabel saat ini dalam cakupan, menggunakan langkah ke dalam, atau tumpukan panggilan untuk melihat dari mana telepon itu datang.

Dengan melakukan banyak hal ini, Anda akan mulai mempelajari struktur kode dengan sangat cepat. Saya mulai seperti yang Anda lakukan pada pekerjaan pemrograman pertama saya, dengan banyak kode yang telah ditulis bertahun-tahun yang lalu dan telah diubah oleh banyak orang selama bertahun-tahun. Kode itu bukan milik saya hanya karena ada tempat orang lain mengerjakannya pada saat bersamaan. Saya tidak bisa menulis ulang semuanya pada saat itu. Menulis tes untuk semua kode itu akan memakan waktu berbulan-bulan atau bertahun-tahun. Debugger benar-benar menyelamatkan saya, tidak tahu bagaimana saya akan belajar kode tanpa itu ...

Hal pertama yang perlu diingat adalah lebih banyak waktu dihabiskan membaca kode daripada menulis kode. Habiskan waktu untuk memahami bagaimana orang lain bekerja - gaya dan pendekatannya terhadap masalah.

Cobalah untuk mengadopsi gaya yang ada sebanyak mungkin - jika tidak, pria setelah Anda memiliki dua kali lebih banyak penyesuaian untuk dilakukan.

Berurusan dengan kode orang lain adalah norma, bukan pengecualian, Anda harus menjadi mahir dalam mencari tahu bagaimana orang lain akan memecahkan masalah atau mengimplementasikan fitur. Setelah Anda selesai melakukannya, Anda akan merasa lebih mudah untuk berurusan dengan kodenya.

Jangan terlalu cepat menganggap kode orang lain itu bau.

Tapi selalu curiga.

Tapi ya, butuh waktu untuk memahami kode dev lain. Semakin banyak fungsi atau objek yang digunakan oleh banyak bagian sistem, semakin Anda harus berhati-hati. Jika Anda dapat memecahkan masalah lebih dekat dengan gejala, itu kadang-kadang bisa membantu. Misalnya, menormalkan data yang masuk dari objek lain di sisi masalah-objek pagar setelah data dikirimkan tetapi sebelum hal lain terjadi.

Ini adalah pertanda buruk ketika mengubah satu hal menghancurkan yang lain secara tak terduga. Jika Anda memiliki pengembang lain yang lebih berpengalaman yang dapat Anda andalkan untuk mendapatkan bantuan, saya sarankan agar mereka melihat hal-hal yang menyebabkan Anda mengalami masalah. Paling tidak Anda dapat mengambil beberapa hal menonton mereka men-debug.

Dalam dunia yang ideal, semua kode yang ditulis oleh pengembang tertentu akan didokumentasikan dengan baik, terstruktur dengan baik dan diuji secara komprehensif, baik dengan alat otomatis seperti tes unit dan menggunakan skrip kasus yang dijalankan pengguna untuk memeriksa apakah Anda mendapatkan hasil yang diharapkan.

Namun, hal pertama yang akan Anda pelajari adalah kita tidak hidup di dunia yang ideal!

Banyak pengembang tidak mendokumentasikan kode mereka dengan benar, jika sama sekali, mereka mencampur logika bisnis dengan kode yang tidak terkait, dan satu-satunya tes yang mereka lakukan adalah menjalankan cepat melalui apa yang mereka harapkan menjadi kasus penggunaan normal.

Ketika bekerja dengan kode seperti ini, hal pertama yang harus Anda lakukan adalah menetapkan apa yang seharusnya dilakukan. Jika ada komentar mereka mungkin memberi Anda petunjuk, tetapi jangan mengandalkannya. Ini pengalaman saya bahwa banyak coders tidak pandai menjelaskan diri mereka sendiri dan bahkan jika mereka meninggalkan komentar mereka mungkin tidak ada artinya. Namun, kecuali jika Anda satu-satunya pembuat kode di perusahaan, seseorang pasti harus memiliki setidaknya ide dasar untuk apa kode ini dan apa yang harus dilakukan. Tanya sekitar!

Jika Anda memiliki tes unit, maka mereka akan membuat hidup Anda jauh lebih mudah. Jika tidak, maka bagian dari mempelajari basis kode mungkin melibatkan penulisan unit test untuk kode yang sudah ada. Biasanya ini tidak dianggap praktik yang baik karena jika Anda menulis unit test agar sesuai dengan kode yang ada, Anda akan berakhir dengan unit test yang menganggap kode berfungsi sebagaimana mestinya (mereka akan ditulis untuk berasumsi bahwa perilaku yang sebenarnya adalah bug adalah benar), tetapi setidaknya itu memberi Anda garis dasar. Jika nanti Anda menemukan bahwa beberapa perilaku yang Anda anggap benar ternyata salah, Anda dapat mengubah unit test untuk menguji apa hasil yang diharapkan daripada hasil yang diberikan kode sekarang. Setelah Anda memiliki unit test, Anda dapat membuat perubahan dan menilai efek samping apa saja yang Anda buat.

Terakhir, sumber daya terbaik yang Anda miliki ketika berhadapan dengan bagian kode yang tidak berdokumen adalah bertanya kepada pengguna akhir. Mereka mungkin tidak tahu apa-apa tentang kode, tetapi mereka tahu apa yang mereka ingin aplikasi lakukan. Pengumpulan persyaratan adalah tahap pertama dalam proyek apa pun, dan berbicara dengan calon pengguna sistem yang akan dikembangkan selalu merupakan bagian penting dari itu. Anggap saja melakukan tahapan penangkapan persyaratan untuk proyek baru yang kebetulan sudah dibangun.

Ingatlah bahwa kode yang ditulis dengan baik dan terdokumentasi dengan baik pun bisa sulit dipahami oleh orang luar. Kode pada dasarnya adalah ekspresi dari bagaimana orang yang menulisnya berpikir pada saat itu, dan setiap orang memiliki proses pemikiran mereka sendiri yang unik. Anda harus belajar menjadi sedikit sabar, dan menjadi seorang detektif. Sulit untuk masuk ke proses pemikiran orang lain itu sulit, tetapi itu adalah keterampilan penting bagi seorang programmer melakukan pemeliharaan pada kode yang ada. Karena kebanyakan pengkodean (sekitar 70%) terkait dengan mempertahankan kode yang ada, ini merupakan keterampilan yang penting untuk dipelajari.

Oh, dan sekarang setelah Anda melihat rasa sakit yang dapat disebabkan oleh kode yang tidak terdokumentasi, tidak teruji, dan campur aduk, Anda tidak akan melakukannya pada pengembang miskin berikutnya, bukan? :) Belajarlah dari kesalahan pendahulu Anda, komentari kode Anda dengan baik, pastikan bahwa setiap modul memiliki tanggung jawab yang jelas, dan pastikan Anda memiliki serangkaian unit test komprehensif yang Anda tulis terlebih dahulu (untuk metodologi TDD) atau setidaknya di samping kode yang sedang dikembangkan.

Ingatlah bahwa kemampuan membaca kode yang belum Anda tulis adalah keterampilan yang sangat berharga, mungkin lebih berharga daripada menulis kode. Sayangnya, ini tidak banyak dipahami dan diajarkan di sekolah.

Yang ingin saya katakan adalah bahwa Anda tidak selalu mengerti kode saat membacanya pertama kali (seperti biasa Anda tidak menulis kode yang sempurna pertama kali) adalah normal. Jika Anda menerima bahwa butuh waktu untuk mendapatkan kode asing, maka Anda tidak akan keberatan melakukan upaya ekstra. Ringkasan kecil:

• Tes unit akan ideal, tetapi tidak selalu realistis; terutama jika Anda bekerja di organisasi besar dengan birokrasi yang berat.

• Pelajari cara menggunakan sistem Kontrol Versi Anda dengan benar; Anda tidak akan pernah merusak yang sudah ada (tidak benar-benar tidak pernah , tapi itu adalah jaring pengaman yang baik).

• Jangan menganggap itu buruk hanya karena Anda tidak memahaminya secara instan. Jangan menganggap itu baik hanya karena itu berfungsi. Yang penting adalah Anda memahami gaya kode pengelola sebelumnya dan menyesuaikan garis yang ditambahkan dengan gayanya. Sang pengelola datang setelah Anda akan berterima kasih untuk itu.

• Di beberapa perusahaan, sayangnya, kesulitan membaca kode dapat dianggap remeh. Ini umum di perusahaan besar dengan proses yang kaku. Mereka sering (secara implisit) lebih suka Anda mendorong kode yang berfungsi dengan cepat daripada meluangkan waktu Anda untuk menulis sesuatu yang bersih. Saya akan menyerahkan kepada Anda untuk memutuskan di mana tim Anda berdiri pada titik ini.

• Akhirnya, jangan pernah lupa bahwa membaca kode adalah keterampilan . Semakin banyak Anda melakukannya, semakin baik Anda melakukannya. Cara lain untuk mengatakan ini adalah bahwa satu - satunya cara untuk menjadi ahli dalam hal itu adalah dengan mempraktikkannya berkali-kali. Seperti disebutkan di atas, membaca kode adalah dan akan menjadi bagian yang jauh lebih besar dari pekerjaan Anda daripada menulis.

Menilai dari masalah Anda dengan secara tidak sengaja memecahkan barang, saya akan menganggap bahwa kode tidak tercakup oleh tes otomatis. Langkah # 0 akan segera memesan dan membaca Bekerja Efektif dengan Kode Legacy oleh Michael Feathers. Ini sangat berharga.

Langkah dasar yang saya sarankan:

• Tutup kode dengan tes yang mencakup fungsi saat ini.
• Refactor sampai dimengerti.
• Tulis tes untuk fungsionalitas baru atau yang dimodifikasi.
• Terapkan fungsionalitas baru.
• Refactor sampai kepuasan.

Saya sengaja tidak menyebutkan rasa tes (unit, integrasi, ...) - hanya mendapatkan semacam cakupan tes otomatis.

(dan, ya, ikuti gaya pengkodean dalam hal tata letak dan penamaan)

Seperti disebutkan sebelumnya: selamat datang di dunia nyata. Saya hanya bisa setuju dengan jawaban sebelumnya. Saya hanya ingin memperpanjang jawaban dengan pengalaman kerja saya tentang perkiraan waktu.

Saran yang bagus untuk membuat Anda jelas, perlu waktu untuk mempelajari bagaimana pengembang lain berpikir. Biasanya Anda akan mengalami bahwa solusi saat ini sering tergantung pada usia dan pengalaman pengembang.

Jika Anda beruntung, tugas yang ada harus dianalisis dan memahami dokumentasi akan banyak membantu Anda (tetapi ini sering tidak terjadi).

Pengalaman saya adalah ketika memodifikasi kode orang lain, cobalah untuk tidak mengubah kode yang tidak melibatkan tugas Anda saat ini. Anda mungkin tahu solusi yang lebih baik atau bisa ditulis dengan cara yang lebih intuitif, tetapi mengubahnya sering menyebabkan masalah seperti:

• Tugas akan memakan waktu lebih lama dan atasan Anda tidak akan memahaminya.
• Kode yang Anda ubah harus diuji, dan biayanya. Solusi saat ini telah diuji dan disetujui.
• Akan sulit untuk melihat perubahan apa yang menyelesaikan tugas saat ini, dan mana yang merupakan koreksi 'adil'.

Tetapi jangan ragu untuk memberi tahu atasan Anda, jika Anda melihat sesuatu yang menurut Anda harus berbeda (itu hanya menunjukkan Anda bisa berpikir).

Akhirnya, pastikan Anda memiliki cukup waktu untuk membuat solusi. Solusi yang lebih cepat hadir dengan pengalaman. Tetapi jarang ada solusi cepat, karena ini adalah alasan pertama / utama untuk kesalahan dan kode yang tidak dapat dipertahankan.

Anggap saja seperti melakukan operasi pada seseorang.

Anda mencari ke dalam untuk masalah yang perlu Anda perbaiki dan perhatikan bahwa sebagian besar arteri, dll. Tidak diatur seperti yang Anda lakukan - jadi Anda memotong dan memotongnya sampai terlihat tepat untuk Anda dan kemudian memperbaiki masalahnya.

Hebatnya pasien Anda segera meninggal.

Aplikasi warisan adalah sama. Mereka sudah memiliki cara kerja - Anda perlu memahami berbagai komponen dalam perangkat lunak dan bagaimana mereka berhubungan satu sama lain dan kemudian melakukan perubahan sehingga berfungsi dengan cara yang sama. Ini tidak mengasyikkan karena membiarkan kreativitas Anda menjadi liar, tetapi Anda dapat melakukannya pada proyek pribadi.

Saya akan meminta insinyur senior untuk duduk bersama Anda selama satu jam atau lebih setiap hari Senin dan menjelaskan aspek berbeda dari sistem. Buat catatan tentang apa yang dia katakan dan kirim email catatan kepadanya dan manajer Anda untuk melihat apakah manajer Anda memiliki sesuatu untuk ditambahkan. Anda harus bangun dengan kecepatan cukup cepat dengan cara ini.

Adapun cara tidak merusak barang-barang, pertama-tama pastikan Anda memahami apa yang sistem lakukan. Tes sebelum - lakukan perubahan - tes sesudahnya. Tidak ada formula ajaib; saat Anda mendapatkan pengalaman, Anda akan menjadi lebih baik - atau dipecat saya kira!

Satu hal yang belum pernah saya lihat menyentuh di sini - jangan bekerja di pulau.

Kecuali jika Anda adalah satu-satunya programmer di pakaian Anda, pasti ada seseorang yang memiliki pengalaman lebih dari Anda, dan sangat mungkin banyak orang yang bisa Anda andalkan.

Mengajukan pertanyaan. Banyak dari mereka.

Jangan khawatir tentang "menjengkelkan" orang lain (masuk akal) - Saya lebih suka seseorang menyela saya untuk satu atau dua pertanyaan selama siklus pengembangan normal, daripada harus memadamkan api di lingkungan produksi nanti.

Ketika Anda siap untuk memeriksa sesuatu, ulas dengan mentor Anda. Mereka harus dapat memberi tahu Anda tidak hanya jika sesuatu akan merusak sesuatu yang lain, tetapi yang lebih penting, mengapa. Meninjau kode juga akan membuat mentor menjadi programmer yang lebih baik, memberinya pandangan ke dalam sistem yang mungkin tidak sering mereka lihat.

Ingat - Anda tidak hanya mempelajari sistem seperti yang perlu dilakukan oleh karyawan baru, tetapi Anda juga belajar bagaimana menjadi seorang programmer.

Dan lima tahun kemudian, dorong Orang Baru berikutnya untuk menggunakan Anda sebagai mentor.

Ketika datang ke kode debugging, ingat: selalu ada alasan . Ketika Anda telah berusaha menemukan dan memperbaiki bug bodoh yang sama selama beberapa hari dan Anda tidak membuat kemajuan, tergoda untuk mulai memikirkan satu atau lebih dari:

• Saya tidak cukup pintar untuk mengetahui bagaimana kode ini bekerja

• Orang yang menulis kode ini tidak tahu apa yang dia lakukan

• Sihir terlibat: sihir yang sangat hitam

Itu semua adalah bentuk menyerah. Antidotnya adalah selalu ingat bahwa komputer itu deterministik: selalu ada alasan untuk apa yang mereka lakukan. Kode tersebut mungkin berbau seperti air surut di tempat pengalengan ikan dan menyerupai semangkuk linguine raksasa, tetapi dengan bersikap rasional tanpa henti dan tetap berpikiran terbuka, Anda akan mengetahuinya .

Apakah Anda menulis unit test jika memungkinkan atau menulis aplikasi kecil yang melibatkan kode yang Anda modifikasi, Anda harus melihat, memahami, dan kemudian mendokumentasikan logika.

Jika kode sebagian besar bekerja - sepertinya memang begitu - maka saya akan mempertahankan gaya pemformatan kode untuk modul itu, apakah itu gaya Anda atau tidak. Itu membuat semuanya seragam. Namun, komentar yang baik tidak pernah ketinggalan zaman.

Saya menyarankan sistem pengujian dan platform pengujian, di mana Anda dapat memodifikasi dan menguji kode ini, tanpa merusak produksi.

Jika Anda dapat menghapus elemen kode ke perpustakaan, saya akan melakukannya, kecuali jika Anda bekerja di perpustakaan.

Seiring waktu, setelah Anda memahami logika, Anda dapat menulis ulang dan menguji.

Saran ini terjaga keamanannya oleh bahasa yang Anda gunakan, kemampuan untuk mendapatkan test bed, dan kendala lain yang Anda miliki.

Cobalah untuk menggunakan beberapa alat penganalisa kode untuk menemukan kode yang tidak digunakan yang dapat dihapus - jadi setidaknya Anda tidak perlu khawatir tentang kode ini.

Telah dikomentari di atas bahwa Anda perlu memahami tujuan sistem, bukan hanya rincian kode. Seorang programmer dengan pengalaman yang cukup untuk menulis sistem entri pesanan umumnya nyaman dengan bagian 'bergerak maju', yang melibatkan pemilihan produk, memformat faktur, dan memproses pembayaran. Di mana mereka macet adalah ketika pengguna memutuskan 'tidak apa-apa' dan mulai membatalkan transaksi, atau ketika mereka membuat kesalahan dalam pemrosesan pembayaran dan menekan tombol 'kembali'. Pada saat itu banyak programmer merasa bingung, karena mereka melihat kode 'muncul entah dari mana' dan tidak tahu mengapa itu ada.

Singkatnya, Anda harus memahami bukan hanya 'aliran normal', tetapi semua kemunduran yang diperlukan jika seseorang membuat kesalahan atau mengubah pikiran mereka. Ini menjadi lebih buruk dengan penggantian atasan, di mana beberapa kode hanya dapat dijalankan dengan hak istimewa akun tertentu.

Jika seseorang menulis 10.000 baris kode setahun, dan aplikasi memiliki 'kehidupan' sepuluh tahun, maka seorang programmer yang bertanggung jawab untuk mengambil pekerjaan orang lain mungkin harus memahami 100.000 baris kode. Membaginya dengan 50 baris per halaman adalah 2000 halaman. Jika program ditulis dengan pola desain, programmer akan menemukan bahwa pemahaman tentang satu 'blok' mengarah pada setidaknya pemahaman umum sebagian besar sisanya. Jika tidak, maka perlu membaca setiap baris terakhir.

Beberapa programmer 'hanya melakukan apa yang diperintahkan' dan menulis spageti. Mereka tidak pernah memahami 'gambaran besar' - mereka hanya melakukan perbaikan ketika pengguna mengeluh. Dalam keadaan seperti itu, adalah ide yang baik untuk mulai bermigrasi apa pun yang Anda bisa ke pola yang sesuai. Akhirnya ini bisa berarti pengodean ulang hal-hal yang tidak 'rusak'. Jangan khawatir tentang hal itu, pastikan saja selama proyek Anda itu semakin progresif dipertahankan.

Ada beberapa jawaban yang sangat bagus di sini. Tapi saya pikir mungkin juga layak menyebutkan berapa banyak keakraban dengan pola desain yang baik dapat membantu, membaca kode yang ada (ditulis dengan baik) dan untuk menulis kode yang dapat dibaca.

Tentu saja bisa sangat membingungkan ketika Anda menemukan SomethingFactorykode yang ada, yang sebenarnya tidak mengikuti pola pabrik . Tetapi sebanyak yang dimungkinkan oleh tim dan kerangka kerja Anda, mungkin bermanfaat untuk menjaga kasus tersebut seminimal mungkin.

Mengikuti pola desain (di mana kebutuhan bisnis memungkinkannya) juga dapat secara signifikan mengurangi duplikasi kode yang pada gilirannya mengurangi bug pada modifikasi di masa depan.

Beberapa sumber yang bagus tentang pola desain adalah

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

dan tentu saja buku itu

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Menelusuri aliran kontrol antara metode sangat penting dalam mengembangkan peta mental logika bisnis.

Solusi kami didasarkan pada pengakuan bahwa salah satu dari sedikit informasi yang dapat dipercaya tersedia ketika mendekati sistem lama adalah sistem yang sedang berjalan itu sendiri. Pendekatan kami memverifikasi jejak eksekusi dan menggunakan pemrograman logika untuk mengekspresikan tes pada mereka.

Menghasilkan model data alur kerja adalah cara terbaik untuk menganalisis semua jalur kode:

Dalam praktiknya, tinjauan kode menjadi sulit dalam alur kerja ilmiah sebelumnya. Asal alur kerja seperti itu berarti bahwa praktik rekayasa perangkat lunak mungkin tidak diterapkan selama pengembangan, yang mengarah ke basis kode yang secara efektif dikaburkan. Sementara analisis statis memiliki teknik yang dikembangkan dengan baik untuk analisis aliran data, mereka gagal untuk mendukung perilaku dalam alur kerja dunia nyata. Misalnya, ketika file konfigurasi harus dimuat untuk menentukan bagaimana data harus diproses, atau kapan evaluasi kode dinamis digunakan.

Dan memvisualisasikan alur kerja sangat ideal:

Motif umum, yang cocok untuk pengembangan visual, adalah penyajian alur kerja sebagai grafik. Ini melindungi pengguna dari kompleksitas sumber daya dan eksekusi yang mendasarinya

Referensi

• Memahami Alur Kerja Warisan melalui Analisis Runtime (pdf)
• Sistem Legacy Berorientasi Objek Pengujian Logika Berbasis Jejak (pdf)
• console.trace () - Web API | MDN
• Melacak panggilan metode melalui Proxy
• Cara Memata-matai Metode Ruby Anda
• Pelacakan mudah fungsi panggilan bersarang di Python - situs web Eli Bendersky
• Metode masuk / keluar logging - Mebyon Kernow
• Jejak: Instrumentasi untuk Menunjukkan Panggilan Fungsi
• -Lacak -
• GitHub - johnno1962 / SwiftTrace: Trace Swift dan Objective-C metode invokasi
• Debug :: Trace - Ekstensi Perl untuk melacak panggilan subrutin - metacpan.org

Pastikan Anda menggunakan program yang membantu Anda menemukan hal-hal di file saat ini. Tidak ada yang lebih buruk daripada mengetahui apa yang Anda cari ada di file saat ini, tetapi Anda gulir dan gulir dan tidak dapat menemukannya. Tampilan garis besar di alat yang Anda gunakan untuk mengedit kode sangat membantu dengan masalah itu.