Bagaimana saya berhenti mendesain dan mulai merancang proyek ini seperti yang disarankan oleh pemimpin saya? [Tutup]

Saya seorang pengembang junior (~ 3 tahun exp.) Dan di pekerjaan saya, kami sedang dalam proses merancang sistem baru. Pengembang utama saya akan menjadi arsitek utama, namun dia menantang saya untuk mencoba merancang sistem sendiri (secara paralel).

Selama beberapa iterasi ide-ide brainstorming dan mengusulkan apa yang saya lihat sebagai saran arsitektur, kepemimpinan saya telah memberi saya umpan balik bahwa sebagian besar dari apa yang saya lakukan adalah "merancang" dan bukan "merancang".

Dia menggambarkan perbedaan itu sebagai arsitektur yang menjadi agnostik-implementasi sedangkan desain adalah deskripsi dari suatu implementasi. Dia mengatakan saya harus melepas topi desainer saya dan mengenakan topi arsitek saya. Dia memberi saya sedikit nasihat tentang cara melakukannya, tetapi saya juga ingin bertanya kepada Anda:

Bagaimana saya keluar dari mode perancang perangkat lunak dan mulai berpikir lebih seperti seorang arsitek?

Berikut adalah beberapa contoh "desain" yang saya buat yang tidak terlihat relevan dengan arsitektur oleh pemimpin saya:

1. Saya datang dengan suatu algoritma untuk memuat dan membongkar sumber daya dari sistem kami dan pimpinan saya mengatakan bahwa algoritma secara kategoris bukan arsitektur.
2. Saya datang dengan serangkaian acara yang harus dinaikkan sistem dan dalam urutan apa ia harus membesarkannya, tetapi ini juga tampaknya tidak memotongnya sebagai arsitektur.

Saya tampaknya terjebak dalam detail dan tidak melangkah mundur cukup jauh. Saya menemukan bahwa bahkan ketika saya datang dengan sesuatu yang berada pada tingkat arsitektur, saya sering tiba di sana dengan mencoba berbagai implementasi dan mencari-cari detailnya kemudian generalisasi dan abstrak. Ketika saya menggambarkan ini sebagai petunjuk, dia mengatakan bahwa saya mengambil pendekatan yang salah: saya harus berpikir "top down" dan bukan "bottom up".

Berikut adalah beberapa detail yang lebih spesifik tentang proyek ini :

• Proyek yang kami buat adalah aplikasi web.
• Saya memperkirakan sekitar 10-100 ribu baris kode.
• Kami baru memulai. Tim teknik kami adalah sekitar 3-5 orang.
• Hal terdekat yang bisa saya bandingkan dengan aplikasi kami adalah CMS yang ringan. Ini memiliki kompleksitas yang sama dan sebagian besar berkaitan dengan pemuatan dan pembongkaran komponen, manajemen tata letak, dan modul gaya plug-in.
• Aplikasi ini ajax-y. Pengguna mengunduh klien sekali kemudian meminta data saat dibutuhkan dari server.
• Kami akan menggunakan pola MVC.
• Aplikasi akan memiliki otentikasi.
• Kami tidak terlalu peduli dengan dukungan browser lama (wah!), Jadi kami ingin memanfaatkan yang terbaru dan terhebat yang ada di sana dan akan keluar. (HTML5, CSS3, WebGL ?, Ekstensi Sumber Media, dan banyak lagi!)

Berikut adalah beberapa tujuan proyek :

• Aplikasi perlu ditingkatkan. Dalam waktu dekat pengguna kami akan berada di urutan ratusan hingga ribuan, tetapi kami berencana untuk puluhan ribu hingga jutaan dan lebih.
• Kami berharap aplikasi ini akan ada selamanya. Ini bukan solusi sementara. (Sebenarnya kami sudah memiliki solusi sementara, dan apa yang kami buat adalah pengganti jangka panjang untuk apa yang kami miliki).
• Aplikasi harus aman karena mungkin memiliki kontak dengan informasi pribadi yang sensitif.
• Aplikasi harus stabil. (Idealnya, itu akan stabil di sekitar tingkat gmail tetapi tidak perlu berada di ekstrem penjelajah Mars.)

Pertama-tama saya akan mengatakan bahwa perbedaan antara arsitektur dan desain terutama semantik. Beberapa tim memiliki poin pemeriksaan di antara keduanya. Pimpinan teknis Anda mendefinisikan arsitektur seperti sebelum desain dan arsitektur sebagai implementasi agnostik. Dari yang saya asumsikan kita berbicara tentang desain seperti dalam model air terjun dan bukan Desain Industri yang akan membantu Anda merancang produk dengan pandangan kepada pengguna sebelum Anda sampai ke arsitektur perangkat lunak. Saya pikir arsitektur sering tergelincir ke dalam desain dan itu tidak selalu merupakan hal yang buruk, seringkali sangat membantu bagi arsitek untuk memiliki pengetahuan yang mendalam tentang apa yang mungkin dalam sistem yang ada.

Setelah mengatakan semua itu, Anda memerlukan saran untuk situasi di mana Anda berada. Ada seluruh dunia arsitektur perangkat lunak di luar sana, makalah, buku, konferensi tetapi Anda umumnya mencari pola dan abstraksi. Tanpa rincian lebih lanjut tentang proyek ini saya hanya bisa memberikan contoh yang luas. Misalnya, jika Anda bekerja dalam integrasi ada Arsitektur Berorientasi Layanan ( SOA) pola di mana Anda membagi bagian-bagian sistem menjadi 'layanan' sehingga Anda dapat bekerja dengan masing-masing bagian dengan cara yang ditentukan, dalam program web ini sering kali diimplementasikan sebagai Layanan Web (meskipun seharusnya tidak terbatas pada itu) dan baru-baru ini munculnya API tenang dengan JSON, sekali lagi saya akan mengatakan ini adalah desain yang berasal dari arsitektur SOA. Saya akan mengatakan Model, View, Controller (MVC) adalah contoh lain dari pola arsitektur yang umum digunakan, membagi tanggung jawab komponen-komponen suatu sistem untuk memungkinkan bagian untuk ditukar, mengandung kesalahan dan pengujian.

Dari tingkat 10.000 kaki, jika Anda bisa menggambarnya di papan tulis dan menjelaskannya kepada seorang programmer yang kompeten yang tidak bekerja di bidang Anda dan tidak tahu bahasa pemrograman Anda dan detail implementasi saat ini maka itu mungkin arsitektur. Jika Anda dapat menulis buku tentang hal itu bahwa siapa pun di luar perusahaan Anda akan peduli maka itu mungkin arsitektur. Jika Anda menemukan detail penjelasan sendiri dan tidak dapat menggeneralisasikannya ke basis kode / perusahaan / industri lain, itu mungkin desain.

Saya setuju bahwa dua contoh yang Anda berikan adalah desain kode dan bukan arsitektur. Yang pertama karena saya pikir ketika Anda mengatakan Anda datang dengan 'algoritma' untuk memuat sumber daya saya pikir Anda maksud Anda merancang serangkaian instruksi untuk menyelesaikan tugas itu, dan bukan bahwa Anda merancang algoritma baru yang akan mereka ajarkan di tahun pertama COMSC tahun depan. Dalam contoh kedua, sekali lagi saya setuju itu desain. Jika Anda menunjukkan kepada saya salah satu dari gagasan ini, saya tidak akan dapat menggunakannya dalam proyek perangkat lunak acak saya. Anda harus pergi ke 'level yang lebih tinggi', Object Oriented (OO) di Jawa daripada saya ingin Kelas Pelanggan menjadi sub-kelas Kelas Person. Bahkan berbicara tentang Pengecualian secara umum dapat dianggap tingkat terlalu rendah (terlalu dekat dengan implementasi).

Untuk mencoba membahas spesifik yang Anda daftarkan, saya pikir apa yang harus Anda pikirkan adalah bagaimana merancang CMS berbasis web. Wordpress memiliki kodeks arsitektur situs di mana mereka berbicara banyak tentang detail implementasi desain tetapi jelas dari pos bahwa arsitektur utama mereka berpusat membuat Wordpress dapat diperluas dengan tema. Merancang antarmuka yang jelas untuk tema sedemikian rupa sehingga dapat ditulis oleh seseorang di luar perusahaan jelas merupakan keputusan arsitektur yang mereka ambil. Ini adalah hal-hal yang baik untuk ditulis di atas kertas ketika merancang solusi 'jangka panjang' Anda (bukan sementara) sehingga semua keputusan desain dan implementasi yang dibuat selama pengembangan (oleh semua pengembang bukan hanya arsitek) sejalan dengan ide ini.

Contoh arsitektur lain untuk situasi Anda:

1. Menempatkan semuanya pada mesin virtual, di-host pada penyedia cloud atau in-house dan memiliki mesin virtual tanpa kewarganegaraan, sehingga setiap mesin yang gagal dapat diganti dengan mesin virtual baru tanpa harus menyalin seluruh negara bagian atau kehilangan informasi apa pun.
2. Membangun pengujian kegagalan produksi langsung dari awal dengan kekacauan simian .

Mungkin mencoba menggambar seluruh sistem di papan tulis. Cobalah pada level detail yang berbeda, board pertama bisa berupa GUI-> dispatcher-> backend-> DB atau sesuatu, dan kemudian menelusuri hingga Anda mulai menggunakan kata ganti.

Perbedaan antara kedua ide ini sangat penting di tempat saya bekerja.

Apa yang Anda sebut "arsitektur," kami sebut "pemrograman dalam bahasa Inggris." Ini sebagian penting karena jika Anda tidak dapat menggambarkannya kepada non-programmer, maka ada sesuatu yang salah. Mungkin Anda tidak cukup memahami masalahnya, ATAU mungkin Anda memecahkan masalah "hantu" (tidak dibahas di sini).

Istilah yang digunakan untuk dua aspek desain yang berbeda ini seringkali berbeda, tetapi prinsip-prinsipnya sudah dikenal di mana-mana. Satu aspek (dalam kasus Anda arsitek, dalam kasus saya perancang) program dalam bahasa Inggris, sedangkan yang lain (dalam kasus Anda "desainer," dalam kasus saya "pengembang") program dalam bahasa tertentu. Mereka juga cukup umum dibedakan sebagai "desain" dan "implementasi." "Desain" menjadi apa yang seharusnya dicapai, dan "implementasi" menjadi kode yang mewujudkannya.

Beberapa contoh dari apa yang saya kerjakan:

Arsitektur dari satu program adalah: kita membutuhkan Manajer atau hub yang terpusat sehingga kita dapat dengan mudah menambahkan modul. Manajer ini akan mendistribusikan acara ke semua modul yang terdaftar. Modul dapat mendaftar sendiri dengan Manajer Acara, dan dengan demikian menerbitkan acara ke seluruh sistem, dan menerima acara yang dipedulikannya. Setiap modul memiliki "kotak surat" yang dapat diperiksa dan dikosongkan sesuai keinginan. Ini akan memungkinkan kita mengakomodasi modul-modul baru yang belum kita ketahui kita butuhkan.

Tidak ada kode di sana. Bisa ditulis dalam bahasa apa saja. Implementasi tidak ditentukan oleh uraian ini.

Arsitektur proyek lain adalah: kita perlu cara untuk memulai dan menghentikan program lain dengan andal tanpa menunggu mereka. Kami dapat memiliki manajer yang bertanggung jawab untuk program tertentu. Kami hanya bisa mengatakannya untuk memulai atau menghentikan programnya dan manajer menanganinya. Jika program lain ini diminta untuk berhenti dan tidak dalam waktu tertentu, manajer tahu bagaimana memaksanya untuk berhenti, dan membersihkan kekacauan. Program tidak dimulai atau dihentikan oleh hal lain, dan manajer dapat ditanya apakah programnya sedang berjalan, berhenti, atau menunggu untuk berhenti. Ini memungkinkan kita melanjutkan hal-hal lain yang perlu kita lakukan, sambil tetap memulai dan menghentikan program-program lainnya.

Sekali lagi, tidak ada yang menentukan implementasi, meskipun beberapa implementasi jelas lebih bermanfaat daripada yang lain.

Perbedaan antara desain (apa yang kita sebut pola atau implementasi) dan arsitektur (apa yang kita sebut desain) adalah bahwa salah satu dari mereka memecahkan masalah pengkodean / implementasi dan yang lainnya memecahkan masalah dunia nyata.

Mungkin ini akan membantu. Saya selalu melihat senioritas seorang insinyur sebagai pertanyaan seberapa besar masalah yang bisa mereka selesaikan sendiri.

Secara kasar, untuk menyampaikan gagasan:

• Anda dapat memberi seseorang yang baru untuk memprogram tugas-tugas kecil yang berisi dengan banyak instruksi eksplisit tentang bagaimana tugas tersebut perlu diintegrasikan dengan karya lain

• Dev tingkat menengah adalah seseorang yang dapat mengambil deskripsi dari sebagian aplikasi, dan membuatnya berfungsi dalam konteks aplikasi itu.

• Seorang pengembang senior dapat membangun aplikasi berukuran sedang dari awal, dalam batasan teknis sebuah toko.

• Pengembang yang lebih senior dapat melakukan itu, dan membuat pilihan teknologi di sepanjang jalan tentang teknologi apa yang akan digunakan untuk membuatnya bekerja dengan baik.

... tapi itu bukan aturan yang keras dan cepat. Dan beberapa orang keluar dari gerbang sebagai IMHO "senior", bahkan jika mereka harus menghabiskan waktu dengan judul yang berbeda.

Apa yang diminta arsitek adalah untuk melihat masalahnya bahkan lebih umum dari itu. Jika Anda harus mengumpulkan sejumlah aplikasi untuk membuat sistem bekerja:

• Aplikasi dan layanan apa yang Anda butuhkan?
• Potongan apa yang berinteraksi dengan pelanggan, dan mana yang saling berinteraksi?
• Bagaimana mereka berkomunikasi?
• Di mana mereka akan menyimpan data?
• Di mana risiko kegagalan?
• Bagaimana Anda akan memberikan keandalan?
• Bagaimana Anda akan memberikan keamanan?

Jadi, dalam arti arsitektur teknis seperti arsitektur bangunan. Itu tata letak, atau rencananya. Ini menunjukkan whats diperlukan untuk berbagai bagian, bagaimana mereka terus bersama-sama, dan sama pentingnya mengapa .

(BTW, saya memiliki kurva pertumbuhan yang sama yang dijelaskan kepada saya untuk arsitek, mulai dari merancang keluarga aplikasi terkait atau serangkaian fitur yang sangat kompleks, hingga menetapkan arahan teknis untuk suatu kelompok, hingga membuat keputusan teknis strategis untuk seluruh organisasi. .)

Yang mengatakan, saya pikir sebagian besar insinyur di semua tingkatan harus melakukan "arsiteking" juga. Itu bukan garis yang cerah. Kedengarannya seperti jika Anda fokus pada Gambaran Besar terlebih dahulu, dan tidak terpaku pada detail implementasi, Anda akan lebih sesuai dengan apa yang dia cari. BTW kemampuan untuk melihat Gambaran Besar serta Detail Kecil adalah aset besar dalam industri ini, jadi ini terdengar seperti peluang besar.

... Ini analoginya. Katakanlah Anda diminta membuat Kotak Hitam Ajaib. Sebagai seorang insinyur, Anda diharapkan untuk terobsesi dengan cara kerja Kotak Hitam Ajaib. Tetapi sebagai seorang arsitek, fokus Anda berbeda. Anda mungkin mengintip ke dalam kotak karena penasaran, tetapi Anda diharapkan untuk terobsesi dengan segala hal di sekitar semua Kotak Hitam Ajaib.

Mirip dengan analogi itu, Anda mungkin berpikir tentang peran arsitektur sebagai memandang seluruh sistem sebagai kotak ajaib. Jadi jika mengambil Kotak Kaca Raksasa dan Anda menempatkan pelanggan, aplikasi klien, firewall, tingkat layanan, basis data, dan bahkan orang-orang di dalamnya, maka sebagai arsitek Anda akan terobsesi tentang cara membuat kotak sistem yang sangat besar itu. bekerja dengan baik .

Perbedaan yang tepat antara "desain" dan "arsitektur" agak subyektif dan ada beberapa tumpang tindih. Namun, ini perbedaannya seperti yang saya pahami:

Arsitektur melihat konsep tingkat tinggi. Siapa saja aktor dalam sistem? Apa objek utama dan mana yang bertanggung jawab untuk apa? Ketika saya berpikir arsitektur, saya pikir Visio, bukan kode.

Misalnya, sistem acara mungkin memiliki manajer acara yang menerima acara yang masuk dan mengirimkannya ke penangan acara. Gagasan utas, asinkron, v. Sinkron, dan konsep tingkat rendah lainnya tidak ikut berperan di sini. MVC adalah contoh lain: detail spesifik tidak ditentukan pada tingkat tinggi tentang bagaimana tiga potong berinteraksi, hanya ada tiga masalah terpisah yang ditangani oleh paket kode terpisah.

Desain melibatkan pembuatan prototipe, membuat sketsa antarmuka kode, kerangka kode, dll. Desain ini berada di antara arsitektur abstrak dan pekerjaan "kode monyet" tingkat rendah.

Dalam kerangka kerja acara, desain mungkin mengatakan "sebuah acara menggunakan antarmuka ini," dan "ada kumpulan thread yang digunakan manajer acara untuk mengirimkan acara ke pekerja." Sebuah desain untuk MVC mungkin "menggunakan Hibernate untuk model, Spring untuk controller, dan GWT untuk tampilan."

Ketika saya melakukan pekerjaan desain, saya telah membuat sketsa antarmuka dan kerangka kode, kemudian menyerahkan hasilnya kepada programmer. Terkadang saya programmer itu. Tapi itu adalah dua fase terpisah, dan keduanya lebih mengarah pada beton daripada arsitektur.

Mengenakan topi arsitektur berarti menjernihkan pikiran Anda dari kode dan memikirkan objek di papan tulis. Pikirkan objek, paket, kerangka kerja, dan aliran pesan di antara mereka. Jika Anda berpikir hanya satu baris kode, Anda salah melakukannya. Jangan terjebak dalam sesuatu seperti "oh, pesan itu bisa berupa string, atau menggunakan SOAP, atau apa pun." Pada level ini, fakta bahwa komunikasi sedang terjadi sudah cukup. Detail tidak relevan.

Jika saya dapat menambahkan apa pun di sini, itu adalah: jangan pikirkan kode . Sama sekali.

Jangan berpikir bagaimana Anda akan menulis kode untuk mencapai sesuatu, tetapi pikirkan tentang apa metode terbaik untuk mencapainya. Deskripsi Anda tentang apa yang perlu Anda lakukan harus agnostik-bahasa , sehingga Anda akan berbicara pola desain - yang merupakan "bahasa" yang umum di antara pengguna bahasa pemrograman yang berbeda - untuk membahas cara melanjutkan.

Untuk kasus penggunaan khusus Anda, lebih banyak pertanyaan arsitektur menurut saya akan sejalan:

• Mengapa Anda menggunakan MVC? Apakah hanya itu yang Anda ketahui? Apakah ada pola yang lebih baik untuk digunakan? Mengapa?
• Kerangka apa yang akan Anda gunakan, dan mengapa ?
• Bagaimana skala Anda? Tidak bijaksana kode, karena itu belum masalah. Apa yang akan menjadi syarat untuk skala secara horizontal; layanan apa (AWS) yang akan Anda gunakan untuk melakukan ini?
• Bagaimana otentikasi akan dilakukan? Bukan kode-bijaksana: apakah Anda akan membuat token acak dan unik pada setiap permintaan dan memeriksanya terhadap token yang diharapkan? Jangan pikirkan bagaimana Anda akan melakukan ini dalam kode. Pikirkan mengapa Anda melakukan ini - karena ini dapat dilakukan dalam hampir semua bahasa web.

Pada dasarnya, jangan bicara sama sekali tentang kode. Bahkan jika Anda tidak tahu bagaimana melakukan sesuatu, ketika ada kemauan, ada caranya . Pikirkan lebih lanjut tentang bagaimana potongan-potongan teka-teki akan cocok dengan yang terbaik, sebelum Anda benar-benar khawatir untuk menyatukannya.

Pikirkan semua operasi (mis. Kasus penggunaan) yang dapat dilakukan oleh sistem Anda. Untuk setiap operasi, dokumentasikan apa yang terjadi dalam hal domain bisnis Anda untuk setiap operasi. Anda hanya boleh berbicara dalam hal domain masalah Anda dan tidak menjelaskan detail implementasi apa pun. Gambarlah sebuah blok besar dan sebutlah Sistem. Kombinasi "blok besar" ini dan deskripsi operasi adalah arsitektur sistem level tertinggi.

Meskipun arsitektur tingkat tinggi ini memberikan titik awal yang layak, sebenarnya tidak banyak nilainya saat membangun sistem yang sebenarnya. Anda harus mencatat satu tingkat detail untuk mengubahnya menjadi arsitektur yang bermanfaat.

Jadi Anda mengikuti ide umum yang sama dengan pendekatan "blok besar" hanya Anda mulai menambahkan "sub-blok" yang diperlukan untuk menyelesaikan setiap operasi. "Sub-blok" ini sering disebut kelas atau modul domain. Ini mudah diidentifikasi dengan menggunakan deskripsi operasi Anda (dari pendekatan blok besar) dan menggambar diagram urutan. Mereka disebut kelas domain karena mereka tidak dimaksudkan untuk menjadi kelas "nyata", tetapi mereka dimaksudkan untuk menggambarkan sistem Anda dalam hal domain masalah sistem Anda.

Hasil akhir dari membuat semua diagram urutan dan mengidentifikasi semua "sub-blok" adalah bahwa Anda sekarang memiliki daftar kelas domain dan daftar operasinya. Ini biasanya berakhir dengan arsitektur perangkat lunak yang cukup dapat digunakan, di mana masing-masing "sub-blok" / modul dapat dibagikan kepada pengembang yang berbeda untuk merancang dan mengimplementasikan.

Tentu saja, jika Anda membiarkannya seperti itu, maka desainer Anda akan memiliki banyak interaksi satu sama lain dalam mendefinisikan antarmuka antar modul. Dengan demikian, arsitek juga dapat memutuskan mekanisme antarmuka spesifik dan tipe data yang akan digunakan antar modul.

Juga, beberapa "sub-blok" masih akan sangat rumit di bawah tenda. Jadi pengulangan lain dari pendekatan "sub-blok" mungkin diperlukan tetapi hanya kali ini pada salah satu modul yang baru diidentifikasi.

Akhirnya, mungkin ada beberapa pola / batasan khusus antara antarmuka yang arsitek ingin agar sistem patuhi (misalnya, callback peristiwa versus pemanggilan metode langsung), sehingga keputusan itu perlu dibicarakan dalam desain arsitektur. Plus mungkin ada modul "umum" yang arsitek ingin semua orang gunakan.

Sebagai pengembang, Anda mungkin terbiasa memberikan solusi. Itu adalah cara berpikir yang sangat baik, tetapi mungkin menghalangi Anda ketika harus berpikir tentang arsitektur.

Saya menemukan bahwa itu membantu untuk menggambarkan masalah yang Anda coba selesaikan terlebih dahulu. Apa saja persyaratannya? Apa saja kendalanya? Bisakah Anda berbicara dengan pemangku kepentingan untuk mengetahui persyaratan ini?

Mungkin membantu jika Anda dapat mendeskripsikan tujuan desain Anda sendiri juga. Apakah solusi Anda perlu ditingkatkan, atau apakah desain untuk satu pengguna cukup? Berapa lama solusi Anda perlu tetap valid? Apakah ini perbaikan satu kali, atau solusi infrastruktur jangka panjang? PErhaps juga penting: Apa batas yang diterima arsitektur Anda?

Dan karena ini adalah pengalaman belajar, jangan takut untuk bertanya, bahkan jika itu konyol.