Perubahan dalam sistem perangkat lunak yang rumit tampaknya berlangsung selamanya, bukan? Bahkan insinyur sering berpikir bahwa perubahan melampaui apa yang seharusnya, meskipun kami menyadari kompleksitas sistem!

Bagi pelanggan, situasinya bahkan lebih sulit dipahami. Masalahnya diperparah oleh kompleksitas acak, yang ditambahkan dari waktu ke waktu karena dukungan sistem yang buruk. Ada perasaan bahwa kami mencoba mengambil air dari sebuah kapal dengan seribu lubang.

Oleh karena itu, cepat atau lambat, pelanggan akan mengirim surat: "Kenapa itu butuh waktu begitu lama?" Jangan lupa bahwa kita, sebagai insinyur perangkat lunak, memiliki jendela ke dunia, yang seringkali tidak mereka miliki. Mereka sangat mempercayai kita, tetapi terkadang perubahan yang tampaknya tidak penting benar-benar membutuhkan banyak waktu. Karena itu, timbul pertanyaan.

Jangan tersinggung oleh pertanyaan ini; menganggapnya sebagai kesempatan untuk menunjukkan empati dan memberi seseorang gambaran yang lebih jelas tentang kompleksitas sistem. Pada saat yang sama, Anda dapat menyarankan cara untuk memperbaiki situasi. Ketika seseorang kesal, ini adalah saat terbaik untuk menawarkan solusi!

Sebuah surat diterbitkan di bawah ini, yang dalam satu atau lain bentuk, kami telah berulang kali mengirim selama bertahun-tahun. Kami harap ini membantu Anda menjawab pertanyaan-pertanyaan ini.

Sepucuk surat

Pelanggan yang terhormat,

Saya melihat komentar Anda pada kartu "Beritahu sebelum berakhirnya tugas" dan saya akan senang untuk membahasnya pada pertemuan berikutnya. Di sini, sebagai referensi, saya akan merangkum pikiran saya, tidak perlu dijawab.

Untuk memparafrasekan catatan Anda:

Mengubah tenggat waktu untuk menyelesaikan tugas satu hari untuk pemberitahuan melalui pos harus dilakukan satu baris. Bagaimana bisa memakan waktu 4-8 jam? Apa yang saya lewatkan?

Di satu sisi, saya setuju dengan Anda. Cukup ubah bagian permintaan dari tasks due <= today ke tasks due <= tomorrow .

Di sisi lain, menguranginya menjadi ide yang disederhanakan, kami secara tidak sengaja mengabaikan kompleksitas yang melekat dan membuat sejumlah keputusan rekayasa. Beberapa dari mereka harus kita diskusikan.

Bagian 1. Mengapa perubahan kecil ini lebih dari yang terlihat?

Ini sederhana, perubahan kecil, satu baris kode. Menghabiskan sepanjang hari untuk itu, bahkan setengah hari, tampak berlebihan.

Tentu saja, Anda tidak bisa hanya melakukan perubahan produksi tanpa menjalankan setidaknya secara lokal atau pada server pengujian. Anda harus memastikan bahwa kode dieksekusi dengan benar, dan jika permintaan berubah, Anda harus membandingkan hasilnya dan memastikan bahwa itu terlihat kurang lebih benar.

Di sini, membandingkan output bisa minimal, hanya pemeriksaan kecil: pastikan hasilnya masuk akal, dll. Ini adalah pemberitahuan untuk karyawan internal. Jika matematika berdasarkan tanggal tidak benar (sedikit kesalahan), kami akan segera mendengarnya dari tim. Jika itu, katakanlah, email untuk pelanggan Anda, studi yang lebih dalam akan diperlukan. Tetapi untuk pengujian dan ulasan yang mudah ini, 20-40 menit sudah cukup, tergantung pada apakah sesuatu yang aneh atau tidak terduga muncul. Menggali data bisa memakan waktu. Melepaskan perubahan tanpa melakukan tinjauan hanyalah kelalaian yang tidak profesional.

Dengan demikian, kami menambahkan waktu untuk logistik normal, seperti melakukan kode, menggabungkan perubahan, menyebarkan, dll: dari awal pekerjaan hingga rilis dalam produksi, setidaknya satu jam berlalu dari insinyur profesional yang kompeten.

Tentu saja, ini mengasumsikan bahwa Anda tahu persis baris kode mana yang harus diubah. Alur kerja tugas pada dasarnya tinggal di sistem lama, tetapi beberapa bagian dari logika tinggal di sistem baru. Memindahkan logika dari sistem lama itu baik, tetapi itu berarti bahwa fungsionalitas tugas saat ini dibagi menjadi dua sistem.

Karena kami telah bekerja bersama begitu lama, tim kami tahu proses mana yang mengirim email dengan tugas yang sudah kadaluwarsa dan dapat menunjuk ke baris kode dalam sistem baru yang mengawali proses. Jadi kita tidak perlu membuang waktu untuk mencari tahu.

Tetapi jika kita melihat kode tugas dalam sistem yang lama, setidaknya ada empat cara berbeda untuk menentukan apakah tugas itu sudah jatuh tempo. Selain itu, melihat pola dan perilaku email, ada setidaknya dua tempat lagi di mana tampaknya logika khusus untuk tugas ini diterapkan.

Dan kemudian logika notifikasi lebih rumit dari yang Anda pikirkan. Ini membedakan antara tugas umum dan individual, terbuka dan pribadi, berulang, fungsi pemberitahuan tambahan dari manajer dalam kasus tugas yang terlambat, dll. Tapi kita dapat dengan cepat mengetahui bahwa sebenarnya hanya 2 dari 6+ definisi tugas yang terlambat digunakan untuk pemberitahuan. Dan hanya satu hal yang perlu diubah untuk mencapai tujuan.

Tinjauan seperti itu dapat dengan mudah memakan waktu setengah jam atau lebih, mungkin kurang jika Anda baru-baru ini berada di bagian basis kode ini. Selain itu, kompleksitas laten berarti bahwa kami dapat melampaui perkiraan kami untuk pengujian manual. Tapi mari kita tambahkan 30 menit saja untuk usaha ekstra.

Dengan demikian, kami mencapai 1,5 jam untuk merasa yakin bahwa perubahan akan dilakukan seperti yang diharapkan.

Tentu saja, kami belum memeriksa apakah proses lain menggunakan kueri yang dapat diubah. Kami tidak ingin secara tidak sengaja mengganggu fungsi lain dengan mengubah konsep "tenggat waktu" menjadi hari yang mendahului hari terakhir untuk menyelesaikan tugas. Kita harus mempertimbangkan basis kode dari sudut pandang ini. Dalam hal ini, tampaknya tidak ada dependensi utama - mungkin karena sebagian besar antarmuka pengguna masih pada sistem yang lama. Oleh karena itu, tidak perlu khawatir tentang mengubah atau menguji proses lain. Dalam kasus terbaik, ini adalah 15-30 menit lagi.

Oh, dan karena bagian utama dari antarmuka pengguna tugas masih ada di sistem lama, kami benar-benar perlu melakukan tinjauan singkat tentang fungsi tugas di sistem ini dan memastikan bahwa umpan baliknya benar. Misalnya, jika antarmuka pengguna menyoroti tugas yang tenggat waktunya telah tiba, kami dapat mengubah logika ini agar sesuai dengan pemberitahuan. Atau setidaknya kembali dan tanyakan kepada klien bagaimana ia ingin melakukannya. Baru-baru ini, saya tidak melihat fungsionalitas tugas di sistem lama dan saya tidak ingat apakah ia mengetahui batas waktu / penundaan. Ulasan ini menambah 15-30 menit lagi. Mungkin lebih jika sistem lama juga memiliki beberapa definisi "tugas", dll.

Dengan demikian, kami pergi ke kisaran 2–2,5 jam untuk menyelesaikan tugas dengan keyakinan bahwa semuanya akan baik-baik saja, tanpa efek samping yang tidak diinginkan atau kebingungan dalam pekerjaan pengguna.

Bagian 2. Bagaimana saya bisa mengurangi waktu ini?

Sayangnya, satu-satunya hasil dari upaya ini hanyalah pemenuhan tugas. Ini tidak optimal, yang sangat mengecewakan. Pengetahuan yang diperoleh pengembang selama bekerja bersifat pribadi dan sementara. Jika pengembang lain (atau diri kami sendiri setelah 6 bulan) lagi perlu melakukan perubahan pada bagian kode ini, proses tersebut harus diulang.

Ada dua taktik utama untuk memperbaiki situasi:

1. Secara aktif membersihkan basis kode untuk mengurangi duplikasi dan kerumitan.
   
2. Tulis tes otomatis.

Catatan: kami sudah membahas dokumentasi, tetapi dalam hal ini ini bukan solusi terbaik. Dokumentasi bermanfaat untuk ide-ide tingkat tinggi, seperti menjelaskan logika bisnis atau proses yang sering diulang, seperti daftar mitra baru. Tetapi ketika datang ke kode, dokumentasi dengan cepat menjadi terlalu tebal dan menjadi ketinggalan zaman ketika kode berubah.

Anda perhatikan bahwa tidak satu pun dari taktik ini termasuk dalam 2–2,5 jam kami.

Misalnya, mempertahankan basis kode yang bersih berarti bahwa alih-alih hanya menyelesaikan tugas, kami mengajukan pertanyaan:

• Mengapa ada begitu banyak cara berbeda untuk mengidentifikasi tugas-tugas yang batas waktunya telah mendekati / kedaluwarsa?
  
• Apakah mereka semua membutuhkan dan mengerjakannya?
  
• Bisakah metode ini direduksi menjadi satu atau dua konsep / metode?
  
• Jika konsep ini dibagi antara yang lama dan yang baru, dapatkah itu dikonsolidasikan?

Dan sebagainya.

Jawaban atas pertanyaan-pertanyaan ini bisa sangat cepat: misalnya, jika kita menemukan kode mati jelas. Atau mereka mungkin memakan waktu beberapa jam: misalnya, jika tugas digunakan dalam banyak proses yang kompleks. Segera setelah kami memiliki jawaban ini, akan diperlukan lebih banyak waktu untuk refactoring untuk mengurangi duplikasi / kebingungan dan mendapatkan deskripsi tunggal tentang konsep "tenggat waktu" - atau mengganti nama konsep dalam kode untuk memahami dengan jelas perbedaannya dan mengapa.

Tetapi pada akhirnya, ini bagian dari basis kode akan menjadi lebih sederhana, akan lebih mudah untuk membaca dan memodifikasi.

Taktik lain yang biasanya kita gunakan adalah pengujian otomatis. Dalam arti tertentu, tes otomatis mirip dengan dokumentasi yang tidak dapat kedaluwarsa dan yang lebih mudah dideteksi. Alih-alih menjalankan kode secara manual dan melihat output, kami menulis kode uji yang meluncurkan permintaan dan memverifikasi output secara terprogram. Setiap pengembang dapat menjalankan kode tes ini untuk memahami bagaimana sistem seharusnya bekerja dan memastikan bahwa itu masih berfungsi seperti itu.

Jika Anda memiliki sistem dengan cakupan tes yang layak, perubahan ini akan memakan waktu lebih singkat. Anda dapat mengubah logika dan menjalankan suite uji lengkap dan memastikannya

1. perubahan berfungsi dengan benar;
   
2. perubahan tidak merusak apa pun (ini bahkan informasi yang lebih berharga daripada paragraf pertama).

Ketika kami membangun sistem dari awal di Simple Thread, kami selalu menyertakan waktu untuk menulis tes otomatis dalam evaluasi tenggat waktu. Ini dapat memperlambat pengembangan awal, tetapi sangat meningkatkan efisiensi kerja dan pemeliharaan. Hanya ketika sistem tumbuh, apakah Anda benar-benar memahami pentingnya tes, tetapi pada titik ini bisa sangat sulit untuk mengembalikan tes ke sistem. Kehadiran tes juga sangat menyederhanakan pekerjaan karyawan baru, dan mengubah perilaku sistem jauh lebih cepat dan lebih aman.

Bagian 3. Dari mana kita berasal? Kemana kita akan pergi

Hari ini, kami jarang menunjukkan dalam penilaian Anda waktu untuk menghapus kode atau menulis tes. Ini sebagian karena menulis tes dari awal adalah overhead kecil, dan menambahkan tes ke backdating basis kode adalah banyak pekerjaan, seperti memulihkan fondasi di bawah rumah tempat tinggal orang.

Ini juga sebagian karena fakta bahwa mulai bekerja dengan Anda, kami segera beralih ke mode resusitasi. Kami memiliki masalah hampir setiap hari dengan menyinkronkan data pihak ketiga, masalah mingguan dengan menghasilkan laporan, permintaan konstan untuk dukungan untuk perubahan data kecil, pemantauan yang tidak memadai dan pencatatan sistem, dll. Basis kode tenggelam karena beban hutang teknis, dan kami dengan tergesa-gesa mencoba untuk menjaga sistem tetap menyala mengapung, sambil menempel lubang dengan pita listrik.

Seiring waktu, sistem menjadi lebih stabil dan dapat diandalkan, kami mengotomatiskan / menyediakan UI untuk swalayan atas permintaan dukungan yang sering. Kami masih memiliki banyak hutang teknis, tetapi kami keluar dari mode darurat. Tetapi saya tidak berpikir bahwa kita akan sepenuhnya beralih dari mentalitas penghidupan kembali ini ke mentalitas "rencana dan eksekusi" yang lebih proaktif dan matang.

Kami mencoba menghapus kode saat dalam perjalanan, dan kami selalu menguji secara menyeluruh. Tetapi berhati-hati dan rajin bukanlah refactoring proaktif atau menciptakan infrastruktur yang diperlukan untuk pengujian otomatis yang baik.

Jika kita tidak mulai membayar hutang teknis, kita tidak akan pernah dapat memperbaiki situasi secara signifikan. Pengembang yang kompeten dan berkompeten tinggi akan membutuhkan waktu berbulan-bulan untuk bernavigasi dan membuat perubahan yang tidak sepele.

Dengan kata lain, 4-8 jam untuk tugas ini adalah sekitar 2-4 kali pasokan, tetapi itu akan secara signifikan mengurangi upaya untuk perubahan tersebut di masa depan. Jika bagian dari basis kode ini lebih bersih dan memiliki cakupan yang baik dengan tes otomatis, maka pengembang yang kompeten akan menyelesaikannya dalam satu jam atau kurang. Dan kuncinya adalah bahwa pengembang baru akan mengambil sedikit lebih banyak waktu.

Untuk perubahan dalam hal ini, kami membutuhkan persetujuan Anda. Ini adalah upaya sadar untuk secara fundamental meningkatkan kinerja sistem Anda, bukan hanya bagaimana pengguna melihatnya. Saya memahami bahwa sulit untuk menyetujui investasi semacam itu karena tidak ada manfaat yang terlihat, tetapi kami senang untuk duduk bersama Anda dan menyiapkan beberapa angka jelas yang akan menunjukkan bagaimana investasi ini akan terbayar dalam jangka panjang dari sudut pandang teknik.

Terima kasih
Al