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


23

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?


6
programmers.stackexchange.com/questions/59050/... Mungkin memperhatikan betapa buruknya melakukan "penulisan ulang besar" biasanya berakhir dari perspektif bisnis. Itulah yang akan dilakukan oleh programmer yang lebih "senior".
quentin-starin

22
@ Ya, satu-satunya hal yang lebih buruk daripada melakukan "penulisan ulang besar" adalah ketakutan melumpuhkan "penulisan ulang besar." Ketika saya memulai posisi saya saat ini, saya mewarisi kekacauan CGI Perl dari dua atau tiga programmer yang berbeda tanpa kontrol sumber, pelacakan bug, atau tes. Butuh beberapa meyakinkan, tapi saya mendapat persetujuan untuk menulis ulang di Ruby on Rails sambil mempertahankan kode warisan. 5 bulan kemudian, alatnya lebih ramah pengguna, dan kami bisa menambahkan fitur baru dalam hitungan hari atau minggu, bukan bulan. Para pengguna sangat gembira, dan saya tidak kehilangan akal. "Penulisan ulang besar" membutuhkan pembenaran yang kuat, bukan penghindaran total.
Jason Lewis

1
@JasonLewis: (Saya kira Anda tidak mengikuti tautan dalam komentar saya sebelumnya?) Tampaknya tidak masuk akal bagi seseorang yang kurang dari setahun yang lalu menyebut dirinya kurang keterampilan penting yang dimiliki oleh tingkat senior dan tidak memilikinya tidak tahu harus mulai dari mana saat memulai proyek baru.
quentin-starin

5
@JasonLewis, saya sepenuhnya setuju dengan Anda. Setiap kali seseorang bertanya tentang menulis ulang aplikasi di SE, banyak orang datang dengan ideologi "jangan lakukan penulisan ulang besar" ini. Saya pikir pasti ada banyak alasan untuk tidak melakukannya tetapi Anda tidak boleh menghindarinya dengan cara apa pun. Saya telah berpartisipasi dalam penulisan ulang 100k baris aplikasi kode dan kami memiliki banyak keberhasilan, sangat mirip dengan apa yang telah Anda jelaskan. Kami bahkan dapat menulis ulang modul demi modul (bagian pertama dari UI, kemudian server, lalu sisanya). 12 bulan kemudian kami memiliki basis pelanggan yang sangat sangat bahagia dan semua orang bangga dengan keputusan yang kami ambil.
Alex

2
Ini adalah bagian dari masalah yang lebih umum: masalah yang dialami pendahulu Anda untuk hasil langsung dengan biaya jangka panjang. Ketika mengambil alih, Anda harus menjelaskan mengapa Anda tidak dapat mempertahankan hasil yang sama.
David Thornley

Jawaban:


23

'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.


7
Tidak ada dokumen dan kode ini hampir tidak dapat diuji kecuali kita akan menolaknya. Saya cukup yakin saya didukung oleh banyak kolega sehingga mendapatkan pengembang lain dalam diskusi mungkin membantu.
ChrisR

@ChrisRamakers Itu berita bagus (dukungan, bukan kurangnya dokumen!). Lebih sulit (walaupun bukan tidak mungkin) bagi para manajer untuk menolak / menolak pendapat profesional dari banyak pengembang. Dan jika pendukung Anda telah berada di perusahaan lebih lama, mereka mungkin memiliki pengalaman berharga menavigasi politik internal organisasi. Semoga berhasil!
Jason Lewis

Selain itu, jika Anda bisa mendapatkan beberapa perangkat lunak pengujian beban, Anda dapat menunjukkan bagaimana itu bisa pecah di bawah beban tinggi.
HLGEM

13

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.


5

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.


ya, saya sudah berpikir tentang menghitung kompleksitas siklomatik rata-rata dan menggunakannya sebagai argumen, tetapi saya yakin ini tidak akan membuktikan apa-apa bagi manajemen. Tapi ini patut dicoba, thnx
ChrisR

5
@ChrisRamakers: Tidak ada yang bisa "terbukti" bagi seorang manajer. Lupakan "bukti". Kumpulkan data. Semua fakta yang Anda miliki. Lebih banyak fakta lebih meyakinkan. Tetapi tidak ada "bukti".
S.Lott

4

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.


1
Setelah melakukan perubahan, perlihatkan file diff, yang dalam basis kode yang buruk akan menyentuh banyak file sumber yang berbeda, memiliki "apa hubungannya dengan itu?" elemen, dll. Jelaskan kepada manajemen berapa banyak dari pekerjaan ini, yaitu waktu == $$, terkait dengan basis kode yang buruk dan bahwa perubahan ke depan semua akan memiliki karakteristik ini.
Larry OBrien

3

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?).


2

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.


1

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.


8
Satu-satunya masalah adalah bahwa jika dia memiliki tanggung jawab utama untuk sistem, dia akan disalahkan ketika tidak lagi berfungsi. "Tapi itu berhasil sebelum kamu mulai!", Kata mereka. Itulah sebabnya saya menyarankan pendekatan proaktif. Memperingatkan mereka di muka, mendokumentasikan masalah, dan kemudian pantatnya ditutupi jika rusak, dan tidak hanya bisa dia mengatakan 'saya bilang begitu ke bosnya, tapi dia bisa mengatakan 'Saya katakan kepadanya sehingga' bos bosnya.
Jason Lewis

3
@Jason - Saya mengerti maksud Anda, tetapi dalam pengalaman saya, penolakan beroperasi ke bawah dan 'memberitahunya' naik rantai akan bertemu dengan sangat cepat dengan 'pemain non tim' dalam perjalanan turun.
Jonno

2
Ini sangat tergantung pada tempat kerja masing-masing, tetapi saya setuju dengan Anda ... Saya bisa mengatakannya dengan lebih baik ... Poin utama saya adalah mendokumentasikan alasan-alasan itu akan gagal di muka, berargumen, dan menjaga agar dokumentasi tersedia untuk ketika itu terjadi ... skenario kasus terbaik, Anda diizinkan untuk memperbaikinya. Rata-rata, Anda tidak kacau ketika gagal. Yang terburuk, Anda sangat memahami sistem dan kelemahannya dan bagaimana cara memperbaikinya dengan cukup mengesankan untuk menjelaskan (secara terperinci jelas) bagaimana dan mengapa Anda meninggalkan posisi terakhir Anda ke calon majikan ketika Anda akhirnya mencari pekerjaan setelah gagal ;-)
Jason Lewis

1
@JasonLewis Jika pemain di perusahaan menggunakan frasa seperti itu I told you somaka itu adalah budaya menyalahkan yang beracun dan bukan tempat OP ingin bekerja lama. Manajer yang baik tidak menyalahkan, manajer yang baik mengakui masalah dan membuat rencana.
maple_shaft

@maple_shaft Saya setuju. Saya tidak bermaksud mengucapkan kata-kata itu secara harfiah, saya lebih mengacu pada mencakup semua basis. Idealnya, kita semua akan memiliki manajer yang baik dan suportif, sepanjang rantai komando. Namun, sering kali, kami memasang lumayan untuk menengahi sehingga kami dapat menggunakan pekerjaan yang kami miliki sebagai batu loncatan untuk pekerjaan yang kami inginkan.
Jason Lewis

1

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.


1

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.


0

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.

Jenis sikap ini membuat pemrogram untuk memaafkan hutang teknis yang sangat besar karena ketidaktahuan atau kemalasan. Tugas seorang programmer adalah untuk menyandikan logika bisnis melalui penggunaan abstraksi. Spesifik yang tidak dapat diubah harus hidup dalam metadata, bukan angka ajaib yang dikodekan. Kedua, 'agak ketinggalan jaman' bisa bersifat subjektif. IMHO, 'sedikit ketinggalan jaman' berarti kerangka / platform masih aktif dikembangkan, dan saya memiliki jalur peningkatan. Alternatifnya adalah 'usang.' Nomor 3 tidak bisa dimaafkan. Anda baru saja menjelaskan cruft. Belum ada yang refactored atau membersihkan basis kode, dan ini dapat diterima?
Jason Lewis

tentu, tapi apa hasilnya setelah Anda menyandikan logika bisnis melalui penggunaan abstraksi ... Kode ini akan terlihat rumit. Itulah definisi "kekacauan". (3) tidak kasar, karena kompleksitas masih diperlukan; kebutuhan untuk memilikinya tidak hilang bahkan setelah masalah terpecahkan.
tp1
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.