Alasan Menulis ADR
(github.blog)ADR = Architecture Decision Records
Mencatat di dalam codebase mengapa sebuah keputusan arsitektur diambil seperti itu.
GitHub menerapkan ini di tim mobile iOS/Android mereka, dan tulisan ini menjelaskan mengapa hal itu diperlukan.
Bukan untuk Anda saat ini, melainkan untuk diri Anda di masa depan
ADR bukanlah proses refleksi atas keputusan yang saya ambil, melainkan membantu mengingat mindset saat memutuskan arsitektur ini 6–12 bulan dari sekarang.
ADR menangkap momen ketika keputusan dibuat, termasuk hingga PoC yang dibahas di rapat/Zoom meeting/Slack/kode.
Tujuannya adalah mengeluarkan konteks yang ada di kepala ke dalam kata-kata agar saat arsitektur ini ditinjau lagi nanti, konteks tersebut bisa dimasukkan kembali ke kepala.
Bonus yang sesungguhnya muncul ketika beberapa bulan kemudian seseorang datang sambil menyalahkan Anda dan bertanya mengapa modul GitHubAPIClient bekerja seperti ini.
Daripada pairing selama 30 menit untuk menjelaskan kodenya, Anda bisa melemparkan ADR ini dan menjelaskan keputusan yang diambil saat membangun modul tersebut.
Bukan untuk Anda, melainkan untuk rekan kerja Anda
ADR seharusnya berisi penjelasan yang lebih panjang daripada satu baris seperti "fitur ini adalah implementasi dari feature-#3128".
Ini adalah bentuk penjelasan yang lebih panjang yang membantu rekan kerja memahami mengapa fitur ini dibuat dengan cara ini, bukan dengan cara lain.
(Dapat dinyatakan di dalam ADR sebagai "alternatif yang dipertimbangkan", "kelebihan dan kekurangan", dan sebagainya.)
Apa yang sederhana bagi Anda bisa jadi rumit bagi rekan kerja Anda.
Jika Anda meluangkan sedikit waktu untuk menuliskan proses berpikir saat mengambil keputusan, Anda memberi kesempatan kepada anggota tim untuk masuk ke dalam kepala Anda.
Dengan menulis ADR, "Decision Socialization" menjadi mungkin.
Dengan begitu, alih-alih mengambil keputusan secara individual, tim dapat mengambil keputusan yang juga mereka tanggung jawab pemeliharaannya.
Jika Anda menulis ADR sebelum mengajukan pull request, Anda bisa mendapatkan review PR yang lebih baik dari tim yang meninjaunya.
Bukan untuk Anda, melainkan untuk rekan kerja Anda di masa depan
ADR bukan untuk menunjukkan betapa pintarnya Anda, atau membuat orang bingung saat melihat arsitektur yang Anda buat.
ADR membantu anggota tim baru memahami codebase saat ini dan bagaimana codebase tersebut berkembang seiring waktu.
Saat tim berkembang dan membesar, jalur komunikasi antaranggota tim pun bertambah.
Jika keputusan seperti ini dituliskan, itu akan membantu komunikasi dengan orang-orang yang baru bergabung seiring pertumbuhan tim.
Skenario terbaiknya adalah anggota tim Anda menulis ADR baru untuk menggantikan keputusan yang dulu Anda buat, dan di masa depan Anda pun bisa belajar dari rekan kerja Anda.
"Tulislah lebih banyak ADR. Setiap kali tim kita membesar dan codebase makin kompleks, ADR adalah cara yang sangat baik untuk membantu diri kita di masa depan, anggota tim saat ini, dan anggota tim di masa depan."
3 komentar
Di antara contoh e-government, ada juga repository terkenal dari Gov.UK yang merangkum ADR mereka terkait arsitektur cloud AWS mereka.
https://github.com/alphagov/govuk-aws/…
Ini sangat membantu sebagai referensi.
Contoh-contoh ADR
Keputusan framework CSS
https://github.com/joelparkerhenderson/architecture_decision_record/…
Premis: karena ingin membuat web app yang modern, cepat, dan responsif, tidak ingin memakai jQuery
Batasan: framework yang tidak mengharuskan penggunaan jQuery
Pertimbangan: tidak memakai apa pun, atau memilih di antara Bootstrap/Bulma/Foundation/Materialize/Semantic UI; secara mendalam mempertimbangkan Bulma dan Semantic UI
Monorepo vs Multirepo
https://github.com/joelparkerhenderson/architecture_decision_record/…
→ sedang menggunakan git sebagai SCM, jadi harus memutuskan monorepo vs polyrepo vs hybrid
→ Monorepo saat organisasi/tim/proyek kecil dan membutuhkan iterasi cepat
→ Polyrepo saat organisasi/tim/proyek besar dan stabilitas lebih penting
Keputusan bahasa pemrograman
https://github.com/joelparkerhenderson/architecture_decision_record/…
→ frontend adalah TypeScript
→ backend adalah Rust
→ front-end bersifat umum tetapi harus bisa dikembangkan, di-deploy, dan diiterasi dengan cepat. Tidak perlu kompatibilitas legacy
→ backend sedikit lebih tinggi daripada yang umum. Perlu mempertimbangkan kualitas, stabilitas, dan keamanan. Dibutuhkan tingkat yang hampir real-time (tidak boleh berhenti karena GC). Functional programming / pemrosesan paralel dan multicore processing, serta keamanan memori juga penting
Batasan: harus bisa dijalankan di serverless milik major cloud service (Amazon Lamba)
Pertimbangan: C/C++/Clojure/Elixir/Erlang/Elm/Flow/Go/Haskell/Java/Javascript/Kotlin/Python/Ruby/Rust/TypeScript
Perdebatan:
→ C: dikecualikan karena keamanan rendah; Rust dapat melakukan sebagian besar hal dengan lebih baik
→ C++: dikecualikan karena berantakan (mess); Rust dapat melakukan sebagian besar hal dengan lebih baik
→ Clojure: pemodelan yang unggul; paling mirip dengan Lisp; runtime yang sangat baik di atas JVM
→ Elixir: runtime unggul untuk deployment dan concurrency; pengalaman developer yang sangat baik; ekosistem relatif kecil
→ Erlang: runtime unggul untuk deployment dan concurrency; pengalaman developer agak menantang; ekosistem relatif kecil
→ Elm: sangat menjanjikan; IBM sedang membagikan contoh-contoh yang baik; ekosistem kecil
→ Flow: peningkatan menarik untuk JS; tetapi para developer mulai menjauh
→ Go: pengalaman developer yang sangat baik; concurrency yang sangat baik; ada keputusan buruk yang membuat bahasanya terasa aneh
→ Haskell: bahasa fungsional terbaik; komunitas developer kecil; belum banyak contoh sukses di production
→ Java: runtime terbaik; ekosistem sangat baik; pengalaman developer biasa saja
→ JavaScript: bahasa paling populer; ekosistem paling luas
→ Kotlin: memperbaiki banyak hal dari Java; dukungan kuat dari JetBrains; beragam contoh sukses migrasi dari Java ke Kotlin
→ Python: bahasa paling populer di sisi administrasi sistem; alat analisis yang baik; web framework yang baik; ditinggalkan setelah Google memilih Go
→ Ruby: pengalaman developer terbaik; web framework terbaik; komunitas yang sangat baik; sangat lambat; sulit dipaketkan
→ Rust: bahasa baru terbaik; menekankan Zero-cost abstractions (abstraksi tanpa memperlambat kinerja); menekankan concurrency; ekosistem relatif kecil; ada batasan pada beberapa optimasi compiler (misalnya akses memori langsung harus
unsafe)→ TypeScript: menambahkan type ke JavaScript; transpiler yang sangat baik; developer makin banyak berpindah dari JS ke TS; dukungan kuat dari Microsoft
Memutuskan untuk tidak memilih yang berbasis VM (karena kompleksitas meningkat)
Untuk runtime tercepat, pilih JS dan C
Untuk runtime yang hampir secepat yang terbaik, pilih TypeScript dan Rust
Jika memilih VM dan web framework
→ Clojure dan Luminous
→ Java dan Spring
→ Elixir dan Phoenix