Sekitar Maret 2017, saya diminta melakukan review kode produk sebelum diluncurkan. Perusahaan itu memiliki masalah dengan kebocoran memori, crash spontan, loading lambat, lonjakan konsumsi CPU, dan rilis direncanakan dalam beberapa minggu. Anda mungkin sudah mendengar cerita ini - bukan dari saya dan bukan tentang perusahaan ini. Dia sangat khas.
Kami berkumpul di akhir pekan dan mulai melihat kode bersama. Setelah sekitar setengah hari, sumber masalah yang diketahui ditemukan, dan setengah hari lagi diperlukan untuk menulis dokumen perbaikan untuk pengembang. Peluncuran itu sukses, tetapi cerita itu membuat saya berpikir: bagaimana produk mencapai kondisi seperti itu.
Ketika saya berbicara dengan para pengembang, mereka tampak orang-orang pintar. Satu-satunya masalah yang jelas adalah kurangnya pengalaman. Saya telah menemukan ini sebelumnya. Ini adalah fenomena umum dan sangat normal. Tetapi dalam kasus ini, sebuah cacat keji diamati: pengalaman tidak cukup untuk
semua pengembang.
Sebuah departemen pengembangan telah dibuat baru-baru ini, dan sebuah tim dipekerjakan tanpa adanya direktur teknis. Bahkan seorang teknisi sulit sekali menguji programmer lain - Saya bahkan tidak bisa membayangkan ujian tanpa pengetahuan teknis. Mereka merekrut pengembang pertama, ia memeriksa pengembang kedua - dan seterusnya, hingga tim terbentuk.
Jika Anda beruntung dan pengembang pertama memiliki pengalaman yang signifikan dan keinginan untuk melatih, maka Anda berada di wanita. Tetapi jika Anda kurang beruntung - dan kemungkinan ini sangat tinggi - maka Anda akan mendapatkan tim yang bergerak cepat yang menciptakan perangkat lunak yang sangat rapuh.
"Bertindak cepat dan menghancurkan segalanya," kata mereka. Tapi ini ide yang sangat buruk jika bisnisnya mengandalkan sejumlah kecil pelanggan besar. Produk yang rusak biasanya menakut-nakuti mereka, yang pada gilirannya hits bisnis Anda Anda dapat menggambarkan strategi yang efektif dengan cara yang berbeda, tetapi frasa "perlahan dan terus bergerak menuju tujuan" jelas tidak mengesankan.
Bahkan, ada keseimbangan antara gerak cepat dan lambat. Sulit untuk menemukan keseimbangan ini, karena setiap produk memiliki saldo sendiri. Saya kira intuisi itu didasarkan pada pengalaman, dan ini adalah jawaban yang mengerikan bagi seorang pemula.
Apa yang harus dilakukan pada pengembang baru?
Tampaknya wajar untuk mencari jawaban di Internet. Ternyata itu
sangat efektif .
Tetapi itu juga
sangat berbahaya .
Saya berkolaborasi dengan perusahaan itu setelah peluncuran produk. Saya melihat melalui sejumlah besar kode, membantu melatih pengembang dan menciptakan proyek baru untuk mereka. Semuanya berjalan lancar.
Suatu saat perhatian saya tertarik oleh satu potong kode. Aku bersumpah aku melihatnya sebelumnya. Tentu saja, dengan googling baris, saya menemukan salinan kode yang tepat dalam satu posting blog. Secara alami, saya membaca seluruh artikel - sampai ke paragraf yang mengatakan:
"Jangan lakukan ini dalam produksi .
"Tetapi baris-baris ini menatap saya langsung dari basis kode dalam produksi.
Tidak butuh waktu lama untuk menemukan banyak potongan kode dari artikel serupa. Penafian ditulis hampir di mana-mana, atau itu jelas tidak cukup. Mereka semua memecahkan satu masalah kecil, tetapi memungkinkan banyak kebebasan untuk membuat kode lebih mudah dibaca. Ini bisa dipahami. Sebagian besar pembaca menghargai keringkasan ketika mempelajari suatu konsep.
Kode dari entri blog ini menyebar melalui basis kode sebagai infeksi, menyebabkan masalah di sana-sini tanpa alasan atau pola apa pun. Dan tidak ada obat yang jelas selain membaca semua kode berturut-turut dan secara manual memperbaiki masalah satu per satu. Tanpa tes unit dan penyebaran otomatis, butuh waktu
hampir satu tahun . Saya cukup yakin bahwa biaya memperbaiki kode melebihi biaya penulisan itu.
Tapi pilihan apa yang dimiliki para pengembang ini? Mereka perlu merilis sesuatu, dan mereka belum pernah merilis aplikasi dalam produksi. Karena itu, mereka melakukan apa yang akan dilakukan oleh orang waras - dan belajar sepanjang jalan.
Sistem produksi gagal dalam banyak hal. Tanpa pengalaman atau pengetahuan teoritis tentang kegagalan-kegagalan ini, sulit untuk secara intuitif memahami bagaimana mencegah atau menyelesaikan masalah-masalah seperti itu. Sulit untuk meminta tim baru untuk mencapai hasil yang sempurna, terutama tanpa semacam kepemimpinan.
Sebelum melanjutkan, saya ingin mencatat bahwa setiap orang yang terlibat dalam kekacauan ini memiliki niat baik. Para pengembang ingin menciptakan produk yang baik dan berkembang. Manajer menginginkan hal yang sama. Penulis blog ingin membagikan solusi yang bermanfaat. Semua orang berusaha saling membantu, dan penting untuk mengingat ini.
Masalahnya bukan pada orang.Saya sangat bersimpati dengan para pengembang yang ada di posisi ini. Mereka memiliki lebih banyak informasi daripada yang pernah mereka butuhkan, tetapi itu benar-benar tidak terorganisir. Ini mirip dengan mencoba merakit sepuluh keping puzzle, Anda hanya perlu menemukannya dalam tumpukan 10.000.000 keping, di mana semua kepingan itu berbentuk bujur sangkar, dan hasil akhirnya tidak diketahui. Semoga beruntung
Jika Anda membaca di sini mengharapkan jawaban, maka saya minta maaf: Saya tidak punya jawaban sederhana. Masalah ini sulit dipecahkan. Solusinya terlalu besar untuk satu artikel, itu berubah setiap hari dan berbeda dalam nuansa untuk setiap proyek.
Masalah ini mendorong saya untuk memulai sebuah blog. Saya cukup beruntung untuk belajar dari mentor, penulis, dan kolega yang sangat berbakat selama hampir dua puluh tahun. Tanpa saran dari orang-orang ini, saya masih akan menulis arahan
GOTO dalam QBasic (brrr). Sudah waktunya untuk mengambil bola dan pergi menyerang.
Untuk meringkas.
Blog ini didedikasikan untuk semua aspek pengembangan aplikasi siap pakai: dari otomatisasi infrastruktur hingga pengujian, desain, debugging, dokumentasi, proses pengembangan, dan keamanan. Setiap artikel independen dan cocok untuk digunakan di dunia nyata -
cocok untuk digunakan dalam produksi .