Saya harap ini bukan pertanyaan umum; Saya benar-benar bisa menggunakan beberapa saran berpengalaman.

Saya baru saja dipekerjakan sebagai "Insinyur SW" satu-satunya di sebuah toko kecil yang terdiri dari para ilmuwan yang telah menghabiskan 10-20 tahun terakhir untuk membangun basis kode yang luas. (Itu ditulis dalam bahasa yang hampir usang: G2 - pikirkan Pascal dengan grafik). Program itu sendiri adalah model fisik dari pabrik pemrosesan kimia yang kompleks; tim yang menulisnya memiliki pengetahuan domain yang sangat mendalam tetapi sedikit atau tidak ada pelatihan formal dalam pemrograman dasar. Mereka baru saja belajar beberapa pelajaran sulit tentang konsekuensi dari manajemen konfigurasi yang tidak ada. Upaya pemeliharaan mereka juga sangat terhambat oleh akumulasi besar "lumpur" yang tidak terdokumentasi dalam kode itu sendiri. Saya akan menghindarkan Anda dari "politik" situasi ( selalu ada politik!), tetapi cukup untuk mengatakan, tidak ada konsensus pendapat tentang apa yang dibutuhkan untuk jalan di depan.

Mereka meminta saya untuk mulai mempresentasikan kepada tim beberapa prinsip pengembangan perangkat lunak modern. Mereka ingin saya memperkenalkan beberapa praktik dan strategi standar industri mengenai konvensi pengkodean, manajemen siklus hidup, pola desain tingkat tinggi, dan kontrol sumber. Terus terang, ini tugas yang cukup menakutkan dan saya tidak yakin harus mulai dari mana.

Awalnya, saya cenderung mengajari mereka dalam beberapa konsep utama Program Pragmatis , atau Fowler's Refactoring ("Code Smells", dll). Saya juga berharap untuk memperkenalkan sejumlah metodologi Agile. Tetapi pada akhirnya, agar efektif, saya pikir saya perlu mengasah 5-7 fundamental inti; dengan kata lain, prinsip atau praktik apa yang paling penting yang secara realistis dapat mereka mulai laksanakan yang akan memberi mereka "ledakan besar".

Jadi itulah pertanyaan saya: Apa yang akan Anda masukkan dalam daftar strategi paling efektif untuk membantu meluruskan spageti (dan mencegahnya di masa depan)?

Kata pengantar

Ini memang tugas yang menakutkan, dan ada banyak alasan untuk dibahas. Jadi saya dengan rendah hati menyarankan ini sebagai panduan yang agak komprehensif untuk tim Anda, dengan petunjuk alat dan materi pendidikan yang tepat.

Ingat: Ini adalah pedoman , dan dengan demikian dimaksudkan untuk diadopsi, diadaptasi, atau dihapus berdasarkan keadaan.

Hati-hati: Membuang semua ini di tim sekaligus kemungkinan besar akan gagal. Anda harus mencoba untuk memetik elemen yang akan memberi Anda energi terbaik, dan memperkenalkannya secara perlahan, satu per satu.

Catatan: tidak semua ini berlaku langsung untuk Sistem Pemrograman Visual seperti G2. Untuk detail lebih spesifik tentang cara menghadapinya, lihat bagian Addendum di bagian akhir.

Ringkasan Eksekutif untuk yang tidak sabar

• Tetapkan struktur proyek yang kaku , dengan:
  • template proyek ,
  • konvensi pengkodean ,
  • membangun sistem yang akrab ,
  • dan set pedoman penggunaan untuk infrastruktur dan alat Anda.
• Instal SCM yang baik dan pastikan mereka tahu cara menggunakannya.
• Arahkan mereka ke IDE yang bagus untuk teknologinya, dan pastikan mereka tahu cara menggunakannya.
• Menerapkan pemeriksa kualitas kode dan pelaporan otomatis dalam sistem pembangunan.
• Menggabungkan sistem pembangunan dengan integrasi berkesinambungan dan sistem inspeksi berkelanjutan .
• Dengan bantuan di atas, identifikasi kualitas "hotspot" kode dan refactor .

Sekarang untuk versi panjang ... Perhatian, bersiaplah!

Kekakuan (Sering) Bagus

Ini adalah pendapat yang kontroversial, karena kekakuan sering dipandang sebagai kekuatan yang bekerja melawan Anda. Memang benar untuk beberapa fase dari beberapa proyek. Tapi begitu Anda melihatnya sebagai dukungan struktural, kerangka kerja yang menghilangkan dugaan, itu sangat mengurangi jumlah waktu dan usaha yang terbuang. Buat itu bekerja untuk Anda, bukan melawan Anda.

Kekakuan = Proses / Prosedur .

Pengembangan perangkat lunak memerlukan proses dan prosedur yang baik untuk alasan yang persis sama bahwa pabrik kimia atau pabrik memiliki manual, prosedur, latihan, dan pedoman darurat: mencegah hasil yang buruk, meningkatkan kemampuan prediksi, memaksimalkan produktivitas ...

Kekakuan datang dalam jumlah sedang, meskipun!

Kekakuan Struktur Proyek

Jika setiap proyek dilengkapi dengan strukturnya sendiri, Anda (dan pendatang baru) hilang dan perlu mengambil dari awal setiap kali Anda membukanya. Anda tidak ingin ini di toko perangkat lunak profesional, dan Anda tidak ingin ini di laboratorium juga.

Kekakuan Sistem Bangun

Jika setiap proyek terlihat berbeda, ada kemungkinan mereka juga membangun secara berbeda . Bangunan seharusnya tidak memerlukan terlalu banyak penelitian atau terlalu banyak menebak. Anda ingin dapat melakukan hal yang kanonik dan tidak perlu khawatir tentang spesifik: configure; make install, ant, mvn install, dll ...

Menggunakan kembali sistem pembangunan yang sama dan membuatnya berkembang dari waktu ke waktu juga memastikan tingkat kualitas yang konsisten.

Anda perlu cepat READMEuntuk menunjuk spesifik proyek, dan dengan anggun memandu pengguna / pengembang / peneliti, jika ada.

Ini juga sangat memudahkan bagian lain dari infrastruktur pembangunan Anda, yaitu:

• integrasi berkelanjutan ,
• inspeksi terus menerus .

Jadi terus perbarui bangunan Anda (seperti proyek Anda), tetapi buatlah lebih ketat dari waktu ke waktu, dan lebih efisien dalam melaporkan pelanggaran dan praktik buruk.

Jangan menemukan kembali roda, dan gunakan kembali apa yang telah Anda lakukan.

Bacaan yang Disarankan:

• Integrasi Berkelanjutan: Meningkatkan Kualitas Perangkat Lunak dan Mengurangi Risiko (Duval, Matyas, Glover, 2007)
• Pengiriman Berkelanjutan: Rilis Sotware Rilis melalui Build, Test, dan Deployment Automation (Humble, Farley, 2010)

Kekakuan dalam Pilihan Bahasa Pemrograman

Anda tidak dapat berharap, terutama dalam lingkungan penelitian, untuk memiliki semua tim (dan bahkan lebih sedikit semua pengembang) menggunakan bahasa dan tumpukan teknologi yang sama. Namun, Anda dapat mengidentifikasi seperangkat alat "yang didukung secara resmi", dan mendorong penggunaannya. Selebihnya, tanpa alasan yang baik, tidak boleh diizinkan (di luar prototipe).

Buat tumpukan teknologi Anda tetap sederhana, dan pemeliharaan serta luasnya keterampilan yang diperlukan seminimal mungkin: inti yang kuat.

Kekakuan Konvensi dan Panduan Pengkodean

Konvensi dan pedoman pengkodean adalah apa yang memungkinkan Anda untuk mengembangkan identitas sebagai tim, dan istilah bersama . Anda tidak ingin masuk ke terra incognita setiap kali Anda membuka file sumber.

Aturan yang tidak masuk akal yang membuat hidup lebih sulit atau melarang tindakan kejelasan sejauh komitmen dilakukan berdasarkan satu pelanggaran sederhana adalah beban. Namun:

• aturan dasar yang dipikirkan dengan baik menghilangkan banyak rengekan dan pemikiran: tidak ada yang harus melanggar dalam keadaan apa pun;

• dan seperangkat aturan yang direkomendasikan memberikan panduan tambahan.

Pendekatan Pribadi: Saya agresif ketika datang ke konvensi pengkodean, beberapa bahkan mengatakan nazi , karena saya percaya memiliki lingua franca , gaya yang dikenali untuk tim saya. Ketika kode sampah diperiksa, kode itu tampak seperti luka dingin di wajah bintang Hollywood: itu memicu ulasan dan tindakan secara otomatis. Bahkan, saya kadang-kadang bertindak lebih jauh dengan menganjurkan penggunaan kait pra-komitmen untuk menolak komitmen yang tidak sesuai. Seperti yang disebutkan, itu tidak boleh terlalu gila dan menghalangi produktivitas: itu harus mendorongnya. Perkenalkan ini secara perlahan, terutama di awal. Tapi itu lebih disukai daripada menghabiskan begitu banyak waktu memperbaiki kode yang salah sehingga Anda tidak dapat bekerja pada masalah nyata.

Beberapa bahasa bahkan menerapkan ini dengan desain:

• Java dimaksudkan untuk mengurangi jumlah sampah kusam yang dapat Anda tulis dengannya (walaupun tidak diragukan banyak yang berhasil melakukannya).

• Struktur blok Python dengan indentasi adalah ide lain dalam pengertian ini.

• Pergilah, dengan gofmtalatnya, yang sepenuhnya menghilangkan segala perdebatan dan upaya ( dan ego !! ) yang melekat pada gaya: lari gofmtsebelum Anda berkomitmen.

Pastikan kode busuk tidak bisa masuk. Konvensi kode , integrasi berkelanjutan dan inspeksi berkelanjutan , pemrograman pasangan dan ulasan kode adalah senjata Anda terhadap iblis ini.

Plus, seperti yang akan Anda lihat di bawah, kode adalah dokumentasi , dan itu adalah bidang lain di mana konvensi mendorong keterbacaan dan kejelasan.

Kekakuan Dokumentasi

Dokumentasi berjalan seiring dengan kode. Kode itu sendiri adalah dokumentasi. Tetapi harus ada instruksi yang jelas tentang cara membangun, menggunakan, dan memelihara berbagai hal.

Menggunakan satu titik kontrol untuk dokumentasi (seperti WikiWiki atau DMS) adalah hal yang baik. Buat ruang untuk proyek, ruang untuk olok-olok dan eksperimen yang lebih acak. Mintalah semua ruang menggunakan kembali aturan dan konvensi umum. Cobalah menjadikannya bagian dari semangat tim.

Sebagian besar saran berlaku untuk kode dan perangkat juga berlaku untuk dokumentasi.

Kekakuan dalam Komentar Kode

Komentar kode, sebagaimana disebutkan di atas, juga merupakan dokumentasi. Pengembang suka mengekspresikan perasaan mereka tentang kode mereka (kebanyakan kebanggaan dan frustrasi, jika Anda bertanya kepada saya). Jadi bukan hal yang aneh bagi mereka untuk mengungkapkannya tanpa syarat yang pasti dalam komentar (atau bahkan kode), ketika sebuah teks yang lebih formal dapat menyampaikan makna yang sama dengan sedikit bahan peledak atau drama. Tidak apa-apa membiarkan beberapa lolos karena alasan yang menyenangkan dan historis: itu juga bagian dari pengembangan budaya tim . Tetapi sangat penting bahwa setiap orang tahu apa yang dapat diterima dan apa yang tidak, dan kebisingan komentar itu hanya itu: kebisingan .

Kekakuan dalam Log Komit

Log komit bukanlah "langkah" siklus hidup SCM Anda yang tidak berguna dan tidak berguna: Anda TIDAK melewatkannya untuk pulang tepat waktu atau melanjutkan tugas berikutnya, atau untuk mengejar ketinggalan dengan teman-teman yang pergi makan siang. Mereka penting, dan, seperti (kebanyakan) anggur yang baik, semakin banyak waktu berlalu semakin berharga mereka. Jadi, lakukan dengan benar. Saya terperangah ketika melihat rekan kerja menulis satu kalimat untuk komit raksasa, atau untuk peretasan yang tidak jelas.

Komit dilakukan karena suatu alasan, dan alasan itu TIDAK selalu dinyatakan dengan jelas oleh kode Anda dan satu baris log komit yang Anda masukkan. Ada lebih dari itu.

Setiap baris kode memiliki cerita , dan sejarah . Difs bisa menceritakan sejarahnya, tetapi Anda harus menulis ceritanya.

Mengapa saya memperbarui baris ini? -> Karena antarmuka berubah.

Mengapa antarmuka berubah? -> Karena perpustakaan L1 mendefinisikannya telah diperbarui.

Mengapa perpustakaan diperbarui? -> Karena library L2, yang kita perlukan untuk fitur F, tergantung pada library L1.

Dan apa fitur X? -> Lihat tugas 3456 dalam pelacak masalah.

Ini bukan pilihan SCM saya, dan mungkin juga bukan yang terbaik untuk lab Anda; tetapi lakukan Gitini dengan benar, dan mencoba memaksa Anda untuk menulis log yang bagus lebih dari kebanyakan sistem SCM lainnya, dengan menggunakan short logsdan long logs. Menghubungkan ID tugas (ya, Anda perlu satu) dan meninggalkan ringkasan generik untuk shortlog, dan memperluas dalam log panjang: menulis changeset ini cerita .

Ini adalah log: Ada di sini untuk melacak dan merekam pembaruan.

Aturan Jempol: Jika Anda mencari sesuatu tentang perubahan ini nanti, apakah log Anda kemungkinan akan menjawab pertanyaan Anda?

Proyek, Dokumentasi, dan Kode HIDUP

Tetap sinkronkan, jika tidak mereka tidak membentuk entitas simbiotik itu lagi. Ini bekerja dengan baik ketika Anda memiliki:

• hapus log komit di SCM Anda, dengan tautan ke ID tugas di pelacak masalah Anda,
• di mana tiket pelacak ini sendiri tertaut ke perubahan di SCM Anda (dan mungkin ke build di sistem CI Anda),
• dan sistem dokumentasi yang menghubungkan semua ini.

Kode dan dokumentasi harus kohesif .

Kekakuan dalam Pengujian

Aturan Jempol:

• Setiap kode baru harus disertai dengan (setidaknya) tes unit.
• Setiap kode warisan yang telah di-refactored harus disertai dengan tes unit.

Tentu saja, ini perlu:

• untuk benar-benar menguji sesuatu yang berharga (atau mereka membuang-buang waktu dan energi),
• ditulis dan dikomentari dengan baik (sama seperti kode lain yang Anda laporkan).

Mereka juga dokumentasi, dan mereka membantu menguraikan kontrak kode Anda. Apalagi jika Anda menggunakan TDD . Bahkan jika tidak, Anda membutuhkannya untuk ketenangan pikiran Anda. Mereka adalah jaring pengaman Anda ketika Anda memasukkan kode baru (pemeliharaan atau fitur) dan menara pengawal Anda untuk menjaga dari kerusakan kode dan kerusakan lingkungan.

Tentu saja, Anda harus melangkah lebih jauh dan memiliki tes integrasi , dan tes regresi untuk setiap bug yang dapat Anda perbaiki.

Kekakuan dalam Penggunaan Alat

Tidak masalah bagi pengembang / ilmuwan sesekali ingin mencoba pemeriksa statis baru pada sumbernya, menghasilkan grafik atau model menggunakan yang lain, atau mengimplementasikan modul baru menggunakan DSL. Tetapi yang terbaik adalah jika ada seperangkat alat kanonik yang diharapkan diketahui dan digunakan oleh semua anggota tim.

Lebih dari itu, biarkan anggota menggunakan apa yang mereka inginkan, selama mereka SEMUA:

• produktif ,
• TIDAK secara teratur membutuhkan bantuan
• TIDAK secara teratur menyesuaikan diri dengan infrastruktur umum Anda ,
• JANGAN mengganggu infrastruktur Anda (dengan memodifikasi area umum seperti kode, membangun sistem, dokumentasi ...),
• TIDAK memengaruhi pekerjaan orang lain ,
• MAMPU untuk melakukan tugas yang diminta secara tepat waktu .

Jika bukan itu masalahnya, tegakkan bahwa mereka mundur ke default.

Kekakuan vs Fleksibilitas, Kemampuan Beradaptasi, Prototipe dan Keadaan Darurat

Fleksibilitas bisa baik. Membiarkan seseorang sesekali menggunakan peretasan, pendekatan cepat-kotor, atau alat kesayangan favorit untuk menyelesaikan pekerjaan tidak masalah. JANGAN PERNAH biarkan ini menjadi kebiasaan, dan JANGAN PERNAH biarkan kode ini menjadi basis kode yang sebenarnya untuk didukung.

Team Spirit Matters

Kembangkan Sense of Pride di Codebase Anda

• Kembangkan rasa bangga dalam Kode
  • Gunakan papan dinding
    • papan pemimpin untuk permainan integrasi berkelanjutan
    • papan dinding untuk manajemen masalah dan penghitungan cacat
  • Gunakan pelacak masalah / pelacak bug

Hindari Menyalahkan Game

• LAKUKAN menggunakan permainan Integrasi Berkelanjutan / Inspeksi Berkepanjangan: itu mendorong kompetisi yang sopan dan produktif .
• LAKUKAN Lacak Cacat: ini hanya perawatan rumah yang baik.
• LAKUKAN mengidentifikasi akar penyebab : itu hanya proses pembuktian di masa depan.
• TETAPI JANGAN menyalahkan : itu kontra produktif.

Ini Tentang Kode, Bukan Tentang Pengembang

Buat pengembang sadar akan kualitas kode mereka, TETAPI membuat mereka melihat kode sebagai entitas yang terpisah dan bukan perpanjangan dari diri mereka sendiri, yang tidak dapat dikritik.

Ini sebuah paradoks: Anda perlu mendorong pemrograman tanpa ego untuk tempat kerja yang sehat tetapi mengandalkan ego untuk tujuan motivasi.

Dari Ilmuwan ke Programmer

Orang yang tidak menghargai dan bangga dengan kode tidak menghasilkan kode yang baik. Agar properti ini muncul, mereka perlu menemukan betapa berharganya dan menyenangkannya itu. Profesionalisme semata dan keinginan untuk berbuat baik tidak cukup: itu membutuhkan semangat. Jadi, Anda perlu mengubah ilmuwan Anda menjadi programmer (dalam arti besar).

Seseorang berdebat dalam komentar bahwa setelah 10 hingga 20 tahun mengerjakan suatu proyek dan kodenya, siapa pun akan merasakan keterikatan. Mungkin saya salah, tetapi saya menganggap mereka bangga dengan hasil kode dan pekerjaan serta warisannya, bukan dari kode itu sendiri atau dari tindakan penulisan kode itu.

Dari pengalaman, sebagian besar peneliti menganggap pengkodean sebagai kebutuhan, atau paling baik sebagai gangguan yang menyenangkan. Mereka hanya ingin itu berhasil. Orang-orang yang sudah cukup berpengalaman di dalamnya dan yang memiliki minat dalam pemrograman jauh lebih mudah dibujuk untuk mengadopsi praktik terbaik dan beralih teknologi. Anda harus membawanya di tengah jalan.

Pemeliharaan Kode adalah Bagian dari Pekerjaan Penelitian

Tidak ada yang membaca makalah penelitian yang jelek. Itulah sebabnya mereka ditinjau ulang, dibaca-ulang, disempurnakan, ditulis ulang, dan disetujui berulang kali hingga dianggap siap untuk dipublikasikan. Hal yang sama berlaku untuk tesis dan basis kode!

Jelaskan bahwa refactoring dan penyegaran basis kode yang konstan mencegah pembusukan kode dan mengurangi hutang teknis, dan memfasilitasi penggunaan kembali di masa depan dan adaptasi pekerjaan untuk proyek lain.

Mengapa semua ini??!

Kenapa kita repot dengan semua hal di atas? Untuk kualitas kode . Atau apakah itu kode kualitas ...?

Pedoman ini bertujuan untuk mengarahkan tim Anda menuju tujuan ini. Beberapa aspek melakukannya dengan hanya menunjukkan kepada mereka jalan dan membiarkan mereka melakukannya (yang jauh lebih baik) dan yang lain mengambilnya (tetapi itulah cara Anda mendidik orang dan mengembangkan kebiasaan).

Bagaimana Anda tahu kapan tujuan itu tercapai?

Kualitas bisa diukur

Tidak selalu secara kuantitatif, tetapi bisa diukur . Seperti yang disebutkan, Anda perlu mengembangkan rasa bangga pada tim Anda, dan menunjukkan kemajuan serta hasil yang baik adalah kuncinya. Mengukur kualitas kode secara teratur dan menunjukkan kemajuan di antara interval, dan bagaimana hal itu penting. Lakukan retrospektif untuk merenungkan apa yang telah dilakukan, dan bagaimana hal itu membuat segalanya menjadi lebih baik atau lebih buruk.

Ada alat yang hebat untuk inspeksi berkelanjutan . Sonar menjadi yang populer di dunia Jawa, tetapi dapat beradaptasi dengan teknologi apa pun; dan ada banyak lainnya. Simpan kode Anda di bawah mikroskop dan cari bug dan mikroba yang menjengkelkan ini.

Tetapi bagaimana jika Kode Saya Sudah Omong kosong?

Semua hal di atas menyenangkan dan lucu seperti perjalanan ke Never Land, tetapi itu tidak mudah dilakukan ketika Anda sudah memiliki (tumpukan beruap dan bau) kode sampah, dan tim enggan untuk berubah.

Inilah rahasianya: Anda harus mulai dari suatu tempat .

Anekdot pribadi: Dalam sebuah proyek, kami bekerja dengan basis kode dengan bobot awalnya 650.000+ Java LOC, 200.000+ baris JSP, 40.000+ JavaScript LOC, dan 400+ MB dependensi biner.

Setelah sekitar 18 bulan, 500.000 Java LOC (PALING BERSIH) , 150.000 baris JSP, dan 38.000 JavaScript LOC, dengan dependensi hingga hampir 100MB (dan ini sudah tidak ada dalam SCM kami lagi!).

Bagaimana kami melakukannya? Kami baru saja melakukan semua hal di atas. Atau berusaha keras.

Ini adalah usaha tim, tapi kami perlahan-lahan menyuntikkan dalam peraturan proses dan alat untuk memonitor detak jantung dari produk kami, sementara buru-buru memotong menghilangkan "lemak": kode omong kosong, dependensi tidak berguna ... Kami tidak berhenti semua pembangunan untuk lakukan ini: kadang-kadang kita memiliki periode yang relatif damai dan tenang di mana kita bebas untuk menjadi gila pada basis kode dan memisahkannya, tetapi sebagian besar waktu kita melakukan semuanya dengan default ke mode "review dan refactor" setiap kesempatan yang kita dapatkan : saat membangun, saat makan siang, selama sprint memperbaiki bug, selama Jumat sore ...

Ada beberapa "karya" besar ... Mengubah sistem build kami dari semut raksasa yang terdiri dari 8500+ XML LOC ke multi-module Maven build adalah salah satunya. Kami kemudian memiliki:

• modul yang jelas (atau setidaknya itu sudah jauh lebih baik, dan kami masih memiliki rencana besar untuk masa depan),
• manajemen ketergantungan otomatis (untuk perawatan dan pembaruan yang mudah, dan untuk menghapus deps yang tidak berguna),
• membangun lebih cepat, lebih mudah dan dapat direproduksi,
• laporan harian tentang kualitas.

Yang lainnya adalah injeksi "sabuk alat utilitas", meskipun kami berusaha mengurangi ketergantungan: Google Guava dan Apache Commons merampingkan kode Anda dan dan mengurangi banyak bug di kode Anda .

Kami juga meyakinkan departemen TI kami bahwa mungkin menggunakan alat baru kami (JIRA, Fisheye, Crucible, Confluence, Jenkins) lebih baik daripada yang ada di tempat. Kami masih perlu berurusan dengan beberapa yang kami benci (QC, Sharepoint dan SupportWorks ...), tetapi itu adalah pengalaman yang ditingkatkan secara keseluruhan, dengan beberapa ruang tersisa.

Dan setiap hari, sekarang ada tetesan antara satu hingga lusinan komit yang hanya berurusan dengan memperbaiki dan merestorasi hal-hal. Kami kadang-kadang memecahkan barang-barang (Anda perlu pengujian unit, dan Anda lebih baik menulisnya sebelum Anda memperbaiki barang-barang), tetapi secara keseluruhan manfaat untuk moral kita DAN untuk produk sangat besar. Kami sampai di sana satu bagian dari persentase kualitas kode pada suatu waktu. Dan sangat menyenangkan melihatnya bertambah !!!

Catatan: Sekali lagi, kekakuan perlu diguncang untuk memberikan ruang bagi hal-hal baru dan lebih baik. Dalam anekdot saya, departemen TI kami sebagian benar dalam mencoba untuk memaksakan beberapa hal pada kami, dan salah bagi yang lain. Atau mungkin mereka dulu benar . Banyak hal berubah. Buktikan bahwa itu adalah cara yang lebih baik untuk meningkatkan produktivitas Anda. Uji coba dan prototipe ada di sini untuk ini.

Siklus Refactoring Kode Spaghetti Incremental Super-Rahasia untuk Kualitas Luar Biasa

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Setelah Anda memiliki beberapa alat berkualitas di toolbelt Anda:

1. Analisis kode Anda dengan pemeriksa kualitas kode.

   Linter, analisa statis, atau apa yang Anda miliki.

2. Mengidentifikasi Anda kritis hotspot DAN buah menggantung rendah .

   Pelanggaran memiliki tingkat keparahan, dan kelas besar dengan jumlah besar yang tingkat keparahannya tinggi adalah bendera merah: dengan demikian, mereka muncul sebagai "hot spot" pada tampilan radiator / heatmap.

3. Perbaiki hotspot terlebih dahulu.

   Ini memaksimalkan dampak Anda dalam jangka waktu singkat karena mereka memiliki nilai bisnis tertinggi. Idealnya, pelanggaran kritis harus ditangani segera setelah muncul, karena berpotensi kerentanan keamanan atau penyebab kecelakaan, dan menghadirkan risiko tinggi menimbulkan tanggung jawab (dan dalam kasus Anda, kinerja buruk untuk lab).

4. Bersihkan pelanggaran tingkat rendah dengan sapuan basis kode otomatis .

   Ini meningkatkan rasio signal-to-noise sehingga Anda dapat melihat pelanggaran signifikan pada radar Anda saat muncul. Sering kali ada pasukan besar pelanggaran kecil pada awalnya jika mereka tidak pernah diurus dan basis kode Anda dilepaskan di alam liar. Mereka tidak menghadirkan "risiko" nyata, tetapi mereka merusak pembacaan dan pemeliharaan kode. Perbaiki baik saat Anda bertemu mereka saat mengerjakan tugas, atau dengan pencarian pembersihan besar dengan kode otomatis menyapu jika memungkinkan. Berhati-hatilah dengan sapuan otomatis besar jika Anda tidak memiliki test suite dan sistem integrasi yang baik. Pastikan untuk setuju dengan rekan kerja waktu yang tepat untuk menjalankannya untuk meminimalkan gangguan.

5. Ulangi sampai Anda puas.

   Yang, idealnya, Anda tidak boleh, jika ini masih merupakan produk aktif: itu akan terus berkembang.

Kiat Cepat untuk Menjaga Rumah yang Baik

• Ketika dalam mode hotfix , berdasarkan permintaan dukungan pelanggan:

  • Ini biasanya merupakan praktik terbaik untuk TIDAK berkeliling memperbaiki masalah lain, karena Anda mungkin memperkenalkan yang baru dengan enggan.
  • Lakukan saja SEAL-style: masuk, bunuh bug, keluar , dan kirim tambalan Anda. Ini serangan bedah dan taktis.

• Tetapi untuk semua kasus lain , jika Anda membuka file, tugas Anda untuk:

  • pasti: tinjau (catat, laporkan laporan masalah)
  • mungkin: bersihkan (pembersihan gaya dan pelanggaran kecil),
  • idealnya: refactor itu (mengatur ulang bagian besar dan tetangga mereka).

Hanya saja, jangan dialihkan ke menghabiskan satu minggu dari file ke file dan berakhir dengan perubahan besar dari ribuan perbaikan yang mencakup beberapa fitur dan modul - itu membuat pelacakan di masa depan sulit. Satu masalah dalam kode = satu tiket di pelacak Anda. Terkadang, perubahan dapat mempengaruhi banyak tiket; tetapi jika itu terjadi terlalu sering, maka Anda mungkin melakukan sesuatu yang salah.

Tambahan: Mengelola Lingkungan Pemrograman Visual

Taman Bertembok Sistem Pemrograman Bespoke

Berbagai sistem pemrograman, seperti G2 OP, adalah beast yang berbeda ...

• Tidak Ada Sumber "Kode"

  Seringkali mereka tidak memberi Anda akses ke representasi tekstual dari "kode" sumber Anda: mungkin disimpan dalam format biner berpemilik, atau mungkin menyimpan sesuatu dalam format teks tetapi menyembunyikannya dari Anda. Sistem pemrograman grafis dipesan lebih dahulu sebenarnya tidak jarang di laboratorium penelitian, karena mereka menyederhanakan otomatisasi alur kerja pemrosesan data berulang.

• Tanpa Tooling

  Selain dari mereka sendiri. Anda sering dibatasi oleh lingkungan pemrograman mereka, debugger mereka sendiri, penerjemah mereka sendiri, alat dan format dokumentasi mereka sendiri. Mereka adalah taman bertembok , kecuali jika pada akhirnya menangkap minat seseorang yang cukup termotivasi untuk merekayasa balik format mereka dan membangun alat eksternal - jika lisensi mengizinkannya.

• Kurangnya Dokumentasi

  Cukup sering, ini adalah sistem pemrograman niche, yang digunakan di lingkungan yang cukup tertutup. Orang yang menggunakannya sering menandatangani NDA dan tidak pernah berbicara tentang apa yang mereka lakukan. Memprogram komunitas untuk mereka jarang terjadi. Jadi sumber daya langka. Anda terjebak dengan referensi resmi Anda, dan hanya itu.

Ironisnya (dan seringkali membuat frustrasi) adalah bahwa semua hal yang dilakukan sistem ini jelas dapat dicapai dengan menggunakan bahasa pemrograman umum dan tujuan umum, dan sangat mungkin lebih efisien. Tapi itu membutuhkan pengetahuan yang lebih dalam tentang pemrograman, sedangkan Anda tidak bisa mengharapkan ahli biologi, ahli kimia atau fisikawan Anda (untuk menyebutkan beberapa) cukup tahu tentang pemrograman, dan bahkan lebih sedikit memiliki waktu (dan keinginan) untuk menerapkan (dan memelihara) sistem yang kompleks, yang mungkin atau mungkin tidak berumur panjang. Untuk alasan yang sama kami menggunakan DSL, kami memiliki sistem pemrograman yang dipesan lebih dahulu.

Anekdot Pribadi 2:Sebenarnya, saya mengerjakan sendiri salah satunya. Saya tidak melakukan tautan dengan permintaan OP, tetapi proyek saya adalah serangkaian besar perangkat lunak pemrosesan dan penyimpanan data yang saling terhubung (terutama untuk penelitian bio-informatika, perawatan kesehatan dan kosmetik, tetapi juga untuk bisnis intelijen, atau domain apa pun yang menyiratkan pelacakan volume besar data penelitian dalam bentuk apa pun dan persiapan alur kerja pemrosesan data dan ETL). Salah satu aplikasi ini adalah, cukup sederhana, IDE visual yang menggunakan lonceng dan peluit yang biasa: antarmuka drag and drop, ruang kerja proyek berversi (menggunakan file teks dan XML untuk penyimpanan metadata), banyak driver yang dapat dicolokkan ke sumber data yang heterogen, dan visual kanvas untuk merancang jaringan pipa untuk memproses data dari sumber data N dan pada akhirnya menghasilkan output yang ditransformasikan M, dan kemungkinan visualisasi yang mengilap dan laporan online yang kompleks (dan interaktif). Sistem pemrograman visual khusus Anda yang dipesan lebih dahulu, menderita sedikit sindrom NIH dengan alasan merancang sistem yang disesuaikan dengan kebutuhan pengguna.

Dan, seperti yang Anda harapkan, ini adalah sistem yang bagus, cukup fleksibel untuk kebutuhannya meskipun kadang-kadang sedikit berlebihan sehingga Anda bertanya-tanya "mengapa tidak menggunakan alat baris perintah saja?", Dan sayangnya selalu memimpin dalam ukuran sedang tim bekerja pada proyek-proyek besar untuk banyak orang yang berbeda menggunakannya dengan praktik "terbaik" yang berbeda.

Hebat, Kita Ditakdirkan! - Apa yang kita lakukan tentang hal itu?

Nah, pada akhirnya, semua hal di atas masih berlaku. Jika Anda tidak dapat mengekstrak sebagian besar pemrograman dari sistem ini untuk menggunakan lebih banyak alat dan bahasa utama, Anda "hanya" perlu menyesuaikannya dengan batasan-batasan sistem Anda.

Tentang Versi dan Penyimpanan

Pada akhirnya, Anda hampir selalu dapat membuat versi berbagai hal, bahkan dengan lingkungan yang paling terbatas dan berdinding. Paling sering daripada tidak, sistem ini masih datang dengan versi mereka sendiri (yang sayangnya sering agak mendasar, dan hanya menawarkan untuk kembali ke versi sebelumnya tanpa banyak visibilitas, hanya menyimpan snapshot sebelumnya). Itu tidak persis menggunakan perubahan diferensial seperti SCM pilihan Anda mungkin, dan itu mungkin tidak cocok untuk beberapa pengguna yang mengirimkan perubahan secara bersamaan.

Tapi tetap saja, jika mereka menyediakan fungsionalitas seperti itu, mungkin solusi Anda adalah mengikuti panduan standar industri tercinta di atas, dan memindahkannya ke sistem pemrograman ini !!

Jika sistem penyimpanan adalah basis data, ia mungkin memperlihatkan fungsi ekspor, atau dapat dicadangkan di tingkat sistem file. Jika itu menggunakan format biner khusus, mungkin Anda bisa mencoba versi itu dengan VCS yang memiliki dukungan yang baik untuk data biner. Anda tidak akan memiliki kendali yang baik, tetapi setidaknya Anda akan memiliki semacam punggung terlindung dari bencana dan memiliki tingkat tertentu kepatuhan pemulihan bencana.

Tentang Pengujian

Laksanakan pengujian Anda di dalam platform itu sendiri, dan gunakan alat eksternal dan pekerjaan latar belakang untuk mengatur cadangan reguler. Sangat mungkin, Anda menjalankan tes ini sama seperti Anda akan menjalankan program yang dikembangkan dengan sistem pemrograman ini.

Tentu, ini adalah pekerjaan hack dan jelas tidak sesuai dengan standar dari apa yang umum untuk pemrograman "normal", tetapi idenya adalah untuk beradaptasi dengan sistem sambil mencoba mempertahankan kemiripan proses pengembangan perangkat lunak profesional.

Jalannya Panjang dan ...

Seperti biasa dengan lingkungan khusus dan sistem pemrograman yang dipesan lebih dahulu, dan seperti yang kami paparkan di atas, Anda berurusan dengan format yang aneh, hanya seperangkat alat yang mungkin kikuk yang terbatas, atau tidak ada sama sekali, dan kekosongan di tempat komunitas.

Rekomendasi: Cobalah untuk menerapkan pedoman di atas di luar sistem pemrograman yang dipesan lebih dahulu, sebanyak mungkin. Ini memastikan bahwa Anda dapat mengandalkan alat "umum", yang memiliki dukungan yang tepat dan dorongan komunitas.

Penanganan Masalah: Saat ini bukan opsi, cobalah untuk memasang kembali kerangka kerja global ini ke "kotak" Anda. Idenya adalah untuk overlay cetak biru ini praktik terbaik standar industri di atas sistem pemrograman Anda, dan membuat yang terbaik dari itu. Saran tetap berlaku: jelaskan struktur dan praktik terbaik, dorong kepatuhan.

Sayangnya, ini menyiratkan bahwa Anda mungkin perlu menyelam dan melakukan banyak pekerjaan kaki. Begitu...

Kata-Kata Terakhir Terkenal, dan Permintaan Rendah Hati:

• Dokumentasikan semua yang Anda lakukan.
• Bagikan pengalaman Anda.
• Open Source alat apa pun yang Anda tulis.

Dengan melakukan semua ini, Anda akan:

• tidak hanya meningkatkan peluang Anda untuk mendapatkan dukungan dari orang-orang dalam situasi yang sama,
• tetapi juga memberikan bantuan kepada orang lain, dan mendorong diskusi seputar tumpukan teknologi Anda.

Siapa tahu, Anda mungkin berada di awal komunitas baru Bahasa Obscure X yang bersemangat . Jika tidak ada, mulailah satu!

• Ajukan pertanyaan tentang Stack Overflow ,
• Mungkin bahkan menulis proposal untuk Situs StackExchange baru di Area 51 .

Mungkin itu indah di dalam , tetapi tidak ada yang tahu sejauh ini, jadi bantu hancurkan dinding jelek ini dan biarkan orang lain mengintip!

Langkah pertama adalah pengenalan Sistem Kontrol Versi (SVN, Git, Mercurial, TFS, dll.). Ini harus dimiliki untuk proyek yang akan memiliki anjak piutang.

Sunting: mengenai VSC - Setiap paket kontrol sumber dapat mengelola binari, meskipun dengan beberapa keterbatasan. Sebagian besar alat di pasar memiliki kemampuan untuk menggunakan penampil perbedaan khusus dan editor, gunakan kemampuan ini. File sumber biner bukan alasan untuk tidak menggunakan kontrol versi.

Ada posting serupa tentang cara menangani kode lawas , mungkin itu rujukan yang bagus untuk diikuti - Nasihat tentang bekerja dengan kode lawas

Ketika saya harus bekerja dengan kode spageti, hal pertama yang saya kerjakan adalah modularisasi . Temukan tempat di mana Anda dapat menggambar garis dan mengekstrak (kurang lebih) potongan basis kode independen. Mereka mungkin tidak akan terlalu kecil, karena tingkat interkoneksi dan kopling yang tinggi, tetapi beberapa garis modul akan muncul jika Anda mencarinya.

Setelah Anda memiliki modul, maka Anda tidak dihadapkan dengan tugas yang menakutkan untuk membersihkan seluruh program yang berantakan. Sekarang, sebagai gantinya, Anda memiliki beberapa modul berantakan independen yang lebih kecil untuk dibersihkan. Sekarang pilih modul dan ulangi pada skala yang lebih kecil. Temukan tempat di mana Anda dapat mengekstrak fungsi besar ke dalam fungsi yang lebih kecil atau bahkan kelas (jika G2 mendukungnya).

Ini semua jauh lebih mudah jika bahasa memiliki sistem tipe yang cukup kuat, karena Anda bisa membuat kompiler melakukan banyak pekerjaan berat untuk Anda. Anda membuat perubahan di suatu tempat yang akan (dengan sengaja) merusak kompatibilitas, lalu mencoba mengompilasinya. Kesalahan kompilasi akan mengarahkan Anda langsung ke tempat-tempat yang perlu diubah, dan ketika Anda berhenti mendapatkannya, Anda telah menemukan segalanya. Kemudian jalankan program dan uji semuanya! Pengujian berkelanjutan sangat penting saat refactoring.

Saya tidak tahu apakah ini pilihan bagi Anda, tetapi saya akan mulai mencoba meyakinkan mereka untuk mempekerjakan lebih banyak pengembang profesional . Dengan cara ini mereka dapat berkonsentrasi dalam masalah domain (saya yakin mereka sudah cukup di sana).

Saya percaya mereka adalah orang yang sangat pintar, tetapi menjadi pengembang yang baik membutuhkan banyak waktu. Apakah mereka siap untuk menghabiskan begitu banyak waktu dalam kegiatan yang bukan bisnis utama mereka? IMHO, ini bukan cara untuk mencapai hasil terbaik.

Wow. Kedengarannya Anda memiliki tantangan yang sangat besar di depan Anda! Saya akan melakukan sesuatu di sepanjang baris berikut:

• Pertama-tama: Prioritaskan . Apa yang ingin Anda capai terlebih dahulu? Apa yang paling penting untuk keadaan proyek saat ini? Apa yang akan Anda dapatkan dari vs berapa banyak waktu yang dibutuhkan untuk sampai ke sana.
• Pastikan Anda memiliki sistem kontrol versi . Git atau Mercurial misalnya.
• Dapatkan beberapa jenis sistem integrasi berkelanjutan (misalnya Jenkins ) dan berjalan.
• Dapatkan sistem pelacakan bug berjalan dan berjalan. Mantis menurut saya cukup bagus.
• Lihatlah analisis kode statis (jika ada sesuatu yang tersedia untuk bahasa yang sedang Anda kerjakan).
• Cobalah untuk mencapai sebanyak mungkin konsistensi dalam segala hal mulai dari penamaan variabel hingga konvensi kode umum dan pedoman dalam basis kode.
• Dapatkan sistem yang diuji . Ini sangat penting untuk sistem warisan besar seperti ini menurut saya. Gunakan uji kasus untuk mendokumentasikan perilaku yang ada , tidak peduli apakah perilaku itu terasa aneh atau tidak (biasanya ada alasan mengapa kode terlihat mengapa tertentu, mungkin baik atau buruk, atau keduanya; P). Michael Feathers Bekerja Secara Efektif dengan Legacy Code adalah sumber yang bagus untuk ini.

Mereka mengatakan bahwa langkah pertama dalam menyelesaikan masalah adalah mengakui bahwa Anda memiliki satu. Dengan mengingat hal itu, Anda bisa mulai dengan membuat grafik dependensi yang mengilustrasikan kusut luas yang menjadi basis kode Anda saat ini. Alat yang bagus untuk menghasilkan diagram ketergantungan? sudah beberapa tahun tetapi mengandung beberapa petunjuk alat yang dapat membantu membuat grafik seperti itu. Saya akan menggunakan satu grafik besar dan jelek yang menunjukkan sebanyak mungkin untuk mengarahkan titik itu ke rumah. Bicara tentang masalah yang disebabkan oleh terlalu banyak saling ketergantungan dan mungkin perlu antri dari Buckaroo Banzai :

Anda dapat memeriksa anatomi Anda semua yang Anda inginkan, dan meskipun mungkin ada variasi normal, ketika sampai ke sana, sejauh ini di dalam kepala semuanya terlihat sama. Tidak, tidak, tidak, jangan tarik itu. Anda tidak pernah tahu apa yang dilampirkan.

Dari sana, perkenalkan rencana untuk mulai meluruskan kekacauan. Pecah kode menjadi modul yang mandiri mungkin. Bersikaplah terbuka terhadap saran bagaimana melakukan itu - orang-orang yang Anda ajak bicara mengetahui sejarah dan fungsionalitas kode lebih baik daripada Anda. Namun, tujuannya adalah untuk mengambil satu masalah besar dan mengubahnya menjadi beberapa masalah kecil yang kemudian dapat Anda prioritaskan dan mulai membersihkan.

Beberapa hal yang harus diperhatikan:

• Buat antarmuka yang bersih antar modul dan mulai menggunakannya. Kode lama mungkin, karena kebutuhan, terus tidak menggunakan antarmuka baru yang bagus untuk sementara waktu - itulah masalah yang mulai Anda pecahkan. Namun, buat semua orang setuju untuk hanya menggunakan antarmuka baru di masa mendatang. Jika ada sesuatu yang mereka butuhkan yang tidak ada di antarmuka, perbaiki antarmuka, jangan berkeliling.

• Cari kasus di mana fungsi yang sama telah diulang. Berusahalah menuju penyatuan.

• Ingatkan semua orang dari waktu ke waktu bahwa perubahan ini dimaksudkan untuk membuat hidup lebih mudah, bukan lebih sulit. Transisi bisa menyakitkan, tetapi itu untuk tujuan yang baik, dan semakin banyak orang ikut, semakin cepat manfaatnya datang.

Setelah melihat ke Gensym G2 sebentar sepertinya cara untuk mendekati masalah ini akan sangat tergantung pada seberapa banyak basis kode terlihat seperti ini:

atau ini:

versus ini, milik 99 Botol Bir :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

Dalam kasus yang terakhir Anda bekerja dengan kode sumber yang secara efektif dikenal kuantitas dan beberapa jawaban lain menawarkan beberapa saran yang sangat bijak untuk menghadapinya.

Jika sebagian besar basis kode adalah yang terakhir, atau bahkan jika potongan yang cukup besar, Anda akan mengalami masalah menarik memiliki kode yang kemungkinan tidak dapat di refactored karena sangat terspesialisasi, atau lebih buruk lagi, sesuatu yang terlihat seperti mungkin dapat dilepas, tetapi kecuali jika didokumentasikan dengan benar, Anda tidak tahu apakah Anda menghapus kode kritis (pikirkan sesuatu di sepanjang garis operasi scram ) yang tampaknya tidak terlihat seperti itu pada pandangan pertama.

Meskipun jelas prioritas pertama Anda akan mendapatkan semacam kontrol versi online, seperti yang ditunjukkan ElYusubov , dan tampaknya kontrol versi telah didukung sejak versi 8.3 . Karena G2 adalah kombinasi dari beberapa metodologi bahasa yang berbeda, Anda mungkin akan merasa paling efektif untuk menggunakan kontrol versi yang disediakan dengannya daripada mencoba menemukan sesuatu yang lain dan membuatnya berfungsi.

Selanjutnya, meskipun beberapa orang mungkin akan menyarankan untuk memulai refactor, saya seorang pendukung yang kuat untuk memastikan Anda sepenuhnya memahami sistem yang Anda kerjakan sebelum Anda mulai menyentuh salah satu kode, terutama ketika berhadapan dengan kode dan diagram visual yang dikembangkan oleh pengembang tanpa pelatihan formal (atau latar belakang) dalam metodologi rekayasa perangkat lunak. Alasan untuk ini adalah beberapa kali lipat, tetapi alasan yang paling jelas adalah bahwa Anda bekerja dengan aplikasi yang berpotensi memiliki lebih dari 100 orang-tahun pekerjaan yang dimasukkan ke dalamnya dan Anda benar-benar perlu memastikan Anda tahu apa yang dilakukannya dan berapa banyak dokumentasi ada di dalamnya. Karena Anda tidak mengatakan industri mana yang digunakan sistem ini, berdasarkan apa yang saya baca tentang G2 tampaknya aman untuk mengasumsikan bahwa itu kemungkinan aplikasi kritis misi yang bahkan mungkin berpotensi untuk juga memiliki implikasi keselamatan jiwa. Dengan demikian, memahami persis apa yang dilakukannya akan menjadi sangat penting. Itu ada kode yang tidak didokumentasikan bekerja dengan yang lain di tim untuk memastikan bahwa dokumentasi ditempatkan untuk memastikan orang dapat menentukan apa yang kode lakukan.

Selanjutnya mulailah membungkus unit test sebanyak mungkin basis kode dan diagram visual yang Anda bisa. Saya harus mengakui beberapa ketidaktahuan tentang cara melakukan ini dengan G2 tetapi mungkin hampir layak untuk membuat kerangka pengujian Anda sendiri untuk mendapatkan ini di tempat. Ini juga merupakan waktu yang ideal untuk mulai memperkenalkan anggota tim yang lain untuk membiasakan mereka dengan beberapa praktik rekayasa yang lebih ketat yang terkait dengan kualitas kode (yaitu semua kode harus memiliki unit test dan dokumentasi).

Setelah Anda memiliki tes unit pada sejumlah kode, Anda dapat mulai mendekati refactoring dengan cara seperti yang disarankan oleh haylem ; Namun, ingat untuk diingat bahwa Anda berurusan dengan sesuatu yang dimaksudkan untuk mengembangkan sistem pakar dan refactoring mungkin merupakan perjuangan berat. Ini sebenarnya sebuah lingkungan di mana ada sesuatu yang bisa dikatakan untuk tidak menulis kode yang sangat umum pada waktu-waktu tertentu.

Akhirnya, pastikan Anda memperhatikan dengan seksama apa yang dikatakan anggota tim lainnya, hanya karena kualitas kode dan diagram bukan yang terbaik tidak selalu mencerminkan buruk pada mereka. Pada akhirnya, untuk saat ini mereka cenderung mengetahui lebih banyak tentang apa yang dilakukan aplikasi daripada Anda. Itulah mengapa lebih penting bagi Anda untuk duduk dan memastikan Anda memahami apa yang dilakukannya sebelum melakukan perubahan besar juga.

Biasanya keluhan yang Anda dengar di muka tidak ada hubungannya dengan masalah penting. Lagi pula, sangat normal untuk mendengar keluhan ini dalam proyek perangkat lunak apa pun.

Sulit memahami kode? Memeriksa. Basis kode besar-besaran? Memeriksa.

Masalah sebenarnya adalah orang-orang pergi, dan ketika orang baru bergabung dengan organisasi, ada disorientasi tertentu. Selain itu, ada masalah harapan yang tidak realistis dan masalah kualitas kode.

Inilah yang akan saya tangani, dalam rangka:

1. Backup, baik versi server dan lokal
2. Siapkan pelacak bug
3. Siapkan sistem versi
4. Atur FAQ / Wiki
5. Pembekalan pertama dari semua ilmuwan / programmer
   • Ingatkan mereka tentang aturan 80/20. 20% bug bertanggung jawab atas 80% masalah.
   • Fokus pada masalah terbesar, dan tetap matikan permintaan peningkatan.
   • Tujuannya di sini bukan untuk menakut-nakuti orang dengan daftar besar, tetapi daftar kemenangan kecil yang bisa dicapai. Lagi pula, Anda harus membuktikan nilai Anda juga.
6. Siapkan sistem pembangunan
   • Mulai bekerja untuk mendapatkan bangunan yang andal (ini mungkin perlu waktu)
   • mengidentifikasi dan memberi nama setiap proyek
   • mengidentifikasi ketergantungan siklik
   • jika ada binari dari beberapa proyek open-source, cobalah untuk mendapatkan sumber
7. Identifikasi bagaimana kode G2 dapat dimodulasi, misalnya API, layanan
8. Identifikasi bagaimana kode G2 dapat diuji, didokumentasikan.
9. Siapkan sistem peninjauan kode
10. Tanya jawab kedua
    • Seperti apa bentuk modul ideal?
    • Cara menutup kode lama
    • Cara membungkus modul baru di sekitar kode lama (Lihat Pola Strangler http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Identifikasi tim crack programmer yang lebih baik dan bekerja bersama mereka untuk membungkus modul mereka.
12. Tinjauan kode ada pada tahap ini untuk meningkatkan komunikasi, dan dokumentasi. Tetap mudah pada tahap ini. Memilah masalah proses.
13. Gulirkan sistem ke pemrogram lain. Biarkan anggota tim crack menjadi mentor sebaya bagi yang lain. Ingat bahwa penskalaan adalah masalahnya di sini. Anda secara efektif dalam peran manajemen.

Pertanyaan-pertanyaan seperti inilah yang menjadi alasan mengapa proyek Software Carpentry ada.

Selama 14 tahun terakhir, kami telah mengajar para ilmuwan dan insinyur keterampilan pengembangan perangkat lunak dasar: kontrol versi, pengujian, cara memodulasi kode, dan sebagainya. Semua materi kami tersedia secara bebas di bawah lisensi Creative Commons, dan kami menjalankan beberapa lusin lokakarya dua hari gratis setiap tahun untuk membantu orang memulai.

Berdasarkan itu, saya pikir titik awal terbaik mungkin buku Robert Glass yang sangat baik (pendek) Fakta dan Kekeliruan Rekayasa Perangkat Lunak : pendekatan berbasis bukti adalah cara yang baik untuk meyakinkan para ilmuwan bahwa apa yang kami katakan kepada mereka tentang praktik pemrograman yang baik adalah lebih dari sekedar opini.
Adapun praktik tertentu, dua yang paling bersedia diadopsi orang adalah kontrol versi dan pengujian unit; begitu mereka ada di tempat, mereka dapat mengatasi jenis refactoring sistematis yang dijelaskan Michael Feathers dalam Bekerja Secara Efektif dengan Legacy Code .
Saya tidak lagi merekomendasikan The Pragmatic Programmer (banyak nasihat, sulit bagi pemula untuk dipraktikkan), dan saya pikir Kode McConnell Lengkap terlalu banyak untuk memulai (meskipun itu hal yang bagus untuk memberi mereka enam bulan atau satu tahun, setelah mereka menguasai dasar-dasarnya).

Saya juga akan sangat merekomendasikan makalah Paul Dubois yang sangat bagus "Menjaga Ketepatan dalam Program Ilmiah" ( Komputasi dalam Sains & Teknik , Mei-Juni 2005), yang menggambarkan pendekatan "pertahanan mendalam" yang menggabungkan selusin praktik berbeda dalam logika, koheren cara.

Saya pikir pertama-tama Anda harus membersihkan situasi Anda. Apa yang mereka inginkan dari Anda?

• Sangat tidak mungkin bahwa mereka ingin Anda mempelajari bahasa kuno, karena sekarang ini tampaknya jalan buntu: ada kesempatan yang menurun untuk menemukan siapa pun yang mengetahui atau ingin belajar G2, sehingga pengetahuan akan terkubur dalam tumpukan kode yang runtuh ketika para ilmuwan saat ini pergi atau kode all-patched gagal lebih dan lebih sering.
• Apakah para ilmuwan (atau beberapa dari mereka) siap untuk belajar bahasa baru dan banyak paradigma pemrograman? Atau apakah mereka ingin memisahkan pemrograman dan aktivitas ilmiah dalam jangka panjang, dan mungkin memiliki lebih banyak programmer jika diperlukan? Ini tampaknya pemisahan keahlian yang rasional dan lebih efisien.

Saya pikir persyaratan inti di sini adalah untuk "menyimpan pengetahuan dalam sistem", jadi Anda harus pergi dan menggali!

Tugas pertama adalah menulis dokumentasi.

Menganalisis struktur dan persyaratan seolah-olah ini akan menjadi tugas baru, tetapi dengan bantuan sistem yang ada. Mereka akan senang karena Anda BERTANYA alih-alih MENGAJAR terlebih dahulu - dan Anda akan segera mendapatkan cukup, tetapi pengetahuan latar belakang yang lebih terorganisir dari sudut pandang seorang programmer: "apa yang terjadi di sini?" Dokumen (struktur statis sistem, alur kerja, komponen, masalah) akan segera bernilai bagi mereka, dan mungkin akan menunjukkan informasi yang lebih relevan kepada mereka daripada kepada Anda (beberapa orang mungkin memiliki "AHA!" Dan mulai memperbaiki beberapa kode dengan segera ) ...

Anda kemudian harus mulai bertanya ke mana mereka ingin pergi?

Jika mereka siap untuk pindah dari G2, sistem apa yang ingin mereka lihat (platform, bahasa, antarmuka, struktur umum)? Anda mungkin mulai menulis pembungkus eksternal di sekitar sistem jika mungkin, memiliki struktur target, tetapi menjaga komponen asli, sehingga perlahan-lahan memulai semacam kerangka kerja yang memungkinkan komponen baru untuk diimplementasikan dalam lingkungan target ini. Anda harus menemukan layanan inti (koneksi data yang persisten dan "toolkit": perhitungan inti, menggambar, ... perpustakaan), dan karenanya Anda memberikan mereka lingkungan yang akrab dalam platform dan bahasa baru, yang memungkinkan transisi baik oleh Anda atau mereka: ambil kode lama satu per satu, laksanakan kembali (dan BERSIH!) di lingkungan baru. Ketika sudah siap, mereka tahu bahasa baru; dan lapisan layanan (kebanyakan dibuat oleh Anda, maaf) siap untuk meng-host komponen baru.

Jika mereka tidak bergerak , Anda harus mempelajari G2, dan membuat kerangka modular di sana, di mana Anda atau mereka harus memindahkan komponen (dengan pembersihan). Bagaimanapun, bahasa hanyalah sebuah serialisasi data dan algoritma pohon ...

Saat menganalisis dan menulis dokumen, membaca, menggunakan, dan mengiklankan pola Desain GoF! :-)

... 2 sen saya

Saya baru saja selesai melakukan serangkaian presentasi tentang prinsip-prinsip SOLID Robert Martin untuk rekan kerja saya. Saya tidak tahu seberapa baik prinsip-prinsip ini diterjemahkan ke G2, tetapi karena Anda mencari 5-7 inti dasar, ini sepertinya seperangkat yang mapan untuk memulai. Jika Anda ingin membulatkannya menjadi 7, Anda bisa mulai dengan KERING dan melempar ke Gagal-Cepat.

Satu-satunya masalah produksi terdengar seperti masalah manajemen perubahan. Jika itu yang terjadi dan perangkat lunak sebaliknya menjalankannya, saran pertama yang akan saya berikan adalah untuk menahan keinginan untuk melakukan terlalu banyak terlalu cepat.

Kontrol sumber, refactoring, dev yang lebih terlatih semuanya adalah saran yang bagus, tetapi jika ini adalah pertama kalinya Anda harus berurusan dengan masalah seperti ini bergerak perlahan dan membuat perubahan terkontrol tidak dapat cukup ditekankan.

Dorongan untuk merobek-robek kekacauan akan menjadi besar di kali, tetapi sampai Anda telah cukup direkayasa dari itu bahwa Anda tahu Anda dapat menguji versi pengganti Anda secara memadai, Anda harus sangat berhati-hati.

Prinsip paling penting untuk bekerja dalam situasi seperti itu adalah:

1. Sabar. Lubang yang membutuhkan waktu 20 tahun untuk menggali tidak akan terisi dalam beberapa minggu.

2. Menjadi positif. Tahan godaan untuk mengeluh dan menggerutu.

3. Bersikap pragmatis. Lihatlah perubahan positif yang dapat Anda capai dalam sehari, dan lakukan itu, hari ini. Sudah punya sistem kontrol versi? Terapkan dan latih orang. Kemudian lihat dan lihat apakah Anda dapat mengotomatisasi pengujian (Pengujian unit atau yang serupa). Bilasan. Ulangi.

4. Jadilah model. Perlihatkan (jangan hanya memberi tahu) orang bagaimana gesit bekerja dengan menjadi gesit. Tiga poin pertama di atas adalah kunci untuk menjadi Orang Baik, yang merupakan pendahulu untuk menjadi pria Agile yang efektif. Menurut saya, orang-orang yang merupakan pengembang yang mengagumkan tidak hanya pintar, mereka juga baik, karyawan teladan dan kolega.

5. Petakan wilayah Anda. Saya memiliki teknik untuk memetakan basis kode warisan raksasa. Saya mengkloning repo, membuat salinan yang berfungsi, dan kemudian saya mencoba mengubah sesuatu, dan melihat apa lagi yang rusak. Dengan menginvestigasi penggandengan (melalui keadaan global, atau API yang rusak, atau kurangnya API yang konsisten atau abstraksi atau antarmuka apa pun untuk diprogram melawan) dan dengan membaca kode yang rusak ketika saya mengubah sesuatu, saya menemukan celah, saya mengajukan pertanyaan yang mengarah ke wawasan dari anggota tim lainnya (Oh kami menambahkan itu karena Boss X 5 tahun yang lalu menuntut itu, itu tidak pernah berhasil!). Seiring waktu, Anda akan mendapatkan peta mental wilayah tersebut. Setelah Anda tahu seberapa besar itu, Anda akan cukup tahu untuk membuat peta dan pulang. Dorong orang lain untuk memetakan wilayah basis kode raksasa Anda, dan untuk membangun pengetahuan teknis tim. Beberapa orang menolak keras pada "dokumentasi" karena tidak lincah. Masa bodo. Saya bekerja di lingkungan ilmiah juga, dan dokumentasi adalah raja bagi saya, manifesto lincah terkutuk.

6. Buat aplikasi kecil. Ketika bekerja dengan basis kode warisan, saya menemukan saya mendapatkan tanah untuk bubur. Saya mendapatkan semangat saya kembali dengan membangun aplikasi pembantu kecil. Mungkin aplikasi itu akan membantu Anda membaca, dan memahami serta memodifikasi basis kode G2 raksasa itu. Mungkin Anda bisa membuat IDE mini atau alat parser yang akan membantu Anda bekerja di lingkungan Anda. Ada banyak kasus di mana Meta-programming dan Tool-building tidak hanya akan membantu Anda keluar dari kebuntuan raksasa yang diberlakukan oleh basis kode warisan pada Anda, mereka juga memberi otak Anda kemampuan untuk terbang tanpa dibatasi oleh bahasa G2 Anda. Tulis alat dan pembantu Anda dalam bahasa apa pun yang dapat Anda lakukan dengan tercepat dan terbaik. Bagi saya, bahasa itu termasuk Python, dan Delphi. Jika Anda seorang Perl, atau Anda sebenarnya suka pemrograman dalam C ++ atau C #, maka tulislah alat bantu Anda dalam bahasa itu.

1. Kontrol revisi : menunjukkan kepada para ahli domain manfaat untuk dapat kembali, melihat siapa yang mengubah apa, dll. (Ini lebih sulit dengan file semua-biner, tetapi jika isinya memang kode, pasti ada semacam G2-ke- konverter teks yang dapat mengaktifkan difs.)

2. Integrasi dan pengujian berkelanjutan : melibatkan pakar domain dalam membuat tes ujung ke ujung (lebih mudah, karena mereka harus sudah memiliki input dan output yang diharapkan di suatu tempat) dan tes unit kecil (lebih sulit, karena kode spaghetti mungkin melibatkan banyak variabel global) yang mencakup hampir semua fungsi dan kasus penggunaan.

3. Ubah kode umum menjadi rutinitas dan komponen yang dapat digunakan kembali. Orang-orang non-perangkat lunak tanpa kontrol revisi mungkin menyalin dan menempelkan 100 baris sekaligus untuk membuat rutinitas. Temukan dan lakukan refactor, yang menunjukkan bahwa semua tes lulus dan kode menjadi lebih pendek. Ini juga akan membantu Anda mempelajari arsitekturnya. Jika Anda beruntung pada saat Anda harus mulai membuat keputusan arsitektur yang sulit, Anda mungkin turun ke 100KLOC.

Secara politis , jika Anda menemukan perlawanan dari timer lama dalam proses ini, pekerjakan seorang konsultan untuk datang dan memberi ceramah tentang metodologi perangkat lunak yang baik. Pastikan Anda menemukan yang bagus yang pandangannya Anda setujui, dan dapatkan manajemen untuk membeli sesuai kebutuhan konsultan bahkan jika pakar domain tidak. (Mereka seharusnya setuju - setelah semua, mereka mempekerjakan Anda, jadi jelas mereka menyadari bahwa mereka membutuhkan keahlian rekayasa perangkat lunak.) Tentu saja, ini adalah trik membuang-buang uang, tetapi alasannya adalah jika Anda - programmer muda jagoan baru - memberi tahu mereka mereka perlu melakukan sesuatu, mereka mungkin mengabaikannya. Tetapi jika manajemen membayar seorang konsultan $ 5.000 untuk datang dan memberi tahu mereka apa yang harus mereka lakukan, mereka akan lebih meyakininya. Poin bonus: minta konsultan menyarankan perubahan dua kali lebih banyak dari yang Anda inginkan, maka Anda bisa menjadi "orang baik" dan berpihak pada pakar domain, berkompromi dengan hanya mengubah setengah sebanyak yang disarankan konsultan.

"Program itu sendiri adalah model fisik dari pabrik pemrosesan kimia yang kompleks ..."

"Karena G2 seperti bukan kode, melainkan kode otomatis yang ditulis oleh beberapa GUI gadawful ..." - Erik Reppen

Dengan asumsi tujuan utama perangkat lunak Anda adalah untuk mensimulasikan (mungkin mengoptimalkan, menjalankan estimasi parameter atas) pabrik kimia yang kompleks , atau bagian dari satu ... maka saya ingin membuang saran yang agak berbeda:

Anda mungkin sebaiknya mempertimbangkan untuk menggunakan bahasa pemodelan matematika tingkat tinggi untuk mengekstraksi esensi, model matematika inti, dari perangkat lunak kode tangan.

Apa yang dilakukan oleh bahasa pemodelan adalah memisahkan deskripsi masalah dari algoritma yang digunakan untuk menyelesaikan masalah. Algoritma ini umumnya berlaku untuk sebagian besar simulasi / optimisasi kelas tertentu (misalnya proses kimia) dalam hal ini mereka seharusnya tidak diciptakan kembali dan dipelihara sendiri.

Tiga paket komersial yang digunakan secara luas di industri Anda adalah: gPROMS, Aspen Custom Modeller, dan (jika model Anda tidak menyertakan fenomena yang didistribusikan di sepanjang domain spasial) ada paket perangkat lunak berbasis Modelica, seperti Dymola.

Semua paket ini mendukung "ekstensi" dengan satu atau lain cara, sehingga jika Anda memiliki bagian dari model Anda yang memerlukan pemrograman khusus, mereka dapat dienkapsulasi menjadi objek (mis. .DLL) yang dapat dirujuk oleh persamaan di dalam model. Sementara itu, sebagian besar model Anda tetap ringkas, dijelaskan dalam bentuk yang mudah dibaca oleh para ilmuwan secara langsung. Ini adalah cara yang jauh lebih baik untuk menangkap pengetahuan dan IP perusahaan Anda.

Sebagian besar dari program-program ini juga harus memungkinkan Anda untuk 'memulai kecil' dan memasukkan bagian-bagian kecil (sub-model) dari kode monolitik Anda ke dalam format mereka, dengan dipanggil secara eksternal. Ini mungkin cara yang baik untuk mempertahankan sistem kerja dan memvalidasinya satu per satu.

Penafian penuh: Saya bekerja sebagai insinyur perangkat lunak di perusahaan di belakang gPROMS selama 8 tahun. Pada waktu itu saya melihat (dan kadang-kadang dimasukkan) contoh-contoh perangkat lunak khusus (misalnya yang berasal dari akademisi) yang telah dimulai dari yang kecil dan rapi, menerapkan beberapa solusi atau algoritme pintar, tetapi kemudian meledak selama bertahun-tahun dengan ekstensi dan modifikasi - tanpa bimbingan dari seorang insinyur perangkat lunak agar tetap bersih. (Saya penggemar berat tim multi-disiplin.)

Jadi saya dapat mengatakan dengan beberapa pengalaman bahwa pilihan-pilihan kunci tertentu dibuat dengan buruk di awal pengembangan perangkat lunak (seperti perpustakaan bahasa atau kunci) cenderung bertahan dan menyebabkan rasa sakit untuk waktu yang lama ... Mereka sudah 'membentuk' perangkat lunak di sekitar mereka. Kedengarannya bagi saya seperti Anda mungkin menghadapi bertahun-tahun pembersihan kode murni di sini. (Saya ragu-ragu untuk menggunakan angka tetapi saya berpikir 10+ tahun orang, mungkin jauh lebih banyak jika Anda tidak bisa mendapatkan kode porting dari G2 ke sesuatu yang mendukung alat refactoring otomatis yang baik seperti Eclipse / Java cepat-pintar.)

Sementara status default saya adalah "refactor dan menjaga sistem kerja", saya juga berpikir begitu masalah menjadi "terlalu besar", maka perubahan / penulisan ulang yang lebih radikal secara keseluruhan menjadi lebih cepat. (Dan mungkin membawa manfaat tambahan, seperti melompat ke teknologi yang lebih modern.) Saya katakan bahwa dengan beberapa pengalaman porting ke platform perangkat lunak baru, tetapi dari apa yang saya kumpulkan itu bahkan lebih dramatis dengan port ke paket pemodelan matematika.

Untuk memberikan perspektif, Anda mungkin cukup kagum dengan pengurangan ukuran. Misalnya 200.000 LoC sebenarnya dapat diwakili dalam sesuatu seperti 5.000 baris persamaan (OK saya tebak di sini, tapi saya bisa mencoba dan memberi Anda kesaksian yang sebenarnya dari teman-teman dalam bisnis); ditambah beberapa modul fungsi yang relatif kecil yang ditulis dalam sesuatu seperti C (misalnya, perhitungan properti fisik - meskipun sekali lagi paket rak mungkin ada tergantung pada proses kimianya). Ini karena Anda benar-benar hanya membuang kode solusi algoritmik dan membiarkan 'tumpukan' tujuan umum pemecah matematika melakukan kerja keras. Setelah Anda menjalankan simulasi, Anda dapat melakukan lebih banyak dengan mereka, seperti mengoptimalkan proses - tanpa mengubah garis kode.

Akhirnya saya akan mengatakan: jika satu-satunya dokumentasi yang dapat diandalkan dari berbagai model matematika (dan algoritma) adalah kode itu sendiri, Anda akan membutuhkan bantuan para ilmuwan dan penulis asli untuk membantu mengekstraksi model-model itu, ASAP, bukan tahun ke jalur ketika beberapa dari mereka mungkin telah pindah. Mereka harus menemukan bahwa bahasa pemodelan matematika cara yang sangat alami untuk menangkap model-model itu - mereka bahkan dapat (shock horor) menikmati (kembali) menulisnya.

Akhirnya, karena jawaban saya mungkin melenceng, saya hanya ingin menambahkan satu buku lagi ke daftar buku bagus yang telah dirujuk di sini: Clean Code oleh Robert Martin. Penuh dengan tip sederhana (dan dibenarkan) yang mudah dipelajari dan diterapkan, tetapi yang dapat membuat dunia berbeda bagi orang-orang yang mengembangkan kode baru di perusahaan Anda.

Saya akan melempar yang berikut:

1. Ada satu programmer di sini. Politik kacau. Mereka tahu perdagangan mereka. Kamu tahu milikmu. Tandai wilayah itu bahkan jika Anda harus mengencinginya. Mereka adalah ilmuwan. Mereka dapat menghargai hal semacam itu atau harus karena mereka cukup banyak melakukan hal yang sama sendiri. Melalui apa pun yang Anda bisa, tandai batas sekarang. Ini yang akan saya perbaiki. Inilah yang saya tidak bisa bertanggung jawab.

2. Ilmuwan menulis / menguji algoritme. Ilmuwan yang ingin dapat menulis algoritme mereka sendiri dalam 1-3 bahasa yang dapat disetujui oleh setiap orang untuk Anda konversi menjadi kode inti. Itu menempatkan menguji barang-barang mereka pada mereka. Selain itu, mereka harus membantu Anda mengisolasi hal-hal sains yang penting vs. yang baik-tahu-tahu-apa yang mereka lakukan untuk arsitektur. Basis kode disemprot. Ada banyak tebasan dan bakar yang perlu dilakukan. Beri mereka opsi untuk memberi Anda versi yang berfungsi yang mempekerjakan apa yang paling mereka ketahui sehingga Anda bisa melakukan yang terbaik. Masukkan pengetahuan mereka ke dalam kotak yang menjadi tanggung jawab mereka tetapi Anda bisa bekerja dengannya.

3. Gunakan bahasa yang ramah terhadap kejadian dengan fungsi kelas satu jika Anda bisa. Ketika semuanya gagal, memicu suatu peristiwa atau melemparkan panggilan balik ke beberapa objek dengan antarmuka dan mekanisme keadaan yang benar-benar masuk akal bisa menjadi penghemat waktu yang sangat besar ketika Anda berlutut dalam kode yang tidak masuk akal berdarah dan sangat mungkin tidak pernah akan. Para ilmuwan tampaknya menyukai Python. Tidak sulit untuk menempelkan hal-hal C matematika intensif tingkat rendah dengan itu. Hanya bilang

4. Cari seseorang yang telah memecahkan masalah ini atau masalah serupa. Luangkan waktu untuk meneliti dengan serius. Orang-orang ini mendengar tentang G2 dari seseorang.

5. Pola desain. Adaptor Gunakan mereka Gunakan mereka dalam situasi seperti ini.

6. Pelajari apa yang Anda bisa tentang sains. Semakin banyak Anda tahu, semakin baik Anda dapat menentukan niat dalam kode.

Lakukan analisis terlebih dahulu.

Saya akan melakukan beberapa analisis sebelum memutuskan apa yang akan diajarkan. Cari tahu di mana titik nyeri terbesar berada. Gunakan itu untuk memprioritaskan praktik apa yang harus diatasi.

Perkenalkan hanya beberapa perubahan pada satu waktu (dalam situasi yang sama saya melakukan 2-3 latihan setiap 2 minggu) .

Saya akan membatasi praktik menjadi ~ 3 tergantung pada tingkat perubahan di sana gaya pemrograman SDLC; sampai mereka mulai merasa nyaman dengan mereka (saya akan mendorong untuk memperkenalkan 1 perubahan baru setiap ~ 1-2 minggu karena mereka menjadi lebih nyaman dengan ide belajar pendekatan baru). Ini juga merupakan ide yang baik untuk mengidentifikasi apa kriteria untuk sukses itu. Apa yang harus dicapai oleh latihan (bahkan jika itu adalah tujuan yang lembut seperti semangat tim). Dengan begitu Anda dapat menunjukkan apakah itu efektif atau tidak.

• Mengapa membatasi jumlah perubahan?

Bahkan jika Anda berasumsi orang-orang ini ingin menjadi programmer yang lebih baik dan terbuka untuk belajar, ada batasan seberapa banyak dan seberapa cepat orang dapat mempelajari konsep-konsep baru dan menerapkannya; terutama jika mereka tidak memiliki dasar CS atau telah berpartisipasi dalam Siklus Hidup Pengembangan Perangkat Lunak sebelumnya.

Tambahkan rapat penutup mingguan untuk membahas bagaimana praktik tersebut memengaruhi mereka.

Pertemuan harus digunakan untuk membahas apa yang berjalan dengan baik dan apa yang perlu dikerjakan. Biarkan mereka memiliki suara dan berkolaborasi. Diskusikan dan buat rencana untuk mengatasi masalah yang mereka hadapi dan untuk melihat perubahan berikutnya yang akan datang. Jaga agar pertemuan tetap fokus pada praktik dan penerapannya. Lakukan sedikit penginjilan tentang manfaat yang harus mereka mulai dari menerapkan praktik-praktik itu.

Praktek-praktek tertentu didahulukan.

Penggunaan sistem kontrol versi (IMO) dengan benar mengalahkan yang lainnya. Di belakangnya ada pelajaran dalam modularisasi, penggandaan / kohesi, dan pelacakan tiket fitur / bug.

Hapus praktik yang tidak berhasil.

Jangan takut untuk menyingkirkan praktik yang tidak berhasil. Jika ada biaya tinggi dan sedikit atau tidak ada manfaatnya, hapus praktik tersebut.

Perbaikan adalah suatu proses.

Sampaikan bahwa perbaikan yang berkelanjutan dan konsisten adalah suatu proses. Identifikasi poin rasa sakit terbesar, terapkan solusi, tunggu / pelatih dan kemudian ulangi. Awalnya akan terasa sangat lambat sampai Anda membangun momentum. Usahakan semua orang fokus pada perbaikan yang akan datang dan perbaikan yang sudah berhasil.

Kedengarannya seperti langkah pertama yang Anda miliki adalah menjual kepada tim kebutuhan untuk berinvestasi dalam metodologi perangkat lunak baru. Per pernyataan Anda, tidak ada konsensus di tim, dan Anda akan membutuhkannya untuk dapat membajak dengan "peningkatan" kode yang lambat.

Saya akan (jika saya bisa) secara pribadi mengambil pelajaran yang sulit dipelajari, dan memperkenalkan masing-masing konsep kunci yang Anda ingin sebagai solusi untuk masalah di industri perangkat lunak.

Misalnya, dua pengembang memiliki salinan berbeda dan akhirnya menyebarkan rilis hibrida yang belum diuji -> Memperkenalkan kontrol, percabangan, dan pengujian versi.

Seseorang menghapus beberapa baris kode yang tidak mereka mengerti dan menyebabkan pemadaman -> perkenalkan DDD.

Jika pelajaran sulit tidak dibagikan dengan Anda dalam detail yang cukup, maka cukup tunjukkan contoh Anda sendiri tentang bagaimana hal-hal buruk terjadi ketika disiplin ini tidak dipatuhi.

Kontrol kode sumber adalah langkah # 1 sebagaimana telah dinyatakan berulang kali. Sementara orang yang bekerja dengan Anda mungkin bukan pengembang profesional dan mereka tidak akan menanggapi banyak perusahaan atau omong kosong. Mereka juga bukan monyet kode tingkat rendah dan mencoba memperlakukan mereka seperti itu dengan memaksa mereka melakukan hal-hal 'dengan cara Anda' tidak akan terbang.

Anda harus mensurvei apa yang ada di luar sana. Jika mereka belum pernah menggunakan kontrol kode sumber, maka hanya mengidentifikasi versi kode yang tepat (jika mungkin) dan apa yang mungkin disampaikan akan memakan waktu lama. Kemudian Anda akan memiliki tugas untuk mengajar kolega Anda bagaimana menggunakan kontrol kode sumber dan meyakinkan mereka bahwa ini sepadan dengan waktu mereka. Mulailah dengan manfaatnya!

Saat Anda melakukan itu, cari buah lain yang tergantung rendah dan selesaikan masalah itu.

Yang terpenting, dengarkan apa yang mereka katakan dan kerjakan untuk memperbaiki situasi mereka. Jangan khawatir tentang mencoba memberi cap pada apa yang mereka lakukan.

Semoga berhasil!