Bagaimana cara menjaga produk perangkat lunak yang besar dan kompleks dapat dipelihara selama bertahun-tahun?

Saya telah bekerja sebagai pengembang perangkat lunak selama bertahun-tahun sekarang. Sudah pengalaman saya bahwa proyek menjadi lebih kompleks dan tidak dapat dipelihara karena semakin banyak pengembang yang terlibat dalam pengembangan produk.

Tampaknya perangkat lunak pada tahap pengembangan tertentu memiliki kecenderungan untuk menjadi "peretas" dan "peretas" terutama ketika tidak ada anggota tim yang mendefinisikan pekerjaan arsitektur di perusahaan lagi.

Saya merasa frustasi bahwa seorang pengembang yang harus mengubah sesuatu mengalami kesulitan mendapatkan gambaran besar dari arsitektur. Oleh karena itu, ada kecenderungan untuk memperbaiki masalah atau membuat perubahan dengan cara yang bertentangan dengan arsitektur asli. Hasilnya adalah kode yang semakin kompleks dan bahkan lebih sulit untuk dipahami.

Apakah ada saran yang bermanfaat tentang cara menjaga kode sumber benar-benar dapat dipertahankan selama bertahun-tahun?

Satu-satunya solusi nyata untuk menghindari pembusukan kode adalah kode dengan baik!

Cara kode dengan baik adalah pertanyaan lain. Cukup sulit bahkan jika Anda seorang programmer yang hebat bekerja sendirian. Dalam tim yang heterogen, masih jauh lebih sulit. Dalam proyek (sub) outsourcing ... hanya berdoa.

Praktik baik yang biasa dapat membantu:

1. Tetap sederhana.
2. Tetap sederhana. Ini berlaku terutama untuk arsitektur, "gambaran besar". Jika pengembang mengalami kesulitan untuk mendapatkan gambaran besar, mereka yang akan kode menentangnya. Jadi buat arsitekturnya sederhana sehingga semua pengembang mendapatkannya. Jika arsitektur harus kurang dari sederhana, maka pengembang harus dilatih untuk memahami arsitektur itu. Jika mereka tidak menginternalisasi itu, maka mereka tidak boleh kode di dalamnya.
3. Bertujuan untuk kopling rendah dan kohesi tinggi . Pastikan semua orang di tim memahami ide ini. Dalam sebuah proyek yang terdiri dari bagian-bagian kohesif yang digabungkan secara longgar, jika beberapa bagian menjadi berantakan yang tidak dapat dipelihara, Anda dapat mencabut dan menulis ulang bagian itu. Lebih sulit atau hampir tidak mungkin jika koplingnya kencang.
4. Bersikaplah konsisten. Standar mana yang mengikuti sedikit hal, tapi tolong ikuti beberapa standar. Dalam sebuah tim, setiap orang harus mengikuti standar yang sama tentunya. Di sisi lain, mudah untuk menjadi terlalu terikat dengan standar dan melupakan yang lain: tolong mengerti bahwa meskipun standar bermanfaat, mereka hanya sebagian kecil dari membuat kode yang baik. Jangan menghasilkan jumlah yang besar.
5. Ulasan kode mungkin berguna untuk membuat tim bekerja secara konsisten.
6. Pastikan bahwa semua alat - IDE, kompiler, kontrol versi, sistem bangun, generator dokumentasi, perpustakaan, komputer , kursi , lingkungan keseluruhan dll. - dipelihara dengan baik sehingga pengembang tidak perlu membuang waktu mereka dengan masalah sekunder seperti seperti melawan konflik versi file proyek, pembaruan Windows, kebisingan dan hal-hal sepele apa pun yang menjengkelkan. Harus berulang kali membuang-buang waktu dengan hal-hal yang tidak menarik seperti menurunkan moral, yang setidaknya tidak akan meningkatkan kualitas kode. Dalam tim besar, mungkin ada satu atau lebih orang yang tugas utamanya adalah memelihara alat pengembang.
7. Saat membuat keputusan teknologi, pikirkan apa yang diperlukan untuk beralih teknologi; keputusan mana yang tidak dapat diubah dan mana yang tidak. Mengevaluasi keputusan yang tidak dapat diubah dengan sangat hati-hati. Misalnya, jika Anda memutuskan untuk menulis proyek di Jawa , itu adalah keputusan yang tidak dapat diubah. Jika Anda memutuskan untuk menggunakan beberapa format biner yang direbus sendiri untuk file data, itu juga merupakan keputusan yang tidak dapat dibalikkan (begitu kode keluar di alam bebas dan Anda harus tetap mendukung format itu). Tapi warna GUI dapat dengan mudah disesuaikan, fitur yang awalnya ditinggalkan dapat ditambahkan kemudian, jadi lebih sedikit menekankan tentang masalah tersebut.

Tes unit adalah teman Anda . Menerapkannya memaksa kopling rendah. Ini juga berarti bahwa bagian-bagian "peretasan" dari program dapat dengan mudah diidentifikasi dan di-refactored. Ini juga berarti bahwa setiap perubahan dapat diuji dengan cepat untuk memastikan mereka tidak merusak fungsi yang ada. Ini harus mendorong pengembang Anda untuk memodifikasi metode yang ada daripada menduplikasi kode karena takut merusak.

Tes unit juga berfungsi sebagai sedikit tambahan dokumentasi untuk kode Anda, menguraikan apa yang harus dilakukan setiap bagian. Dengan tes unit yang luas, programmer Anda tidak perlu mengetahui seluruh arsitektur program Anda untuk membuat perubahan dan menggunakan kelas / metode yang ada.

Sebagai efek samping yang bagus, unit test juga diharapkan akan mengurangi jumlah bug Anda.

Semua orang di sini cepat menyebutkan kode busuk , dan saya benar-benar mengerti dan setuju dengan ini, tetapi masih merindukan gambaran yang lebih besar dan masalah yang lebih besar di sini. Busuk kode tidak terjadi begitu saja. Selanjutnya, tes unit disebutkan mana yang baik, tetapi mereka tidak benar-benar mengatasi masalah tersebut. Seseorang dapat memiliki cakupan tes unit yang baik dan kode relatif bebas bug, namun masih memiliki kode dan desain yang membusuk.

Anda menyebutkan bahwa pengembang yang mengerjakan proyek mengalami kesulitan menerapkan fitur dan melewatkan gambaran yang lebih besar dari keseluruhan arsitektur, dan dengan demikian mengimplementasikan peretasan ke dalam sistem. Di mana kepemimpinan teknis untuk menegakkan dan mempengaruhi desain? Di mana ulasan kode dalam proses ini?

Anda sebenarnya tidak menderita busuk kode, tetapi Anda menderita busuk tim . Faktanya adalah bahwa tidak masalah jika pencipta asli perangkat lunak tidak lagi berada di tim. Jika pemimpin teknis dari tim yang ada sepenuhnya dan benar-benar memahami desain yang mendasarinya dan bagus dalam perannya sebagai pemimpin teknologi, maka ini bukan masalah.

Ada beberapa hal yang bisa kita lakukan:

Berikan satu orang tanggung jawab keseluruhan untuk arsitektur. Ketika memilih orang itu, pastikan mereka memiliki visi dan keterampilan untuk mengembangkan dan memelihara arsitektur, dan bahwa mereka memiliki pengaruh dan wewenang untuk membantu pengembang lain mengikuti arsitektur. Orang itu harus menjadi pengembang berpengalaman yang dipercaya oleh manajemen dan yang dihormati oleh rekan-rekan mereka.

Buat budaya di mana semua pengembang mengambil kepemilikan arsitektur. Semua pengembang perlu dilibatkan dalam proses pengembangan dan pemeliharaan integritas arsitektur.

Mengembangkan lingkungan di mana keputusan arsitektur mudah dikomunikasikan. Dorong orang untuk berbicara tentang desain dan arsitektur - tidak hanya dalam konteks proyek saat ini, tetapi secara umum juga.

Praktik pengkodean terbaik membuat arsitektur lebih mudah dilihat dari kode - luangkan waktu untuk refactor, komentar kode, untuk mengembangkan tes unit, dll. Hal-hal seperti konvensi penamaan dan praktik pengkodean yang bersih dapat banyak membantu dalam berkomunikasi arsitektur, sehingga sebagai tim yang Anda butuhkan meluangkan waktu untuk mengembangkan dan mengikuti standar Anda sendiri.

Pastikan semua dokumentasi yang diperlukan jelas, ringkas, terkini dan mudah diakses. Jadikan diagram arsitektur tingkat tinggi dan rendah agar publik (menyematkannya ke dinding dapat membantu) dan dapat dipertahankan secara publik.

Akhirnya (sebagai perfeksionis alami) saya perlu mengakui bahwa integritas arsitektur adalah aspirasi yang layak, tetapi bahwa ada hal-hal yang lebih penting - seperti membangun tim yang dapat bekerja sama dengan baik dan benar-benar mengirimkan produk yang berfungsi.

Cara saya mengatasi masalah ini adalah dengan memotongnya di root:

Penjelasan saya akan menggunakan istilah dari Microsoft / .NET , tetapi akan berlaku untuk platform / kotak alat apa pun:

1. Gunakan standar untuk penamaan, pengkodean, checkin, aliran bug, aliran proses - pada dasarnya apa saja.
2. Jangan takut untuk mengucapkan selamat tinggal kepada anggota tim yang tidak mematuhi standar. Beberapa pengembang tidak bisa bekerja dalam standar yang ditentukan dan akan menjadi musuh kolom ke-5 di medan perang untuk menjaga basis kode tetap bersih
3. Jangan takut untuk mengalokasikan anggota tim berketerampilan rendah untuk pengujian untuk jangka waktu yang lama.
4. Gunakan setiap alat di gudang Anda untuk menghindari memeriksa kode yang membusuk: ini melibatkan alat khusus, serta tes unit pra-tertulis yang menguji file build, file proyek, struktur direktori, dll.
5. Dalam tim yang beranggotakan 5-8 orang, suruh lelaki terbaik Anda melakukan refactoring hampir secara konstan - membersihkan kekacauan yang ditinggalkan orang lain. Bahkan jika Anda menemukan spesialis terbaik di bidangnya, Anda masih akan memiliki kekacauan - itu tidak dapat dihindari, tetapi dapat dibatasi oleh refactoring yang konstan.
6. Apakah menulis unit test dan memeliharanya - JANGAN bergantung pada unit test untuk menjaga proyek tetap bersih, mereka tidak.
7. Diskusikan semuanya. Jangan takut untuk menghabiskan waktu berjam-jam untuk membahas hal-hal di tim. Ini akan menyebarkan informasi dan akan menghapus salah satu akar penyebab kode buruk: kebingungan tentang teknologi, tujuan, standar, dll.
8. Berhati - hatilah dengan konsultan yang menulis kode: kode mereka, hampir secara definisi, akan menjadi barang yang menyebalkan.
9. Lakukan ulasan lebih baik sebagai langkah proses sebelum check-in. Jangan takut untuk mengembalikan komitmen.
10. Jangan pernah menggunakan prinsip buka / tutup kecuali pada tahap terakhir sebelum rilis: itu hanya menyebabkan kode membusuk dibiarkan berbau.
11. Setiap kali masalah terjadi, luangkan waktu untuk memahaminya sepenuhnya sebelum menerapkan solusi - kebanyakan kode membusuk berasal dari menerapkan solusi untuk masalah yang tidak sepenuhnya dipahami.
12. Gunakan teknologi yang tepat. Ini akan sering datang dalam set dan menjadi segar: Lebih baik bergantung pada versi beta dari kerangka kerja Anda memastikan dukungan dari di masa depan, daripada bergantung pada sangat stabil, tetapi kerangka kerja usang, yang tidak didukung.
13. Pekerjakan orang-orang terbaik.
14. Memberhentikan sisanya - Anda tidak menjalankan kedai kopi.
15. Jika manajemen bukan arsitek terbaik dan mereka ikut campur dalam proses pengambilan keputusan - cari pekerjaan lain.

Bersihkan kode busuk dengan refactoring, sambil menulis unit test. Bayar (ini) hutang desain pada semua kode yang Anda sentuh, kapan pun Anda:

• Kembangkan fitur baru
• Perbaiki masalah

Sangat mempercepat siklus pengembangan tes pertama Anda dengan:

• Refactoring untuk mengonversi modul kode ke bahasa scripting
• Gunakan mesin uji berbasis cloud yang cepat

Kode refactor untuk menggunakan kopling rendah (unit yang sangat kohesif secara internal) dengan:

• Lebih sederhana, (lebih banyak) fungsi (rutin)
• Modul
• Objek (dan kelas atau prototipe)
• Fungsi murni (tanpa efek samping)
• Lebih suka delegasi, lebih dari warisan
• Layers (dengan API)
• Koleksi kecil, program satu arah yang dapat beroperasi bersama

Pertumbuhan organik itu baik; desain muka besar buruk.

Punya pemimpin yang memiliki pengetahuan tentang desain saat ini. Jika tidak, baca kode proyek hingga Anda memiliki pengetahuan.

Baca buku refactoring.

Jawaban sederhana: Anda tidak bisa .

Itu sebabnya Anda harus bertujuan untuk menulis perangkat lunak kecil dan sederhana . Ini tidak mudah.

Itu hanya mungkin jika Anda berpikir cukup lama tentang masalah Anda yang tampaknya rumit untuk mendefinisikannya sesederhana dan sesingkat mungkin.

Solusi untuk masalah yang benar-benar besar dan kompleks seringkali masih dapat diselesaikan dengan membangun modul-modul kecil dan sederhana.

Dengan kata lain, seperti yang ditunjukkan orang lain, kesederhanaan dan longgar adalah bahan utama.

Jika itu tidak mungkin atau tidak layak, Anda mungkin sedang melakukan penelitian (masalah kompleks tanpa solusi sederhana yang diketahui, atau tidak ada solusi yang diketahui sama sekali). Jangan berharap riset menghasilkan langsung produk yang dapat dipelihara, bukan itu tujuan penelitian.

Saya bekerja pada basis kode untuk produk yang telah dalam pengembangan berkelanjutan sejak 1999, sehingga Anda dapat membayangkan itu cukup rumit sekarang. Sumber peretasan terbesar dalam basis kode kami adalah dari beberapa kali kami harus memindahkannya dari ASP Classic ke ASP.NET , dari ADO ke ADO.NET, dari postback ke Ajax , beralih perpustakaan UI, standar pengkodean, dll.

Secara keseluruhan kami telah melakukan pekerjaan yang wajar untuk menjaga basis kode tetap terpelihara. Hal-hal utama yang kami lakukan yang berkontribusi pada hal itu adalah:

1) Konstan refactoring - Jika Anda harus menyentuh sepotong kode yang hacky atau sulit dipahami, Anda diharapkan untuk mengambil waktu ekstra untuk membersihkannya dan diberi kelonggaran dalam jadwal untuk melakukannya. Tes unit membuat ini jauh lebih menakutkan, karena Anda dapat menguji terhadap regresi lebih mudah.

2) Jaga lingkungan pengembangan yang rapi - Waspada tentang menghapus kode yang tidak lagi digunakan, dan jangan meninggalkan salinan cadangan / copy pekerjaan / kode eksperimental yang ada di direktori proyek.

3) Standar pengkodean yang konsisten untuk kehidupan Proyek - Mari kita hadapi itu, pandangan kita tentang standar pengkodean berkembang seiring waktu. Saya sarankan tetap dengan standar pengkodean yang Anda mulai untuk kehidupan proyek kecuali Anda punya waktu untuk kembali dan retrofit semua kode untuk memenuhi standar baru. Sangat menyenangkan bahwa Anda melebihi notasi Hongaria sekarang, tetapi terapkan pelajaran itu ke proyek-proyek baru dan jangan hanya beralih di tengah-tengah proyek baru itu.

Karena Anda telah menandai pertanyaan dengan manajemen proyek, saya telah mencoba menambahkan beberapa poin non-kode :)

• Rencanakan pergantian - asumsikan bahwa seluruh tim pengembangan akan menghilang pada saat ia mencapai fase pemeliharaan - tidak ada pengembang yang layak garamnya ingin terjebak mempertahankan sistemnya selamanya. Mulailah menyiapkan materi penyerahan segera setelah Anda punya waktu.

• Konsistensi / keseragaman tidak dapat cukup ditekankan. Ini akan mencegah budaya 'pergi sendiri' dan mendorong pengembang baru untuk bertanya, jika mereka ragu.

• Tetap mengarusutamakan - teknologi yang digunakan, pola desain dan standar - karena pengembang baru untuk tim (di tingkat apa pun) akan memiliki lebih banyak peluang untuk bangun dan berjalan dengan cepat.

• Dokumentasi - terutama arsitektur - mengapa keputusan dibuat, dan standar pengkodean. Juga simpan referensi / catatan / peta jalan ke dalam mendokumentasikan domain bisnis - Anda akan kagum betapa sulitnya bagi bisnis perusahaan untuk menjelaskan apa yang mereka lakukan kepada pengembang tanpa pengalaman domain.

• Tetapkan aturan dengan jelas - tidak hanya untuk tim pengembangan Anda saat ini, tetapi pikirkan tentang pengembang pemeliharaan di masa depan. Jika ini berarti menempatkan hyperlink ke desain yang relevan dan mengkode dokumentasi standar pada setiap halaman, maka jadilah.

• Pastikan bahwa arsitektur dan terutama lapisan kode dibatasi dengan jelas dan dipisahkan - ini berpotensi memungkinkan untuk penggantian lapisan kode saat teknologi baru datang, misalnya, mengganti UI Formulir Web dengan UI jQuery HTML5 , dll., Yang mungkin beli satu tahun atau lebih dari umur panjang yang ditambahkan.

Salah satu properti dari kode yang sangat dapat dipertahankan adalah fungsi kemurnian .

Kemurnian berarti bahwa fungsi harus mengembalikan hasil yang sama untuk argumen yang sama. Artinya, mereka tidak harus bergantung pada efek samping dari fungsi lain. Selain itu, berguna jika mereka tidak memiliki efek samping sendiri.

Properti ini lebih mudah untuk disaksikan dibandingkan dengan properti sambungan / kohesi. Anda tidak harus keluar dari cara Anda untuk mencapainya, dan saya pribadi menganggapnya lebih berharga.

Ketika fungsi Anda murni, tipenya adalah dokumentasi yang sangat bagus dengan sendirinya. Selain itu, menulis dan membaca dokumentasi dalam hal argumen / nilai pengembalian jauh lebih mudah daripada yang menyebutkan beberapa kondisi global (mungkin diakses oleh utas lain O_O).

Sebagai contoh menggunakan kemurnian secara luas untuk membantu pemeliharaan, Anda dapat melihat GHC . Ini adalah proyek besar sekitar 20 tahun di mana refactoring besar sedang dilakukan dan fitur-fitur utama baru masih diperkenalkan.

Terakhir, saya tidak terlalu suka poin "Keep it simple". Anda tidak dapat membuat program Anda sederhana ketika Anda membuat model hal-hal kompleks. Cobalah membuat kompiler sederhana dan kode Anda yang dihasilkan kemungkinan akan berakhir lambat. Tentu, Anda dapat (dan seharusnya) membuat fungsi individu menjadi sederhana, tetapi keseluruhan program tidak akan sesederhana itu.

Selain jawaban lain, saya akan merekomendasikan layer. Tidak terlalu banyak tetapi cukup untuk memisahkan berbagai jenis kode.

Kami menggunakan model API internal untuk sebagian besar aplikasi. Ada API internal yang terhubung ke database. Kemudian lapisan UI . Orang yang berbeda dapat bekerja pada setiap level tanpa mengganggu atau merusak bagian lain dari aplikasi.

Pendekatan lain adalah membuat semua orang membaca comp.risks dan The Daily WTF sehingga mereka mempelajari konsekuensi dari desain yang buruk dan pemrograman yang buruk, dan mereka akan takut melihat kode mereka sendiri diposting di The Daily WTF .

Karena banyak dari jawaban ini tampaknya berfokus pada tim-tim besar, bahkan sejak awal, saya akan menempatkan pandangan saya sebagai bagian dari tim pengembangan dua orang (tiga jika Anda termasuk perancang) untuk sebuah startup.

Jelas, desain dan solusi sederhana adalah yang terbaik, tetapi ketika Anda memiliki orang yang benar-benar membayar gaji Anda, Anda tidak perlu punya waktu untuk memikirkan solusi yang paling elegan, sederhana dan dapat dipelihara. Dengan mengingat hal itu, poin besar pertama saya adalah:

Dokumentasi Bukan komentar, kode sebagian besar harus didokumentasikan sendiri, tetapi hal-hal seperti dokumen desain, hierarki dan dependensi kelas, paradigma arsitektur, dll. Apa pun yang membantu programmer baru, atau bahkan yang sudah ada, untuk memahami basis kode. Juga, mendokumentasikan pseudo-library aneh yang muncul pada akhirnya, seperti "menambahkan kelas ini ke elemen untuk fungsi ini" dapat membantu, karena itu juga mencegah orang dari menulis ulang fungsionalitas.

Namun, bahkan jika Anda memiliki batas waktu yang berat, saya menemukan bahwa hal baik yang perlu diingat adalah:

Hindari peretasan dan perbaikan cepat. Kecuali jika perbaikan cepat adalah perbaikan aktual, selalu lebih baik untuk mencari tahu masalah yang mendasarinya untuk sesuatu, dan kemudian memperbaikinya. Kecuali Anda benar-benar memiliki skenario "buat ini berfungsi dalam 2 menit, atau Anda dipecat", melakukan perbaikan sekarang adalah ide yang lebih baik, karena Anda tidak akan memperbaiki kode nanti, Anda hanya akan pindah ke tugas berikutnya yang Anda miliki.

Dan tip favorit pribadi saya lebih dari kutipan, meskipun saya tidak dapat mengingat sumbernya:

"Kode seolah-olah orang yang datang setelahmu adalah psikopat pembunuh yang tahu di mana kau tinggal"

Satu prinsip yang belum disebutkan tetapi yang saya anggap penting adalah prinsip terbuka / tertutup .

Anda tidak boleh memodifikasi kode yang telah dikembangkan dan diuji: setiap potongan kode tersebut disegel. Sebagai gantinya, perluas kelas yang ada dengan subkelas, atau gunakan mereka menulis pembungkus, kelas dekorator atau menggunakan pola apa pun yang Anda rasa cocok. Tetapi jangan mengubah kode kerja .

Hanya 2 sen saya.

• Jadilah pengintai . Selalu tinggalkan kode lebih bersih daripada yang Anda temukan.

• Perbaiki jendela yang rusak . Semua komentar itu "berubah dalam versi 2.0" saat Anda menggunakan versi 3.0.

• Ketika ada peretasan besar, rancang solusi yang lebih baik sebagai sebuah tim dan lakukan itu. Jika Anda tidak dapat memperbaiki retasan sebagai sebuah tim, maka Anda tidak memahami sistem dengan cukup baik. "Minta bantuan orang dewasa." Orang-orang tertua di sekitar mungkin pernah melihat ini sebelumnya. Cobalah menggambar atau mengekstraksi diagram sistem. Cobalah menggambar atau mengekstraksi kasus penggunaan yang terutama hacky sebagai diagram interaksi. Ini tidak memperbaikinya, tetapi setidaknya Anda bisa melihatnya.

• Asumsi apa yang tidak lagi benar yang mendorong desain ke arah tertentu? Mungkin ada refactoring kecil yang bersembunyi di balik beberapa kekacauan itu.

• Jika Anda menjelaskan cara kerja sistem (bahkan hanya satu kasus penggunaan) dan mendapati diri Anda harus meminta maaf atas suatu subsistem berulang kali, itu masalahnya. Apa yang akan menjadikan sisa sistem lebih sederhana (tidak peduli seberapa sulit untuk diterapkan dibandingkan dengan apa yang ada). Subsistem klasik untuk ditulis ulang adalah subsistem yang mencemari setiap subsistem lainnya dengan semantik dan implementasinya. "Oh, Anda harus groz nilai sebelum Anda memasukkannya ke dalam subsistem froo, maka Anda un-groz lagi ketika Anda mendapatkan output dari froo. Mungkin semua nilai harus groz'ed ketika dibaca dari pengguna & penyimpanan, dan sisanya dari sistem ini salah? Ini menjadi lebih menarik ketika ada dua atau lebih grozifikasi yang berbeda.

• Habiskan seminggu sebagai tim menghapus peringatan sehingga masalah nyata terlihat.

• Format ulang semua kode ke standar pengkodean.

• Pastikan sistem kontrol versi Anda terkait dengan pelacak bug Anda. Ini berarti perubahan di masa depan adalah baik dan dapat dipertanggungjawabkan, dan Anda dapat bekerja MENGAPA.

• Lakukan arkeologi. Temukan dokumen desain asli dan tinjau. Mereka mungkin berada di PC lama di sudut kantor, di ruang kantor yang ditinggalkan atau di lemari arsip yang tidak pernah dibuka oleh siapa pun.

• Publikasikan ulang dokumen desain pada wiki. Ini membantu melembagakan pengetahuan.

• Tulis prosedur seperti daftar periksa untuk rilis dan build. Ini menghentikan orang untuk berpikir, sehingga mereka dapat berkonsentrasi untuk menyelesaikan masalah. Automate build sedapat mungkin.

• Coba integrasi terus menerus . Semakin cepat Anda mendapatkan bangunan yang gagal, semakin sedikit waktu proyek dapat menghabiskan dari rel.

• Jika pemimpin tim Anda tidak melakukan hal-hal ini, baik itu buruk bagi perusahaan.

• Cobalah untuk memastikan semua kode baru mendapatkan pengujian unit yang tepat dengan cakupan terukur. Jadi masalahnya tidak bisa lebih buruk.

• Coba uji unit beberapa bit lama yang tidak diuji unit. Ini membantu mengurangi ketakutan akan perubahan.

• Otomatiskan tes integrasi dan regresi Anda jika Anda bisa. Setidaknya punya daftar periksa. Pilot cerdas dan mendapat banyak bayaran dan mereka menggunakan daftar periksa. Mereka juga mengacaukan sangat jarang.

Baca dan baca kembali Kode Lengkap oleh Steve McConnell. Ini seperti Alkitab penulisan perangkat lunak yang baik, dari desain proyek awal hingga satu baris kode dan semua yang ada di antaranya. Yang paling saya sukai tentang hal ini adalah didukung oleh data padat selama beberapa dekade; bukan hanya gaya pengkodean terbaik berikutnya.

Saya datang untuk menyebutnya "Efek Rumah Misteri Winchester". Seperti rumah, itu dimulai cukup sederhana, tetapi selama bertahun-tahun banyak pekerja yang berbeda menambahkan begitu banyak fitur aneh tanpa rencana keseluruhan sehingga tidak ada yang benar-benar mengerti lagi. Mengapa tangga ini tidak menuju ke mana-mana dan mengapa pintu itu hanya terbuka satu arah? Siapa tahu?

Cara untuk membatasi efek ini adalah mulai dengan desain bagus yang dibuat di mana cukup fleksibel untuk menangani ekspansi. Beberapa saran telah ditawarkan untuk hal ini.

Tetapi, sering kali Anda akan mengambil pekerjaan di mana kerusakan sudah terjadi, dan sudah terlambat untuk desain yang baik tanpa melakukan desain ulang dan menulis ulang yang mahal dan berpotensi berisiko. Dalam situasi itu, yang terbaik adalah mencoba menemukan cara untuk membatasi kekacauan sambil merangkulnya sampai batas tertentu. Mungkin mengganggu kepekaan desain Anda bahwa semuanya harus melalui kelas 'manajer' tunggal yang besar, jelek, tunggal atau lapisan akses data digabungkan erat ke UI, tetapi belajarlah untuk menghadapinya. Kode pertahanan dalam kerangka itu dan mencoba untuk mengharapkan yang tak terduga ketika 'hantu' programmer masa lalu muncul.

Refactoring kode dan pengujian unit sangat baik. Tetapi karena proyek jangka panjang ini berjalan ke peretasan, ini berarti bahwa manajemen tidak meletakkan kakinya untuk membersihkan busuk. Tim diminta untuk memperkenalkan hacks, karena seseorang tidak mengalokasikan sumber daya yang cukup untuk melatih orang dan menganalisis masalah / permintaan.

Mempertahankan proyek yang berjalan lama adalah tanggung jawab manajer proyek seperti halnya pengembang individu.

Orang tidak memperkenalkan retasan karena mereka menyukainya; mereka dipaksa oleh keadaan.

Saya hanya ingin menempatkan masalah non-teknis dan pendekatan pragmatis (mungkin).

Jika manajer Anda tidak peduli dengan kualitas teknis (kode yang dapat dikelola, arsitektur sederhana, infrastruktur yang andal, dan sebagainya), menjadi sulit untuk meningkatkan proyek. Dalam hal ini perlu untuk mendidik manajer tersebut dan meyakinkan untuk "menginvestasikan" upaya ke dalam pemeliharaan dan mengatasi utang teknis .

Jika Anda bermimpi dengan kualitas kode yang ditemukan dalam buku-buku itu, Anda juga memerlukan atasan yang peduli akan hal ini.

Atau jika Anda hanya ingin menjinakkan "proyek Frankenstein" ini adalah tips saya:

• Atur dan sederhanakan
• Mempersingkat fungsi
• Prioritaskan keterbacaan di atas efisiensi (jika tentu saja dapat diterima, dan beberapa keuntungan efisiensi terlalu menyedihkan untuk disimpan)

Dalam pengalaman saya, pemrograman lebih entropis daripada muncul (setidaknya dalam paradigma imperatif-terstruktur populer). Ketika orang menulis kode untuk "hanya bekerja" kecenderungannya adalah kehilangan organisasinya. Sekarang pengorganisasian kode membutuhkan waktu, kadang-kadang lebih dari membuatnya berfungsi.

Di luar implementasi fitur dan perbaikan bug, luangkan waktu Anda untuk pembersihan kode.

Saya terkejut menemukan bahwa tidak satu pun dari banyak jawaban yang menyoroti yang jelas: membuat perangkat lunak terdiri dari banyak perpustakaan kecil dan independen. Dengan banyak perpustakaan kecil, Anda dapat membangun perangkat lunak yang besar dan kompleks. Jika persyaratan berubah, Anda tidak perlu membuang seluruh basis kode atau menyelidiki cara mengubah basis kode klakson besar untuk melakukan sesuatu yang lain daripada apa yang sedang dilakukan. Anda hanya memutuskan perpustakaan mana yang masih relevan setelah persyaratan berubah dan bagaimana menggabungkannya untuk memiliki fungsi baru.

Gunakan teknik pemrograman apa pun di perpustakaan yang membuat penggunaan perpustakaan mudah. Perhatikan bahwa mis. Setiap pointer fungsi pendukung bahasa yang tidak berorientasi objek mendukung sebenarnya pemrograman berorientasi objek (OOP). Jadi, misalnya dalam C, Anda dapat melakukan OOP.

Anda bahkan dapat mempertimbangkan untuk berbagi perpustakaan kecil dan independen di antara banyak proyek (git submodules adalah teman Anda).

Tidak perlu dikatakan, setiap perpustakaan kecil dan independen harus diuji unit. Jika perpustakaan tertentu tidak dapat diuji unit, Anda melakukan sesuatu yang salah.

Jika Anda menggunakan C atau C ++ dan tidak menyukai gagasan memiliki banyak file .so yang kecil, Anda dapat menautkan semua pustaka menjadi file .so yang lebih besar, atau Anda dapat melakukan tautan statis. Hal yang sama berlaku untuk Java, cukup ubah .so menjadi .jar.

Sederhana: kurangi biaya perawatan sebagian besar kode Anda menjadi nol sampai Anda memiliki jumlah komponen yang dapat dipelihara. Kode yang tidak perlu diubah tanpa dikenakan biaya perawatan. Saya sarankan bertujuan untuk membuat kode benar-benar memiliki biaya pemeliharaan nol , tidak mencoba untuk mengurangi biaya lebih dari iterasi refactoring kecil dan cerewet. Buat biaya nol segera.

Oke, harus diakui itu jauh, jauh lebih sulit daripada kedengarannya. Tetapi tidak sulit untuk memulai. Anda dapat mengambil sebagian dari basis kode, mengujinya, membangun antarmuka yang bagus di atasnya jika desain antarmuka berantakan, dan mulai menumbuhkan bagian-bagian dari basis kode yang dapat diandalkan, stabil (seperti tidak ada alasan untuk mengubah), sementara secara bersamaan menyusut bagian-bagian yang tidak dapat diandalkan dan tidak stabil. Basis kode yang terasa seperti mimpi buruk untuk dipertahankan sering tidak membedakan bagian yang bergerak yang perlu diubah dari bagian yang tidak, karena semuanya dianggap tidak dapat diandalkan dan cenderung berubah.

Saya benar-benar merekomendasikan untuk memisahkan organisasi basis kode Anda menjadi bagian "stabil" dan "tidak stabil", dengan bagian stabil menjadi PITA besar untuk dibangun kembali dan diubah (yang merupakan hal yang baik, karena mereka tidak perlu perlu diubah dan dibangun kembali jika mereka benar-benar termasuk dalam bagian "stabil").

Ini bukan ukuran basis kode yang membuat pemeliharaan sulit. Ini ukuran basis kode yang perlu dipertahankan. Saya bergantung pada jutaan baris kode setiap kali saya, katakanlah, menggunakan API sistem operasi. Tetapi itu tidak berkontribusi pada biaya pemeliharaan produk saya, karena saya tidak harus mempertahankan kode sumber sistem operasi. Saya hanya menggunakan kode dan itu berfungsi. Kode yang hanya saya gunakan dan tidak perlu memelihara tidak ada biaya pemeliharaan pada saya.