JH Rainwater "Cara merumput kucing": di sisi lain pembangunan

Kami terus membagikan ekstrak dari manual bagi mereka yang bersiap untuk memimpin tim pengembangan. Pada bagian sebelumnya, kami berbicara tentang segala sesuatu yang asing, yang menunggu pemimpin teknis di posisi baru, tetapi sekarang kami kembali ke hal-hal yang kerabat dan teman - sebenarnya pemrograman. Di sini, pengembang kemarin dapat merasakan elemennya, tetapi ia tidak harus rileks - bidang tanggung jawab tumbuh dan bergeser. Di bawah kucing, kami menyajikan ikhtisar singkat tentang semua tanggung jawab baru dan kiat adaptasi yang dibawa Rainwater dalam bukunya.

Perbedaan mendasar terletak pada dua nuansa. Pertama, pimpinan jauh lebih awal memasuki proses dan tidak ditutup sampai akhir kemenangan. Kedua, sementara pengembang fokus pada tugas sempit yang ditetapkan untuknya, bosnya meninjau produk secara keseluruhan, sementara tidak lupa untuk merinci ketika situasi membutuhkannya. Mari kita pergi bersama dengan penulis untuk mencoba menguraikan peran pemimpin tim pada setiap tahap pembuatan aplikasi.

Definisi persyaratan dan spesifikasi

Techlide yang baik mulai bekerja dengan produk bahkan ketika itu dalam keadaan perinatal - yaitu, dalam bentuk ide umum, permintaan atau daftar fungsi. Namun, di sini Anda perlu segera mengklarifikasi: Rainwater sangat percaya bahwa pengembang tidak boleh terlibat dalam pekerjaan pemasar atau manajer produk - atau lebih tepatnya, ia harus menghindari skenario ini dengan sekuat tenaga. Bukannya tidak mungkin atau tercela bagi "teknisi" untuk memahami realitas pasar dan persyaratan komersial, tetapi menggabungkan kedua peran ini sangat sulit. Antara lain, ada risiko yang lebih besar bahwa pengembang internal akan menang dan karakteristik produk akan disesuaikan dengan minat tim pemrogram, daripada pengguna akhir. Jauh lebih mudah dan aman untuk bekerja ketika visi umum produk dalam hal fungsinya sudah disiapkan dan diuji untuk kelangsungan hidup oleh orang-orang yang berpengetahuan.

Untuk penggabungan kedua peran tersebut, pengembang yang dalam klasifikasi kami sering menjadi bagian dari koboi yang sering dianjurkan - mereka merindukan "garasi" saat tim kecil membuat seluruh produk dari dan ke dan tidak diperlukan interaksi eksternal. Penulis sedang terburu-buru untuk menghilangkan semua ilusi pada skor ini: dalam kondisi modern, interaksi antara kelompok teknis dan non-teknis harus terjadi secara teratur, di seluruh siklus hidup aplikasi. Pertemuan pertama diadakan untuk persiapan bersama spesifikasi. Manajer pengembangan (atau salah satu pengembang terkemuka) berkenalan dengan deskripsi produk, mengecualikan segala sesuatu yang menurutnya tidak dapat dibenarkan atau tidak realistis dari sudut pandang teknis dan mengambil rencana akhir untuk menerjemahkannya ke dalam bahasa teknologi. Kemudian kelompok bertemu dari waktu ke waktu untuk “memeriksa jam” dan memastikan bahwa implementasi tidak menyimpang terlalu banyak dari rencana semula.

Frekuensi yang disarankan untuk rapat semacam itu adalah sekali seminggu, walaupun, tentu saja, Anda perlu melakukan penyesuaian pada kecepatan umum pengembangan dan fitur-fitur organisasi proses untuk perusahaan tertentu.

Pertemuan rutin juga akan diperlukan karena alasan lain - upaya untuk menyimpang dari kursus awal kemungkinan tidak hanya datang dari sisi pengembangan. Sebagian besar aplikasi, agar tetap kompetitif, terus berkembang dengan alat dan kemampuan tambahan. Oleh karena itu, proses mempertimbangkan, mengevaluasi, dan membuang ide dapat diulangi secara tak terbatas, hanya dalam skala yang lebih kecil daripada spesifikasi spesifik. Sangat penting bagi Tehlid untuk tetap mengikuti rencana pengembangan produk - ini tidak hanya memberinya ruang untuk bermanuver dari sudut pandang organisasi (alokasi tanggung jawab, penentuan persyaratan), tetapi juga memungkinkan Anda untuk menghitung terlebih dahulu konsekuensi untuk sistem secara keseluruhan, harmoni dan keberlanjutan.

Sebelum menyetujui untuk mengambil fungsi baru untuk bekerja, Anda harus bertanya pada diri sendiri sejumlah pertanyaan:

• Apa dampak perubahan yang diajukan terhadap arsitektur sistem dalam jangka pendek dan panjang?
• Bagaimana perubahan yang diusulkan akan mempengaruhi infrastruktur jaringan di mana itu akan terjadi?
• Bagaimana perubahan yang diajukan akan memengaruhi kemampuan pengguna untuk berinteraksi secara efektif dan produktif dengan produk ini?
• Apa dampak yang akan diajukan perubahan pada tindakan karyawan yang harus bekerja sama dengan dia - untuk menerapkan, menemani?

Refleksi semacam itu akan membantu mengidentifikasi jebakan dan menetapkan arahan umum untuk berdialog dengan kelompok lain.

Desain

Ketika persyaratan disetujui dan diberkati oleh semua peserta dalam proses, saatnya tiba untuk apa yang disebut Rainwater koordinasi keputusan arsitektur dan desain. Dengan kata lain, panduan teknis perlu menggambarkan sistem yang akan melakukan fungsi yang ditentukan pada tahap spesifikasi, dan memikirkan komponen yang bertanggung jawab untuk prosedur tertentu. Sangat penting untuk bertindak dalam urutan ini:

Arsitektur pertama, kemudian komponen.

Penulis menekankan ini berkali-kali, karena banyak pengembang yang tidak terbiasa dengan seni desain produk jatuh ke dalam perangkap ini. Tampaknya logis untuk mengambil daftar persyaratan, menentukan komponen yang diperlukan untuk masing-masing dan menganggap produk sebagai kombinasi sederhana dari mereka. Namun pada kenyataannya, pendekatan mekanistik ini memunculkan monster yang kaku dan terorganisir secara acak yang menyedot semua cairan dari pengembang yang terlibat dalam mendukung proyek. Untuk menghindari hal ini, Anda harus pergi ke arah lain, dari keseluruhan ke khusus. Anda sudah memiliki visi fungsional umum dari produk dengan perspektif pengembangan - Anda perlu “mencerminkannya” dalam visi teknis umum Anda dengan perspektif pengembangan, yaitu arsitektur.

Arsitektur bangunan

Jika kita menggunakan metafora yang usang, arsitektur adalah kerangka produk, yang menjadi dasar bagi keputusan pribadi tentang implementasi prosedur. Kami menghidupkan kembali metafora ini sedikit, menambahkan klarifikasi: kerangka harus dipertajam untuk menumbuhkan anggota badan baru. Dua persyaratan utama untuk arsitektur adalah organisasi logis komponen yang jelas dan fleksibilitas yang akan menambah yang baru seiring pertumbuhan proyek.

Mungkin tahap dalam pengembangan ini mungkin bisa disebut yang paling bertanggung jawab - para ahli mengatakan bahwa justru mengabaikan masalah arsitektur yang paling sering menyebabkan runtuhnya proyek. Di antara penyebab umum kegagalan, mereka menyebutkan:

• Kurang pemikiran, organisasi yang ceroboh (atau absen sama sekali).
• Kekakuan dan keterusterangan sistem yang berlebihan, mencegah perluasannya sesuai dengan kebutuhan komersial.
• Interkonektivitas komponen yang berlebihan, kurangnya fleksibilitas dalam konfigurasi.
• Kompleksitas yang berlebihan di tingkat atas, membuatnya sulit untuk memodifikasi komponen dasar.

Dengan demikian, tugas membangun arsitektur harus didekati dengan serius, bukan menghemat sumber daya. Ingatlah bahwa Anda meletakkan fondasi yang dengannya Anda harus bekerja sampai akhir - itu harus menahan semua perubahan yang menunggu proyek di masa depan. Proses ini sebagian besar kreatif dan visioner, tetapi metode penataan standar berguna untuk menyeimbangkan sistem. Sebagai contoh, gambarkan diagram blok dengan satu set penuh koneksi atau bahkan menerapkan tata letak sederhana (satu set komponen tingkat rendah dengan bertopik dan mengembalikan nilai) untuk memastikan bahwa arsitektur bekerja dalam proyeksi vertikal. Yang terakhir sangat diinginkan untuk dilakukan sebelum memulai pengembangan nyata, komponen lengkap - menghilangkan bug dengan elemen "mainan" jauh lebih mudah dan lebih tidak menyakitkan.

Pada akhir pekerjaan pada tahap ini, Anda harus siap untuk menjawab pertanyaan-pertanyaan berikut:

• Bagaimana pengguna berinteraksi dengan sistem?
• Komponen apa yang perlu dirakit untuk memastikan berfungsinya sistem?
• Apa yang akan menjadi mekanisme untuk interaksi komponen yang memastikan berfungsinya sistem?
• Teknologi apa yang paling cocok untuk membuat aplikasi ini?
• Bagaimana seharusnya mengirimkan sistem ke klien?

Perencanaan komponen

Ketika kerangka umum dikembangkan, sekarang saatnya untuk menyelidiki secara khusus dan menanamkan komponen yang saat ini relevan dalam struktur organik. Kesulitan utama di sini adalah untuk menahan ukuran keterhubungan yang diperlukan. Di satu sisi, komponen tidak boleh dianggap sebagai wadah yang sangat terisolasi untuk rangkaian operasi tertentu - melainkan sebagai sistem organ, yang masing-masing berkomunikasi dengan yang lain, tetapi menjalankan fungsinya. Pada saat yang sama, saling ketergantungan yang kuat antar daerah harus dihindari, akibatnya modifikasi satu komponen akan mengarah pada keseluruhan rantai perubahan, atau bahkan kegagalan fungsi, di seluruh sistem.

Tumpukan teknologi diuraikan pada tahap terakhir, sekarang Anda harus memahaminya secara rinci. Dalam pilihan bahasa, perpustakaan, dan lebih jauh masuk akal untuk dibimbing tidak hanya oleh profesional, tetapi juga motif pragmatis. Katakanlah, apakah Anda memiliki personel yang cukup kompeten untuk mendukung sistem yang dibangun berdasarkan teknologi canggih, langka, atau kompleks? Dan sebaliknya, jika Anda memilih teknologi yang lebih tua, seberapa menjanjikannya - akankah mereka tetap bekerja di seluruh siklus hidup, akankah masalah kompatibilitas mulai muncul? Semua masalah yang terkait dengan solusi perangkat keras, pembuatan, konfigurasi dan pemeliharaan infrastruktur harus dipertimbangkan dengan hati-hati.

Pengembangan dan kontrol kualitas

Jadi, perencanaan akhirnya selesai dan proyek berjalan - pengembangan aplikasi yang sebenarnya dimulai. Peran pemimpin teknis dalam proses ini terutama terdiri dari pemantauan, sehingga semuanya berjalan sesuai dengan persyaratan dan standar; ia terlibat langsung dalam pembuatan kode, sebagai aturan, hanya dalam situasi force majeure. Untuk sebagian besar, kepala melakukan fungsi polisi kode, yaitu, melakukan tinjauan kritis reguler kode untuk memastikan bahwa mereka tidak bertentangan dengan kerangka kerja arsitektur dan prinsip-prinsip dasar pemrograman.

Selama inspeksi, seorang pemimpin teknis mungkin menghadapi berbagai jenis kesalahan. Rainwater memfokuskan pembaca pada dua varietas:

• Pelanggaran standar . Ini termasuk gaya, penamaan, komentar - secara umum, segala sesuatu yang membantu pihak ketiga memahami apa yang terjadi dalam kode, serta kelalaian dalam semangat beberapa titik keluar atau operator GoTo yang dibenci. Penting untuk memastikan bahwa semua peserta dalam proses pengembangan berbicara dalam bahasa yang sama - ini membuat kode transparan dan memungkinkan Anda untuk dengan cepat mengungkap langkah-langkah yang salah. Nama-nama parameter dan variabel harus secara jelas menunjukkan konten mereka, komentar harus membantu melacak kode pemikiran pengembang, membenarkan keputusannya. Ngomong-ngomong, jika seseorang dari tim dengan keras kepala menolak untuk mengomentari kode, perlu dipertimbangkan alasannya. Seringkali ini hanya kemalasan atau kekhasan pemikiran, tetapi dalam beberapa kasus itu mungkin menjadi gejala bahwa karyawan itu sendiri tidak benar-benar mengerti apa yang dia lakukan - bingung atau hanya menyalin potongan kode orang lain untuk alasan yang baik. Penting juga untuk memantau dengan cermat mereka yang secara teratur mengabaikan penanganan kesalahan: ketidakmampuan untuk mengidentifikasi sumber bug adalah kelemahan serius bagi pengembang.
• Konektivitas yang lemah dan saling ketergantungan yang kuat adalah dua area gangguan yang dapat dipertimbangkan bersama, karena kehadiran satu menyiratkan kehadiran yang lain. Di sini, pada kenyataannya, semuanya tergantung pada tingkat percabangan dan jenisnya. Dengan tingkat percabangan yang tinggi dalam hal keluaran, berfungsinya prosedur melibatkan akses ke banyak prosedur lain, yang, tentu saja, tidak diinginkan. Percabangan di pintu masuk, sebaliknya, memiliki efek positif, karena menunjukkan enkapsulasi yang ketat. Jika Anda ragu ketika menganalisis kode untuk parameter ini, alangkah baiknya membuat diagram blok dengan hierarki objek yang ditandai. Ini segera mengungkapkan semua yang perlu Anda ketahui: apakah mungkin untuk melacak silsilah objek, apakah ada logika dalam pengaturan panah, atau apakah semuanya terlihat berantakan.

Jika kode polisi mendeteksi pelanggaran di area ini dan lainnya, prosedur penangkapan akan terlihat seperti ini: kode tersebut dikirim kembali ke pengembang dengan komentar yang diperlukan, pengerjaan komponen terkait ditangguhkan hingga cacat diperbaiki. Sangat diharapkan bahwa pengembang menangani ini sendiri, meskipun dengan tips - jika Anda melakukan segalanya untuknya, komponen bimbingan kode inspeksi hilang.

Jangan menunda revisi sampai waktu yang lebih baik. Pertama-tama, ini bisa sangat kembali di masa depan dan membutuhkan lebih banyak sumber daya untuk memperbaiki seluruh bola salju masalah. Kedua, teori broken windows juga berfungsi dalam pemrograman - kode yang tidak rapi dan membingungkan menghasilkan kode yang lebih tidak rapi dan membingungkan, hanya karena tampaknya valid.

Akhirnya, berbicara tentang kontrol kualitas, orang tidak bisa tidak menyentuh masalah faktor manusia yang terkenal. Rainwater merekomendasikan agar manajer mengambil posisi tengah. Beberapa derajat resistensi terhadap gangguan terhadap kode adalah alami dan tidak berbahaya. Kesediaan total untuk mengikuti instruksi orang lain dan menerima pendapat orang lain bahkan harus mengingatkan Anda - seringkali ini berarti bahwa pengembang, pada kenyataannya, tidak peduli dengan apa yang dia rilis. Tetapi di sisi lain, ketidakmampuan untuk menerima kritik yang sehat menghambat pertumbuhan profesional dan kerja tim. Dengan demikian, technlide harus menumbuhkan kulit yang lebih tebal dan tidak takut untuk memaksakan diri, tanpa mengambil reaksi negatif ke jantungnya.

Pengujian

Di sini, penting bagi pemimpin untuk mengingat dua aturan dasar: pengujian harus dilakukan dan mengorganisir pelaksanaannya adalah tanggung jawab Anda. Jika perusahaan memiliki departemen pengujian yang secara alami terlibat dalam proses, maka tidak akan ada masalah dengan ini. Jika tidak, Anda harus mengalokasikan sumber daya dari cadangan Anda sendiri untuk masalah ini.
Dalam skenario kedua, menurut penulis, ada keuntungan tertentu: pengujian adalah keterampilan yang berguna bagi pengembang. Ini sangat berguna untuk menarik pendatang baru ke tugas-tugas ini, sehingga mereka dengan cepat mendapatkan kualifikasi. Pada awalnya, Anda dapat mengambil tugas pengujian hingga setengah dari waktu kerja mereka.

Kalau tidak, untuk memastikan kualitas inspeksi yang baik, perlu untuk memastikan bahwa produk tidak dimasak sepanjang waktu dalam kelompok yang sama - idealnya, produk harus diuji “di samping”. Jika sebuah perusahaan memiliki beberapa tim pengembangan, mungkin masuk akal untuk setuju dengan para pemimpin lain untuk membuat grup campuran.