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 README
untuk menunjuk spesifik proyek, dan dengan anggun memandu pengguna / pengembang / peneliti, jika ada.
Ini juga sangat memudahkan bagian lain dari infrastruktur pembangunan Anda, yaitu:
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:
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 gofmt
alatnya, yang sepenuhnya menghilangkan segala perdebatan dan upaya ( dan ego !! ) yang melekat pada gaya: lari gofmt
sebelum 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 Git
ini dengan benar, dan mencoba memaksa Anda untuk menulis log yang bagus lebih dari kebanyakan sistem SCM lainnya, dengan menggunakan short logs
dan
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:
Analisis kode Anda dengan pemeriksa kualitas kode.
Linter, analisa statis, atau apa yang Anda miliki.
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.
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).
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.
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!