Pola Arsitektur yang Ditinjau lewat Python
(cosmicpython.com)- Aplikasi Python yang kompleks makin sulit diuji dan diubah hanya dengan pendekatan implementasi sederhana seiring bertambahnya skala, dan buku ini membahas pola arsitektur sebagai solusinya melalui contoh kode
- Dengan menggunakan penjualan furnitur online MADE.com dan rantai pasok global sebagai contoh, buku ini menempatkan pemodelan domain sebagai pusat untuk menerjemahkan masalah operasional dunia nyata ke dalam model perangkat lunak
- Poros utamanya adalah TDD, DDD, dan arsitektur berbasis peristiwa, dengan tujuan pengujian unit yang cepat, sedikit pengujian E2E, model yang terpisah dari infrastruktur, dan integrasi berbasis pesan
- Menggunakan Flask, SQLAlchemy, pytest, Docker, Redis, tetapi fokusnya adalah membangun struktur di mana pilihan teknologi tertentu terdorong menjadi detail implementasi
- Dapat dibaca oleh mereka yang pernah menangani aplikasi Python yang kompleks, dan tidak perlu lebih dulu memahami DDD atau pola arsitektur aplikasi klasik
Berangkat dari masalah struktur yang mudah diuji
- Setelah buku Harry sebelumnya Test-Driven Development with Python, masih tersisa pertanyaan tentang bagaimana aplikasi harus disusun agar mudah diuji
- Intinya adalah membuat struktur yang memungkinkan logika bisnis cukup ditangani dengan pengujian unit, sambil meminimalkan jumlah pengujian integrasi dan E2E
- Konsep seperti "Hexagonal Architecture", "Ports and Adapters", dan "Functional Core, Imperative Shell" sempat disebut, tetapi saat itu belum benar-benar dipahami atau dipraktikkan dengan baik
- Bob menjadi arsitek karena tidak ada orang di tim yang menangani arsitektur perangkat lunak, dan ia mempelajari pendekatan baru dalam menulis kode dan cara berpikir dari Ian Cooper
Kasus MADE.com: memodelkan rantai pasok ke dalam perangkat lunak
- Kedua penulis bekerja di perusahaan e-commerce Eropa MADE.com, dan menerapkan teknik dalam buku ini untuk membangun sistem terdistribusi yang memodelkan masalah bisnis nyata
- Domain contoh didasarkan pada sistem pertama yang dibuat Bob di MADE, dengan tujuan merangkum hal-hal yang perlu diajarkan ketika programmer baru bergabung ke tim
- MADE.com mengoperasikan rantai pasok global yang terdiri dari mitra pengiriman barang dan produsen
- Untuk menekan biaya, mereka ingin mengoptimalkan pengiriman agar stok tidak menumpuk lama di gudang
- Idealnya, pada hari pelanggan membeli sofa, produk itu tiba di pelabuhan dan langsung dikirim ke rumah pelanggan tanpa penyimpanan
- Karena barang bisa memerlukan 3 bulan untuk tiba dengan kapal kontainer, penyesuaian waktu menjadi sulit
- Dalam operasi nyata, terus muncul variabel seperti kerusakan, banjir, keterlambatan akibat badai, kesalahan penanganan oleh mitra logistik, dokumen yang hilang, dan perubahan pesanan oleh pelanggan
- Untuk menangani masalah seperti ini, mereka berusaha merepresentasikan operasi dunia nyata ke dalam perangkat lunak dan mengotomatiskan sebanyak mungkin pekerjaan
Batasan yang muncul saat proyek Python membesar
- Python telah tumbuh dan matang dengan cepat, tetapi kini mulai sungguh-sungguh menangani jenis masalah yang sudah lama dihadapi ekosistem C# dan Java
- Startup berubah menjadi bisnis nyata, dan aplikasi web serta otomasi skrip berkembang menjadi perangkat lunak enterprise
- Dalam filosofi Python ada ungkapan “There should be one—and preferably only one—obvious way to do it”, tetapi ketika skala proyek membesar, cara yang paling obvious tidak selalu cocok untuk mengelola kompleksitas dan perubahan kebutuhan
- Teknik dan pola yang dibahas dalam buku ini bukan hal baru, tetapi dalam dunia Python kebanyakan masih tergolong relatif baru
- Buku ini bukan pengganti Domain-Driven Design karya Eric Evans atau Patterns of Enterprise Application Architecture karya Martin Fowler, dan justru sering merujuk pada karya klasik tersebut serta merekomendasikannya untuk dibaca
- Contoh kode dalam literatur sebelumnya sering ditulis dalam Java atau C++/#, sehingga bisa terasa berat bagi pengembang Python untuk membacanya
Tiga alat untuk mengelola kompleksitas
- Test-Driven Development (TDD) membantu membuat kode yang benar, serta memungkinkan refactoring atau penambahan fitur tanpa takut pada regresi
- Membahas cara menjalankan pengujian secepat mungkin
- Cara memperoleh cakupan dan umpan balik sebanyak mungkin dari pengujian unit yang cepat dan tanpa dependensi
- Cara meminimalkan pengujian E2E yang lambat dan tidak stabil
- Domain-Driven Design (DDD) membantu tetap fokus pada pembuatan model yang baik untuk domain bisnis
- Membahas cara agar model tidak terikat pada perhatian infrastruktur
- Membahas cara agar model tidak menjadi sulit diubah
- Mikroservis yang loosely coupled dan terintegrasi lewat pesan, yang kadang disebut reactive microservices, dibahas sebagai solusi untuk mengelola kompleksitas antar aplikasi atau domain bisnis yang berbeda
- Tidak selalu jelas bagaimana menyesuaikannya dengan alat yang sudah ada di ekosistem Python seperti Flask, Django, dan Celery
- Bahkan jika tidak menggunakan atau tidak tertarik pada mikroservis, sebagian besar pola dalam buku ini dan banyak isi tentang arsitektur berbasis peristiwa tetap dapat diterapkan pada arsitektur monolitik
Pembaca dan pengetahuan prasyarat
- Buku ini ditujukan untuk pembaca yang setidaknya pernah menangani aplikasi Python yang cukup kompleks dari dekat
- Buku ini cocok untuk pembaca yang telah merasakan sakitnya mengelola kompleksitas
- Tidak diperlukan pengetahuan awal tentang DDD atau pola arsitektur aplikasi klasik
- Penjelasan dibangun per bab dengan berpusat pada aplikasi contoh
- Karena para penulis menggunakan TDD dalam pekerjaan mereka, mereka sering memperlihatkan kode pengujian terlebih dahulu lalu implementasinya
- Buku ini menggunakan Flask, SQLAlchemy, pytest, Docker, dan Redis, tetapi mengenalnya lebih dulu hanya membantu, bukan keharusan
- Salah satu tujuan utamanya adalah membangun arsitektur di mana pilihan teknologi tertentu menjadi detail implementasi kecil
Susunan buku
- Buku ini dibagi menjadi dua bagian
-
Bagian 1: arsitektur yang mendukung pemodelan domain
- Pemodelan domain dan DDD dibahas pada Bab 1, 2, dan 7
- Dasarnya adalah bahwa masalah bisnis yang kompleks harus dicerminkan sebagai model domain di dalam kode
- Dijelaskan cara memulai dari model yang tidak memiliki dependensi eksternal dan memungkinkan pengujian unit yang cepat
- Setelah itu dibahas kembali pemilihan aggregate yang tepat dan masalah integritas data
- Pola Repository, Service Layer, dan Unit of Work dibahas pada Bab 2, 4, dan 5
- Pola-pola ini saling melengkapi untuk memisahkan model dari dependensi yang tidak perlu
- Dibuat lapisan abstraksi di sekitar penyimpanan persisten, serta lapisan layanan yang menangkap titik masuk sistem dan use case utama
- Menunjukkan struktur yang memudahkan pembuatan titik masuk tipis seperti API Flask atau CLI
- Pembahasan tentang abstraksi dan pengujian berlanjut pada Bab 3 dan 5
- Setelah memperkenalkan pola Repository, dibahas cara memilih abstraksi dan peran abstraksi dalam cara pengikatan
- Setelah pola Service Layer, dibahas piramida pengujian dan cara menulis pengujian unit pada tingkat abstraksi setinggi mungkin
-
Bagian 2: arsitektur berbasis peristiwa
- Arsitektur berbasis peristiwa dibahas dari Bab 8 hingga 11
- Memperkenalkan pola Domain Events, Message Bus, dan Handler
- Domain Events adalah sarana untuk merepresentasikan gagasan bahwa suatu interaksi dalam sistem memicu tindakan lain
- Message Bus memungkinkan tindakan memicu peristiwa dan memanggil handler yang sesuai
- Dibahas cara menggunakan peristiwa sebagai pola integrasi antarlayanan dalam arsitektur mikroservis
- Commands dan events dibedakan, dan aplikasi pada dasarnya menjadi sistem pemrosesan pesan
- Bab 12 membahas contoh CQRS dengan pendekatan yang menggunakan peristiwa dan yang tidak
- Bab 13 merapikan dependensi eksplisit dan implisit serta mengimplementasikan framework dependency injection yang sederhana
- Dalam epilog, penulis menjelaskan cara menerapkan prinsip-prinsip ini pada perangkat lunak yang sudah ada, bukan hanya pada contoh sederhana yang baru dimulai, dan menyediakan bacaan lanjutan
Kode contoh dan cara mengikuti
- Buku ini disusun di sekitar satu proyek contoh, dan proyek itu diperluas secara bertahap seiring kemajuan bab
- Penulis menganggap penting agar pembaca benar-benar menyentuh kodenya dan memperoleh intuisi tentang cara pola-pola tersebut bekerja
- Semua kode tersedia di GitHub dan setiap bab memiliki branch terpisah
- Daftar branch dapat dilihat di halaman branches GitHub
- Tiga cara mengikuti disarankan
- Membuat repositori sendiri dan membangun aplikasi dengan mengikuti contoh di buku, sambil merujuk ke repositori penulis saat diperlukan
- Mencoba menerapkan tiap pola ke proyek kecil milik sendiri per bab
- Berlatih cepat menggunakan "Exercise for the Reader" di tiap bab dan kode GitHub yang sebagian dibiarkan kosong
- Khusus bagi pembaca yang ingin menerapkan pola-pola ini pada proyek sendiri, menangani contoh sederhana lebih dulu menjadi latihan yang aman
- Setidaknya saat membaca tiap bab, pembaca disarankan mengambil kode dari repositori dengan
git checkoutdan memeriksanya dalam konteks aplikasi yang benar-benar berjalan
Lisensi dan format
- Kode dan versi online dilisensikan dengan Creative Commons CC BY-NC-ND
- Untuk tujuan nonkomersial
- Wajib atribusi
- Boleh disalin dan dibagikan
- Edisi cetak mengikuti lisensi terpisah, dan jika ada kekhawatiran terkait penggunaan ulang, pembaca diarahkan untuk menghubungi O’Reilly
- Konvensi penulisan buku membedakan penggunaan italic, fixed-width, fixed-width bold, dan fixed-width italic
- Italic menunjukkan istilah baru, URL, alamat email, nama file, dan ekstensi
- Fixed-width menunjukkan daftar program dan elemen kode
- Fixed-width bold menunjukkan perintah atau teks yang harus diketik pengguna apa adanya
- Fixed-width italic menunjukkan teks yang diganti dengan nilai yang diberikan pengguna atau ditentukan oleh konteks
2 komentar
Sudah tersedia dalam edisi bahasa Korea Architecture Patterns with Python
Pendapat di Hacker News
Buku ini adalah gudang harta yang bagus untuk mempelajari pola arsitektur, cepat masuk ke topik dan mudah menangkap intinya
Namun dari sudut pandang praktik, sebagian pola seperti ini bisa sangat memperbesar masalah kompleksitas dan performa di Python, terutama jika dipakai bersama framework seperti Django yang sudah menggunakan pola ActiveRecord
Setelah mengalami berbagai perusahaan besar dan kecil yang memakai Python, perusahaan besar yang memakai pola arsitektur ketat memang kodenya “bersih”, tetapi pekerjaan yang awalnya tampak sederhana pun terasa terlalu rumit dan lambat tanpa perlu
Sebaliknya, perusahaan besar yang tidak terlalu memedulikan pola seperti itu memang punya kode yang benar-benar buruk rupa, seperti file if-else raksasa atau model Django yang berisi semua logika bisnis, tetapi karena bisa dibaca, dipahami, dan if-else 1000 barisnya bisa diubah, mereka lebih produktif
Saya enggan mengakui bahwa saya lebih produktif di perusahaan yang kodenya tidak bersih, tetapi itu juga berarti banyak perdebatan tanpa akhir tentang apa yang disebut bersih bisa dihindari
Seseorang menetapkan bahwa “untuk melakukan X atau Y, harus membuat N hal lain lebih dulu”, sehingga pekerjaan sederhana pun harus mengubah banyak file, fungsi, dan class
Di perusahaan yang tidak terlalu memedulikan pola arsitektur, mungkin ada banyak kode yang tidak enak dilihat, tetapi sering kali lebih mudah dipahami orang baru karena referensi tidak langsungnya lebih sedikit dan objek pekerjaannya terkumpul di satu area
Sering kali fungsi 100 baris yang mudah dinavigasi, diubah, dan di-debug lebih baik daripada fungsi-fungsi kecil yang tersebar di banyak file
Bukan berarti semua abstraksi itu buruk, tetapi makin lama bekerja, saya merasa makin sedikit abstraksi membuat unit atau fitur individual dalam kode lebih mudah ditalar, dan akhirnya menyimpulkan bahwa yang benar-benar sulit saja yang perlu diabstraksikan, bukan hal-hal sederhana
Jika keduanya ada, menjelajahi codebase terasa intuitif; jika salah satunya tidak ada, fungsi 1000 baris bisa tampak lebih mudah dibaca
Pesawat luar angkasa adalah produk yang dirancang sangat tinggi, dan karena sebagian besarnya bekerja sebagai perangkat kendali perangkat lunak, di dalamnya sudah ada model desain yang rapi yang bisa ditemukan dan disalin
Pemodelan domain seharusnya bukan menyalin model yang sudah ada, melainkan memanfaatkan keunggulan perangkat lunak dibanding teknologi fisik dan sosial yang hendak digantikan oleh perangkat lunak baru, lalu membuatnya lebih baik
Dalam model domain yang ada pun terdapat abstraksi yang bagus, sehingga banyak elemen inti yang harus masuk ke model baru, dan penting juga memahami apa yang ingin dicapai para pemangku kepentingan dengan sistem saat ini
Namun model dalam dunia bisnis dan budaya tidak dioptimalkan untuk kode, sering kali sudah tua atau berantakan, dan kasus batas serta bagian yang kurang eksplisit ditafsirkan dan ditangani oleh manusia
Model seperti itu harus diperlakukan sebagai sumber inspirasi, bukan tujuan akhir
Pola arsitektur seperti ini mirip dengan manajemen proyek: keduanya menciptakan overhead, dan jika dipakai sembarangan, biayanya jauh melampaui nilai yang diperoleh sehingga mendapat reputasi buruk
Namun jika digunakan dengan hati-hati, pola ini bisa menentukan keberhasilan proyek
Misalnya, jika membuat REST API kalender sederhana, saya tidak akan memakai arsitektur yang rumit
Sebaliknya, dalam sistem trading, menjaga arsitektur port dan adapter sangat penting untuk beralih dengan mulus antara mode simulasi dan mode produksi
Sebab simulator dan mesin trading nyata, feed peristiwa historis dan feed real-time harus bisa ditukar dengan mudah, dan tidak mungkin membuat dua set logika bisnis lalu menjaganya tetap sinkron
Pola bukanlah implementasi, melainkan lebih dekat ke proses berpikir tentang apa yang sedang dilakukan, rencana untuk menanganinya, dan desain tingkat tertinggi API yang ingin disediakan ke bagian kode lainnya
Di Python, karena fungsi adalah objek, state machine pun sering kali cukup berupa sekumpulan fungsi yang saling mengembalikan satu sama lain dan pengulangan
f = f(x)Ada juga yang menyarankan memakai pola Borg alih-alih Singleton, tetapi dalam praktiknya sering kali cukup memakai modul saja, dan
syssudah membuatnya seperti singleton“Dependency injection” juga sering kali hanyalah istilah keren untuk meneruskan argumen ke fungsi, terkadang meneruskan fungsi lain
Flyweight bukanlah benda terpisah, melainkan teknik interning, dan pola Command yang disebut di sumber asli adalah salah satu poin utama dalam ceramah kritik terkenal Jack Diederich (https://www.youtube.com/watch?v=o9pEzgHorH0); cukup gunakan
functools.partialdengan baikDikotomi antara kode bersih dan kode buruk rupa bisa jadi ilusi karena belum melihat contoh yang lebih baik
Fungsi pendek tidak harus menuntut hierarki class yang kompleks, dan sejak awal mungkin class memang tidak diperlukan
Pemrograman berorientasi objek adalah tentang objek, bukan class; jika class adalah intinya, namanya tentu pemrograman berorientasi class
Dalam buku ini, konsep yang melampaui Python atau bahasa tertentu, misalnya arsitektur berbasis event, command, dan CQRS, sangat berguna
Namun bagian lain punya masalah, dan bisa menjadi berbahaya ketika developer yang kurang berpengalaman menerimanya seperti doktrin lalu mencoba mengimplementasikan semuanya sekaligus
Pola repository umumnya membantu, tetapi dalam banyak kasus, termasuk contoh di buku ini, ia menjadi pilihan berlebihan yang hampir tidak memberi keuntungan dan hanya menambah kompleksitas
Terutama jika memakai SQLAlchemy, SQLAlchemy sendiri sudah sampai taraf tertentu berperan sebagai repository, lebih tepatnya lapisan abstraksi database relasional yang ditumpangi ORM
Lapisan service dan unit of work juga berguna untuk aplikasi dengan banyak use case kompleks, tetapi pada sistem yang terdiri dari service-service kecil dengan cakupan tanggung jawab sempit, keduanya cepat membengkak
Dependency injection di Python juga demikian
Design pattern pada akhirnya hanyalah alat, jadi developer harus memahami kapan memakainya, dan yang lebih penting, kapan tidak memakainya
Buku ini juga punya nasihat semacam itu, tetapi saya berharap hal tersebut dibahas lebih menonjol di bagian awal, bukan di akhir tiap bab
Jika akses database diperlukan, saya melihatnya sebagai pola ringan yang layak direkomendasikan untuk selalu dipakai demi pemisahan kepentingan
Pada akhirnya, itu hanya membuat semua akses database untuk entitas tertentu melewati satu repository milik entitas itu, dan di dalam repository kita bebas mengeksekusi query langsung atau memakai ORM sesuai keinginan
Banyak isi pada bagian pola repository di artikel itu lebih dekat ke detail Python, Django, dan SQLAlchemy daripada ke polanya sendiri
Saya terutama memakai Python, dan memahami dependency injection sebagai “membuat fungsi menerima semua input yang dibutuhkan untuk komputasi sebagai parameter”; menurut saya itu layak dijadikan prinsip utama desain proyek
Lapisan service dan dependency injection cukup membantu saat menulis program fungsional
Saya memakai skrip pemrosesan gambar kompleks yang dibuat dengan Python seolah-olah sebagai plugin untuk layanan pemrosesan gambar terdistribusi berbasis Celery, dan lapisan service serta dependency injection mengubah kode dari
dependency.do_thing(params)menjadido_thing(dependency, params)Ini membuatnya jauh lebih mudah diuji
Di lingkungan deployment nyata, saya bisa menjalankan pekerjaan pemrosesan gambar dengan seluruh I/O diganti palsu, atau menjalankan pekerjaan pemrosesan gambar nyata di atas Celery palsu
Beberapa fungsi bisa diuji end-to-end sebelum deployment penuh, dan jika memakai tipe Result bersama lapisan service, informasi error terkait juga lebih mudah diteruskan ke klien web tanpa membuat program crash
Menarik melihat pola-pola itu, tetapi akan lebih baik jika di bagian awal ada panduan tentang situasi apa yang paling berguna untuk mengimplementasikannya
Jika pola adalah alat, akan membantu bila ada arahan kapan memakainya dan kapan menghindarinya
Memang sebagian dibahas di bagian kelebihan dan kekurangan, jadi mungkin ini soal urutan dan penekanan
Saat membuat aplikasi web kecil untuk bisnis baru sambil belajar Python, beberapa pola memberi ide untuk penyederhanaan, sementara pola lain membuat saya memutuskan untuk menghindarinya
Saya rasa ia menimbulkan kerusakan besar dengan mencuci otak developer yang kurang berpengalaman lewat hal-hal seperti “Clean Code”
Rekayasa perangkat lunak bukan ilmu alam yang ketat, jadi hampir tidak ada peluru perak dan semuanya adalah trade-off
Orang yang mengatakan tahu satu jalan yang benar itu berbahaya atau nyaris pemula
Saya developer TypeScript, tetapi buku ini adalah salah satu buku arsitektur favorit saya dan sering saya jadikan rujukan
Saya terutama menyukai unit of work palsu dan pola service untuk pengujian, dan di semua proyek saya hampir secara fanatik memakainya saat mengganti layanan pihak ketiga dengan versi palsu
Poin penting di sini adalah objek palsu, bukan objek mock
Buku ini juga membantu dalam urusan penamaan; misalnya, ia menyarankan agar nama event dibuat spesifik ke domain, bukan berpusat pada infrastruktur atau pola
Contohnya
CART_ITEM_BECAME_UNAVAILABLElebih baik daripadaUSER_NOTIFICATIONSebagian hal seperti ini memang terasa jelas, tetapi merepotkan untuk dijelaskan ke rekan tim; karena cosmic python tersedia online, mudah untuk mengirim tautannya
Secara keseluruhan, ini materi yang bagus dan sangat memengaruhi saya
https://www.obeythetestinggoat.com/pages/book.html
Buku itu juga buku yang sama-sama saya sukai, dan meski hampir tidak memakai Python dalam pekerjaan, saya sering kembali membukanya saat memakai bahasa lain
Saya juga suka karena tersedia baik online maupun dalam bentuk buku cetak
Buku ini juga pasti akan saya baca
Menurut saya Python adalah bahasa perekat yang bagus
Saya lelah dengan pola pikir berorientasi objek yang dipaksakan: semua hal harus dienkapsulasi dan diwariskan, hanya boleh punya field privat lalu mengaturnya lewat method
Saya juga lelah dengan SOLID, clean coding, clean architecture, pola GoF, dan Uncle Bob
Saya lelah dengan kingdom of nouns dan FizzBuzz Enterprise Edition
Sekarang saya sebisa mungkin mengurangi orientasi objek dan mengikuti alur imperatif atau fungsional
Saat sesekali memakai Python, yang terutama karena di kantor saya memakai .NET, bukan karena tidak suka Python, saya ingin pengalaman yang bebas dari objek dan pattern
Ini bukan berarti buku ini tidak bernilai; ia berguna untuk mempelajari pattern
Namun jangan memaksakan semua pemrograman dunia nyata ke dalam pattern, objek, dan SOLID
Dengan begitu, kompleksitas yang tidak relevan tetap berada di luar domain, dan fungsi-fungsi itu bisa digunakan ulang tanpa harus selalu membuat objek utuh yang belum tentu dibutuhkan
Jika yang ingin dilakukan di sini kira-kira seperti ini, rasanya sangat berlebihan
Mengimplementasikan ulang model SQLAlchemy lalu menyebutnya “repository”, mengimplementasikan ulang sesi SQLAlchemy lalu menyebutnya “unit of work”, dan menambahkan “service layer” yang bahkan tidak memakai model
Dengan alasan mengurangi coupling, semua atribut model diurai menjadi parameter fungsi terpisah, dan semuanya ditebar ke message bus seolah-olah menghilangkan kemampuan debugging
Namun ini hanya berlaku untuk jalur tulis
Untuk baca, ada tabel denormalisasi terpisah dan kueri dilakukan dengan SQL mentah
Memang begitu kalau melihat bab 12
Melihat trafik MADE.com, bulan lalu kunjungannya sekitar 500 ribu gabungan desktop dan mobile, kira-kira 12 view per menit
Dalam situasi seperti itu, muncul sinisme bahwa pekerjaan yang bisa membahas DDD seharian memang patut membuat iri
Untuk tiap pattern ada ringkasan kelebihan dan kekurangannya, dan meski ada bagian yang kurang, mereka jelas mengatakan bahwa kita harus memikirkan apakah pattern itu cocok dengan kebutuhan aplikasi
Mungkin tidak banyak aplikasi yang membutuhkan semua isi buku ini, tetapi jelas ada banyak aplikasi yang bisa menerapkan satu atau lebih pattern
Namun jika ini akun sekali pakai, ini lebih mirip reaksi negatif sambil lalu yang tidak bernilai
Sejak beberapa tahun lalu saya mulai memakai Python secara profesional
Saya pindah dari Kotlin dan TypeScript, dan bahasanya sendiri mudah didekati, tetapi saya kesulitan membuatnya terasa Pythonic sambil tetap mencapai loose coupling dan kemudahan pengujian yang sudah saya kenal
Atas rekomendasi rekan kerja, saya membeli buku ini dan membacanya dari awal sampai akhir, dan buku ini sangat membantu saya memahami cara melakukan manajemen kompleksitas pada codebase Python yang tidak sepele
Saya tidak mengikuti semua pattern yang disarankan buku ini, tetapi buku ini menunjukkan apa saja yang mungkin dilakukan dan bagaimana menerapkan pengalaman dari paradigma lain ke Python tanpa terasa seperti “developer Java yang menulis Python”
Sangat direkomendasikan, dan uangnya tidak terasa sia-sia
Ini benar-benar salah satu buku pemrograman Python yang bagus
Satu hal yang disayangkan adalah kurangnya static type di kode, tetapi itu adalah keputusan yang sengaja diambil para penulis
Seberapa sulit memberi type hint pada kode adalah ukuran yang sangat bagus untuk menunjukkan seberapa sulit kode itu dipahami nantinya
Ada type hint seperti di sini: https://www.cosmicpython.com/book/chapter_08_events_and_mess...
Di sebagian bagian buku memang ada bagian tanpa type hint
dataclasses, dan itu mewajibkan anotasi tipePython tidak mendukung static type
Alat berbasis anotasi tipe tidak memengaruhi proses kompilasi, dan kecuali memakai metaprogramming seperti
dataclasses, alat itu juga tidak bisa membuat Python menolak kodeIa hanya menyediakan diagnostik
Saya menyimpan buku ini di rak
Bukunya kecil seperti K&R, dan karena sering saya bolak-balik, terlihat cukup banyak bekas usang
Bacaan sekaligus ringkasan yang sangat bagus
Sekitar 3 tahun lalu saya bekerja di lingkungan DDD berbasis C#/.NET, dan sekarang ketika melihat kembali konsep-konsep ini dengan Python, intinya terasa lebih tersaring
Jika Anda tertarik pada konten semacam ini, sangat direkomendasikan
Sekitar 2,5 sampai 3 tahun lalu saya membaca edisi cetak buku ini dan cukup menikmatinya
Buku ini berhasil mempertahankan testing sebagai topik kelas satu, dan terus memperbaruinya setiap kali menambahkan fitur
Di antara buku arsitektur lama, ada juga yang tidak memperlakukan testing dengan prioritas setinggi itu
Jika testing dibuat mudah disiapkan, mudah ditulis, dan mudah diperbarui, kita jadi lebih jarang menjalankan kode secara manual untuk memeriksa masalah, sehingga proses pengembangan lebih menyenangkan
Dengan kata lain, tercipta feedback loop yang lebih cepat
Bagian berorientasi event dalam buku ini sangat menarik, tetapi tidak terlihat terlalu praktis untuk benar-benar diimplementasikan dalam pekerjaan saya saat ini