Anda tidak bisa merancang perangkat lunak jika tidak membuat dan memperbaikinya sendiri

• 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

[cshj55]

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.

[khris]

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.

[coremaker]

Bukankah jika kita memperbaiki proses untuk menyempurnakan arsitektur, itu sudah cukup untuk menyelesaikan masalah yang diangkat?

[GN⁺]

Komentar Hacker News

• Menggambarkan situasi ketika dalam rapat tim pembahasannya bukan “DRY lebih baik atau WET lebih baik”, melainkan diskusi ketergantungan yang rumit seperti, “Bisakah fitur ini dimasukkan ke subsistem A? Tidak, di sana tidak ada informasi B, dan untuk mengeksposnya kita harus menulis ulang D...”
  Katanya ini pemandangan yang terasa akrab, lalu dengan nada bercanda menyebutkan berbagai nama sistem fiktif, dan di akhir menambahkan tautan YouTube

  • “Wingman” itu lucu. Tapi jumlah perangkat lunak yang masih belum mendukung ISO8601 masih terlalu banyak. Bahkan Git pun belum sepenuhnya kompatibel
  • Ini terasa seperti satire yang terlalu realistis. Idealnya, satu tim hanya bertanggung jawab atas satu layanan saja. Tapi sekarang zamannya satu developer memegang empat microservice sekaligus, jadi melelahkan
  • Situasi seperti ini sering terjadi ketika programmer juga ditugasi merancang sistem bisnis. Seharusnya analis sistem yang memimpin desain

• Sudah 30 tahun menulis kode, tapi hampir tidak pernah melihat kasus di mana upaya yang konsisten dicurahkan pada desain dan arsitektur
  Kebanyakan ‘arsitek’ tidak benar-benar mendesain; senior developer yang mendesain lalu hanya meminta umpan balik
  Jika rata-rata masa kerja hanya 2 tahun, orang akan mendesain sambil hanya memahami sebagian sistem, dan arsitek sering kali cuma memberi persetujuan

  • John Ousterhout membahas masalah ini dan mengajarkannya di Stanford, lalu mengembangkannya menjadi buku 『A Philosophy of Software Design』. Ada juga video kuliahnya
  • Dulu pernah ikut proyek yang punya ‘arsitek’, tapi kenyataannya dia cuma orang yang ikut rapat. Tidak ada yang benar-benar memberi saran desain
  • Dua tahun cukup untuk sepenuhnya mengubah atau merusak sebuah subsistem. Perangkat lunak sekarang berubah secepat itu
  • Dalam 2~3 tahun, orang bisa memahami codebase berukuran 50~100 orang dengan cukup mendalam. Setelah itu, kalau diberi kesempatan memimpin perbaikan arsitektur, perusahaan bisa bertumbuh secara teknis. Arsitek seharusnya berperan mengoordinasikan ide-ide ini dan menjaga konsistensi

• ‘Generic Software Design’ berguna untuk menentukan arah implementasi. Ia menyediakan bahasa dan kerangka bersama yang memudahkan pemecahan masalah
  Tapi implementasi nyata bisa berbeda dari rencana. Seperti dalam teori pemrograman Naur, pengetahuan sejati tentang sistem ada di kepala developer

• Pernyataan “dalam codebase besar, konsistensi lebih penting daripada desain yang baik” adalah jebakan dari nasihat yang digeneralisasi itu sendiri
  Jika hanya menekankan konsistensi, kebiasaan buruk akan terus dipertahankan

  • Di perusahaan kami justru kebalikannya: terlalu bebas. Semua orang membuat dengan caranya sendiri, sehingga ada sedikit Redux di satu sudut, sedikit library query lain di sudut lain. Akhirnya maintenance jadi lebih sulit
  • Ini bukan sekadar masalah kualitas kode, tapi masalah efisiensi organisasi secara keseluruhan. Dengan konsistensi, kecepatan pengembangan meningkat, review dan onboarding lebih mudah, dan bug bisa diperbaiki sekaligus
  • Waktu membaca kalimat itu saya sempat tersentak. Tapi kalau baca artikelnya sampai akhir, hakikat konsistensi adalah keseragaman dan ketepatan
  • Menjaga konsistensi itu penting, tapi perbaikan bertahap juga penting. Setiap kali menyentuh kode, lakukan perbaikan kecil dan kumpulkan ‘quick wins’
  • Pernyataan “konsistensi lebih penting daripada desain yang baik” bertentangan dengan Boy Scout Rule. Jika terlalu terpaku pada konsistensi, bisa berujung pada refactor besar-besaran yang berisiko

• Di satu sisi ada ‘arsitek’ yang tidak paham realitas, dan di sisi lain ada Real Programmer yang hanya terobsesi pada optimasi detail
  Kedua ekstrem sama-sama bermasalah, dan pengambil keputusan harus memahami detail sekaligus konteks
  Sebagai cerita terkait, disebut The Story of Mel

• Setuju dengan pernyataan bahwa “orang yang mendesain harus bertanggung jawab atas keberhasilan dan kegagalan proyek”
  Ini juga seharusnya berlaku pada orang yang memilih metodologi pengembangan. Scrum master tidak memikul rasa tanggung jawab sebesar lead engineer

• Aplikasi terbaik yang pernah saya ikuti punya tiga ciri berikut

  1. Mengutamakan sistem yang sederhana dan efektif
  2. Developer memahami semua use case karena mereka sendiri adalah pengguna nyata
  3. Ada otonomi untuk langsung memperbaiki masalah yang ditemukan
     Kebebasan ini meningkatkan kepuasan developer sekaligus kualitas produk

• Menurut pengalaman saya, dalam codebase besar, obsesi pada konsistensi justru merupakan kesalahan
  Tiap modul punya kebutuhan berbeda, jadi strategi testing dan penamaannya pun seharusnya berbeda

• Dalam kondisi ideal, developer juga harus menjadi pengguna nyata dari perangkat lunak yang mereka buat
  Dengan begitu mereka bisa langsung merasakan error atau ketidaknyamanan, dan punya motivasi untuk memperbaikinya

  • Developer perlu punya jalur untuk melihat masalah pengguna secara langsung tanpa harus melewati tahap customer support. Insight dari tiket, forum, SNS, dan semacamnya sangat besar
  • Dalam XP, memasukkan pelanggan ke dalam tim adalah ide yang brilian. Menggantinya dengan perwakilan bisnis adalah salah satu dosa asal Scrum

• Arsitek perangkat lunak terpisah yang tidak ikut maintenance itu tidak realistis
  Proyek terus berubah, jadi peran yang hanya memberi arahan dari kejauhan tidak membantu

  • Saya belum pernah bekerja di perusahaan yang punya peran seperti itu. Perangkat lunak yang kompleks itu seperti partai catur yang sedang berjalan. Prinsip strategi memang perlu, tapi nasihat dari orang yang tidak tahu kondisi papan saat ini tidak ada artinya