Saya akan senang untuk berdiskusi di komentar di bawah artikel: pertanyaan, pendapat, sanggahan!
Ada yang diketahui
Di Lamoda, saya bergabung dengan tim yang mengerjakan dukungan dan pengembangan sistem pemrosesan pesanan. Tidak ada yang jelas, tapi sangat menarik.
Setelah memiliki studio web kecil tapi ambisius tempat saya bekerja sebelumnya, saya terkesan dengan keseriusan dalam perusahaan besar. Proses pengembangan yang diatur tampak seperti mekanisme yang dipoles sempurna. Tinjauan kode yang ketat tetapi membimbing dari pemimpin dan anggota tim sangat penting untuk sistem yang kompleks dan penting. Bagi saya, tugas titik terbang, mempengaruhi satu atau dua file, tidak lebih. Sebagian besar basis kode dan perilaku sistem disembunyikan dariku oleh kabut perang.
Setelah sekitar satu bulan, saya menyelesaikan salah satu tugas pertama yang berkaitan dengan membuat perubahan nyata pada sistem kerja. Intinya diringkas untuk menambahkan satu bidang ke laporan pengembalian dana ke klien. Peninjauan kode, pengujian unit, teknisi QA menguji rilis - semuanya tampak baik-baik saja. Karena sistemnya besar dan kompleks, kami dibebaskan dua kali seminggu, menurut peraturan - dan pada hari Kamis tugas saya pergi ke produksi. Hampir sepanjang hari, insinyur rilis sibuk membangun dan meluncurkan kode, diikuti dengan peralihan kompulsif antar tab dengan grafik pemantauan, kesalahan, antrian, log - segala sesuatu yang dapat mengindikasikan masalah. Tapi semuanya tampak bagus. Kode tersebut digabungkan ke dalam cabang master dan disebarkan untuk menangani tugas-tugas lain.
Keheningan di log dan pemantauan menyembunyikan bug yang mengerikan: kueri database mengembalikan jumlah baris yang salah. Jumlah total yang akan dikembalikan beberapa kali lebih tinggi dari yang asli ... Tapi kami baru mengetahui hal ini pada hari Senin. Saya masih ingat betapa lelah dan mencela Pimpinan Teknis itu memandang saya saat kami naik lift kantor keesokan paginya. Dia menangkap bug tersebut hingga pukul tiga pagi dan menyiapkan perbaikan untuk pelepasan. Dan perusahaan mengalami beberapa dampak dari kesalahan saya. Ini adalah bug kritis pertama saya, tetapi jauh dari yang terakhir. Orang membuat kesalahan, dan mereka melakukannya sepanjang waktu.
Takeaway # 1:Proses bisnis dan data diutamakan. Penting untuk memperhatikan data yang digunakan sistem tersebut. Tentukan apa yang Anda hadapi sebelum membuat perubahan. Pahami konteks di mana penyesuaian dilakukan. Selalu pertimbangkan masalah yang sedang diselesaikan dari perspektif konteks di atas level. Dengan kata lain, pahami dengan jelas apa yang terjadi dalam kaitannya dengan proses bisnis dan siapa konsumen dari model yang terpengaruh. Struktur aplikasi dapat memiliki lapisan abstraksi sebanyak yang Anda inginkan dan berbagai tingkat kualitas abstraksi itu sendiri, tetapi ini tidak berarti apa-apa jika model atau proses bisnis secara keseluruhan rusak.
Saya terus bekerja di tim yang sama, mendapatkan pengalaman, dan enam bulan kemudian, di tim stand-up, saya melontarkan kalimat yang, secara umum, saya memahami cara kerja sistem pemrosesan pesanan kami.
Tentu saja saya salah.
Kompleksitas sistem yang besar tidak boleh dianggap remeh. Politisi Amerika Donald Rumsfeld mengatakan dengan sangat baik tentang ini:
... seperti yang kita tahu, ada yang terkenal; Ada hal-hal yang kita ketahui, yang kita ketahui. Kita juga tahu bahwa ada hal-hal yang tidak diketahui; Artinya, kita tahu bahwa ada beberapa hal yang tidak kita ketahui. Tetapi ada juga hal-hal yang tidak diketahui yang tidak diketahui - hal-hal yang tidak kita ketahui, yang tidak kita ketahui. Dan jika Anda melihat sejarah negara kita dan negara bebas lainnya, kategori terakhir biasanya sulit.
Kesimpulan # 2: Ketika bekerja dengan sistem yang kompleks, penting untuk memahami apa yang kita ketahui tentang mereka, apa yang tidak kita ketahui, dan perilaku mereka yang bahkan tidak dapat kita duga. Dan ini bukan hanya tentang perkakas dan mengikuti tren "Pemantauan menuju Pengamatan" , tetapi juga tentang manajemen ketergantungan dan penilaian risiko dalam desain. Misalnya, sebelum memutuskan untuk menggunakan database tren keren untuk sistem kritis, saya sangat menyarankan Anda untuk tetap menggunakan situs ini boringtechnology.club
Semuanya rusak
Setelah dua tahun bekerja dengan sistem pemrosesan pesanan, saya dapat mengatakan bahwa saya tahu sekitar 80% aplikasi dengan percaya diri. Artinya, tentang setiap modul sistem saya memahami cara kerjanya, dan saya dapat membuat perubahan. Saya tahu proses bisnis mana yang direfleksikan dalam model tertentu, bagaimana mereka saling berhubungan dan mempengaruhi satu sama lain. Saya melakukan integrasi dengan sistem pemrosesan pembayaran, yang dirancang oleh tim tetangga. Selain integrasi, kode lama harus dihilangkan, karena pembayaran sebelumnya merupakan bagian dari sistem kami - tugas ini adalah pemfaktoran ulang modul besar yang terakhir dan paling ambisius. Semuanya berjalan sangat lancar bahkan tidak menarik.
Pada saat yang sama, konflik muncul di dalam diri saya, sebagai pengembang. Sejujurnya saya tidak mengerti mengapa sistem pemrosesan pesanan kami, yang sangat penting untuk pengoperasian seluruh bisnis kami, sangat rapuh. Sistem besar tetangga sama rapuhnya. Dari semua pengalaman yang saya peroleh dalam dua tahun kerja, tampaknya semacam keandalan dari sistem yang kompleks hanya dapat diharapkan ketika melakukan kasus uji standar. Dan ketika Anda mencoba membuat perubahan yang dibutuhkan bisnis Anda, segalanya berantakan pada manuver drastis pertama dari pengembang yang tidak beruntung.
Merefleksikan semua ini, saya menemukan artikel Semuanya rusak , di mana penulis menulis tentang masalah yang sama, tetapi pada skala yang lebih besar (dan juga hampir sama, tetapi dari sudut yang berbeda - Kekecewaan perangkat lunak). Setiap kali saya bersemangat ketika saya menemukan konfirmasi dari luar tentang perasaan batin saya - sehingga saat itu, setelah membaca artikel itu, saya akhirnya merasakan bagaimana ketidakpuasan saya yang samar berubah menjadi wawasan yang hidup dan jelas:
Software sangat buruk karena sangat rumit.
Kami tidak harus pergi jauh untuk contoh dalam pekerjaan kami: tepat pada saat itu, menambahkan hanya beberapa tiang, kami benar-benar merusak pembuatan pesanan untuk sementara waktu.
Sistem kita yang besar dan penting sangat buruk karena tidak sesuai dengan pikiran kita! Dan semua proses bisnis yang terkunci di dalam sistem tidak sesuai dengan kepala manajer dan analis - dan secara umum tidak ada orang seperti itu yang akan memahami bagaimana semuanya bekerja sama.
Kesimpulan # 3: Saat merancang sistem, penting untuk mempertimbangkan beban kognitifnya. Ini terdiri dari kompleksitas solusi teknis, serta model dan proses bidang subjek. Sistem yang dirancang dengan baik memiliki beban kognitif yang tinggi pada bidang subjek dan rendah pada solusi teknis.Idealnya, satu sistem harus memiliki beban kognitif yang dapat ditangani oleh satu orang.
Oke, masalahnya jelas. Tetapi misalkan kita memiliki kesempatan untuk menulis ulang sistem yang terlalu kompleks dan karena itu buruk dengan menyederhanakannya. Apa lagi yang harus Anda perhatikan? Dalam sibernetika, ada teorema Conant-Ashby:
Regulator yang baik dari suatu sistem harus memiliki model sistem itu. Regulator yang baik
Makna dari teorema ini adalah jika kita ingin mengontrol suatu objek maka diperlukan model yang baik (akurat dan dapat dimengerti) dari objek tersebut. Dan semakin kompleks objeknya atau semakin sedikit informasi tentangnya, semakin sulit untuk mendapatkan modelnya yang baik - dan ini berdampak negatif pada manajemen.
Saya pikir sangat sedikit orang yang tidak setuju bahwa semua layanan kami adalah model. Tapi apa yang kita modelkan? Sangat penting untuk memperhatikan proses bisnis, model tidak hanya keadaan, tetapi juga perilaku.
Pada akhir 2017, saya pindah ke tim CORE yang baru. Tim ini kemudian dibentuk khusus untuk melaksanakan tugas-tugas strategi TI penguraian sistem monolitik. Tujuan utama kami adalah untuk memotong sistem pemrosesan pesanan yang sangat besar tetapi rapuh itu (sulih suara: maka samurai belum tahu bahwa jalan ini memiliki permulaan, tetapi tanpa akhir!).
Itu adalah pengalaman baru bagi saya. Sebuah tim dengan prinsip dan cara berpikir yang sangat berbeda. Keputusan dibuat dengan cepat, ada eksperimen dan hak untuk membuat kesalahan. Keseimbangan hasilnya sempurna: kami mencoba dan memutar kembali di mana dampaknya minimal, tetapi kami menentukan setiap langkah secara detail untuk momen kritis.
Kami menulis layanan baru untuk membuat pesanan dari awal dalam bahasa lain (sebagai pengembang php, kami beralih ke golang). Kami mengevaluasi hasil pertama dan menulis ulang lagi. Penekanannya adalah pada kesederhanaan dan keandalan. Mereka menempatkan model data di tengah, dan membangun seluruh arsitektur. Hasilnya adalah layanan yang andal dan tangguh. Kami berhasil menjalankannya tanpa kegagalan, menggunakan mekanisme eksperimental. Seiring waktu, sistem yang dibangun telah menunjukkan nilainya lebih dari sekali.
Takeaway # 4:Semua model salah, tetapi beberapa berguna. Status pemodelan tidak cukup untuk membangun sistem yang benar dan stabil. Penting untuk melihat perilaku: pola komunikasi, aliran peristiwa, siapa yang bertanggung jawab atas data ini atau itu. Anda harus mencari hubungan antar data dan memperhatikan alasan hubungan tersebut.
Ini semua tentang dum dum da da dum dum
Di universitas saya ada kursus analisis matematika, yang diajarkan oleh seorang profesor dan Ph.D. Elena Nikolaevna. Dia sangat ketat, tapi adil. Pada tes sesekali menemukan masalah, untuk solusinya perlu "memutar" ceramah sedikit - untuk mengambil langkah independen menuju pemahaman materi. Dan pada ujian akhir, yang, omong-omong, saya lulus untuk kedua kalinya, saya harus menunjukkan fleksibilitas berpikir dan menggunakan intuisi saya untuk menyelesaikan masalah dengan “baik”. Berikut adalah aturan bahwa E.N. dia memberi tahu kami seluruh kursus, dan yang saya gunakan sepuluh tahun kemudian:
Jika Anda tidak tahu apa yang harus dilakukan, lakukan apa yang Anda ketahui.
Karena itulah saya bangga mengenal matan dengan baik. Karena menurut standar E.N. tidak cukup hanya mengetahui materi, tetapi penting juga untuk memahaminya, untuk dapat mensintesis sesuatu yang baru.
Kesimpulan # 5: Semakin jauh Anda melangkah, semakin banyak tanggung jawab yang harus Anda ambil dan semakin banyak keputusan yang harus Anda buat. Pada saat tertentu, keyakinan mutlak menghilang sebagai sebuah kategori, tetapi muncul seni keseimbangan yang mengikuti keberanian untuk mengambil langkah.
Ada saatnya ketika tidak ada orang yang tepat di sekitar Anda yang bisa menghilangkan ketidakpastian yang ada. Anda harus menilai sendiri risikonya dan bertanggung jawab atas diri Anda sendiri. Buat keputusan dalam menghadapi ketidakpastian.
Pada paruh kedua tahun 2018, tim kami memimpin proyek Sertifikat Hadiah. Awalnya, saya bertanggung jawab untuk pengembangan di dalam dan di sekitar pemrosesan. Kemudian, pada akhir tahun, kepemimpinan teknis dari seluruh proyek mengambil alih saya bersama dengan tugas memulihkan keseimbangan kekuatan setelah sebagian dari tim pergi.
Aturan yang ada di kepala dan tatanan dunia pengembang meledak, dan akhirnya runtuh. Tanggung jawab untuk sebuah proyek yang besar dan kompleks memberhentikan saya dari ide-ide idealis tentang dunia pembangunan dengan konsep dan pelangi. Dunia pembatasan yang kejam dan solusi yang cukup membutuhkan pemahaman dan revisi semua pendekatan dan aturan yang saya ikuti.
Takeaway # 6:Sindrom Penipu. Bagaimana jika saya terekspos? Tentu saja mereka akan membongkar jika tidak ada yang dilakukan. Jika Anda melakukan sesuatu yang penting, maka setelah beberapa saat Anda memperhatikan bahwa tidak ada yang mengekspos Anda.
Divergensi dan Konvergensi
Sesuai dengan kronologi "Developer's Path" saya seharusnya ada cerita yang menarik dari segi teknis tentang proyek kebijakan pribadi. Dalam proyek ini, kami menerapkan pemrosesan data waktu nyata, dan "dengan cepat" mengubah prinsip arsitektur sistem, pindah ke Arsitektur Berbasis Kejadian. Tetapi tentang ini, saya sudah memiliki laporan terpisah dari konferensi Highload '19 (dan artikel di sini di Habré). Oleh karena itu, saya lebih suka memberi tahu Anda tentang "hal-hal penting" dari teknis dan bukan manajemen.
Ketika seorang pengembang tumbuh ke posisi senior, yang harus dibaca sebagai "siap bertanggung jawab dan tahu bagaimana membuat keputusan secara mandiri," maka langkah klasik berikutnya adalah memimpin tim. Seorang pemimpin tim adalah orang yang terutama bertanggung jawab atas tim, yaitu. untuk orang dan proses pembangunan. Pelanggan tidak datang ke pengembang, dia datang ke pemimpin tim, dan bertanya tentang kewajiban dari pemimpin tim juga.
Ternyata ini adalah hal yang paradoks - segera setelah pengembang tumbuh untuk bekerja secara mandiri sebagai insinyur, dia dilemparkan ke dalam badai yang disebut manajemen.
Tidak, mungkin bagi seseorang jalur ini tampaknya cukup nyaman, dan transisi dari algoritme dan protokol yang sangat tidak ambigu untuk interaksi sistem komputer ke koordinasi sekelompok orang terlihat logis. Tetapi bagi saya tampaknya bukan tanpa alasan bahwa sebagian besar percakapan dalam obrolan khusus dan konferensi untuk pemimpin tim berkisar pada konsep "rasa sakit".
Apa sakitnya seorang pemimpin tim? Bukankah karena seorang insinyur yang bertanggung jawab atas manajemen ?! Tidak, mengapa ini terjadi dapat dimengerti - kami tidak memiliki sekolah manajemen teknis seperti itu, dan diasumsikan bahwa seorang insinyur TI adalah manusia super yang dapat memahami segalanya, termasuk hal yang "sederhana" seperti manajemen.
Tapi saya memutuskan untuk pergi ke arah lain dan memilih posisi pemimpin teknologi sebagai langkah karier berikutnya. Sebagai seorang arsitek, saya bekerja dengan tim pengembangan, dan sekarang saya mendengar dari orang-orang apa yang saya sendiri katakan kepada manajer setahun yang lalu:
Mengapa persyaratan dikembangkan dengan sangat buruk? Solusi kruk! Dua minggu apa ?! Di sini bekerja selama sebulan.
Tapi ehehei, sekarang tugasku menyelesaikan masalah seperti itu. Tetapi segera setelah Anda menerjemahkan pemikiran Anda ke dalam paradigma biaya & manfaat, Anda menyadari bahwa semua masalah ini tidak dapat diselesaikan - Anda tentang kehidupan itu!
Takeaway # 7: Pembukaan! Manajer tidak berurusan dengan pemecahan masalah; mereka mengelola kekacauan.
Sebagai pemimpin teknis, tugas saya adalah menghilangkan ketidakpastian bagi tim pengembangan. Persyaratan tidak berhasil? Solusi kruk? Bukankah arsitektur menyediakan? Ini semua adalah sinyal kerapuhan dan perbedaan sistem.
Katakanlah bahwa pengaturan tugas di layanan pembuatan pesanan terlihat seperti ini:
Ini diperlukan untuk menambahkan bidang X dan bidang Y. Diperlukan bahwa nilai dalam bidang Y 'pada keluaran sama dengan nilai Z jika X adalah 1.
Masalahnya terletak pada pernyataan persyaratan. Kesalahannya di sini adalah sama sekali tidak jelas status sistem apa yang ingin Anda capai. Langkah-langkah yang didefinisikan sepenuhnya dalam pernyataan tersebut menyebabkan ketidakpastian selama implementasi dan operasi.
Setelah beberapa tugas seperti itu, layanan pembuatan pesanan akan berada dalam keadaan yang agak rapuh - dan kasus seperti ketika kita menambahkan beberapa bidang dan semua yang rusak akan mulai terjadi.
Tujuan: untuk memastikan konvergensi keadaan sistem, konsistensi pernyataan tugas dan pengurangan ketidakpastian untuk mencapai stabilitas.
Orang-orang yang bekerja di garis representasi terus-menerus membangun dan memperbarui model mereka tentang apa yang ada di luar garis. Kegiatan ini sangat penting untuk ketahanan sistem Internet dan merupakan sumber utama kapasitas adaptif. Di Atas Garis, Di Bawah Garis
Arsitek harus memahami kesatuan sistem sosio-teknis. Mampu mengoordinasikan proses di atas garis presentasi sehingga sistem di bawah garis presentasi memenuhi kendala kebenaran, stabilitas, dan kemampuan beradaptasi.
Kesimpulan # 8: Jika aturan berhenti bekerja, selamat, Anda telah mencapai kondisi batas di mana model saat ini berhenti bekerja. Saatnya merevisi ide-ide Anda dan menemukan model baru yang akan memenuhi kendala saat ini dan memungkinkan Anda membangun proses dan aturan yang memadai.
Lembut itu sederhana, orang itu keras!
Tidak benar-benar. Inilah yang ditulis dalam salah satu buku tentang arsitektur. Dan rasanya semakin jauh saya melangkah, semakin sering saya mengulang-ulang buku ini.
Konsep teknis, algoritme, dan standar sudah jelas - Anda hanya perlu menerimanya dan secara konsisten mencari tahu. Saya tidak mencoba meremehkan pekerjaan para insinyur - algoritme untuk sistem terdistribusi sangat kompleks jika Anda tidak membangun sistem seperti itu setiap hari. Tetapi lebih sering daripada tidak, kesulitan utama yang kita hadapi dalam proses pekerjaan muncul ketika kita perlu memahami mengapa layanan ini atau itu membutuhkan tingkat abstraksi untuk domain tersebut. Dan masalahnya sering diperparah oleh fakta bahwa orang yang menulis layanan tersebut tidak ada.
Algoritma yang sederhana untuk diterapkan lebih berhasil daripada yang akurat secara matematis. Paxos akurat secara matematis, tetapi hanya dengan deskripsi protokol Raft, yang lebih mudah diterapkan, aplikasi praktis dari algoritma konsensus telah dikembangkan.
Bahasa Golang dikritik karena terlalu terbatas. Tetapi di sanalah Docker, Kubernetes, dan banyak sistem terdistribusi lainnya ditulis. Sistem kendala yang dirancang dengan baik berfungsi sebagai dasar untuk sistem yang berhasil.
Semuanya akan jauh lebih mudah jika teknologi tidak harus memperhitungkan faktor manusia. Tapi mereka harus melakukannya. Setiap sistem dalam TI, dalam konstruksi dan pemeliharaan yang melibatkan lebih dari satu orang, harus memperhitungkan faktor manusia.
Dan di sini teknologi muncul di persimpangan antara perangkat lunak & manusia, yang dirancang untuk menyusun kekacauan dan menggambarkan interaksi yang kompleks. Domain Driven Design, Microservices, Agile - semuanya menciptakan batasan yang menjelaskan prinsip dan aturan interaksi. Struktur muncul dengan jelas bagaimana bekerja. Tetapi tidak selalu menjadi lebih baik dengan munculnya teknologi semacam itu. Seringkali yang terjadi justru sebaliknya - Apa yang Tidak Dapat Dibeli Dengan Uang .
Kesimpulan # 9: Program bisa dan harus sederhana. Untuk melakukan ini, Anda perlu menerapkan kekuatan pada pembentukan budaya teknik. Dialah yang akhirnya menentukan kinerja layanan.
Membaca daftar
Buku
Jalan Manajer: Panduan untuk Pemimpin Teknologi yang Menavigasi Pertumbuhan dan Perubahan, Camille Fournier - tautkan
Teka-teki Elegan: Sistem Manajemen Teknik, Will Larson - Tautkan
Topologi Tim: Pengorganisasian Tim Bisnis dan Teknologi untuk Arus Cepat, Manuel Pais dan Matthew Skelton - Link
meluruskan Software, Juval Lowy - Link
Berpikir dalam Sistem: A Primer, Donella Meadows - referensi
Artikel
Model Mental, jalan Jenderal Fernam - Link
Kompleksitas Bias: Mengapa Kita Memilih rumit untuk Simple. Fernam Street - tautkan
Apa yang Tidak Dapat Dibeli Dengan Uang, Kurang Salah - tautan
Menjadi Berorientasi pada Kebenaran yang Tidak Biasa, Lebih Sedikit Salah -link
Hukum Pemrograman dan Realitas: Apakah Kita Tahu Apa Yang Kita Pikirkan Kita Ketahui? - tautan
Tidak Ada Esensi Peluru Perak dan Kecelakaan Rekayasa Perangkat Lunak - tautan
Seni Pemecahan Masalah - tautan
Dari Perangkat Lunak Fragile ke Antifragile - tautan
Komputer dapat dipahami - tautan
Tuckman Was Wrong! (Tentang tim) - referensi
Cara gagal di hampir semua dan masih menang besar - Link
Kesederhanaan Sebelum Generality, Gunakan Sebelum Reuse - Link
Kesederhanaan, Silakan - Sebuah Manifesto untuk Software Development - link
Software Desain adalah Hubungan Manusia - Tautan