Seringkali dalam proses implementasi proyek, tim dihadapkan dengan pertanyaan: apa yang harus lebih diperhatikan - pelepasan fitur baru atau peningkatan kualitas kode? Biasanya, manajer memilih fitur. Seringkali, pengembang tidak senang dengan keadaan ini, percaya bahwa mereka tidak punya cukup waktu untuk bekerja pada arsitektur dan kualitas kode.
Hukum Betterridge mengatakan: "
Judul apa pun yang berakhir dengan tanda tanya dapat dijawab dengan kata tidak." Mereka yang mengenal saya secara pribadi tahu bahwa saya tidak membagikan pemikiran ini. Tetapi dalam artikel ini saya ingin melangkah lebih jauh dan membuktikan bahwa mengajukan pertanyaan dari judul artikel ini sama sekali tidak masuk akal. Perumusan pertanyaan semacam itu menunjukkan bahwa ada trade-off antara biaya dan kualitas. Dan Anda harus terus menjaga keseimbangan. Dalam artikel ini, saya akan membuktikan bahwa kompromi ini tidak berlaku untuk dunia pengembangan sistem komputer dan, pada kenyataannya, menciptakan perangkat lunak berkualitas tinggi pada akhirnya lebih murah.
Terlepas dari kenyataan bahwa audiens target utama dari artikel ini adalah pengembang, itu tidak memerlukan pengetahuan khusus untuk memahaminya. Saya ingin artikel ini bermanfaat bagi semua orang yang entah bagaimana terhubung dengan proses pengembangan, dan terutama kepada manajer yang membentuk vektor pengembangan produk.
Kami terbiasa memilih antara harga dan kualitas.
Seperti yang saya tulis sebelumnya, ketika mengembangkan perangkat lunak, Anda harus selalu membuat pilihan antara kualitas produk dan biaya pengembangannya. Ketika Anda membeli smartphone baru, Anda punya pilihan. Bayar lebih banyak uang dan dapatkan prosesor yang lebih cepat, lebih banyak memori dan layar yang lebih baik, atau bayar lebih sedikit, tetapi mengorbankan beberapa fitur. Ada pengecualian untuk aturan ini: terkadang produk dengan kualitas lebih tinggi lebih murah. Dan kadang-kadang orang bahkan tidak dapat membandingkan secara objektif dua produk dan memilih yang lebih baik. Misalnya, mereka tidak melihat perbedaan antara layar yang dibuat menggunakan teknologi yang sama sekali berbeda. Namun, pernyataan "Biaya kualitas tinggi lebih banyak" biasanya benar.
Kualitas perangkat lunak sangat banyak.
Berbicara tentang kualitas perangkat lunak, Anda harus mulai dengan menentukan kriteria kualitas. Apa itu perangkat lunak berkualitas? Mulai saat ini, segala sesuatunya menjadi sedikit rumit, karena setiap sistem komputer memiliki banyak kriteria yang dapat dievaluasi kualitasnya. Anda dapat mengevaluasi UI dan UX: seberapa cepat dan sederhana pengguna dapat menyelesaikan masalahnya? Keandalan dapat dinilai: apakah ada bug dalam program yang mengarah pada perilaku yang salah dan tidak stabil? Kriteria lain adalah arsitektur: seberapa terstruktur kode sumber program, seberapa sederhana dan cepat programmer dapat menemukan potongan kode yang dia butuhkan saat ini?
Daftar kriteria kualitas di atas, tentu saja, tidak lengkap. Tetapi kriteria ini cukup untuk menunjukkan satu hal penting. Beberapa kriteria di mana kualitas suatu program biasanya dievaluasi bahkan tidak terlihat oleh pengguna akhir. Pelanggan dapat memberikan umpan balik dan mengatakan seberapa baik perangkat lunak memecahkan masalah bisnis mereka. Pengguna dapat mengeluh tentang antarmuka yang tidak nyaman. Atau mereka akan mengeluh tentang bug, terutama jika menyebabkan hilangnya data atau tidak tersedianya sistem yang berkepanjangan. Tetapi pengguna tidak dapat menghargai arsitektur dan kualitas kode.
Oleh karena itu, saya membagi kriteria kualitas ke dalam dua kategori:
eksternal (misalnya, UI / UX atau keberadaan bug) dan
internal (arsitektur). Perbedaan mereka yang paling penting adalah bahwa pengguna dapat mengevaluasi kualitas eksternal, tetapi mereka tidak dapat memahami seberapa baik (atau buruk) arsitektur internal sistem.
Sekilas, kualitas internal tidak penting bagi pengguna (tetapi hanya pada awalnya)
Jika pengguna tidak dapat mengevaluasi kualitas internal perangkat lunak, apakah kriteria ini penting? Mari kita bayangkan situasi hipotetis bahwa dua tim pengembang, secara independen satu sama lain, memutuskan untuk membuat aplikasi untuk melacak dan memperkirakan penundaan penerbangan. Saya mengelola satu tim, dan Rebecca memimpin yang kedua. Himpunan fungsi dasar untuk aplikasi kurang lebih sama, antarmuka untuk kedua aplikasi juga ternyata cukup nyaman dan dipikirkan, tidak ada bug penting dalam aplikasi. Satu-satunya perbedaan adalah bahwa kode sumber aplikasi dari Rebecca jelas terstruktur dan terorganisir, dan kode yang dibuat oleh tim saya adalah sekumpulan kelas dan metode yang berantakan dengan nama-nama yang tidak jelas dan logika yang lebih tidak jelas tentang bagaimana kode ini saling berhubungan. Ada perbedaan lain: saya menjual aplikasi saya seharga $ 6, dan Rebecca menjual aplikasi yang hampir sama dengan $ 10.
Karena kode sumber aplikasi tidak dapat diakses oleh pengguna, dan kualitas kode tidak memengaruhi pengalaman pengguna, mengapa pengguna harus membayar tambahan $ 4? Dengan kata lain - mengapa membayar lebih untuk kualitas internal, yang tidak masalah bagi pengguna?
Jika Anda mengembangkan ide ini lebih jauh, Anda bisa sampai pada kesimpulan bahwa berinvestasi dalam kualitas eksternal lebih menguntungkan daripada internal. Membuat pilihan antara dua aplikasi, pengguna dapat memilih salah satu yang lebih mahal jika ia memiliki antarmuka yang lebih baik dan lebih nyaman. Tetapi pengguna tidak melihat struktur internal aplikasi, belum lagi fakta bahwa pengguna dapat membandingkan arsitektur kedua aplikasi. Jadi mengapa membayar lebih untuk sesuatu yang tidak membawa manfaat praktis? Dan mengapa pengembang harus menghabiskan waktu dan sumber daya untuk meningkatkan kualitas internal program mereka?
Program dengan kualitas internal yang tinggi lebih mudah dikembangkan
Mengapa sangat penting bagi programmer untuk memiliki kode kualitas? Pemrogram menghabiskan sebagian besar waktu mereka membaca dan mengeditnya. Bahkan ketika mengembangkan sistem baru, pekerjaan hampir selalu dilakukan dalam konteks kode yang sudah ditulis. Ketika seorang programmer menambahkan fitur baru, pertama-tama ia harus mencari tahu bagaimana fitur ini cocok dengan arsitektur aplikasi yang ada. Maka sering kali Anda perlu membuat perubahan pada arsitektur sehingga fitur baru dapat diimplementasikan. Seringkali Anda perlu menggunakan struktur data yang sudah ada dalam sistem. Oleh karena itu, Anda perlu memahami bahwa struktur data ini berarti hubungan seperti apa yang ada di antara mereka dan struktur data baru apa yang perlu ditambahkan untuk mengimplementasikan fitur.
Kode berkualitas tinggi memungkinkan pemrogram untuk menavigasi dengan cepat. Mencapai situasi di mana kode menjadi sulit dipahami sebenarnya sangat sederhana. Kondisi logis dapat terjalin, hubungan antara struktur data bisa rumit dan implisit. Nama-nama yang diberikan Tony untuk variabel dan fungsi 6 bulan lalu mungkin sudah jelas baginya, tetapi juga tidak dapat dipahami oleh pengembang baru, serta motif yang mendorong Tony untuk meninggalkan perusahaan. Pengembang biasanya menyebut ini
"utang teknis" (
utang teknis ), atau dengan kata lain, perbedaan antara status kode saat ini dan status ideal di mana ia bisa.
Salah satu keuntungan utama yang diberikan oleh kode berkualitas tinggi adalah bahwa pemrogram dapat dengan cepat memahami cara kerja sistem dan membuat perubahan yang diperlukan. Ketika aplikasi dibagi menjadi beberapa modul, programmer tidak perlu mempelajari semua 500.000 baris kode sumber dan dia dapat dengan cepat menemukan ratusan baris yang dia butuhkan saat ini. Ketika pemrogram memberikan nama yang bermakna untuk variabel, fungsi, dan kelas, Anda dapat dengan mudah memahami apa yang dilakukan masing-masing bagian kode tanpa harus mempelajari lebih dalam konteksnya. Jika struktur data dalam program bertepatan dengan terminologi dari domain domain bisnis, maka mudah bagi programmer untuk menghubungkan permintaan fungsionalitas baru dengan cara kerja sistem. Utang teknis juga meningkatkan waktu yang diperlukan untuk bekerja dengan kode. Kemungkinan melakukan kesalahan juga meningkat. Dalam hal bug karena kualitas kode yang buruk, waktu tambahan akan diperlukan untuk melokalisasi masalah dan memperbaikinya. Dan jika bug tidak segera diketahui, maka ini akan menyebabkan masalah dalam kode produksi dan fakta bahwa Anda harus menghabiskan lebih banyak waktu memperbaiki masalah ini di masa depan.
Setiap perubahan dalam kode memengaruhi masa depan produk. Seringkali ada situasi di mana ada cara sederhana dan cepat untuk mengimplementasikan fitur baru, tetapi dengan biaya melanggar arsitektur saat ini (yaitu karena peningkatan utang teknis). Jika seorang programmer memilih jalur ini, ia melepaskan fitur lebih cepat, tetapi memperlambat pekerjaan pengembang lain yang harus mendukung kode ini nanti. Jika semua orang di tim melakukan ini, maka bahkan aplikasi yang dirancang dengan baik dengan kode yang baik akan dengan cepat tumbuh menjadi hutang teknis, dan bahkan beberapa perubahan akan memakan waktu beberapa minggu.
Pengguna ingin mendapatkan fitur baru secepat mungkin.
Kami sedang mendekati titik penting, yaitu: untuk menjawab pertanyaan, mengapa kualitas perangkat lunak internal masih penting bagi pengguna? Kualitas internal yang tinggi mendorong pelepasan fitur baru yang lebih cepat, karena lebih mudah, lebih cepat, dan lebih murah untuk dilakukan. Aplikasi saya dengan Rebecca sekarang terlihat hampir sama, tetapi setelah beberapa bulan kode kualitas tinggi Rebecca akan memungkinkan dia untuk merilis fitur baru setiap minggu, dan saya akan terjebak di tempat, mencoba untuk mengatasi hutang teknis dan mencoba untuk meluncurkan setidaknya satu fitur baru. Saya tidak akan dapat bersaing dengan Rebecca dalam kecepatan pengembangan, dan aplikasinya akan dengan cepat mengambil alih fungsi saya. Pada akhirnya, pengguna akan menghapus aplikasi saya dan menggunakan aplikasi Rebecca, meskipun biayanya lebih mahal.
Visualisasi pengaruh kualitas internal
Keuntungan utama dari kualitas internal yang tinggi dari program ini adalah pengurangan biaya perubahan di masa depan. Tetapi menulis kode berkualitas tinggi membutuhkan lebih banyak upaya, dan ini meningkatkan sumber daya yang diperlukan dalam jangka pendek.
Grafik di bawah ini secara skematis menunjukkan bagaimana Anda dapat membayangkan rasio fungsionalitas dan waktu yang dibutuhkan untuk mengembangkannya. Biasanya, kurva terlihat seperti ini:
Beginilah proses pengembangan terlihat ketika kode tidak terlalu berkualitas tinggi. Pada awalnya, pengembangan cukup cepat, tetapi kemudian semakin banyak waktu diperlukan untuk lebih memperluas fungsionalitas. Pada titik waktu tertentu, untuk membuat perubahan kecil, programmer harus terlebih dahulu mempelajari banyak kode yang rumit dan membingungkan. Setelah perubahan dibuat, ditemukan bahwa ada sesuatu yang rusak, dan ini mengarah pada tambahan waktu yang dihabiskan untuk menguji dan memperbaiki kesalahan.
Kualitas internal yang tinggi berkontribusi pada efisiensi pengembangan pada tahap selanjutnya. Beberapa tim bahkan berhasil mendapatkan efek sebaliknya, ketika setiap fitur baru dirilis lebih cepat dari yang sebelumnya karena fakta bahwa adalah mungkin untuk menggunakan kembali kode yang sudah ditulis. Tetapi ini jarang terjadi, karena ini membutuhkan tim yang sangat profesional dengan organisasi kerja yang baik. Namun terkadang ini masih terjadi.
Namun, ada satu trik. Pada tahap awal pengembangan, mengabaikan kualitas kode lebih efektif daripada mengikuti standar tinggi. Tetapi kapan periode ini berakhir?
Untuk menjawab pertanyaan ini, Anda harus terlebih dahulu mengklarifikasi bahwa gambar tersebut mewakili
pseudografi . Tidak ada satu cara sejati untuk mengevaluasi kinerja tim. Tidak mudah untuk memahami bagaimana kode buruk mempengaruhi kualitas akhir produk (dan jika korelasi ini ada, seberapa jelasnya). Omong-omong, masalah ini relevan tidak hanya untuk industri TI. Bagaimana, misalnya, untuk mengevaluasi kualitas pekerjaan seorang pengacara atau dokter?
Tetapi kembali ke pertanyaan, pada titik apa layak mulai memikirkan tentang kualitas kode. Pengembang yang berpengalaman percaya bahwa kualitas kode yang buruk mulai melambat dalam beberapa minggu setelah dimulainya proyek. Pada tahap awal proyek, keindahan arsitektur dan kode dapat diabaikan.
Juga, dari pengalaman saya sendiri, saya dapat mengatakan bahwa bahkan proyek kecil mendapatkan keunggulan kompetitif yang serius jika mereka menggunakan praktik pembangunan modern dan efektif dalam pekerjaan mereka dan berpikir tentang kualitas kode.
Bahkan tim terbaik pun terkadang menulis kode buruk
Mereka yang baru dalam proses pengembangan percaya bahwa kode buruk menunjukkan bahwa tim tidak bekerja dengan baik. Tetapi, seperti yang ditunjukkan oleh latihan, bahkan tim yang paling berpengalaman pun terkadang membuat kesalahan dan menulis kode yang buruk.
Untuk menunjukkan ini dengan jelas, saya ingin memberi tahu Anda tentang percakapan dengan salah satu pemimpin tim terbaik kami. Pada saat itu, dia baru saja menyelesaikan proyek yang dianggap sangat sukses oleh semua orang. Pelanggan senang dengan sistem baru, baik dari fitur-fitur baru dan dari sumber daya yang dihabiskan untuk pengembangannya. Tim juga senang dengan proyek yang selesai. Pemimpin teknis tim juga sangat senang dengan hasilnya, tetapi mengakui bahwa sebenarnya arsitektur sistem tidak begitu berhasil. Saya bertanya kepadanya, "Tapi bagaimana mungkin Anda adalah salah satu arsitek terbaik kami?" Dia menjawab seperti halnya arsitek berpengalaman mana pun akan menjawab: "Kami membuat keputusan yang baik, tetapi hanya sekarang kami mengerti bagaimana melakukannya dengan benar."
Banyak orang membandingkan penciptaan sistem yang kompleks dengan desain gedung pencakar langit. Rupanya, oleh karena itu, pengembang berpengalaman disebut "arsitek." Tetapi dalam proses pembuatan perangkat lunak, selalu ada beberapa ketidakpastian, tidak seperti karakteristik dari area aktivitas lainnya, di mana ketidakpastian jauh lebih sedikit. Pelanggan tipikal memiliki pemahaman yang buruk tentang apa yang mereka inginkan dari program dan mulai memahami ini hanya dalam proses mengerjakannya. Paling sering, pada saat itu ketika mereka ditampilkan versi pertama dari program. Elemen-elemen dari mana program dibuat (bahasa pemrograman, perpustakaan, platform) berubah setiap beberapa tahun. Menggambar analogi dengan konstruksi gedung pencakar langit, dapatkah Anda membayangkan situasi di mana pelanggan meminta arsitek untuk menambahkan selusin lantai lagi dan mengubah tata letak lantai yang lebih rendah, meskipun faktanya separuh bangunan sudah dibangun? Situasi menjadi lebih rumit ketika ternyata teknologi yang digunakan untuk produksi beton, sifat fisik dan karakteristiknya diperbarui setiap 2 tahun.
Dalam menghadapi tantangan baru yang terus-menerus, pertumbuhan jumlah dan kompleksitasnya, tim harus terus-menerus menghasilkan sesuatu yang baru. Semakin, perlu untuk memecahkan masalah yang belum pernah ada yang dipecahkan sebelumnya, dan karenanya tidak ada solusi yang terkenal dan terbukti untuk mereka. Biasanya pemahaman yang jelas tentang masalah datang hanya pada saat solusinya, jadi saya sering mendengar pendapat bahwa memahami seperti apa arsitektur sistem yang kompleks harus muncul setidaknya satu tahun setelah dimulainya pekerjaan. Dan bahkan tim pengembangan paling profesional di dunia tidak akan dapat membuat sistemnya sempurna.
Tim yang profesional dan terorganisir berbeda dengan yang kurang terorganisir dalam proses mengerjakan sistem itu menciptakan lebih sedikit hutang teknis dan juga menyingkirkan yang sudah ada. Ini membantu proyek untuk mengembangkan dengan cepat dan merilis fitur-fitur baru secepat mungkin. Tim semacam itu berinvestasi dalam pembuatan tes otomatis, yang membantu mengidentifikasi masalah lebih cepat dan menghabiskan lebih sedikit waktu untuk menemukan dan memperbaiki bug. Anggota tim semacam itu terus-menerus bekerja untuk mempertahankan kode berkualitas tinggi dan dengan cepat menyingkirkan kode buruk hingga mulai mengganggu kemajuan. Sistem CI juga berkontribusi terhadap hal ini, terutama dalam situasi di mana banyak orang secara bersamaan mengerjakan tugas yang berbeda. Sebagai metafora, Anda bisa membawa dapur setelah memasak. Tidak mungkin memasak sesuatu tanpa mengotori meja, piring, dan peralatan dapur lainnya. Jika Anda tidak segera membersihkannya, kotoran akan mengering dan itu akan jauh lebih sulit untuk mencucinya. Dan lain kali Anda ingin memasak sesuatu, itu akan jauh lebih sulit bagi Anda untuk melakukan ini karena pertama-tama Anda harus mencuci gunung piring.
Penelitian dan Penilaian DevOps (DORA)
Pertukaran antara biaya dan kualitas bukan satu-satunya di dunia pengembangan perangkat lunak yang tampak sederhana pada pandangan pertama, tetapi dalam praktiknya semuanya ternyata menjadi lebih rumit. Ada juga diskusi luas tentang apa yang terbaik untuk dipilih - pengembangan cepat dan tingkat rilis, atau tingkat lebih lambat dan pengujian yang ketat. Diyakini bahwa penggunaan pendekatan kedua memungkinkan tercapainya stabilitas sistem produksi yang lebih tinggi. Namun, studi
DORA membuktikan bahwa ini tidak benar.
Setelah mengumpulkan statistik selama beberapa tahun, para peneliti mengidentifikasi praktik mana yang berkontribusi pada kinerja tim yang lebih tinggi. Ternyata tim yang paling efektif memperbarui server produksi berkali-kali dalam sehari, dan pelepasan kode sejak ditulis untuk rilis tidak lebih dari satu jam. Mengikuti pendekatan ini memungkinkan Anda untuk melepaskan perubahan di bagian-bagian kecil, dan kemungkinan kerusakan serius berkurang. Tim yang membuat rilis lebih jarang, menurut statistik, menghadapi banyak masalah serius. Selain itu, tim yang terbiasa dengan kecepatan tinggi dapat pulih lebih cepat setelah kecelakaan. Penelitian juga menunjukkan bahwa dalam tim semacam itu proses biasanya lebih selaras dan mereka beroperasi secara lebih terorganisir.
Dukungan untuk sistem dengan arsitektur yang baik lebih murah
Poin paling penting dari apa yang kita bicarakan di atas:
- Kurangnya perhatian terhadap kualitas kode menyebabkan akumulasi utang teknis
- Utang teknis memperlambat pengembangan sistem
- Bahkan tim profesional terkadang membuat keputusan yang buruk. Tetapi penerapan praktik-praktik modern dan "pembayaran kembali" utang teknis berkala memungkinkan Anda untuk mengendalikannya
- Mempertahankan tingkat kualitas kode yang tinggi meminimalkan hutang teknis. Ini memungkinkan untuk fokus pada fitur-fitur baru dan melepaskannya dengan sedikit usaha, lebih cepat dan lebih murah.
Sayangnya, biasanya sulit bagi pengembang untuk menjelaskan hal ini kepada manajemen. Saya sering mendengar keluhan bahwa manual ini tidak memungkinkan untuk mempertahankan kode berkualitas tinggi dengan membatasi waktu yang dialokasikan untuk mengerjakan tugas. Ketika menjawab pertanyaan manajemen, mengapa menghabiskan sumber daya tambahan untuk keindahan kode, pengembang biasanya menjawab bahwa ini adalah indikator profesionalisme tinggi. Tetapi hanya menggunakan argumen ini menyiratkan bahwa sumber daya tambahan dihabiskan untuk mempertahankan kualitas tinggi, yang dapat digunakan untuk tugas-tugas lain. Dan ini merongrong argumen untuk profesionalisme itu sendiri. Yang benar adalah bahwa karena arsitektur berkualitas buruk dan kode yang buruk, hidup menjadi lebih sulit bagi semua orang: lebih sulit bagi pengembang untuk bekerja dengannya, dan bagi pelanggan harganya lebih mahal. Ketika membahas kualitas kode dengan manajemen, saya mendesak agar kode itu dianggap semata-mata sebagai indikator ekonomi. Jika program di dalamnya dilakukan dengan kualitas tinggi, akan lebih mudah dan lebih murah untuk menambahkan fitur baru ke dalamnya. Ini berarti bahwa berinvestasi dalam penulisan kode kualitas pada akhirnya mengurangi keseluruhan biaya pengembangan.
Ini adalah alasan sebenarnya mengapa pertanyaan dari judul artikel tidak masuk akal. Menghabiskan sumber daya tambahan untuk arsitektur dan kode yang baik, dari sudut pandang ekonomi, pada akhirnya, lebih menguntungkan. , , , . , . ( ). , .
. :
, , . – . . , . .