Di bidang pengembangan perangkat lunak, sering kali ada tesis seperti "
Tidak ada yang peduli dengan kode Anda " (terjemahan - "
Kode Anda tidak menarik bagi siapa pun "), "Kode hanyalah alat" dan situasi kesalahpahaman total pada bagian bisnis mengapa kita harus meluangkan waktu dan uang untuk semacam "refactoring" dari kode yang sudah berfungsi.
Saya ingin memberi tahu Anda apa yang “mengarah pada karakteristik” dapat mengarah pada, alih-alih memperhatikan kualitas kode, dan mengapa tidak hanya pemrogram yang membutuhkan kode yang baik.
Dukungan
Tesis utama, yang tanpanya artikel saat ini, pada prinsipnya, tidak akan berarti:
Apa yang telah terjadi di dunia pemrograman selama beberapa dekade, untuk itu bahasa yang lebih maju, paradigma, pendekatan dibuat, untuk mana mereka membedakan berbagai template dan mengurus desain kode, pada kenyataannya, dua hal - Meningkatkan kecepatan pengembangan dan memfasilitasi dukungan dari basis kode (yang pada dasarnya kecepatan pengembangan fungsionalitas baru).
Dan inilah yang dibutuhkan bisnis.
Anda dapat, tentu saja, berpendapat bahwa mereka sendiri membutuhkan metodologi yang meningkatkan efisiensi tenaga kerja programmer untuk menjual pekerjaan mereka lebih mahal, mampu melakukan lebih banyak per unit waktu, tetapi karena situasi ketika programmer memesan proyek selesai besar segera tanpa perlu dukungan lebih lanjut sangat Jarang, dan biasanya fungsinya dipesan secara bertahap, pada awal proyek Anda tidak akan merasakan efek buruk dari desain yang buruk, itu lebih merupakan investasi di masa depan.
Ada gambar dari
blog Martin Fowler tentang hal ini, yang menunjukkan kecepatan memperkenalkan fungsionalitas baru ke dalam proyek tergantung pada waktu keberadaannya (yaitu seberapa besar itu).
Sumbu horizontal adalah masa proyek, sumbu vertikal adalah fungsi agregat.
Garis merah menggambarkan kecepatan pengembangan proyek dengan desain yang baik, dan garis biru menggambarkan proyek yang ditulis tanpa batasan dalam bentuk persyaratan untuk kualitas kode.
Dengan demikian, jika Anda berpikir bahwa aplikasi Anda akan gagal dan tidak akan berkembang, atau sedang mempersiapkan secara eksklusif untuk beberapa acara mendatang, Anda tidak perlu memikirkan desain sistem. Dalam situasi yang berlawanan, desain yang baik kemungkinan besar akan menghasilkan, dan membayar berkali-kali.
Kadang-kadang Anda dapat mendengar pendapat bahwa pada awal proyek Anda tidak perlu memikirkan kualitas kode dan menulis ulang lagi setelah presentasi yang sukses kepada klien / investor, tetapi dalam sebagian besar kasus ini adalah kesalahan memulai proyek, dan cara termudah untuk mendapatkan
utang teknis selama bertahun-tahun yang akan datang.
Kode bukan alat, kode adalah produk akhir
Perusahaan perangkat lunak tidak menggunakan kode sebagai alat. Ini adalah produk utama perusahaan, itu adalah kode akhir dari program yang menentukan kualitas, kecepatan, kepatuhan dengan persyaratan fungsionalitasnya. Itu tidak bisa begitu saja diambil dan sepenuhnya diganti tanpa menimbulkan kerugian sementara dan material, seperti yang dapat dilakukan dengan Komputer / IDE / Pengembangan Metodologi, yang pada dasarnya sudah akan menjadi alat untuk menciptakan produk.
Tentang "Fokus pada kinerja"Dalam artikel yang saya referensikan, pemikiran berikut ini disuarakan: Anda perlu berkomunikasi dengan pelanggan / Manajer Proyek pada tingkat kesiapan proyek, dan contoh berikut adalah sebaliknya:
Bayangkan bahwa perancang akan mulai memberi tahu Anda tentang lapisan yang ia gunakan di Photoshop, tentang berapa banyak objek yang ia miliki di sana, gradien apa yang digunakan pada kuas mana, dan skrip animasi keren apa yang ia tulis. Itu tidak menarik bagi Anda. Apakah Anda tertarik untuk memotret?
Jadi disini. Ada satu perbedaan karena itu
tidak dapat dengan mudah diproyeksikan ke situasi dengan dukungan produk perangkat lunak - semua lapisan dan kuas di Photoshop menjadi tidak berguna bagi siapa pun setelah hasil kerja (gambar), dan sama saja adalah alat untuk mencapai hasil , bukan produk akhir.
Jadi, ketika menyusun persyaratan untuk gambar akhir, pelanggan tidak bisa khawatir tentang apa yang akan digunakan dalam proses. Dalam hal perangkat lunak, jika pelanggan (bisnis) hanya akan menuntut fungsionalitas dari aplikasi, ia berisiko mendapatkan apa yang diinginkannya - fungsionalitas baru, tetapi tidak ada pertanyaan bahwa itu perlu dipertahankan dan dikembangkan.
Sayangnya, ini adalah masalah yang cukup umum pada outsourcing, ketika perusahaan hanya menjual waktu pengembangnya, dan pelanggan tidak dapat secara obyektif mengevaluasi kualitas sistem, dan waktu yang diperlukan untuk menyelesaikan masalahnya. Ketika biaya mengubah kode meningkat secara eksponensial, itu hanya akan menguntungkan perusahaan itu sendiri kepada agen outsourcing - lebih banyak waktu manusia dapat dimonetisasi, dan perusahaan yang memesan produk sudah siap - sudah terlambat untuk menulis ulang sistem rumit dan tidak nyaman, karena memerlukan investasi besar dan menghentikan pengiriman fungsi baru itu tidak bisa diizinkan.
Kode - tempat kerja programmer
Sepanjang waktu artikel itu dalam konsep salinan, saya banyak berpikir apakah item ini harus dimasukkan di dalamnya, tetapi setelah sedikit mengamati prioritas calon yang mencari pekerjaan, saya menyadari bahwa momen ini sangat penting.
Kode adalah sesuatu yang harus dikerjakan oleh seorang programmer setiap hari, produk kreatifnya, apa yang ia ciptakan, tetapi ia ciptakan bukan hanya satu, tetapi dalam sebuah tim, dan sering kali bukan dari awal. Dia perlu menerima bagian proyek yang sudah ada, mengembangkannya berdasarkan fungsionalitas yang ditulis sebelumnya. Seorang karyawan kemungkinan besar akan tidak senang bekerja di suatu produk yang diciptakan dengan buruk.
Pertama-tama, menurut pendapat saya, adalah tim yang bekerja bersama dalam proyek ini. Kualitas produk yang dihasilkan secara langsung tergantung pada bagaimana kerja tim dibangun, pada aturan internal dan persyaratan yang ditetapkan di dalamnya.
Di tempat kedua adalah teknologi. Kerangka kerja tidak nyaman yang dipilih atau diwariskan, alat-alat usang dan berkualitas rendah, perpustakaan dipaku ke tempat proyek dengan semua kruk dan bug yang harus Anda pakai, dan kurangnya orang dengan kompetensi yang cukup dan waktu untuk menghilangkan pendekatan warisan dapat dengan mudah menakuti potensi baru pekerja. Selain alasan yang disebutkan di atas, ini juga merupakan jumlah yang lebih kecil dari prospek dan peluang untuk pengembangan programer, karena alih-alih mempelajari alat-alat modern dan paling efektif, perlu untuk mengembangkan alat peraga untuk mengadaptasi solusi untuk tugas saat ini yang telah diterima karena alasan historis.
Kenapa ini semua
Sayangnya, persyaratan untuk aplikasi nyata jarang dapat dibentuk pada 100%, dan tidak memerlukan revisi selama pengembangan. Selain itu, situasinya hampir mustahil ketika proyek tidak harus disesuaikan dengan persyaratan baru setelah diluncurkan. Bisnis berkembang, berkembang, membutuhkan fungsionalitas yang tidak dibahas sebelumnya, memasuki pasar baru.
Hampir mustahil untuk membangun arsitektur yang ideal dan dipikirkan dengan sangat rinci dalam kondisi seperti itu, dan, seringkali, tidak perlu, karena biayanya dalam hal ini terlalu tinggi untuk tahap awal proyek.
Tentu saja, menulis kode yang baik tidak boleh menjadi sakit kepala bagi mereka yang memesan perangkat lunak dari programmer, dan tidak mungkin siapa pun yang tidak dapat menulisnya dapat memeriksanya.
Namun demikian, perusahaan yang mengembangkan produk perangkat lunak, jika ingin membuatnya secara kualitatif, harus memahami bahwa bagian yang signifikan dari produk sebagai kode sumbernya secara langsung mempengaruhi keberhasilannya, dan hal-hal seperti refactoring kode sumber dan memodifikasi arsitektur dengan persyaratan baru juga harus menjadi anggaran, waktu harus dialokasikan untuk programmer. Jika seseorang tertarik dengan kualitas produk, tentu saja.
Namun, industri TI sedang berkembang, produk, perusahaan, alat berkembang, pengguna menjadi lebih selektif, persaingan meningkat, dan ada harapan bahwa masa depan akan tetap dengan produk-produk berkualitas tinggi.
Kesimpulan
Padahal, topik artikel itu, tentu saja, sangat kontroversial.
Grafik di atas tidak menjawab pertanyaan kapan desain sistem mulai membuahkan hasil.
Utang teknis untuk itu dan utang, yang memungkinkan Anda untuk mendapatkan sedikit lebih banyak waktu sekarang dan mengembalikannya dengan bunga nanti, dan masalah utamanya sangat sederhana, dan sangat mirip dengan fenomena serupa dalam perekonomian, adalah ketidakmampuan untuk melunasi utang dan ketidakmampuan untuk secara akurat memperkirakan pendapatan masa depan.
Kualitas kode juga merupakan hal yang sangat subyektif, dan, sayangnya, secara praktis tidak diformalkan, jika tidak programmer dapat digantikan oleh robot.
Bagaimanapun, hal yang paling penting adalah mencapai kompromi yang kompeten dan menemukan jalan tengah, yang akan memungkinkan kita untuk tidak menenggelamkan proyek dalam jurang utang teknis dalam mengejar fungsionalitas, dan tidak menyerah pada ceruk yang menarik bagi pesaing, melakukan desain sistem alih-alih fungsionalitas.