Bagaimana cara membuktikan suatu aplikasi dibangun di atas basis kode yang buruk?

Saat ini saya sedang meninjau sistem yang dibangun oleh beberapa pengembang yang sebelumnya bekerja di pekerjaan saya. Sistem ini bekerja dengan sangat baik dari sudut pandang pengguna, tetapi ketika mempelajari ulasan kode itu sangat berantakan. Saya lebih dari yakin bahwa cara aplikasi dibangun tidak akan tahan untuk pembaruan di masa depan, apalagi peningkatan penggunaan yang tinggi.

Masalahnya adalah saya tahu betapa buruknya itu, tetapi atasan saya tidak. Bagaimana saya bisa membuktikannya kepada manajer saya sehingga dia benar-benar melihat masalah dan dapat diyakinkan untuk melakukan triase minimal pada basis kode saat ini, dan dalam waktu dekat memulai garis pengembangan baru untuk versi aplikasi yang berikutnya?

'Tapi itu berfungsi sekarang' adalah respons manajemen standar terhadap frustrasi sah para insinyur perangkat lunak. Hal pertama yang saya lakukan adalah mengkompilasi dokumentasi (jika ada) dan menggunakannya untuk menunjukkan kontradiksi antara kode dan dokumentasi.

Jika Anda bisa, kumpulkan serangkaian unit test yang komprehensif. Jalankan ini dengan setiap perubahan sehingga Anda dapat mendokumentasikan regresi yang dapat disalahkan pada basis kode yang ada.

Terakhir, jika Anda dapat menarik pengembang dari departemen lain yang pekerjaannya Anda percayai, dapatkan kode mata kedua. Salah satu pengembang mengatakan 'ini omong kosong' lebih mudah untuk diberhentikan, daripada ketika seorang pengembang senior yang sudah lama memastikan dia dan berkata, 'Tidak, Jim, dia benar. Ini omong kosong di cracker omong kosong. '

Tentu saja, itu semua tergantung pada lingkungan Anda, ukuran perusahaan, dll.

Saya selalu merekomendasikan untuk melihat The Pragmatic Programmer Jika Anda belum membacanya. Tidak hanya itu harus dibaca untuk setiap profesional perangkat lunak, tetapi memiliki beberapa saran bagus untuk berurusan dengan manajemen, rekan kerja, pengguna, dll. Yang tidak melihat rekayasa perangkat lunak sebagai kerajinan.

Dari perspektif manajemen, tidak ada yang salah dengan sistem dan Anda hanya mengeluh karena [Anda hanya ingin menulis ulang / Anda tidak mengerti apa yang dilakukan insinyur sebelumnya / Anda ingin pekerjaan Anda mudah]. Sedikit orang bodoh, tetapi ketika seseorang di atas melihat bahwa semuanya bekerja dengan baik sekarang, mereka segan melihat krisis di mana Anda melakukannya (saya yakin ada alegori perubahan iklim di sana di suatu tempat ...) .

Sampai batas tertentu, mereka ada benarnya. Manajemen melihat masalah ketika rilis melampaui perkiraan semula, perkiraan tampaknya terlalu tinggi untuk pekerjaan yang dilakukan, "ini tidak mungkin dilakukan dengan basis kode yang ada", dan kemunculan bug yang tinggi melewati QA. Jika segala sesuatunya berjalan lancar, mudah untuk menepuk kepala Anda dan memberi tahu Anda untuk melakukan yang terbaik, karena itu tidak mempengaruhi garis bawah.

Apa yang harus dilakukan tergantung pada organisasi Anda dan perangkat lunak itu sendiri. Namun, pada dasarnya, saya sarankan untuk mendokumentasikan setiap komplikasi yang muncul sebagai akibat dari kode warisan yang buruk. Saat memperkirakan tugas, jelaskan kepada manajemen mengapa menurut Anda akan memakan waktu begitu lama, dengan penjelasan terperinci tentang aspek apa dari basis kode lama yang menambahkan biaya tambahan ini. Ketika bug dimasukkan ke dalam kode, sertakan alasan mengapa bug ini bisa masuk, dan bagaimana masalah dalam basis kode lama bertanggung jawab.

Saya menyarankan untuk menyampaikan kekhawatiran Anda kepada para pemangku kepentingan dengan cara yang menunjukkan bahwa perangkat lunak telah melampaui desain aslinya dan sekarang bermasalah untuk terus meningkatkan.

Ada berbagai alat yang tersedia yang dapat melakukan cakupan kode dan tinjauan kode. Alat Google cocok untuk teknologi Anda, ini biasanya alat standar industri. Saya sarankan Anda menggunakan alat-alat ini dan menghasilkan laporan berkualitas kode dan menyampaikannya kepada Manajer. Pastikan kritik Anda kontruktif dan non-politis.

Pilih contoh yang mudah dimengerti di mana manajemen akan menganggapnya sebagai permintaan perubahan yang sederhana, tetapi karena desain yang ada, itu jauh lebih sulit.

Anda tidak ingin mereka memikirkan permintaan khusus, tetapi pastikan Anda memberi tahu mereka bahwa ini adalah APAPUN yang akan menjadi seperti perubahan. Tidak ada yang ingin dilukis di sudut dengan aplikasi. Pengembang percaya pada YAGNI, tetapi manajemen percaya pada CYA.

Saran untuk pengujian beban bisa menjadi pendekatan yang baik, tetapi mereka mungkin tidak yakin bahwa kekhawatiran penggunaan meningkat memenuhi potensi pertumbuhan dunia nyata (Perusahaan tidak akan berlipat ganda dalam satu tahun.).

Semuanya relatif. Mereka mungkin tidak ingin memasukkan sumber daya ke dalam proyek ini ketika mereka memiliki rencana untuk proyek yang lebih penting untuk menghabiskan waktu Anda. Jangan diberi label karena tidak melihat gambaran besarnya.

Ketika Anda berbicara tentang membuktikan sesuatu, semua hal metode ilmiah ikut bermain, dan bagian dari apa artinya adalah bahwa jika Anda akan menerima standar objektif untuk memutuskan apa yang benar, Anda harus menerima kemungkinan bahwa, setelah diselidiki, fakta-fakta menjengkelkan itu ternyata tidak berada di pihak Anda.

Dalam kasus Anda, saya pikir ada 2 hal yang harus dibuktikan.

Pertama, bahwa basis kode saat ini adalah "buruk". Apa yang mungkin Anda buktikan adalah bahwa "pendapat profesional dari hampir semua pengembang yang memeriksa kode ini adalah bahwa itu buruk".

Kedua, bahwa perusahaan akan lebih baik menulis ulang basis kode. Ini masalah karena meskipun poin pertama benar, yang kedua mungkin tidak. Juga, Anda tidak cukup tahu untuk membuat keputusan ini. Ini adalah tugas manajemen, dan jika Anda ingin mereka menghormati penilaian profesional Anda tentang poin pertama, Anda harus menghargai penilaian mereka tentang poin kedua.

Tetapi mereka tidak dapat menentukan poin kedua tanpa informasi yang Anda berikan. Anda perlu mengkomunikasikan apa yang Anda ketahui tentang bagaimana masalah dalam kode akan berdampak pada bisnis, dan apa yang Anda ketahui tentang bagaimana penulisan ulang akan berdampak pada bisnis. Ini sulit, karena keduanya melibatkan memprediksi masa depan yang memiliki banyak ketidakpastian.

Tetapi Anda dapat mencoba menyatakan masalahnya dalam istilah bisnis. Berapa banyak waktu ekstra yang dihabiskan untuk perubahan dan regresi? Berapa biaya penulisan ulang? Seberapa cepat biaya sistem saat ini akan naik dari waktu ke waktu jika tidak ditulis ulang? Bagaimana jika ada peningkatan penggunaan, apa peluang bencana jika kode saat ini disimpan? Anda tidak dapat benar-benar mengetahui semua ini, tetapi Anda dapat memberikan tebakan yang lebih baik daripada orang lain. Berikan rentang, atau sesuatu untuk mengomunikasikan seberapa akurat Anda pikir Anda dapat memprediksi hal-hal ini.

Sebagian besar pengembang tidak suka mempertahankan kode yang buruk. Itulah sebabnya sangat disayangkan bahwa kode yang tidak perlu menulis ulang dari perspektif pengembang mungkin tidak layak untuk ditulis ulang dari perspektif bisnis.

Sebagai contoh, bahkan jika penulisan ulang berakhir menguntungkan, itu mungkin bernilai kurang dari biaya peluang menghabiskan uang di tempat lain di perusahaan. Atau basis kode yang buruk mungkin membutuhkan waktu lebih lama untuk berubah dan memiliki lebih banyak regresi, tetapi tidak cukup untuk membuat penulisan ulang menguntungkan. Mereka mungkin mencari untuk dibeli dalam beberapa bulan ke depan, dan menghabiskan uang untuk menulis ulang akan muncul di buku tetapi perangkat lunak kereta tidak.

Cobalah untuk memikirkannya dari perspektif bisnis, dan jangan memasak angkanya untuk mendapatkan yang Anda inginkan. Penulisan ulang yang besar hampir tidak pernah tidak penting dari sudut pandang bisnis. Jika Anda ingin membuktikan sesuatu yang tidak dapat dibuktikan secara langsung, cobalah yang terbaik untuk membantahnya. Jika Anda terus mencoba yang terbaik untuk datang dengan cara tidak untuk menulis ulang dari awal tapi tidak ada yang Anda datang dengan rasa merek, mungkin maka itu benar-benar waktu untuk menulis ulang dari awal. Dan melakukan upaya itu akan menunjukkan kepada manajemen Anda bahwa Anda serius dalam mewakili kepentingan perusahaan, bukan kepentingan Anda (Anda mewakili kepentingan perusahaan, bukan kepentingan Anda, bukan?).

Saya kira itu tergantung apa yang buruk tentang basis kode. Menjadi "Bukan cara saya melakukan sesuatu" tidak berarti itu adalah basis kode yang buruk.

Hal-hal yang membuat basis kode buruk:

• Lubang keamanan

  Masalah yang membuat Server, aplikasi, dan / atau data rentan. Terutama apa pun yang membuat data sensitif perusahaan, klien, atau pelanggan berisiko. Ini harus mudah didokumentasikan.

• Bekerja Rusak

  Ini hanya berfungsi karena Anda memijat data dan melakukan pemeliharaan pada aplikasi hampir terus menerus agar tetap berfungsi. Jika Anda pergi dan tidak ada yang mengambil kelonggaran itu tidak akan berfungsi lagi. - Dokumentasikan berapa banyak waktu yang Anda habiskan untuk melakukan ini. Dan perhatikan berapa banyak yang bisa Anda hemat. Cukup sering proses ini tidak efisien bagi pengguna juga dan Anda mungkin dapat mendokumentasikannya juga.

• Sebenarnya tidak berfungsi

  Tampaknya berfungsi tetapi hasilnya salah. Ini biasanya menyebabkan masalah di telepon, seperti angka yang tidak cocok, angka cacat tinggi, dll.

Apa yang bukan basis kode buruk (tidak baik):

• Ditulis pada teknologi yang tidak didukung usang. (VB6, COBOL, .net1.1 Dll)

Perhatikan keuntungan bermigrasi ke teknologi baru. Cobalah untuk menemukan jalur migrasi yang memindahkan potongan sekaligus sehingga Anda dapat meminimalkan risiko dan membangun kepercayaan pengguna dan manajemen. Pastikan bahwa logika bekerja pada dasarnya sama dengan aslinya.

• Kode tidak berformat / buruk diformat

Ini adalah cara termudah untuk Anda perbaiki karena umumnya Anda dapat menambahkan komentar dan memperbaiki format tanpa benar-benar memengaruhi kode. Tapi itu tidak membutuhkan penulisan ulang. Jika Anda merasa ini dikombinasikan dengan masalah lain, hal pertama yang harus dilakukan adalah memperbaikinya sehingga Anda dapat menilai dengan lebih baik kelayakan kode.

Anda telah menjawab pertanyaan Anda sendiri dengan suatu cara.

Cara meyakinkan mereka untuk menghabiskan uang pada sistem adalah menunggu sampai tidak berfungsi dengan baik bagi pengguna. Jika Anda pikir itu tidak akan skala, baik menunggu itu terjadi atau lakukan tes beban untuk membuktikannya.

Maka usulan sederhana untuk membersihkan ini untuk skala akan memakan waktu X jam.

Ini adalah situasi sulit yang harus dihadapi karena dari sudut pandang pengguna semuanya berada pada titik yang dapat diterima dan stabil sekarang. Terutama dengan manajer non-teknis, tidak ada yang perlu dikhawatirkan saat ini, tetapi meminta untuk menulis ulang basis kode adalah keputusan yang sangat besar dan tidak boleh dianggap enteng, terutama pada pendapat dan upaya seorang pria lajang (sendiri) .

Jadi Anda berada dalam kesulitan untuk membuat kasus untuk penulisan ulang karena hutang teknis yang besar (menurut Anda, kami tidak memiliki contoh dan harus mengambil kata-kata Anda untuk itu) serta berada di tempat yang sulit mengalami kesulitan mempertahankan dan menambahkan fitur ke dalam sistem ini.

Perkiraan Anda untuk fitur baru akan tinggi, menjustifikasi angka tinggi ini dengan fakta, membuktikan bahwa hal-hal ini memang akan memakan banyak waktu. Jika Anda tidak menyampaikan ini dengan benar maka manajer Anda mungkin menganggap Anda tidak kompeten dan Anda tentu tidak menginginkannya. Ketika ia mempertanyakan estimasi tinggi, maka jelaskan mengapa Anda merasa akumulasi utang teknis menghalangi kemampuan untuk dengan cepat dan murah menambahkan fitur ke perangkat lunak saat ini. Jika manajer Anda memiliki dua sel otak untuk disatukan, ia akan mulai memahami dengan sangat cepat.

Intinya adalah bahwa Anda tidak harus mencoba meyakinkan manajer Anda, tetapi mengarahkan manajer Anda dengan informasi yang sesuai (dan dipilih dengan cermat) sehingga ia dapat meyakinkan diri mereka sendiri bahwa menulis ulang adalah kursus yang dapat diterima. Anda harus membuat manajer berpikir itu adalah idenya selama ini.

Pertama-tama tentukan akumulasi utang teknis dalam basis kode Anda. Kemudian perhatikan pertanyaan dan jawaban ini , di mana dijelaskan bagaimana meyakinkan manajemen untuk melunasi hutang teknis sebelum melangkah lebih jauh.

Ada alasan mengapa semua perangkat lunak dewasa terlihat seperti berantakan:

1. Semua kekacauan itu menyandikan logika kritis yang menjadi sandaran bisnis. Tanpanya tidak ada yang berhasil. Setiap bit itu diperlukan untuk memecahkan masalah pengguna.
2. Ini menggunakan teknologi yang sedikit usang. Pemrogram saat ini tampaknya berpikir bahwa jika tidak menggunakan beberapa templat ajaib, itu hanya berantakan. Ini adalah pandangan yang rusak. Siapa pun yang datang terlambat ke proyek yang lebih besar akan memiliki tahap ini sambil mempelajari semua detail.
3. Persyaratan yang kritis beberapa waktu lalu tidak lagi begitu kritis. Ini karena perangkat lunak sudah menyelesaikan masalah tersebut. Datang terlambat ke proyek, mungkin tampak seperti perangkat lunak yang kompleks tanpa alasan yang bagus - masalahnya tidak ada lagi, tetapi kompleksitas dalam kode masih ada.