Arsitektur perangkat lunak dinilai terlalu tinggi, desain sederhana dianggap remeh

Kami menawarkan Anda terjemahan jabatan Gergel Oros, yang menjabat sebagai Manajer Teknik di Uber. Di dalamnya, ia berbagi pandangannya tentang desain sistem skala besar, berdasarkan pengalaman praktisnya sendiri di Uber dan Microsoft. Dikombinasikan dengan komentar di Hacker News , yang menambah argumen balasan dan melengkapi sudut pandang penulis, artikelnya telah menjadi salah satu posting paling menarik dalam seminggu. Istilah "desain kode" digunakan dalam artikel untuk membandingkan dengan "arsitektur" tradisional - lebih lanjut dapat ditemukan di sini .

Saya memiliki pengalaman yang cukup dalam mendesain dan menciptakan sistem skala besar. Saya berpartisipasi dalam penulisan ulang sistem pembayaran terdistribusi di Uber, merancang dan merilis Skype di Xbox One, dan secara terbuka merilis RIB , kerangka kerja arsitektur seluler yang dibuat oleh Uber. Semua sistem ini memiliki desain yang dipikirkan dengan cermat, melewati beberapa iterasi, dan banyak pertemuan diadakan di papan tulis, dan diskusi lainnya. Kemudian desain muncul dengan dokumen desain, yang didistribusikan di antara pengembang lain untuk mengumpulkan umpan balik tambahan, yang berlanjut sampai kami beralih ke pengembangan.

Semua sistem ini berskala besar: ratusan pengembang menciptakannya - atau mereka menggunakannya dalam desain mereka - dan hari ini mereka mengalahkan dalam hati sistem yang digunakan jutaan orang setiap hari. Selain itu, proyek-proyek ini tidak dibuat dari awal. Sistem pembayaran seharusnya menggantikan dua sistem pembayaran lain yang ada yang digunakan oleh lusinan sistem lain dan lusinan tim, semuanya tanpa membahayakan bisnis. Menulis ulang aplikasi Uber adalah proyek yang dilakukan beberapa ratus insinyur secara bersamaan - termasuk memasukkan semua fungsi yang ada ke arsitektur baru.

Biarkan saya mulai dengan sesuatu yang mungkin terdengar tidak terduga. Pertama, kami tidak pernah menggunakan alat perencanaan arsitektur perangkat lunak standar untuk bekerja pada desain sistem ini. Kami tidak menggunakan UML , atau model 4 + 1 , atau ADR , atau C4 , atau diagram dependensi . Kami membuat banyak diagram, tetapi tidak ada yang mengikuti aturan ketat. Hanya persegi panjang dan panah yang baik yang diperlukan - dan kami mendapatkan diagram yang mirip dengan ini, yang menggambarkan arus informasi , atau lainnya, yang menggambarkan struktur kelas dan hubungan antara komponen . Dua bagan dalam dokumen desain yang sama sering memiliki gaya yang berbeda, karena sering ditambahkan atau diedit oleh orang yang berbeda.

Kedua, kami tidak memiliki arsitek yang akan memiliki desain. Tidak ada Arsitek TI maupun Arsitek Perusahaan . Ini benar - baik Uber, maupun Skype / Mircrosoft tidak memiliki posisi penuh waktu untuk arsitek perangkat lunak. Insinyur tingkat tinggi, seperti yang berada di posisi Staff Engineer, masih diharapkan untuk menulis kode secara teratur. Semua proyek kami memiliki insinyur yang berpengalaman - namun, tidak satu orang memiliki arsitektur atau desain sendiri. Sementara insinyur berpengalaman adalah kekuatan pendorong di balik proses desain, pengembang lain terlibat dalam diskusi, termasuk bahkan "Juni" hijau - apalagi, mereka sering menantang keputusan orang lain dan membawa opsi alternatif untuk diskusi.

Ketiga, kami hampir tidak pernah merujuk pada pola arsitektur umum dan jargon lain yang diterima secara umum, yang digunakan dalam literatur populer tentang arsitektur perangkat lunak seperti manual Martin Fowler . Tidak ada referensi untuk layanan microser, arsitektur tanpa server, batas aplikasi , arsitektur berbasis peristiwa, atau apa pun. Beberapa istilah ini muncul selama sesi curah pendapat; Namun, kami tidak perlu merujuk mereka sendiri dalam dokumentasi desain.

Desain Perangkat Lunak di Perusahaan dan Startup Teknologi

Jadi bagaimana kita menangani semuanya? Dan mengapa kita tidak mengikuti pendekatan umum untuk arsitektur perangkat lunak?

Saya membahas masalah ini dengan sesama insinyur yang bekerja di perusahaan teknologi lain - baik ukuran FANG (Facebook, Amazon, Netflix, Google), dan startup kecil. Sebagian besar tim dan proyek - apakah mereka besar atau kecil - menggabungkan pendekatan yang mirip dengan desain dan implementasi:

1. Mulailah dengan tugas bisnis. Masalah apa yang kita coba selesaikan? Produk apa yang kami coba buat dan mengapa? Bagaimana kita bisa mengukur keberhasilannya?
2. Brainstorming untuk “pendekatan” yang dipilih. Berkumpul bersama tim dan temukan solusi yang berfungsi dalam beberapa sesi. Jangan terlalu menunda dengan fase ini. Mulai dari tingkat atas dan secara bertahap turunkan diri Anda ke tingkat di bawah ini.
3. Gambarlah pendekatan Anda di papan tulis. Kumpulkan tim, dan biarkan salah satu dari Anda menggambarkan pendekatan yang disandarkan tim. Anda harus dapat menjelaskan dengan jelas arsitektur sistem / aplikasi Anda dengan bantuan papan - mulai dari level tertinggi dan, jika perlu, semakin rendah. Jika Anda mengalami kesulitan dengan penjelasan atau tidak cukup jelas untuk rekan kerja, maka Anda perlu memikirkan rincian keputusan Anda dengan lebih baik.
4. Perbaiki dalam bentuk dokumentasi sederhana dengan diagram sederhana berdasarkan apa yang Anda jelaskan sebelumnya dengan papan tulis. Pertahankan jargon seminimal mungkin: Anda ingin bahkan junior memahami apa yang dikatakan. Gunakan bahasa yang jelas dan mudah dalam deskripsi Anda . Di Uber, kami menggunakan dokumen seperti RFC yang didasarkan pada templat sederhana.
5. Diskusikan pengorbanan dan alternatif . Desain perangkat lunak yang baik dan arsitektur yang baik adalah pilihan yang tepat untuk pertukaran. Dalam dan dari dirinya sendiri, tidak ada pilihan desain yang buruk atau baik: semuanya tergantung pada konteks dan tujuan. Apakah arsitektur Anda dibagi menjadi berbagai layanan? Sebutkan mengapa Anda memutuskan untuk tidak membuat satu layanan besar, di mana mungkin ada keuntungan lain seperti penyebaran yang lebih sederhana dan lebih cepat. Sudahkah Anda memutuskan untuk memperluas modul atau layanan dengan fungsi baru? Alih-alih, pertimbangkan kemungkinan mengembangkan layanan atau modul terpisah, dan apa pro dan kontra dari pendekatan ini.
6. Bagikan dokumen desain dalam tim / organisasi dan kumpulkan umpan balik. Sebelumnya, di Uber, kami mengirimkan semua dokumen desain untuk perangkat lunak kepada semua teknisi kami - hingga saat staf kami bertambah menjadi 2.000 orang. Sekarang kami telah berkembang ke skala seperti itu, kami masih berusaha menjangkau audiens sebanyak mungkin - tetapi pada saat yang sama kami telah mulai memastikan bahwa tingkat kebisingan informasi tidak melebihi batas yang diizinkan. Dorong orang lain untuk bertanya dan menyarankan alternatif. Pragmatis tentang batas waktu untuk mendiskusikan umpan balik dan memasukkannya ke dalam dokumen jika perlu. Keinginan khusus dapat diterapkan segera dan cepat, sementara umpan balik terperinci lebih baik dibongkar dengan seseorang secara langsung.

Mengapa pendekatan kami berbeda dari apa yang biasanya disebutkan dalam literatur tentang arsitektur perangkat lunak? Sebenarnya, pendekatan kami pada dasarnya tidak begitu berbeda dari apa yang dijelaskan dalam manual arsitektur. Hampir semua manual menyarankan dimulai dengan tugas bisnis, serta menjelaskan solusi dan pertukaran - kami juga melakukan ini. Apa yang tidak kami lakukan adalah tidak menggunakan alat yang lebih canggih yang dianjurkan oleh banyak arsitek dan buku arsitektur. Kami mendokumentasikan desain sesederhana mungkin, menggunakan alat paling sederhana dan paling jelas, seperti Google Documents atau Office 365.

Saya percaya bahwa perbedaan utama dalam pendekatan kami adalah budaya rekayasa perusahaan yang berbeda. Tingkat otonomi yang tinggi dan hierarki yang diminimalkan adalah fitur yang umum di antara perusahaan teknologi modern dan perusahaan pemula; dalam kasus perusahaan yang lebih tradisional, ini jauh dari selalu benar. Ini juga alasan mengapa di tempat-tempat ini mereka sering menggunakan "desain berdasarkan akal sehat" alih-alih desain berdasarkan pada proses dengan aturan yang ketat.

Saya tahu bank dan perusahaan mobil, di mana pengembang secara aktif berkecil hati membuat keputusan arsitektur tanpa harus naik rantai, mendapatkan persetujuan dari arsitek beberapa tingkat lebih tinggi, yang mengawasi beberapa tim. Ini membuat proses lebih lambat, dan dengan sejumlah besar permintaan, arsitek menjadi kelebihan beban. Oleh karena itu, para arsitek ini bahkan membuat dokumen yang lebih formal, dengan harapan sistem akan menjadi lebih mudah dipahami - menggunakan semua alat yang literatur yang Anda kenal menjelaskan. Dokumen-dokumen ini didukung oleh pendekatan top-down, karena bertindak dengan cara yang mengintimidasi para insinyur - lagi pula, mereka bukan arsitek, dan tidak boleh meragukan atau membantah keputusan, karena mereka telah didokumentasikan dengan menggunakan metode formal di mana mereka kurang berpengalaman. Karena itu, mereka biasanya tidak melakukannya. Jujur, perusahaan-perusahaan ini melakukan hal yang sama untuk membuat pengembang menjadi sumber daya yang dapat dipertukarkan - karena ini memungkinkan mereka untuk memindahkan orang dari satu proyek ke proyek lain dalam waktu singkat. Mungkin tidak akan mengejutkan bagi Anda bahwa alat yang berbeda lebih cocok untuk lingkungan yang berbeda.

Desain perangkat lunak sederhana tanpa jargon, bukan pola arsitektur

Tujuan dari perancangan sistem haruslah kesederhanaan. Semakin sederhana sistem, semakin mudah untuk dipahami - dan semakin mudah untuk menemukan masalah di dalamnya, serta mengimplementasikannya. Semakin jelas bahasa yang digunakan untuk mendeskripsikannya, semakin mudah diakses desainnya. Hindari menggunakan jargon yang tidak akan dipahami oleh setiap anggota tim - bahkan kolega Anda yang paling tidak berpengalaman harus dapat memahami apa yang dipertaruhkan di tingkat orang lain.

Desain bersih seperti kode bersih: mudah dibaca dan mudah dimengerti. Ada banyak cara bagus untuk menulis kode bersih. Namun, Anda akan sering mendengar bahwa seseorang menyarankan memulai dengan menerapkan pola desain "geng empat" pada kode Anda. Kode bersih dimulai dengan prinsip tanggung jawab tunggal, nama yang jelas, dan konvensi yang mudah dipahami. Prinsip-prinsip ini berlaku untuk arsitektur murni.

Jadi apa peran pola arsitektur? Saya menemukan mereka berguna - sama bermanfaatnya dengan pola desain kode. Mereka dapat memberi Anda ide tentang bagaimana Anda dapat meningkatkan kode atau arsitektur Anda. Ambil pola desain kode: Saya memperhatikan diri saya ketika saya melihat singleton dalam kode - dan saya mengangkat alis dan menggali lebih dalam ketika saya melihat kelas yang berperilaku seperti fasad , tetapi sebenarnya itu hanya membuat panggilan. Tetapi hari belum tiba ketika saya berpikir, "sebuah pabrik abstrak hanya memintanya di sini." Sebenarnya, perlu waktu lama bagi saya untuk mengetahui apa yang dilakukan pola ini dan sebelum saya sadar; Pemahaman muncul sebagai hasil kerja keras dengan injeksi ketergantungan , salah satu dari sedikit area di mana pola ini tersebar luas dan sangat berguna . Saya juga mengakui bahwa meskipun saya menghabiskan banyak waktu membaca dan memahami pola desain "geng empat", mereka memiliki pengaruh yang jauh lebih kecil pada pengembangan profesional saya sebagai seorang programmer daripada umpan balik yang saya terima dari pengembang lain mengenai kode saya.

Demikian juga, mengetahui pola arsitektur umum adalah hal yang baik: itu membantu mengurangi waktu yang dihabiskan dalam diskusi dengan orang-orang yang memahaminya dengan cara yang sama Anda lakukan. Tetapi pola arsitektur bukanlah tujuannya, dan mereka tidak akan menjadi pengganti untuk pilihan desain sistem yang lebih sederhana. Ketika Anda merancang suatu sistem, Anda mungkin tiba-tiba menyadari bahwa Anda secara tidak sengaja menerapkan beberapa pola umum - dan ini bagus, karena nanti akan lebih mudah bagi Anda untuk merujuk pada pendekatan yang digunakan. Tetapi Anda tidak boleh mengambil satu atau lebih pola dan menggunakannya sebagai palu, yang Anda akan selalu melihat paku.

Pola arsitektur muncul ketika para insinyur memperhatikan fakta bahwa dalam situasi tertentu masuk akal untuk membuat keputusan serupa mengenai desain dan implementasinya. Seiring waktu, keputusan ini menerima nama, dicatat dan dibahas oleh masyarakat umum. Pola arsitektur adalah alat yang muncul setelah solusi ditemukan, dengan harapan ini akan membantu membuat hidup lebih mudah bagi orang lain. Sebagai seorang insinyur, Anda harus menetapkan sebagai tujuan Anda pencarian independen untuk solusi untuk masalah Anda dan belajar selama proses ini - alih-alih mengambil pola arsitektur "hype" dengan harapan bahwa ini akan menyelesaikan masalah Anda.

Cara belajar bagaimana merancang sistem yang lebih baik

Orang-orang sering meminta saran kepada saya: bagaimana cara "memompa" dalam arsitektur dan desain sistem? Insinyur berpengalaman biasanya merekomendasikan membaca tentang pola arsitektur, serta buku tentang arsitektur perangkat lunak. Saya sepenuhnya mendukung rekomendasi untuk membaca sebanyak mungkin - terutama buku, karena mereka memungkinkan Anda untuk masuk ke dalam subjek jauh lebih dalam daripada posting pendek - namun, saya punya beberapa rekomendasi yang lebih praktis.

• Libatkan salah satu anggota tim dan lakukan papan tulis bersama. Gambarlah di papan tulis apa yang sedang Anda kerjakan dan jelaskan arti gambar itu. Pastikan kolega Anda memahami apa yang dikatakan. Dan ketika Anda akhirnya mengerti, mintalah umpan balik.
• Jelaskan desain Anda dalam dokumen sederhana dan bagikan dengan tim Anda, minta mereka untuk umpan balik. Tidak masalah seberapa sederhana atau kompleks tugas yang sedang Anda kerjakan - bisa berupa refactoring kecil atau proyek skala besar - Anda harus meringkasnya dengan ringkas. Lakukan sedemikian rupa sehingga bagi Anda dokumen ini masuk akal, dan untuk yang lain dapat dimengerti; untuk inspirasi - inilah contoh bagaimana ini dilakukan di Uber . Bagikan dokumen ini dengan tim Anda dalam format yang memungkinkan untuk berkomentar - misalnya, menggunakan Google Documents, Office 365 atau yang serupa. Mintalah orang lain untuk melengkapi dengan pikiran dan pertanyaan mereka.
• Buat dua desain yang berbeda dan kontras. Ketika kebanyakan dari kita mendesain arsitektur, mereka biasanya berjalan satu arah: jalan yang muncul di kepala mereka. Namun, arsitektur bukanlah sesuatu yang hitam dan putih. Munculkan opsi desain arsitektur kedua yang mungkin cocok untuk situasi Anda juga. Bandingkan kedua desain dan jelaskan mengapa yang satu lebih baik dari yang lain. Tunjukkan bahwa Anda telah mempertimbangkan opsi kedua untuk beberapa waktu sebagai alternatif, dan jelaskan mengapa Anda membuat keputusan yang tidak menguntungkannya.
• Tentukan kompromi yang siap Anda buat - cari tahu mengapa Anda menerimanya dan apa yang ingin Anda capai dengan bantuan mereka. Tentukan dengan jelas batasan yang ada yang terpaksa Anda perhitungkan.
• Melakukan tinjauan terhadap desain orang lain. Dan lakukan dengan bijak. Jika perusahaan Anda memiliki budaya berbagi desain yang dibagikan orang menggunakan papan tulis, rapat, atau dokumen - dapatkan lebih banyak darinya. Biasanya selama peninjauan, orang menganggap desain kode orang lain sebagai pengamat; alih-alih, ajukan pertanyaan klarifikasi untuk bagian-bagian yang tidak Anda mengerti. Tanyakan alternatif apa yang mereka pertimbangkan. Tanyakan kompromi apa yang mereka buat dan batasan apa yang mereka pertimbangkan. Jadilah penasihat setan dan sarankan alternatif lain yang mungkin lebih sederhana - bahkan jika itu tidak lebih baik daripada solusi mereka - dan tanyakan pendapat mereka tentang proposal Anda. Meskipun Anda belum memikirkan desain Anda dengan sangat baik dibandingkan dengan orang yang mempresentasikannya, diskusi Anda masih dapat membawa sesuatu yang baru dan membantu Anda lebih memahami tugas yang Anda lakukan.

Desain perangkat lunak terbaik sederhana dan mudah dimengerti. Lain kali Anda memulai proyek baru, alih-alih merenungkan pertanyaan, " Bagaimana saya merancang sistem ini, pola apa yang harus saya gunakan dalam pertempuran dan dengan metodologi formal apa yang harus saya dokumentasikan? ", Pikirkan - " Bagaimana saya bisa sampai pada desain sesederhana mungkin - yang akan mudah dimengerti oleh siapa pun? "

Praktik terbaik arsitektur perangkat lunak, pola arsitektur aplikasi perusahaan, cara formal menggambarkan sistem adalah semua alat yang berguna untuk dimiliki, karena suatu hari mereka dapat sangat berguna bagi Anda. Tetapi ketika merancang sistem, ada baiknya memulai dengan yang sederhana dan terus membuatnya sesederhana mungkin. Cobalah untuk menghindari kompleksitas yang dibawa oleh arsitektur dan alat formal yang lebih kompleks ke sistem Anda.

Posting ini menyebabkan diskusi panas antara pekerja industri yang berbagi pengalaman dan sikap mereka terhadap arsitektur perangkat lunak. Anda dapat membaca diskusi ini di Hacker News , Lobste.rs, dan Reddit .

Sementara sebagian besar komentator setuju dengan pesan utama artikel tersebut, yang lain memperhatikan bahwa pada kenyataannya pendekatan semacam itu mungkin tidak berlaku untuk dunia "perusahaan berdarah", di mana arsitek "memakan roti mereka" dengan alasan yang baik; mereka bertanya pada diri sendiri bagaimana sistem yang dirancang sedemikian rupa 20 tahun kemudian akan terlihat seperti dan mengingat "teori windows pecah", dan juga berbicara tentang integrasi 300 sistem TI , yang menurut definisi tidak dapat sederhana - karena masing-masing dari mereka memiliki API unik, beberapa sistem bekerja pada Kobol dan masing-masing melayani dari 5.000 hingga 7.000 operator.