Secara tradisional, proses pengembangan perangkat lunak dibandingkan dengan konstruksi. Istilah "arsitek" hanya memperkuat hubungan asosiatif antara proses-proses ini. Tetapi kenyataan modern membuat model ini tidak relevan, karena ada mekanisme yang tidak bisa dijelaskan:
- Jika kita membuat semacam objek fisik atau produk, lalu mengapa perangkat lunak tidak pernah dianggap lengkap?
- Jika kita berbicara tentang solusi teknik, lalu mengapa kita tidak pernah bisa dengan yakin merencanakan ke depan?
- Jika kita arsitek atau pembangun, lalu mengapa begitu banyak proyek berakhir dengan kegagalan?
- Dan akhirnya, dengan begitu banyak tips, praktik terbaik, prinsip, buku, dan laporan pengembangan perangkat lunak, mengapa begitu banyak proyek berubah menjadi tempat kerja yang tak tertahankan?
Saya mengusulkan terjemahan laporan brilian Sarah May "Kode layak huni", yang dekat dengan teks, di mana dia mempertimbangkan semua masalah ini.
Mengapa penting memiliki model?
Model ini memungkinkan kita untuk menggambar analogi antara proses yang tidak dikenal atau sulit dipahami dan sesuatu yang akrab, dapat dipahami oleh kita. Selain itu, tidak hanya cocok untuk menggambarkan situasi ketika semuanya baik-baik saja, tetapi, seperti analogi yang baik, model harus memandu kita dalam situasi batas.
Proses pengembangan perangkat lunak adalah kombinasi dari dua entitas yang saling terkait, berinteraksi, namun terpisah: kode dan tim.
Konfirmasi ini adalah hukum Conway. Hubungan entitas ini memberi tahu kita bahwa masalah dalam kode terkait dengan masalah dalam tim dan sebaliknya. Oleh karena itu, kami memiliki dua opsi untuk menyelesaikannya: di sisi kode dan di sisi tim.
Beberapa masalah tampaknya hanya masalah dengan kode, beberapa hanya dengan tim. Padahal, semuanya merupakan masalah dengan kedua komponen tersebut. Oleh karena itu, model baru harus sesuai untuk realitas modern dan mencerminkan hubungan antara kedua komponen proses pembangunan.
Deskripsi model baru
Ruang di mana aplikasi tinggal
Konstruksi bangunan memiliki tiga tahap berbeda: desain, konstruksi dan pemeliharaan. Sebelumnya, pengembangan perangkat lunak tampak serupa: hasil pengembangan adalah produk jadi. Itu diinstal oleh pengguna dan ditransfer untuk mendukung grup terpisah, dan pengembang mulai melakukan sesuatu yang lain.
Namun dalam dunia aplikasi web, penyebaran dan rilis beberapa kali sehari, pada kenyataannya, tidak ada yang lengkap. Situasi serupa diamati pada aplikasi dan game seluler, ketika mereka diperbarui secara otomatis di konsol melalui Steam (paling sering pada saat yang paling tidak tepat). Selain itu, dalam lingkungan bisnis yang berubah, aplikasi harus fleksibel dan mampu berubah. Upaya pengembangan harus luar biasa untuk memastikan fleksibilitas ini. Hal yang sama tidak dapat diharapkan dari bangunan.
Infrastruktur yang kami gunakan saat mengembangkan aplikasi lebih seperti bangunan. Apa yang kita buat bukanlah bangunan itu sendiri, karena sebagian besar aplikasi aplikasi mengambil ruang dalam struktur yang telah didirikan. Kedengarannya seperti langkah turun dari arsitek ke desainer interior, tetapi ada banyak kekuatan dalam model seperti itu. Bangunan di dalamnya adalah dasar untuk aplikasi kita: fondasi adalah OS, tingkat parkir adalah bahasa pemrograman, bangunan itu sendiri adalah kerangka kerja yang digunakan, dan kami sedang mengembangkan aplikasi yang sudah ada di dalamnya.
Ruang internal (struktur) yang disediakan oleh bangunan dapat diubah, namun lebih sulit untuk mengubahnya daripada kode Anda sendiri. Sebanyak pembongkaran dinding lebih sulit daripada memindahkan furnitur. Dengan demikian, bangunan itu sendiri (kerangka kerja) memberlakukan batasan tertentu pada kemampuan dan penampilan interior Anda (aplikasi).
Setiap bangunan dioptimalkan untuk keperluannya sendiri. Aplikasi dapat ditempatkan di salah satu dari mereka, tetapi beberapa ruang akan lebih cocok untuk itu, dan beberapa akan lebih buruk. Oleh karena itu, kode yang akan Anda tempatkan di ruang preformed akan dihasilkan dengan cara tertentu oleh ruang ini.
Masih ada banyak pekerjaan bangunan di industri kami, tetapi kebanyakan dari kita masih mengerjakan interior (aplikasi).
Tujuan baru dalam pengembangan
Jika Anda menambahkan semua ini bahwa proyek tidak pernah dianggap selesai, Anda sampai pada kesimpulan bahwa kode bukanlah apa yang kita bangun, tetapi di mana kita tinggal . Ini membuat Anda melihat tujuan pengembangan dari sudut yang berbeda. Tempat di mana kita tinggal harus dibuat layak huni : cocok, nyaman dan nyaman untuk hidup. Dan tidak hanya untuk diri kita sendiri, tetapi juga bagi mereka yang tinggal bersama kita. Dalam hal kode, tidak cukup hanya dengan menyelesaikan produk dan melanjutkan. Itu juga harus dibuat layak huni : dapat dimengerti, didukung, dapat dikembangkan - untuk tim yang "hidup" di dalamnya.
Apa itu Kode Layak Huni?
Layak huni dalam kaitannya dengan rumah berarti Anda hidup di ruang di mana Anda dapat melakukan aktivitas sehari-hari dengan nyaman dan mudah. Ada lampu baca di kamar tidur, serbet di meja kopi, ada kotak untuk joystick di ruang tamu, dan ada dudukan sepeda di lorong.
Tetapi apa yang layak huni bagi sekelompok orang tergantung pada diri mereka sendiri. Rumah yang nyaman untuk orang tua muda dengan anak tidak seperti rumah untuk siswa atau orang tua, atau untuk orang tua tunggal dengan anak remaja.
Layak untuk kode berarti hal yang sama: Anda dapat mengubah atau menambahkan apa yang Anda inginkan, tetapi tanpa kerumitan dan gangguan yang berlebihan. Anda mengerti di mana, jadi dengan mudah melompat ke tempat yang tepat dalam kode dan bekerja dengannya. Di sini prinsipnya sama: fakta bahwa layak huni untuk satu tim tidak cocok untuk yang lain. Apa yang layak huni untuk satu senior dan empat junior berbeda dari layak huni untuk lima senior, dan sangat berbeda dari layak huni untuk tim outsourcing.
Orang-orang datang dan pergi, jadi membuat dan memelihara kode dalam kondisi layak huni adalah proses yang berkelanjutan. Penampilan anggota tim yang baru ini mirip dengan teman sekamar yang baru: dia memiliki sofa yang aneh, yang karena alasan tertentu dia sangat suka, jadi Anda dengan enggan setuju untuk menempatkannya di ruang tamu. Dan setelah beberapa hari, seorang tetangga menyarankan untuk mengganti gorden dan kerai, karena ada yang lebih ergonomis. Dan yang terburuk adalah dia mencuci piring dengan tab bukan spasi! 
Tapi sekarang kamu hidup bersama, jadi kamu harus bernegosiasi.
Ternyata suasana hati dan kondisi Anda lebih tergantung pada mereka yang tinggal bersama Anda daripada pada hal-hal khusus di apartemen dan bahkan lebih sedikit pada tata letaknya. Juga dengan kode: kesejahteraan Anda terutama tergantung pada orang-orang dengan siapa Anda bekerja, dan lebih sedikit pada kode itu sendiri atau kerangka kerja.
Bagaimana proyek menjadi berantakan
Tetapi bagaimana jika kode Anda terlihat seperti ruangan ini? Bagaimana membuatnya cocok untuk tim? Di mana untuk memulai?
Setuju, sulit untuk bergerak di sini, belum lagi memahami cara menertibkan. Mengapa rumah mencapai kondisi ini? Sering dikatakan bahwa ini adalah kemalasan. Psikolog berpikir secara berbeda: rumah menjadi seperti itu karena serangkaian keputusan yang tampaknya tidak signifikan.
Bayangkan bagaimana semuanya bisa dimulai. Ada ruangan kecil tempat Anda mencoba mengoptimalkan ruang: menambahkan beberapa rak dan laci, menggunakan ambang jendela. Untuk sementara, semuanya baik-baik saja: Anda tetap memesan setiap hari. Tetapi malam itu datang setelah hari yang sulit ketika Anda tidak keluar. Di pagi hari Anda ketiduran, dan ketika Anda kembali ke rumah, Anda makan malam tepat di meja Anda dan lupa untuk menghapus piring. Orang tua membawa barang-barang lama Anda selama akhir pekan. Tidak ada waktu untuk membongkar mereka dan Anda meletakkan kotak apa adanya. Dan Anda merasa bahwa ruangan tidak lagi berurutan, tetapi kondisinya sangat menyedihkan sehingga Anda tidak dapat memahami di mana harus mulai memperbaiki situasi dan segera berubah menjadi IT. Serangkaian keputusan salah kecil: ruangan sudah berantakan, mengapa tidak melempar buku ke lantai?
Hal yang sama terjadi dengan kode. Anda membuka file yang sudah buruk, setengah lusin pola yang tidak lagi berfungsi. Dan manajer berdiri di belakang Anda, menunggu bug diperbaiki. Hal pertama yang terlintas dalam pikiran adalah untuk memperbaiki bug dengan selotip sebanyak mungkin dan segera keluar dari sini.
Solusi lokal yang kelihatannya kecil ini adalah apa yang membuat kode tidak bisa hidup . Namun, ada cara untuk keluar dari lubang ini, yang kita gali sendiri.
Keselamatan melalui Perubahan dalam Kebiasaan
Pernahkah Anda memperhatikan bahwa di kebanyakan rumah yang berantakan dan terawat sering ada banyak majalah, kliping koran dengan interior yang indah dan nyaman? Ada juga foto, proyek, tips untuk pengaturan ruang hidup yang kompeten.
Orang-orang yang tinggal di rumah berantakan ingin hidup secara berbeda, mereka melihat semua majalah ini dan bercinta dengan interior yang sama, tetapi mereka tidak tahu bagaimana mencapainya. Dan mereka berpikir bahwa hanya beberapa keputusan penting, suatu peristiwa akan memungkinkan mereka untuk membuat rumah mereka sama seperti pada gambar.
Ada acara Hoarders di TV Amerika. Orang-orang yang hidup dalam kekacauan abadi setuju untuk berpartisipasi, sehingga tim profesional akan membersihkan dan membuat interior desainer di rumah mereka. Nah, dan seperti biasa, di akhir program, foto-foto indah SEBELUM dan SETELAH. Menariknya, sebagian besar peserta mengakui bahwa pada akhirnya rumah mereka kembali ke keadaan semula. Sederhana: urutan keputusan kecil yang salah yang sama mengarahkan mereka ke hasil sebelumnya.
Ternyata cara yang lebih efektif adalah secara bertahap bekerja lebih lama, bukan dengan isi rumah, tetapi dengan orang-orang itu sendiri. Tujuannya adalah mengubah kebiasaan mereka sehingga mereka menjaga ketertiban sebagai bagian dari kehidupan sehari-hari mereka. Sayangnya, produser akan menganggap opsi ini terlalu membosankan untuk sebuah reality show.
Kode yang berantakan berlaku dengan cara yang sama: kita bertarung setiap hari, hanya untuk menyelesaikan masalah saat ini, dan bermimpi untuk menulis ulang semuanya. Sekarang, jika kita hanya bisa mengulang semuanya, kita pasti tidak akan membuat kesalahan yang sama! Kita harus menulis ulang jQuery di Ember! Kita harus memotong monolit menjadi layanan mikro!
Terkadang berhasil, setidaknya cukup lama untuk menulis posting blog yang menang. Tapi kemudian lampu padam, kamera berhenti bekerja, kru film meninggalkan situs, dan jika Anda belum mengubah kebiasaan Anda, Anda berada dalam kekacauan lagi dan bahkan lebih cepat dari yang Anda pikirkan.
Orang-orang berpikir bahwa kesalahan besar membunuh kita: rumah itu terlalu kecil, tata letak tidak berhasil, kerangka kerja yang salah, monolit, tidak cukup sumber daya. Ini tidak benar. Kita terbunuh oleh keputusan yang sangat kecil yang disebabkan oleh kebiasaan dan cara berpikir.
Anda dapat menulis ulang apa pun yang Anda inginkan. Tetapi, jika tim Anda tidak mengubah kebiasaannya, maka Anda akan menemukan diri Anda berada dalam jaringan layanan mikro yang rumit, seperti halnya Anda memiliki jaringan kelas dan modul yang rumit dalam sebuah monolit.
Kebiasaan tim
Perlu dicatat bahwa kita tidak berbicara tentang individu, tetapi tentang kebiasaan dan norma tim. Ini menjelaskan mengapa citra pengembang sebagai individu profesional, pengrajin tidak mencerminkan kenyataan. Ini bukan pengembang terpisah yang malas dan tidak profesional. Ini adalah tim dengan budaya kerja tim yang lemah.
Sama seperti dengan teman sekamar: setiap orang harus melakukan pembersihan setiap hari, mencuci piring sendiri, secara berkala membersihkan kamar mandi dan toilet, membersihkan ruang tamu bersama. Tetapi ada kegiatan yang lebih kompleks untuk meningkatkan livability , yang dapat dibiarkan "hanya untuk tertarik". Misalnya, melebihi lemari dapur atau pilih meja yang cocok di ruang tamu alih-alih terlalu besar.
Tetapi pekerjaan sehari-hari adalah apa yang harus dilakukan setiap orang. Artinya, Anda dapat memiliki orang-orang di tim yang tertarik dalam refactoring arsitektur global, memecah modul terlalu besar, mengoptimalkan interaksi antara mereka dan mereka yang tidak ingin melakukan ini. Setiap orang tidak wajib berpartisipasi dalam penataan ulang furnitur, tetapi semua orang harus mencuci piring.
Dua ekstrem tidak dapat ditelusuri atau mengapa buku tidak berfungsi
Interior yang indah, bukan? Semuanya sangat cocok dan dipikirkan, tidak lebih. Dalam satu kata - mimpi. Sama seperti deskripsi pola yang menunjukkan versi indah dari kode abstrak yang sangat konsisten dan sempurna. Begitu indah sehingga mata bersukacita.
Ya, apartemen dalam gambar itu indah, tetapi Anda tidak dapat hidup di dalamnya. Apartemen dari halaman majalah sengaja dirampas kekacauan, karena kekacauan adalah sesuatu yang individual.
Kekacauan ini terdiri dari hal-hal yang berbeda untuk semua orang. Jika Anda suka membaca, maka ini adalah buku-buku, jika Anda suka permainan komputer, ini adalah konsol dan joystick, dan jika Anda suka kegiatan di luar ruangan, itu adalah sepeda atau kayak. Hal-hal yang Anda gunakan harus ada di tangan, jadi Anda harus tahan dengan kekacauan tertentu. Yang utama adalah tidak boleh terlalu banyak.
Majalah tentang interior yang indah di dunia pengembangan perangkat lunak menunjukkan kode bersih yang tidak realistis dan karenanya menetapkan pedoman yang salah. Ini adalah buku tentang pengembangan perangkat lunak, pola desain, kiat dari blog dan artikel. Kode yang memenuhi semua persyaratannya, sangat konsisten dan abstrak - tidak berlaku di dunia nyata. Bahkan jika Anda berhasil mencapai ini, Anda tidak dapat hidup di dalamnya.
Kita perlu sedikit kekacauan untuk merasa nyaman. Ini berlaku untuk apartemen dan kode.
Kedua ekstrem itu tidak hidup . Jika Anda memiliki sepotong kode yang tidak Anda pahami dan tidak tahu bagaimana cara menggunakannya, maka itu merupakan salah satu dari yang ekstrem ini. Entah itu terlalu berserakan sehingga tidak mungkin untuk membedakan ide-ide yang cocok dari yang tidak tepat, atau sangat murni sehingga ide-ide yang cocok tidak mungkin ditemukan.
Terlebih lagi, kedua ekstrim ini dapat eksis secara bersamaan dalam proyek yang sama. Terkadang bahkan di lingkungan satu sama lain. Kode yang dapat dihidupkan ada di antara keduanya. Selain ruang yang nyaman untuk tinggal, tempat ini ada di antara foto-foto dari sampul majalah dan apartemen yang berantakan.
Oleh karena itu, Anda harus dapat mengambil sedikit kekacauan karena itu membuat ruang layak huni .
Terwujud
Anda dapat mengatakan: “Ini semua, tentu saja, sangat menarik, tetapi bagaimana jika kode saya sudah benar-benar berantakan? Atau bagaimana jika proyeknya tidak terlalu buruk, tetapi saya ingin memastikan bahwa itu tidak bergerak ke arah yang salah? "
Katakanlah kode Anda tampak seperti ruang tamu warisan yang berantakan dengan jalur pemahaman kambing sempit yang melewatinya. Jangan khawatir, Anda bukan orang jahat - ini bisa terjadi pada semua orang.
Jika Anda melihat masalah dari sudut pandang teknik, maka itu hanya berteriak: "Tulis ulang! Bagaimana mungkin mengatur sesuatu di tempat seperti itu tanpa ruang kosong? Bawa semuanya keluar dari sini dan mulai lagi dari awal! ”Perencanaan top-down ini sangat cocok untuk tugas-tugas teknik tertentu, tetapi tidak untuk sebagian besar perangkat lunak. Ini bukan karena kami insinyur yang buruk atau kami mencoba dengan buruk, tetapi karena di daerah kami pendekatan teknik tidak berfungsi. Dan kode itu berfungsi sebagai ruang tempat orang hidup. Anda perlu memahami bahwa orang-orang itulah yang Anda butuhkan untuk dikerjakan.
Begini cara melakukannya. Ada empat aturan yang berlaku untuk bahasa dan kerangka kerja apa pun.
Jangan salahkan
Hampir seperti di dunia kedokteran. Saat membuka file yang sudah berantakan, berjanji bahwa Anda tidak akan memperburuknya. Bahkan jika Anda tidak punya waktu untuk memperbaiki hal-hal yang sudah mengerikan. Jika, saat melakukan peninjauan kode, Anda melihat bagaimana seseorang melanggar aturan ini, ingatkan dia tentang apa yang Anda setujui.
Percaya pada perbaikan yang konsisten
Tumpukan lima buku di lantai dan satu yang dirapikan di rak buku lebih baik daripada tumpukan enam buku. Mungkin orang yang menyentuh kode ini lain kali akan menggeser buku lain dari tumpukan ke rak. Jika Anda menunggu waktu untuk meletakkan semuanya sekaligus, ini tidak akan pernah terjadi.
Menggunakan pendekatan ini bisa menjadi masalah. Perbaikan berturut-turut sulit bagi banyak orang, sehingga mereka terus hidup dengan keinginan yang membara untuk sepenuhnya menulis ulang modul, subsistem, atau aplikasi. Akibatnya, tumpukan buku tidak berkurang dan tetap di lantai dari iterasi ke iterasi.
Jadikan housekeeping sebagai bagian dari alur kerja
Jangan memulai cerita pengguna untuk refactoring. Jangan menunggu dua minggu untuk memperbaiki satu file. Pelajari cara memasukkan aturan sederhana ke dalam pekerjaan sehari-hari Anda. Aturan kepanduan mengatakan: tinggalkan kamp lebih bersih daripada sebelum Anda tiba. Jika Anda mengikutinya terus-menerus, maka secara bertahap singkirkan "kebiasaan buruk".
Tetap berkomunikasi
Bersiaplah untuk selalu berkomunikasi dengan setiap anggota tim tentang apa yang Anda lakukan. Paragraf sebelumnya tidak berarti Anda harus menyembunyikan apa yang Anda lakukan. Anda hanya perlu mempertimbangkan refactoring dan menertibkan segala sesuatu sebagai bagian dari semua yang Anda lakukan.
Ketika Anda refactor:
- Jangan minta izin. Ini adalah bagian dari pekerjaan Anda. Tetapi terbuka untuk mendiskusikan keputusan Anda.
- Jangan mengelak dari tanggung jawab atas kesalahan Anda dan belajarlah dari masing-masing kesalahan itu. Kesalahan juga merupakan bagian dari pekerjaan. Melalui mereka kita dapat memahami apa yang sedang kita kerjakan. Anda akan melakukannya, merendahkan diri. Kadang-kadang Anda tidak dapat menyelesaikan refactoring, kadang-kadang, sebaliknya, Anda bisa terlalu terhanyut, tetapi yang terpenting adalah belajar dari kesalahan Anda berulang-ulang.
- Minta tip, tetapi jangan selalu ikuti mereka. Tugas Anda sebagai pengembang adalah menentukan apa yang Anda butuhkan untuk refactor dan apa yang tidak. Anda harus memiliki kebebasan untuk membuat keputusan ini dan membuat kesalahan.
- Lakukan semuanya bersama karena Anda tinggal di sini. Ini sangat penting. , , , .
Kesimpulan
— . — . , , , , .
. — . , , , , .
Referensi
- , ,
- Prinsip terkait dari Bob Martin