Apakah normal bahwa saya tidak dapat mengingat lebih dari tiga bug yang ditugaskan kepada saya, juga tidak dapat saya mengerti seribu baris kode spaghetti?

Saya sedang mengerjakan basis kode lama yang ... tidak sempurna , di lingkungan yang tidak baik. Ini bukan basis kode terburuk yang pernah saya lihat dalam hidup saya, tetapi masih ada banyak masalah: nol unit test; metode dengan ribuan + baris kode; kesalahpahaman prinsip-prinsip dasar berorientasi objek; dll.

Sakit mempertahankan kode.

1. Setiap kali saya harus men-debug seribu baris metode yang ditulis dengan buruk dengan variabel digunakan kembali di seluruh, saya benar-benar hilang.
2. Beberapa modifikasi atau refactoring yang telah saya lakukan memperkenalkan bug di tempat lain aplikasi.
3. Karena tidak memiliki dokumentasi, tes, atau arsitektur yang dapat diobservasi dan dikombinasikan dengan metode yang tidak disebutkan namanya, saya merasa bahwa saya mengisi semua memori kerja saya yang tersedia. Tidak ada ruang tersisa untuk semua hal lain yang harus saya ingat untuk memahami kode yang harus saya modifikasi.
4. Gangguan terus-menerus di tempat kerja mengganggu saya dan memperlambat saya.
5. Saya tidak dapat mengingat lebih dari dua atau tiga tugas sekaligus tanpa sistem pelacakan kutu, dan saya melupakan semuanya selama akhir pekan.

Kolega saya sepertinya tidak memiliki masalah serupa.

1. Mereka mengelola untuk debug metode yang ditulis dengan buruk jauh lebih cepat daripada saya.
2. Mereka memperkenalkan lebih sedikit bug daripada yang saya lakukan ketika mengubah basis kode.
3. Mereka tampaknya mengingat dengan baik semua yang mereka butuhkan untuk mengubah kode, bahkan ketika itu mengharuskan membaca ribuan baris kode dalam dua puluh file yang berbeda.
4. Mereka tampaknya tidak terganggu oleh email, dering telepon, orang-orang berbicara di sekitar, dan orang lain mengajukan pertanyaan kepada mereka.
5. Mereka tidak ingin menggunakan sistem pelacakan bug yang sudah kita miliki sejak kita menggunakan TFS. Mereka lebih suka mengingat setiap tugas yang harus mereka lakukan.

Mengapa ini terjadi? Apakah ini keterampilan yang diperoleh pengembang saat bekerja dengan kode yang ditulis dengan buruk untuk waktu yang lama? Apakah relatif kurangnya pengalaman saya dengan kode buruk berkontribusi pada masalah / perasaan ini? Apakah saya memiliki masalah dengan memori saya?

Ya, itu normal bagi orang terstruktur untuk dipengaruhi oleh kode / lingkungan yang tidak terstruktur. Rekan Anda mungkin lebih baik menyaring semua kebisingan latar belakang. Sebagai penderita migrain saya tahu kemampuan saya untuk menyaring lingkungan saya sangat menurun ketika migrain datang. Orang berbeda-beda.

Hal yang sama berlaku untuk kode, kolega Anda mungkin telah belajar untuk menyaring "kebisingan kode" yang berasal dari berbagai tingkat abstraksi dalam satu metode dan telah menjadi mahir dalam "memotong" kode ke area fungsionalitas yang lebih besar.

Ini hanya membutuhkan waktu untuk beradaptasi dengan basis kode seperti yang Anda gambarkan. Kolega Anda mungkin memiliki lebih banyak waktu untuk berkembang ke dalamnya dan mungkin telah mengambil konvensi, pola, dan konstruksi yang tidak melompat pada "pemula basis kode". Mungkin ada lebih banyak struktur kekacauan daripada yang bisa Anda bayangkan. Bicaralah dengan kolega Anda, minta mereka untuk berpasangan dengan Anda beberapa waktu dan memilih otak mereka tentang bagaimana mereka mendekati penyelesaian salah satu bug yang ditugaskan untuk Anda. Ketika mereka meminta Anda untuk membuka unit X, Y atau Z, tanyakan kepada mereka mengapa yang itu, bagaimana dengan memberitahu mereka bahwa itu mungkin relevan, dll.

Tersesat dalam metode seribu baris adalah normal. Serang dengan editor lipat yang baik dan tambahkan komentar untuk memotong berbagai bagian menjadi fungsi dan / atau prosedur tanpa benar-benar melakukannya. Mencetak barang-barang dan menggunakan stabilo kuno juga dapat membantu.

Refactoring tanpa jaring pengaman dari unit test menembak diri Anda sendiri. Jangan. Hanya saja, jangan.

Tidak ada yang mengharuskan Anda untuk menyimpan semuanya dalam ingatan. Jika kolega Anda tidak menginginkan atau membutuhkan sistem bug, cukup tulis tugas yang diberikan kepada Anda di daftar todo Anda sendiri dan tulis catatan ketika / setelah berbicara dengan seseorang tentang perincian tugas Anda.

ada 3 poin utama yang saya lihat:

poin 1, 2 dan 3 berasal dari fakta bahwa kolega Anda lebih berpengalaman dengan basis kode yang berarti mereka tahu keanehannya. Ini berarti bahwa mereka menggunakan memori jangka panjang untuk proses debug dan dapat mengingat bahwa doXYZ benar-benar melakukan UVW tetapi tidak pernah diganti namanya karena alasan historis. Namun jika mereka pernah mengambil beberapa bulan dari pengkodean di atasnya maka mereka akan mulai merasakan sakit Anda.

untuk poin 4 tahan gangguan, jangan biarkan bisnis yang tidak mendesak membawa Anda keluar dari zona , butuh waktu lama untuk kembali ke dalamnya setelah gangguan; atur IM perusahaan menjadi sibuk, coba jadwalkan dalam blok-blok panjang (sore penuh) hanya dengan coding

untuk poin 5 detik buat lembar excel dengan bug yang sedang Anda kerjakan sebagai daftar todo pribadi Anda, (atau gunakan kemampuan manajemen tugas dalam IDE Anda), saya berani bertaruh bahwa beberapa rekan Anda melakukan hal yang sama

Tidak terdengar seperti masalah memori bagi saya. Sepertinya Anda kebiasaan / kecenderungan kerja Anda tidak cocok untuk apa yang Anda temui, dan Anda terlalu memikirkan rekan kerja Anda dan bukan diri Anda sendiri.

1. Metode garis seribu - semua orang akan kehilangan itu kecuali mereka hanya bekerja di atasnya. Mereka mungkin lebih cepat dalam mengambilnya atau mendapatkannya kembali. Anda tidak dapat mengubahnya kecuali melalui pengalaman, dan mungkin bahkan tidak.

2. Refactoring memperkenalkan bug, yah, itu selalu berisiko. Anda dapat mencoba mengembangkan unit test untuk mencakup apa yang Anda ubah sebelum melakukannya, tetapi itu mungkin tidak diizinkan oleh manajemen (mungkin tidak, atau itu sudah dilakukan). Dan unit test bukan sihir. Mereka masih bisa melewatkan banyak hal, Anda masih bisa memperkenalkan bug. Kemungkinannya adalah mereka tidak refactoring. Ini kembali ke (1), mereka mungkin mencoba untuk fokus pada apa yang perlu diperbaiki, yang berarti mereka sampai ke titik lebih cepat, tetapi kehilangan gambaran yang lebih besar, dan akan memakan waktu lebih lama untuk memperbaiki hal berikutnya dalam kekacauan ribuan baris.

3. Buat apa yang Anda butuhkan untuk menyelesaikan pekerjaan. Jika itu berarti membuat diagram alur atau dokumentasi lain, maka lakukanlah. Apakah mereka membutuhkannya atau tidak, dan apakah mereka menggunakannya atau tidak setelah Anda membuatnya, tidak relevan.

4. Gangguan memperlambat semua orang. Berfokus pada hal itu hanya akan memperlambat Anda. Terima dan coba kembali ke alur secepat mungkin.

5. Mempertahankan dua atau tiga bug dalam pikiran tidak buruk, tiga atau empat akan lebih baik, tetapi alih-alih mencoba untuk memperbaiki itu, menyerah dan tuliskan. Selembar kertas, papan tulis, tfs, excel, word atau notepad - tulis saja. Saya yakin itulah yang dilakukan rekan Anda. Entah itu atau memperbaiki hal-hal secara acak.

Pemrograman bukan tentang memori yang sempurna, dan ini bukan tentang bisa mengabaikan gangguan - berfokus pada ini hanya gangguan yang Anda buat.

CAVEAT / PEMBARUAN: Setelah membaca jawaban di bawah ini, saya merasa itu mungkin terasa agak terlalu keras. Bukan maksud saya, lingkungan yang Anda gambarkan mengerikan dan itu akan mempengaruhi kebanyakan orang (mungkin bahkan programmer yang lebih baik menderita, tetapi mereka "lebih baik" dengan membandingkannya dengan orang lain di lingkungan yang sama). Jawaban saya hanyalah refleksi poin demi poin dalam pertanyaan Anda, dengan asumsi bahwa lingkungan tidak akan berubah (walaupun seharusnya).

Jawaban yang benar-benar dapat ditentang:

1) Itu tergantung dari pengalaman dalam teknologi, dalam mempertahankan aplikasi (lebih jika itu dirancang buruk) dan bahkan di bagian tertentu dari aplikasi. Juga tergantung pada masalah konsentrasi Anda (nomor 4)

2) Ini sama dengan angka 1, tetapi menggunakan metrik yang berbeda. Jawaban yang sama

3) noteblock dan pena. Atau dokumen word / excel. Tidak terlalu sulit untuk dipecahkan.

4) itu adalah masalah konsentrasi pribadi. Namun, tidak yakin apakah bisa meningkatkannya sendiri.

5) menggunakan sistem tiket atau tidak tidak harus diputuskan oleh pemrogram tetapi oleh manajer proyek. Tanyakan pendapatnya / presentasikan poin Anda. Jika dia menentangnya, jangan membuka kunci dan menulis lagi.

Saya telah melalui situasi seperti itu sebelumnya dan berdasarkan pengalaman itu saya dapat mengatakan bahwa masalah Anda tidak terkait dengan memori dan bahwa ada sesuatu di pikiran Anda (yang pasti tidak terkait dengan pekerjaan) yang membuat Anda stres dan membuat Anda tidak fokus 100 % pada tugas yang dihadapi.

Jadi langkah pertama adalah menjernihkan pikiran Anda dari hal-hal itu ketika Anda berada di meja Anda.

Stres itu mungkin juga meningkat karena Anda merasa ketinggalan dalam hal produktivitas, jadi cobalah berbicara dengan rekan kerja Anda dan minta mereka memberi tip tentang pendekatan mereka pada refactoring.

Akhirnya jangan merasa malu jika Anda harus menuliskan masalah yang telah Anda pecahkan dan / atau sedang bekerja saat ini (tidak harus menjadi sistem pelacakan bug canggih) lebih baik untuk memastikan sesuatu karena Anda membacanya dari catatan Anda daripada menyatakannya di atas kepala Anda sementara tidak 100% yakin akan hal itu