Sindrom Plumbing: Aturan Kode Warisan untuk Pengujian

Banyak yang menemukan pendatang baru yang datang ke proyek dan menyatakan bahwa "semuanya perlu segera diperbaiki." Dan beberapa orang sendiri mengatakan atau berpikir. Ini adalah "sindrom saluran air": perilaku yang ditandai oleh keinginan untuk melakukan segala sesuatu dengan caranya sendiri, "dengan benar", ketika bekerja pada proyek baru atau ketika beralih ke pekerjaan baru. Jadi, kode, teknologi atau alat yang ada perlu ditulis ulang, lebih disukai "untuk diri mereka sendiri." Topik ini akan menjadi hal biasa jika tidak diulangi begitu sering dari proyek ke proyek, dengan setiap perekrutan baru.

Semakin lama sebuah proyek “hidup”, semakin banyak ia mengakumulasikan sebuah kode “historis”, yang diwariskan, dan semakin tinggi peluang untuk bertemu dengan mata seorang tukang ledeng yang terkena dampak “sindrom”. Dalam pos ini, saya ingin memberi tahu Anda prinsip apa yang dipatuhi Parallels (segera, spoiler adalah prinsip "jangan lakukan apa-apa"), dan apa yang kami lakukan jika kami memutuskan untuk "mengulang semuanya". Meskipun secara umum kami percaya bahwa sindrom ini harus diobati, dan bahwa penggunaan warisan kadang-kadang bahkan berguna, karena memungkinkan Anda untuk melepaskan produk tepat waktu dan tidak membuang waktu untuk mengembangkan teknologi Anda.

Ketika Anda bekerja dengan "program jangka panjang", persentase yang cukup besar di dalamnya adalah kode lawas. Sebagai contoh, Parallels Desktop telah dikembangkan selama lebih dari 15 tahun. Setiap tahun tim berkembang, orang-orang baru datang, lihat apa yang tertulis dan nyatakan: "Semuanya bengkok, mari sobek tangan programmer dan tulis ulang semuanya." Situasi yang biasa?

Sebelum mulai mengatakan apakah kode warisan itu baik atau buruk, saya ingin memutuskan konsep siapa yang mengerti ini dan apa. Dua definisi biasanya digunakan: yang pertama adalah kode yang tidak dicakup oleh tes. Dari sudut pandang pengujian otomatis, semua kode tidak tercakup oleh pengujian. Kode warisan kedua adalah kode yang Anda warisi. Ketika Anda perlu memahami cara kerjanya, tetapi tidak ada yang bertanya. Dan Anda harus repot dengan itu sendiri.

Kebijaksanaan yang Diberdayakan

I. Yang terbaik adalah musuh dari yang baik. Jika kode atau sistem lawas melakukan semua fungsi yang diperlukan dengan kualitas yang dapat diterima, maka Anda tidak perlu memperbaikinya, lebih baik mengarahkan energi didih Anda ke sesuatu yang lebih berguna.

II Dari yang penting dan yang baru, pilih yang penting, dari yang sama pilih yang baru. Jika kode lama berisi fungsionalitas penting dan tidak dicakup oleh tes, Anda harus memberikan perhatian maksimal padanya, baik dalam hal memproses kode dan dalam hal menutupinya dengan tes. Jika kode lama dan fitur baru sama pentingnya, maka Anda harus fokus pada fitur baru (pengembangan dan pengujian).

III. Jika yang lama tidak setuju dengan peningkatan, buat yang baru di dekatnya, lalu buang yang lama. Jika kode lama diperlukan tetapi tidak mungkin diubah, gunakan kode lama hingga Anda menulis dan men-debug yang baru. Ketika kode baru berfungsi, kode lama dapat dibuang.

Apa yang harus dilakukan

Langkah 1. Kami melihat siapa yang berkata
1. Freelancer . Paling sering, orang-orang yang tidak memiliki pengalaman bergabung dengan proyek besar dari samping melempar kode sepenuhnya. Sebagai contoh, saya sendiri pertama kali bekerja pada freelance, menulis proyek dari awal, dan, seperti banyak pengembang serupa, saya telah mengembangkan kebiasaan yang cukup stabil - untuk melakukan persis seperti yang saya rasa nyaman.

2. Tidak berpengalaman . Kadang-kadang pernyataan seperti itu menunjukkan kurangnya kualifikasi orang itu sendiri di bidang subjek: ia tidak tahu sejarah proyek, dan, misalnya, bahwa konstruksi "menakutkan" (menurut pendapatnya) ini dihasilkan dari fakta bahwa selama proses pengembangan orang menemukan bug eksternal sistem dan mulai menyiasati mereka. Akibatnya, ada semacam spaghetti dari tambalan dan kruk yang saling berhubungan untuk bug ini. Pengetahuan tentang semua perangkap yang ada pada manusia dari luar tidak bisa pada prinsipnya.

3. D'Artagnan . Paling sering, ini terjadi dengan insinyur yang tidak memiliki pengalaman produk dan pengalaman dalam proyek-proyek besar yang tidak mengerti berapa harga yang mereka dapatkan. Seorang pria memukul dadanya dengan tumitnya, dan mengatakan bahwa dia akan melakukannya dengan cemerlang, segar, dan hanya dalam waktu seminggu, tetapi dia bisa sangat keliru tentang kemampuannya, dan karena dia benar-benar kehilangan poin seperti pengujian dan integrasi ke dalam sistem yang lebih besar yang ada.

4. Spesialis berkualifikasi tinggi. Satu-satunya jenis "pelamar" yang harus Anda dengarkan, meskipun bergegas untuk mengulangi sarannya, masih tidak layak sampai Langkah 2. Selesai, kami memiliki profesional ultra-kelas dan dia benar-benar dapat membuktikan bahwa kami tidak begitu, dan bisa berbuat lebih baik. Tetapi kenyataannya adalah bahwa saya belum pernah bertemu orang tingkat senior tunggal dengan pernyataan seperti itu. Ketika seseorang tumbuh ke tingkat seperti itu, dia sudah bisa membayangkan proyek secara keseluruhan dan memahami semua kekurangan dari metode "revolusioner".

Langkah 2. Membuat argumen
Hal pertama yang perlu dilakukan seseorang untuk berhenti dan menganalisis argumennya. Uji coba ini harus dimulai oleh ketua tim. Dengan peringatan bahwa "sindrom saluran air" tidak mulai menderita seseorang yang dirinya sendiri memimpin tim. Maka analisis penerbangan adalah pekerjaan manajer proyek, meskipun, sejujurnya, pemimpin tim yang matang tidak pernah memulai perubahan penuh tanpa argumentasi yang serius.

Argumen apa yang akan gagal:
"Kami akan menulis sendiri, dengan catur dan penyair"
Paling sering, jika suatu produk telah lama beredar di pasaran, maka entah bagaimana itu sudah berhasil. Dia telah menunjukkan bahwa, terlepas dari sifat mengerikan dari apa yang ada di bawah tenda, itu berfungsi. Sebagai contoh, kami memiliki Parallels Desktop (solusi untuk menjalankan Windows dan sistem operasi lain pada Mac tanpa me-reboot), dan kadang-kadang Anda dapat mendengar dari pemula: "entah bagaimana Anda semua terlalu rumit di sini, mari kita tulis mesin virtual saya." Dan karena hal-hal seperti itu, pada prinsipnya, tidak dapat dilakukan dengan segera, ketika seseorang mengatakan ini, dia entah di luar topik atau tidak atas kemauannya sendiri. Penting untuk memberinya pengalaman pertama dalam proyek dan memahami mengapa hal itu diimplementasikan sejak awal.

"Itu jelek."
Masalahnya adalah bahwa seringkali seseorang tidak memiliki argumen lain. "Tidak maju secara teknologi," "dilakukan pada beberapa sampah," "mengapa itu ditulis dalam C, sekarang modis untuk menulis di Go." Ini bukan argumen untuk membuat ulang sistem. Karena ketika Anda melampaui satu bagian kode Anda, Anda mulai menyadari bahwa pengerjaan ulang Anda mungkin lebih buruk daripada sebelumnya. Mungkin terlihat lebih cantik di dalam, dan bekerja lebih lambat, yang tidak dapat diterima untuk produk. Saya tidak melihat ini di Parallels, tetapi di perusahaan sebelumnya kami harus sepenuhnya mengalami semua konsekuensi dari langkah ini. Kami memutuskan bahwa serangkaian driver untuk peralatan tertentu diimplementasikan dengan buruk, dan kami membutuhkan desain yang lebih elegan dan lebih luas yang akan lebih mudah untuk dirawat dan ditambahkan fitur-fitur baru ke dalamnya. Mereka menulis yang baru dan indah selama satu setengah tahun, tetapi pada akhirnya ternyata sama buruknya dan tidak memberikan keuntungan apa pun. Dan biaya sumber daya ternyata sangat besar: dua pengembang menelan sebuah perusahaan selama setengah tahun.

Mengapa lebih baik tidak menyentuh kode jangka panjang proyek besar

Anda bahkan dapat membunuh proyek Anda
Di mana jaminan bahwa Anda akan menulis sesuatu lagi dan itu akan berfungsi dengan benar? Bagaimanapun, ini belum. Dari sudut pandang bisnis, Anda harus hidup di masa sekarang dan memastikan kelangsungan pendapatan.

Anda bisa mematahkan kruk
Dalam proyek apa pun, ada yang namanya kludge (lebih dikenal sebagai "penopang"), dan banyak hal tidak berdokumen. Ya, ada metodologi pengembangan seperti itu, ketika dokumentasi pertama kali ditulis, dan kemudian pengembangan diikuti secara ketat olehnya, tetapi masih menunjukkan dirinya di tahun 90-an sebagai terlalu lembam untuk tugas-tugas bisnis. Mungkin dengan cara ini Anda dapat membuat roket, yaitu, dalam proses di mana pembangunan telah berlangsung selama beberapa dekade, ini dibenarkan, karena ada risiko besar penyimpangan. Dan bahkan di sana Anda harus membuat beberapa perubahan saat bepergian.

Dan dari sudut pandang pengembangan komersial perangkat lunak, tidak ada begitu banyak waktu untuk pertama-tama memperhitungkan semuanya dalam dokumentasi, dan kemudian melakukannya. Dan ternyata semua produk memiliki sejumlah besar data yang tidak terkatakan. Bertemu dengan beberapa jenis masalah lingkungan, misalnya, beberapa besi bekerja untuk memotong spesifikasi, membuat putaran untuk itu. Dalam banyak kasus, jika itu adalah perubahan yang relatif kecil, maka itu sering dilupakan dan tidak tercermin dalam dokumentasi. Itu baru saja dimasukkan ke dalam kode, dan paling sering - dengan semacam komentar waras, sayangnya.

Dan itu dimulai: mari kita buang semua kruk ini, karena tidak jelas bahwa itu merusak kode. Dan mereka tidak berpikir apa yang akan terjadi. Misalnya, ketika kami membuat salah satu tambalan kami untuk kernel Linux, maka di satu tempat kruk itu menggedor: itu sangat jelek dan pada saat yang sama sangat buruk dijelaskan. Dan kemudian dalam diskusi mereka belajar: peralatan tertentu tanpa gudang ini tidak berfungsi. Ya, itu tidak lagi diproduksi, tetapi pengguna masih memilikinya dan berfungsi. Dan hilangnya dukungan untuk perangkat keras ini bertentangan dengan filosofi komunitas Linux. Saya harus menulis ulang kode kami sehingga solusi ini dipertahankan satu-satu, dan setelah itu semua orang puas.

Anda dapat membuang sumber daya
Contoh pemborosan sumber daya diberikan di atas. Harus dipahami bahwa setiap revolusi mengarah ke perang saudara, ke periode tertentu dengan kemunduran dalam keadaan urusan, di mana tidak ada yang akan berhasil.

Anda dapat kehilangan inisiator dan proyek
Sindrom Plumbing terutama memengaruhi karyawan baru. Patut diingat bahwa orang-orang semacam itu berisiko karena mereka dapat meninggalkan perusahaan selama masa percobaan (bukan karena mereka mengatakan bahwa masa percobaan tidak hanya untuk orang tersebut, tetapi juga untuk perusahaan). Pria itu diberikan carte blanche, dia mulai mengulanginya, dan kemudian menyatakan bahwa dia tidak suka kopi di perusahaan dan pergi. Ini adalah situasi yang sangat berbahaya. Ternyata tidak ada yang baru, tetapi yang lama sudah rusak. Maka seseorang (dan sama sekali bukan penggemar) harus membawanya ke bentuk kerja.

Apa yang harus dilakukan ketika keputusan untuk tidak mengulangi keputusan itu jelas, dan orang itu "terbakar dengan sebuah gagasan"?

Berikan waktu untuk dingin dan berpikir
Anda hanya perlu memberikan waktu kepada orang yang datang ke proyek besar yang sudah ada untuk mengenal satu sama lain dengan lebih baik. Karena ketika sebuah ide datang dari seseorang yang telah lama bekerja di sebuah perusahaan dan khususnya dengan produk ini, maka inisiatifnya akan ditanggapi dengan lebih serius dan akan dianalisis dengan argumennya. Anda perlu menjelaskan kepadanya bahwa Anda tidak boleh melempar ke area yang belum Anda kenal dengan baik dan tidak tahu situasi saat ini. Sangat diragukan bahwa seseorang yang baru saja tiba, setelah melihat kode, akan dapat menjelaskan dengan wajar mengapa semuanya salah dan mengapa perlu diubah.

Jika seseorang menolak penolakan atau penawaran seperti itu, maka ini adalah kesempatan untuk mencatat bahwa, mungkin, pengembang ini tidak siap untuk bekerja dalam tim dan kesulitan komunikasi mungkin timbul dengannya (dan ini merupakan faktor yang sangat penting bagi kami). Sejak saat itu pemimpin tim harus bekerja secara terpisah, dalam "mode manual". Mungkin orang seperti itu harus mempertimbangkan kembali pandangannya tentang kariernya dan menjadi freelance, di mana Anda dapat melakukan segalanya "sesuai kebutuhan".

Arahkan energinya ke arah yang berbeda
Sebagian besar produk besar selalu memiliki beberapa hambatan dan masalah yang muncul secara teratur, karena semuanya berubah di luar. Meskipun, menurut saya, masih sangat berbahaya untuk membiarkan orang baru masuk ke kode sampai ia bekerja selama beberapa bulan dengan men-debug bug kecil, berkenalan dengan kode yang ada dan membuktikan tingkat keahliannya.
Dimungkinkan untuk memberinya tugas dari beberapa proyek sampingan, sehingga ia akan meletakkan barang-barang barunya di sana dan melihat apa yang terjadi. Ini asalkan ada slot dalam sumber daya, karena ada sejumlah tugas, di sini, seperti dengan bisnis ventura, saya berinvestasi di 100 perusahaan dan menerima pengembalian satu.

Saat Anda masih harus mengulang

Produk mati dalam kondisi yang ada
Argumen untuk mengulang - jika lingkungan eksternal telah banyak berubah sehingga produk yang ada telah berhenti berfungsi. Misalnya, ketika mereka merilis sistem operasi baru, di mana pengguna mulai beralih ke dalam jumlah besar, tetapi dalam OS ini ada sesuatu yang berubah sehingga produk Anda, yang berfungsi dengan baik di versi sebelumnya, berhenti berfungsi atau menjadi benar-benar merepotkan bagi pengguna untuk menggunakannya. Atau ketika platform mati - misalnya, dari yang lama Anda dapat mengutip BeOS, di mana mereka bekerja cukup banyak dengan produk multimedia, misalnya, menggubah musik. Sistem mati, dan karena sangat berbeda, kode-kode darinya praktis tidak ditransfer ke sistem lain. Hal yang sama terjadi dengan OS BeOS sendiri: ada komputer Atom yang mereka targetkan, dan kemudian pabrikan berhenti melepaskan prosesor ini, dan orang-orang yang menulis untuk komputer ini praktis dibiarkan tanpa apa-apa. Dan mereka dipaksa untuk segera beradaptasi dengan Intel, yang ternyata buruk bagi mereka - ceruk ditempati dan OS lain memerintah di sana. Dan untuk setidaknya entah bagaimana memperpanjang hidup mereka, mereka harus secara serius mengulanginya dengan tujuan meningkatkan portabilitas dan sebagainya.

Sindrom Plumbing bekerja: tahap renovasi

Hal ini diperlukan untuk dilakukan secara evolusioner dan paralel, tanpa merusak sistem. Proses dan tahapan perubahan tergantung pada apakah kita mengubah seluruh produk secara keseluruhan atau bagian penting dari itu. Jika keseluruhan produk, maka ini sebenarnya merupakan awal dari proyek baru dari awal. Tetapi dalam kebanyakan kasus, mereka masih berubah bagian, karena dalam kasus pertama akan diperlukan lebih dari satu tahun sebelum basis kode baru mendapatkan stabilitas dan kepatuhan dengan kualitas konsumen untuk memenuhi setidaknya tingkat itu.

Jika Anda mengganti komponen, maka disarankan untuk melakukannya: jika antarmuka eksternal tidak memerlukan perubahan, maka kami diam-diam membuat implementasi kedua. Dianjurkan untuk segera menemukan garis pemisah: di sini yang lama tetap, tetapi di sini sudah mungkin untuk mengulang, menemukan titik masuk. Jadi, menjaga antarmuka, ubah isinya.

Ini seperti mobil, di mana mereka memutuskan untuk mengganti mesin gas dengan motor listrik. Untuk pengguna, sedikit yang berubah: bodi yang sama, empat roda dan setir tetap ada. Dan di bawah tenda, segalanya bisa terjadi.

Jika Anda berhasil menemukan titik pembagian seperti itu, maka Anda dapat secara evolusioner mengulang dan siapa pun yang berdiri di titik pembagian itu bahkan mungkin tidak melihat perubahan (kecuali, mudah-mudahan, peningkatan kualitas pekerjaan). Dan kemudian dalam proses pengujian internal beralih dan simpan produk. Sayangnya, ini jauh dari selalu memungkinkan, dan kemudian perubahan dapat menyebabkan bencana.

Atau opsi ini: antarmuka diperbaiki, implementasi dilakukan, dan kemudian antarmuka mulai berubah secara iteratif.

Masuk akal untuk memulai perubahan serius pada cabang samping dan sampai terlihat selesai, tidak terintegrasi ke dalam produk utama. Bahkan berkenaan dengan subsistem, lebih buruk jika dengan nama ini kami mulai melakukan sesuatu yang sama sekali baru dan tim bubar, maka tidak ada produk sama sekali.

Alih-alih sebuah kesimpulan

Seorang anak laki-laki dilahirkan dengan kacang, bukan pusar. Dan dia secara berkala bertanya kepada orang tuanya mengapa dia punya kacang di sana. Orang tua berjanji untuk memberitahunya tentang hal ini pada hari ulang tahunnya yang ke-14. Pria itu berusia 14 tahun. Kemudian dia pergi lagi ke ayah dan ibunya dan bertanya mengapa dia punya kacang, bukan pusar. Orang tua berjanji untuk memberitahunya tentang hal itu ketika dia akan berusia 18 tahun. Pada usia 18, dia bertanya lagi, dan kemudian mereka memberi tahu dia bahwa ada pulau tropis di mana pohon palem tumbuh, dan di bawah pohon palem ini sebuah batang pohon dimakamkan. Ada jawaban untuk semua pertanyaannya. Pria itu menabung uang untuk waktu yang lama dan masih meracuni dirinya sendiri di pulau ini. Saya menemukan pohon palem, menggali sebuah peti tempat meletakkan kunci inggris. Tanpa ragu-ragu, dia membuka mur dengan kunci pas yang ditemukan dan pantatnya jatuh. Moral: kadang-kadang Anda tidak perlu mencari petualangan di poin kelima.