- Partisipasi desain yang nyata dalam sistem berskala besar hanya dimungkinkan bagi engineer yang benar-benar menangani kode tersebut secara langsung, dan saran abstrak pada umumnya tidak banyak berarti
- Saran desain umum (generic design) sering kali diberikan dengan hanya memahami domain tanpa mengenal codebase
- Dalam pekerjaan nyata, kendala yang spesifik dan menjaga konsistensi jauh lebih penting daripada prinsip desain, dan yang paling penting adalah memahami keadaan kode saat ini
- Dalam merancang sistem baru atau menentukan arah teknis untuk seluruh perusahaan, prinsip desain umum dapat berguna sampai batas tertentu
- Namun, struktur desain yang berpusat pada arsitek dan terpisah dari lapangan mudah gagal, dan orang yang mengusulkan desain harus bertanggung jawab atas hasilnya
Batasan desain perangkat lunak umum
- Merancang sistem berskala besar membutuhkan pemahaman mendalam tentang detail konkret dalam kode
- Saran abstrak hampir tidak membantu dalam menyelesaikan masalah nyata
- Dalam praktik, konsistensi (consistency) lebih penting daripada ‘desain yang baik’
- Karena codebase nyata kompleks dan menghasilkan konsekuensi yang sulit diprediksi, pilihan cara implementasi yang aman menjadi terbatas
- Codebase bersama berskala besar selalu berada dalam keadaan transisi tempat berbagai desain bercampur, sehingga kondisi keterikatan kode saat ini lebih penting daripada target ideal
- Karena sebagian besar sistem tidak mungkin ditulis ulang sepenuhnya (rewrite), kita harus bergantung pada konsistensi internal dan ketelitian engineer
Karakteristik desain perangkat lunak yang konkret
- Diskusi desain yang efektif terjadi dalam percakapan di antara sedikit engineer yang menangani sistem itu setiap hari
- Topik diskusi bukan prinsip umum, melainkan konteks spesifik seperti struktur detail sistem atau alur data
- Misalnya, bukan “apakah DRY itu baik”, tetapi diskusi teknis yang rinci seperti “apakah fitur ini bisa dimasukkan ke subsistem A, apakah informasi B dapat diakses dalam konteks C”
- Kontribusi penting datang dari meluruskan kesalahpahaman kecil atau dampak rinci dari perubahan kode
Kapan saran desain umum berguna
- Saat pertama kali merancang proyek baru, prinsip umum berguna karena belum ada kendala yang spesifik
- Saat sulit memilih di antara beberapa opsi implementasi, prinsip umum dapat menjadi kriteria pengambil keputusan (tie-breaker)
- Ini juga membantu menjaga konsistensi pada tingkat seluruh perusahaan, yang merupakan salah satu peran resmi software architect
- Bahkan dalam pilihan teknologi yang luas seperti cloud vs on-premises, AWS vs Azure, prinsip umum bisa menjadi rujukan, tetapi kendala yang spesifik tetap tidak bisa diabaikan
Arsitek dan masalah ‘local minima’
- Banyak perusahaan terjebak dalam struktur desain abstrak yang berpusat pada arsitek tanpa pengalaman lapangan
- Pendekatan ini terlihat efisien di permukaan, tetapi pada kenyataannya menghasilkan desain yang tidak bisa diimplementasikan oleh engineer di lapangan
- Karena arsitek tidak mengimplementasikan langsung, mereka kekurangan tanggung jawab terhadap hasil (skin in the game)
- Jika desain berhasil, mereka bisa mengambil pujian; jika gagal, kesalahan dapat dialihkan ke tim eksekusi
- Struktur seperti ini cenderung memperkuat aktivitas desain yang formal daripada nilai yang nyata
Kesimpulan dan usulan
- Diskusi desain yang berguna terjadi dalam percakapan konkret pada level unit kode, dan perancang harus benar-benar akrab dengan codebase
- Prinsip arsitektur umum sebaiknya dibatasi pada desain sistem baru, membantu keputusan detail pada sistem yang ada, dan penetapan arah teknis di tingkat perusahaan
- Orang yang mengusulkan desain proyek harus bertanggung jawab atas keberhasilan dan kegagalannya, dan engineer yang benar-benar menangani kode harus menjadi pelaku utama desain
- Dengan demikian, orang yang benar-benar memahami sistem nyata dan mampu melakukan deployment dapat diakui sebagai perancang yang sesungguhnya
3 komentar
> Dalam pekerjaan nyata, batasan yang konkret dan menjaga konsistensi jauh lebih penting daripada prinsip desain, dan memahami kondisi kode saat ini adalah hal yang paling krusial.
Ini memang sejalan dengan keyakinan saya selama ini, jadi rasanya menghangatkan hati.
Jadi ini sebabnya belakangan para guru malah bilang kalau para junior jauh lebih jago memakai agen. Karena itu yang selama ini membuat mereka bisa terus menghasilkan uang, mereka jadi tidak melakukan unlearning.
Bukankah jika kita memperbaiki proses untuk menyempurnakan arsitektur, itu sudah cukup untuk menyelesaikan masalah yang diangkat?