Tentunya Anda semua pada tahap yang berbeda dalam karir Anda pernah menghadapi masalah seperti itu: Anda melihat tugas itu, tampaknya itu sederhana dan persyaratannya jelas, lalu ternyata Anda perlu menerapkannya secara berbeda. Waktu untuk implementasi telah dihabiskan, dan tenggat waktu sudah tiba, dan tugas sebenarnya belum siap. Kami harus menulis ulang dengan cepat, mungkin melanggar tenggat waktu. Man-hour terbuang percuma, dan menghabiskan uang, dan jika masalah ini bukan untuk satu pengembang, tetapi untuk seluruh perusahaan, maka segumpal tugas yang terlambat bertambah, biaya pengembangan tumbuh, bisnis tidak dapat menerapkan strategi, dan perusahaan menderita kerugian.
Apa masalahnya?
Masalah ini muncul karena pencelupan yang tidak memadai dalam tugas. Ada banyak alasan, berikut beberapa di antaranya:
- kurangnya dokumentasi terkini;
- kesalahpahaman tentang proses bisnis;
- elaborasi persyaratan tidak sepenuhnya;
- faktor manusia (sumber pengetahuan dan pelaku berbicara tentang hal yang sama, tetapi mereka memahaminya secara berbeda);
- kecerobohan pribadi pelaku dan pelanggan;
- dan lainnya (masing-masing menginjak penggaruk dengan caranya sendiri).
Sebagai hasil dari pencelupan yang tidak memadai dalam tugas, pengembang melakukan hal yang salah atau tidak sepenuhnya, penguji melakukan hal yang salah, pengembang melakukan hal yang salah, dan SRE memantau parameter yang salah.
Bagaimana ini bisa diperbaiki?
Di tempat kerja sebelumnya, saya telah melihat algoritma kerja berikut:
- pengumpulan informasi dan pembentukan persyaratan;
- tim sedang mempersiapkan dan memikirkan solusi bersama;
- seorang pelaksana ditunjuk yang melaksanakan tugas;
- review kode;
- perbaikan;
- pengujian;
- lebih banyak perbaikan;
...
- lebih banyak perbaikan;
- lama ditunggu penyelesaian tugas.
, , ?
, , , , . 
Deskripsi solusi teknis dibuat bahkan sebelum dimulainya pengembangan dan kemudian ditinjau oleh seluruh tim. Untuk kejelasan dan peningkatan persepsi, kami memutuskan untuk mengencerkan teks dengan skema grafis. Tujuan dari tindakan ini adalah untuk mengidentifikasi jebakan, memilih alat yang tepat, berinteraksi dengan benar dengan node lain dalam sistem, dan dapat melibatkan seluruh tim dalam solusi. Hasil yang kami harapkan adalah penurunan biaya tenaga kerja dan kesalahan dalam proses bisnis (ke depan, saya akan mengatakan bahwa kesalahan dalam logika bisnis secara praktis telah hilang, banyak kesalahan teknis telah dihindari, perbaikan telah dikurangi, dan waktu rata-rata untuk menyelesaikan tugas telah menurun dengan cukup baik). Ternyata juga jauh lebih mudah dan cepat untuk mengedit deskripsi atau diagram tekstual daripada kode yang sudah tertulis.
Maka algoritma kerjanya adalah sebagai berikut:
- pengumpulan informasi dan pembentukan persyaratan;
- tim sedang mempersiapkan dan memikirkan solusi;
- pengembang yang bertanggung jawab ditunjuk;
- pengembang menjelaskan solusi teknis ;
- kemudian solusi teknis ini ditinjau oleh tim dan orang lain yang terlibat dalam bidang subjek ;
- dan hanya setelah solusi disetujui, pengembang menulis kodenya ;
- review kode;
- pengujian.
Mengapa sangat penting untuk menjelaskan solusi teknis sebelum penerapan sebenarnya:
- logika solusi ditinjau, kesalahan diperbaiki pada tahap desain;
- pengembang mendalami domain sebelum implementasi, yang memungkinkan untuk memikirkan arsitektur terlebih dahulu;
- departemen yang berdekatan dapat segera memahami seperti apa API itu dan siap untuk memulai pengembangan paralel;
- mengklarifikasi kebutuhan kolega tergantung pada implementasi Anda;
- ( , , ).
Exness?
Setelah datang ke Exness, saya ingin cepat terbiasa dengan tim, mempelajari infrastruktur, dan mulai menyelesaikan misi tempur. Dalam tugas besar pertama, saya memutuskan untuk menggunakan pengalaman yang terkumpul dan meminimalkan risiko pemecahan masalah yang salah. Untuk menggambarkan interaksi layanan, saya memutuskan untuk menggunakan diagram sekuens, diagram blok untuk menggambarkan pengoperasian algoritma dan diagram ER untuk menggambarkan skema database.
Dalam proses menggambar diagram, saya belajar dari kolega saya layanan apa yang mungkin diperlukan untuk menyelesaikan masalah saya, memeriksa permintaan kepada mereka dan data di database, jadi saya sudah memahami apa dan bagaimana cara kerjanya. Tidak perlu banyak waktu untuk mengembangkan diagram, dan saat meninjau diagram, saya menerima umpan balik yang berguna:
- pengembang front-end ingin tahu dalam kasus apa, data dan status apa yang akan dia terima dari back-end;
- QA perlu memahami dari mana data dalam layanan berasal untuk mencakup sebanyak mungkin kasus.
Dalam diagram, saya telah merinci pengecualian dan bagaimana mereka "keluar" dan sumber data yang digunakan. Ini memungkinkan untuk menunjukkan secara visual kepada kolega bagaimana fungsionalitas itu bekerja dan apa yang diharapkan darinya, masing-masing, kolega dapat mulai menerapkan bagian mereka tanpa menunggu implementasi saya. Pengembang front-end tahu bagaimana layanan akan merespons dan dapat mulai menulis integrasi, QA memiliki informasi tentang bagaimana layanan menanggapi situasi yang berbeda dan bagaimana mereproduksi situasi ini. Hasilnya, pengembangan dan pencelupan dalam tugas menjadi cukup cepat, dan diagram yang digambar melengkapi dokumentasi layanan yang sedang dikembangkan.
Contoh
Contoh yang dijelaskan di bawah ini adalah gabungan dari berbagai situasi.
Pengembang baru menerima tugas dengan kata-kata " Tulis layanan mikro baru untuk menolak aplikasi yang lewat waktu. Beri tahu pelanggan tentang perubahan status. "
Setelah mengklarifikasi detail teknis, Anda dapat memahami masalahnya seperti ini:
- membangun layanan mikro, membuat satu POST di dalamnya - metode API bernama reject_old_requests;
- dalam metode API ini, Anda perlu mendapatkan data dari database, menentukan filter berdasarkan pengguna, status, dan tanggal dalam permintaan;
- untuk setiap permintaan, ubah status di layanan yang mengelola permintaan;
- kemudian kirim permintaan ke layanan notifikasi untuk memberi tahu pengguna tentang perubahan status aplikasi.
Diagram urutan untuk tugas ini mungkin terlihat seperti ini:
dan kesalahan apa yang mungkin Anda alami:
- di bawah layanan mikro baru, analis dapat berarti metode API biasa di layanan mikro untuk bekerja dengan permintaan, tetapi sulit untuk mengenali skenario seperti itu (dalam praktik saya, ada kasus ketika analis memahami metode API biasa sebagai layanan mikro, sejauh yang saya tahu analis tidak beradaptasi dengan terminologi yang benar);
- mungkin aplikasi tersebut memiliki sub-aplikasi atau aplikasi terkait, yang keberadaannya mungkin tidak diketahui oleh pengembang baru, dan analis mungkin lupa untuk melaporkan dan berharap pengembang sendiri yang akan mendapatkan informasi tersebut;
- Mungkin akan ada banyak aplikasi, dan penolakan mereka dalam penjualan akan memakan waktu lama. Dalam hal ini, akan lebih baik untuk berbaring dan memungkinkan untuk menolak di latar belakang;
- — , . , .
Akibatnya, ternyata Anda harus menulis ulang solusi seperti itu dari awal, karena adanya kesalahan semacam itu dapat membuat penerapannya tidak dapat dijalankan.
Jika Anda menulis solusi teknis sebelum pengembangan dan menggunakan diagram urutan untuk kejelasan, maka selama peninjauan, rekan kerja yang lebih mendalam di bidang subjek akan dapat melihat kesalahan dan menunjukkannya. Dan mungkin pengembang itu sendiri akan dapat melihat beberapa masalah dan memperbaikinya sebelum meninjau.
Saya yakinkan Anda, hanya mengatakan solusi untuk suatu masalah tidak berarti menyelesaikan masalah dengan benar, yang satu tidak akan mengungkapkannya dengan benar, dan yang lain tidak akan memahami dengan benar, dan tugas tidak akan dilaksanakan dengan benar. Diagram urutan bukanlah peluru perak, tetapi dalam banyak kasus diagram ini akan membantu memperjelas beberapa detail.
Seperti apa diagram tersebut setelah koreksi:
Apa gunanya grafik?
Tidak setiap orang dapat mentransfer pemikiran ke kertas dengan baik, jadi lebih baik terkadang untuk mengencerkan teks dengan deskripsi grafis. Deskripsi masalah yang lebih deskriptif akan berguna tidak hanya untuk pengembang, tetapi juga untuk penguji, karena mereka menghadapi masalah pencelupan yang sama seperti pengembang. Penguji tidak hanya perlu memeriksa hasil positif, tetapi untuk memastikan bahwa sistem merespons dengan benar dan dapat diprediksi dalam situasi apa pun; untuk meniru kasus seperti itu, seseorang perlu memahami dengan baik apa yang telah berubah dalam sistem. Untuk tim secara keseluruhan, mungkin lebih mudah untuk menyimpan dokumentasi dalam bentuk diagram atau berbagai skema, karena mereka singkat, dengan perubahan besar membutuhkan waktu lebih sedikit untuk diedit daripada deskripsi tekstual. Dalam pemfaktoran ulang utama, bagan sangat diperlukan karena memungkinkan Anda untuk dengan cepat memahami siapa dan bagaimana bekerja dengan simpul tertentu dalam sistem.Untuk pemimpin tim, hal ini akan berguna karena Anda dapat mengurangi waktu Anda dan waktu rekan kerja junior untuk mendalami, dan karenanya, merencanakan tugas dengan lebih akurat. Ketika mentransfer kasus dari satu pengembang ke pengembang lainnya, biaya waktu berkurang, masing-masing, situasi dengan faktor bus membaik.
Kesimpulan apa yang bisa ditarik?
Diagram urutan adalah alat yang sangat kuat dan berguna yang menghemat waktu Anda dan kolega Anda. Deskripsi visual menyederhanakan persepsi dan memungkinkan Anda untuk fokus pada solusi itu sendiri tanpa masuk jauh ke dalam implementasi teknis. Tetapi sama sekali tidak mengatakan bahwa deskripsi visual seperti itu adalah keselamatan dari semua masalah, tetapi itu akan membantu menyelesaikan sebagian besar masalah itu.
Diagram pasti akan membantu dengan:
- kualitas dan kecepatan perendaman dalam proyek / tugas;
- memperbaiki situasi dengan faktor bus;
- mengurangi biaya tenaga kerja untuk memelihara dokumentasi teknis;
- menyederhanakan transfer kasus antar rekan kerja;
- mengurangi biaya tenaga kerja untuk implementasi, pengujian dan peninjauan kode, karena logika pemecahan masalah ditinjau bahkan sebelum dimulainya implementasi - Anda akan menghindari banyak kesalahan.
Secara pribadi, dalam praktik saya, diagram telah dan tetap menjadi alat yang sangat diperlukan.
Saya juga berharap Anda menemukan alat yang akan mengoptimalkan pekerjaan Anda. Terima kasih sudah membaca sampai akhir.
NB Tulis di komentar, apakah Anda menggunakan praktik ini, alat apa yang Anda gunakan?