Dalam posting ini, saya akan berbicara tentang masalah yang dihadapi tim Scrum Front End kami selama setahun bekerja pada proyek yang layak. Kami mulai mengembangkan proyek dari awal menggunakan tumpukan teknologi React + Typescript. Menengok ke belakang, saya melihat jutaan orang terbuang sia-sia karena proses pengembangannya tidak diatur sejak awal. Tetapi ada alasan untuk ini.
Pertama, Anda harus memenangkan tender. Untuk melakukan ini, perlu cepat mengajukan Produk Minimal Berharga. Dan inilah kesalahan pertama yang membutuhkan biaya yang layak untuk pelanggan kami. Kedengarannya seperti ini: cepat memotong MVP. Pelanggan ingin melihat hasilnya dengan cepat, tetapi ini berarti kami mengorbankan infrastruktur yang baik, arsitektur yang andal, dan setahun kemudian kami sampai pada kesimpulan bahwa arsitektur Front End kami memerlukan refactoring yang serius. Sekitar beberapa bulan. Jadi kami membocorkan 500.000 rubel.
Melihat ke belakang, saya dapat mengatakan dengan yakin bahwa hal pertama yang harus dilakukan adalah memperhitungkan semua fungsi yang ingin dilihat pelanggan pada akhirnya, setelah beberapa tahun. Jadi kita bisa menghindari kesalahan arsitektur dalam gaya "arsitektur ini tidak menyediakan ini." Akibatnya, setiap chip utama memerlukan refactoring yang serius.
Untuk memenangkan tender, perusahaan kami mengirim pengembang yang tidak memiliki pengalaman dalam merancang aplikasi besar dan sistem yang dapat diperluas yang dapat diandalkan. Bisnis yang jelas, tender itu bukan pesanan, dan tak seorang pun ingin menyebarkan personel yang baik. Tetapi kurangnya arsitek teknis di (tingkat kelas) menyebabkan fakta bahwa aplikasi kita berubah menjadi kode spaghetti dan berhenti memenuhi persyaratan SOLID. Dan di sinilah letak kesalahan masing-masing pelanggan. Tidak mungkin mempertahankan laju pengembangan yang konstan tanpa menambah sumber daya tim. Prinsip Agile "Investor, pengembang dan pengguna harus dapat mempertahankan ritme yang konstan tanpa batas" hanya berfungsi jika persyaratan diketahui dan dikerjakan sejak awal, seluruh rangkaian fungsionalitas, arsitektur yang andal dan dapat dikembangkan dirancang (dengan kata lain, jika setiap kelas dipikirkan dengan mempertimbangkan final fungsionalitas sistem) dan proses yang jelas. Dan ini harus dilakukan dalam MPV sebelum menggergaji produk. Kalau tidak, dengan waktu linier, kompleksitas aplikasi tumbuh secara eksponensial. Ini berarti fitur gash dalam setahun akan menelan biaya O (e (N)) lebih mahal daripada di awal.
Di tim kami, satu-satunya desainer adalah karyawan jarak jauh. Itu adalah kesalahan serius. Karyawan yang jauh selalu menjalani kehidupannya sendiri. Dia menggambar desain untuk dirinya sendiri, indah dan baik, pelanggan senang. Tetapi semua pesona ini pada akhirnya bermuara pada kenyataan bahwa pada bentuk logis yang sama kita memiliki N gaya dan tata letak yang berbeda. Dari awal, itu layak menempatkan persyaratan: menyesuaikan dgn mode kerangka kerja tertentu (kami memiliki Desain Ant). Jika sesuatu tidak ada di sana, lakukan apa yang ada di sana. Pelanggan mengira React adalah pembangun blok. Dan dia masih tidak mengerti mengapa kita melihat bentuk primitif selama 4 hari. Bereaksi adalah konstruktor, tetapi hanya jika pada awal pengembangan kami memiliki satu set komponen yang dapat digunakan kembali yang serupa (kerangka UI). Seorang desainer tanpa pengalaman tata letak tidak akan pernah melakukan ini sendiri. Pengembang tidak akan pernah memberi tahu pelanggan tentang hal ini. Ini harus diikuti oleh pemimpin. Jadi pemimpin tim Front End harus menjadi pengembang Front End di masa lalu, dan bukan Back End seperti biasa. Oleh karena itu, kami sampai pada kesimpulan bahwa tim Agile yang berfungsi penuh harus menyertakan pemimpin yang kompeten di setiap bidang kerjanya (FE, BE). Para pemimpin ini harus memiliki keterampilan lunak yang kuat untuk menyampaikan kepada pelanggan apa yang ingin saya uraikan dalam artikel ini. Dan ini sangat, sangat sulit.
Ketika kami merilis rilis pertama, kami menyadari bahwa ada sesuatu yang terus-menerus rusak pada hari terakhir sebelum demo. Sepanjang tahun pengembangan, setiap cabang rilis berubah menjadi set kruk yang mematikan (matikan, lepaskan itu) yang kemudian secara ajaib berakhir di cabang pengembangan. Dan ada serangkaian komit (nyalakan ini, nyalakan). Setelah satu tahun, kami sampai pada kesimpulan bahwa kami perlu memiliki kebijakan percabangan yang jelas. Namun yang paling penting, orang yang bertanggung jawab akan menghilangkan kekacauan yang ada. Ini berarti: memoderasi keinginan kacau pelanggan, atau memoderasi bug kacau, atau pada masing-masing stand memiliki konfigurasi sendiri menonaktifkan semacam fitur grafis atau tombol. Membungkus setiap tombol dalam pernyataan if gila. Kami sampai pada kesimpulan bahwa kami memerlukan arsitektur Front End plug-in fitur-modular (disable-enable). Saya sudah lama berpikir bagaimana mencapai arsitektur seperti itu. Tapi satu hal yang saya mengerti dengan pasti. Kami membutuhkan konteks penuh. Jadi perpustakaan js-beans lahir (https://www.npmjs.com/package/js-beans). Setiap stand memiliki konteks json sendiri. Pengaya dikumpulkan dalam rantai (rantai) melalui pola Proxy. Jadi, misalnya, kami memiliki sumber data sebagai nampan terpisah, dan berbagai transformasi dilakukan sebagai nampan Proxy opsional menggantikan nampan ini, tetapi menyuntikkannya ke dalam dirinya sendiri. Sebagai contoh, jika Anda perlu skala model data untuk menguji kinerja FPS, saya cukup menambahkan baris untuk mengaktifkan scaling plugin di file json. Terjadi kerusakan pada produksi, tetapi tidak diputar secara lokal, saya menyalakan penebang dengan satu baris tanpa membangun kembali dudukan (dudukan membutuhkan waktu sekitar 20 menit, dan selusin dudukan tidak selalu cukup untuk semua orang). Atau jika Anda perlu dengan cepat mematikan beberapa modul karena fakta bahwa itu dapat rusak (nonaktifkan kacang opsional dalam konteks).
Seiring waktu berlalu, stan dimatikan selama seminggu. Mustahil untuk mengembangkan front secara lokal. Kami belum menyediakan arsitektur otonom pada moka. Aku harus mengatasinya melalui rasa sakit dengan derit. Melihat ke belakang sekarang, saya akan melakukannya di awal. Tapi kami punya MVP, dan kami dipaksa untuk menulis kode tanpa teknik yang mendalam. Tetapi pelanggan menganggap kami sebagai profesional, dan berpikir bahwa kami harus segera menulis kode tanpa kesalahan. Berikut ini adalah kesalahan berikut. Nama perusahaan tidak berbicara tentang profesionalisme tim. Profesionalisme tim ditentukan oleh profesionalisme pemimpin tim. Jika tidak ada pemimpin teknis dalam tim, dalam setahun proyek Anda akan macet. Jadi, Anda menggabungkan jutaan lebih banyak.
Kami memiliki arsitek jarak jauh. Tetapi hanya satu hal yang diketahui tentang dia: dia. Tahap terakhir pengembangan pemimpin menurut Vladimir Tarasov. Dalam hal ini arsitek kami mencapai kesempurnaan. Nomor kesalahan N: Anda tidak memiliki arsitek teknis yang merancang sistem di tingkat kelas. Anda tidak memiliki seseorang untuk meminta bantuan jika Anda macet. Mintalah bantuan dari tim lain yang lebih berpengalaman, kata pelanggan kepada kami. Tetapi untuk beberapa alasan, tim lain tidak pernah punya waktu untuk membantu kami. PR kami telah hang untuk bulan kedua. Saya sangat berharap bahwa ada seorang pria pemberani yang akan memanggilnya. Sebagai hasilnya, hidup telah memberi kita kode kita dengan banyak fenomena paranormal dalam bentuk sihir dan set kruk untuk semua kesempatan. Hanya satu yang hilang. Penjelasan khusus
Sihir dan @Kostyle. Ide bagus untuk ES selanjutnya.
Kami memutuskan bahwa lebih banyak middle dan lebih sedikit pria yang lebih menguntungkan untuk proyek tersebut. Sekarang kita berpikir secara berbeda. Jika anggaran Anda kecil, Anda perlu menyewa spesialis termahal. Jika Anda, seperti kami, tidak memiliki masalah anggaran, Anda dapat dengan aman menghemat spesialis dan mengubah Peninjauan Kode menjadi pertempuran paranormal.
Kami pikir kami akan memenuhi tenggat waktu triwulanan. Sekarang kita berpikir secara berbeda. Singkatnya, untuk selamanya, kita perlu menulis ulang proyek. Dan lebih disukai dari awal. Saya harap pelanggan kami tidak akan pernah tahu tentang itu. Setelah semua, kami baru saja membangun tim yang cantik)
Kami memutuskan untuk bermain-main dengan teknologi baru di mana kami memiliki sedikit keahlian. Mereka direkomendasikan kepada kami. Tentu saja kami ingin mendapatkan pengalaman. Sekarang saya berpikir bahwa akan lebih baik jika hanya menggunakan teknologi yang saya punya pengalaman.
Kami memberikan perkiraan berdasarkan hari kerja 8 jam. Pada kenyataannya, perkiraan harus diberikan berdasarkan hari kerja 4 jam. Mengapa tidak ada yang memasukkan teh, menceritakan kisah menarik, menemukan toilet di navigator, berbicara di telepon, berkorespondensi, mempelajari teknologi baru dan, yang paling penting, perselisihan yang antusias dalam tim. Yang terakhir mungkin yang paling tak terhindarkan, dan yang paling mahal. Meskipun, jujur saja, untuk Ruang Terbuka Anda masih perlu membuang beberapa jam. Bicara konstan sangat mengurangi konsentrasi. Diberkatilah pelanggan yang memahami semua ini!
Taksiran kami melelahkan dan berubah menjadi polemik teknis yang membosankan. Efektivitas aksi unjuk rasa sangat minim. Tapi kami menemukan solusinya: pizza lezat. Ketika aroma lezat mengiritasi hidung, seseorang mulai mengekspresikan pikirannya dengan lebih jelas.
Awalnya kami punya satu tim kecil, lalu satu tim besar. Perencanaan memakan waktu 2-3 jam. Diam 30 menit. Untuk apa saya menghormati PO kami, itu karena ia memutuskan untuk membaginya menjadi banyak yang kecil dan untuk mengalokasikan PO mini sendiri di masing-masing. Ini mungkin keputusan terbaik dalam sejarah proyek kami.
Sejak awal, kami tidak punya waktu untuk menulis tes. Setelah setengah tahun, kami sampai pada kesimpulan bahwa mereka masih perlu ditulis. Tapi kami masih belum menemukan waktu untuk ini. Utang teknis prioritas terlalu tinggi telah terakumulasi. Jangan simpan hutang teknis - ini utopia. Dia akan selalu seperti itu.
Kesimpulan subyektif pribadi saya:
- Jika pengembang Anda tidak mengerti untuk apa IOC untuk FrontEnd, maka kemungkinan besar ketika mereka memahaminya akan terlambat.
- Jika pengembang Anda tidak mengerti mengapa FrontEnd membutuhkan pengetahuan tentang OOP, maka kode Anda sulit didukung.
- Spesialis yang lebih murah lebih baik daripada yang lebih menguntungkan.
- Jika Anda memiliki seorang arsitek, kemungkinan besar Anda membutuhkan satu lagi.
- Jika Anda melihat MVP, selesaikan dan ubah proyek.
- Jika MVP sudah direkam sebelum Anda, jangan pergi ke proyek ini.
- Jika Anda kehilangan MVP dan tidak ingin pergi, kemungkinan besar Anda akan berubah pikiran.
- Jika Anda zapilili MVP dan ingin proyek Anda bertahan, tulis ulang dari awal.
- Jika Anda menunjukkan artikel ini kepada pelanggan, kemungkinan besar Anda akan dipecat.
- Jika Anda bekerja pada Agile, kemungkinan besar Anda mengerti saya.
Anda tidak mungkin menghindari semua masalah ini bahkan setelah membaca artikel ini. Tujuan saya adalah menunjukkan kepada Anda bahwa ini tidak bisa dihindari. Dan sekeras apa pun Anda berusaha, Anda tidak akan pernah memiliki kondisi ideal. Jadi bersiaplah untuk itu. Dan sebelum pemberhentian, Anda dapat dengan aman menunjukkan artikel ini kepada pelanggan Anda. Biarkan dia siap secara moral untuk ini.
PS: Pepatah, kalau pernah baca artikel ini, tahu semua yang saya jelaskan itu fiktif dan tidak ada kemiripan dengan proyek kami) Tapi semua ini tidak penting, karena hari ini saya akan berlibur. Liburan pertama dalam setahun kerja tidak teratur yang melelahkan! (sebagai pemimpin FE).