Apakah ini tanda-tanda pengembang yang buruk? [Tutup]

Saya dulu menyalahkan perubahan spesifikasi dari klien untuk pembusukan kode, tidak menyadari bahwa model bisnis berubah dan itu tugas saya untuk berkembang dengan cara yang mudah beradaptasi. Saya sekarang melihat itu sebagai pertanda pengembang yang buruk (saya telah berubah!).

Tetapi sekarang saya melihat 'ikan paus' lain dalam diri saya. Beberapa kali baru-baru ini saya mendapati diri saya berkata 'itu seperti mencoba memasukkan pasak persegi ke dalam lubang bundar', dan juga saya mendapati diri saya menyalahkan keragu-raguan klien untuk sebuah proyek yang tidak mengalami kemajuan.

Apakah ada tanda-tanda saya harus mencari di mana saya harus mengubah sikap saya? Apakah klien selalu benar, atau kadang-kadang saya dibenarkan frustrasi?

Saya tidak akan mengatakan Anda adalah pengembang yang buruk. Menyadari masalah yang sudah bergerak Anda melampaui definisi ini.

Persyaratan berubah. Itu diberikan. Pengembang yang baik perlu mempertimbangkan hal ini. Banyak teknik pemrograman modern membantu mengatasi hal itu.

Tetap setia pada spesifikasi asli tidak realistis. Juga tidak realistis mengubah persyaratan setiap saat.

Klien jelas tidak selalu benar. Itu 'benar' lebih sering daripada yang kita inginkan, meskipun (seperti dalam, cobalah untuk mengakomodasi dia jika dia tidak benar-benar mati). Tetapi ketika Anda melihatnya mengarahkan proyek ke arah yang salah, cobalah untuk mengadvokasi hal-hal yang menurut Anda benar.

Tidak ada aturan keras tentang hal-hal ini, dan bahkan pengembang yang baik dan berpengalaman belum mencapai 'Zen' yang sempurna. Satu-satunya pendekatan yang salah adalah tidak mencoba untuk memperbaiki ini.

Ada kasus di mana itu adalah klien. Tapi itu masalahmu juga

Ada kasus di mana itu adalah pengembang, dan ada kasus, di mana itu adalah pelanggan. Tapi, biasanya mereka berdua adalah masalah Anda , jadi sikap menyalahkan diri sendiri cenderung lebih berhasil, karena itu ada di sisi penyelesaian masalah alih-alih menunjuk tanpa jari. Karenanya, Anda akan sering menemukannya di pengembang yang lebih berpengalaman.

Sikap yang lebih baik lagi adalah IMHO untuk melihatnya tanpa kesalahan: "itu kesalahan pelanggan, saya memiliki kode yang buruk, karena ia selalu mengubah persyaratan" kemudian menjadi "pelanggan ini mencari tahu apa yang diinginkannya, jadi umpan balik, prototipe cepat, dan fleksibilitas lebih penting daripada kelengkapan, ketahanan dan kecepatan ".

Jenis pikiran Zen: jangan menilai itu, lihat saja seperti apa adanya.

Pertama, klien tidak tahu apa yang mereka inginkan sampai mereka melihatnya. Itu bagian dari daya tarik dari iterasi paradigma Agile yang kecil dengan keterlibatan klien yang banyak. Kedua, jangan berharap produk menjadi "lengkap" ketika kode Anda lengkap.

Microsoft menggunakan produk yang disebut 'Watson' (pesan umpan balik kirim yang Anda dapatkan ketika windows meledak) untuk melacak masalah langsung kembali ke klien. Keterlacakan adalah cara yang baik untuk melacak masalah kembali ke pengguna yang mengalaminya. Anda bisa mendapatkan keterlacakan dengan bertanya. Atau, jika Anda memiliki sumber daya, integrasikan fungsionalitas ke dalam produk. Kuncinya adalah melacak masalah / peningkatan sehingga bisa diatasi.

Akhirnya, yakin klien bisa berubah-ubah. Dalam kasus seperti itu, saya mencoba untuk fokus pada rahasia gunung es .

Mengubah persyaratan adalah fakta kehidupan yang sulit; tetapi kode busuk tidak disebabkan oleh hal itu.

Pembusukan kode terjadi ketika ada beberapa bagian dari kode Anda yang jarang Anda gunakan; jadi ketika Anda melakukan beberapa perubahan yang "seharusnya tidak mempengaruhi hal lain", Anda mungkin memperkenalkan bug. Dengan kata lain, kode yang tidak melihat siang hari perlahan terurai dan Anda tidak bisa mengatakan kapan itu berhenti bekerja.

Ya, itu salah Anda dan bukan pengguna Anda.

Solusi nyata? sering-seringlah menguji semua kode Anda. Tentu saja, cara terbaik adalah memiliki tes otomatis dengan jangkauan yang baik.

Keragu-raguan klien bisa menjadi masalah besar dan jika Anda bukan orang yang bertanggung jawab mengelola hubungan klien daripada itu mungkin sangat sulit untuk ditangani. Anda dapat berbicara dengan orang yang berurusan dengan klien dan menjelaskan dengan tenang bahwa kemajuan tidak dapat terjadi sampai klien membuat keputusan. Jika Anda adalah yang bertanggung jawab atas hubungan klien, Anda harus memberitahu klien bahwa mereka perlu untuk membuat keputusan sebelum proyek dapat melanjutkan. Mungkin bukan karena sikap Anda perlu perbaikan, hanya meditasi sebentar untuk menenangkan diri. ;)

Javier menunjukkan bahwa perubahan persyaratan adalah fakta kehidupan yang sulit. Saya juga frustrasi dengan situasi ini karena terlalu sering saya menemukan diri saya mengerjakan suatu produk di mana pengembang harus membuat keputusan. Pendapat saya dulu adalah "Mengapa manajemen tidak dapat mengetahuinya dengan klien?", Atau "Mengapa kita memulai proyek ini jika klien tidak tahu apa yang mereka inginkan?", "Banyak sakit kepala ketika mereka berubah jadi keterlambatan pengembangan ".

Fakta sederhana: ini akan selalu terjadi, tidak hanya dalam pemrograman / pengembangan perangkat lunak tetapi di setiap lapisan masyarakat. Dunia hanya akan menjadi tempat yang sangat membosankan dan sangat berbeda jika orang tidak pernah berubah pikiran, tidak pernah beradaptasi, tidak pernah menangani perubahan. Orang-orang memiliki kecenderungan untuk melihat apa yang mereka berikan, dan memperbaikinya. Apakah Anda tidak melakukan hal yang sama dengan kode Anda? Jika saya memiliki blok kode yang tidak saya sukai (tidak efisien, berantakan), saya akan memperbaikinya. (Apakah sistem operasi mengeluh pada saya? ... kadang-kadang, jika saya menggunakan OS tanpa nama tertentu, tetapi umumnya tidak)

Sebagai programmer kita perlu mengambil peluang untuk memperbaiki keadaan, dan tidak merasa tertekan atau terganggu olehnya. Manfaatkan kesempatan ini untuk berbicara dengan orang lain, tingkatkan gaya Anda, tingkatkan etos kerja Anda, dekati hal-hal dengan pikiran terbuka, dorong diri Anda untuk menjadi lebih baik dari kemarin. Maju terus dalam karir Anda dan jangan cepat puas.

Saya mengerti bahwa tidak semua orang akan setuju dengan jawaban ini, tetapi saya pikir sangat penting bahwa jawaban untuk pertanyaan ini mencakup perspektif yang lebih luas.

Saat Anda berinteraksi dengan klien, Anda tidak sedang pemrograman; Anda sedang belajar dan mengajar.

Jaga agar klien mendapat informasi dan mendidik mereka tentang proses tersebut. Perubahan akan terjadi. Biarkan mereka tahu Anda akan mencoba menerapkannya, tetapi akan lebih mahal. Biarkan mereka yang memutuskan.

Jangan masuk ke detail teknis bahkan ketika pertanyaan yang mereka ajukan bersifat teknis. Anda tergoda karena Anda akan merasa sedikit defensif dan ingin mengambil tantangan / mendapatkan geek-on Anda. Jangan lakukan itu; mereka tidak peduli dengan detailnya dan akan berhenti mendengarkan setelah 45 detik.

Jika Anda tidak memberi tahu mereka sebelumnya, jangan berharap mereka tahu tentang standar industri dan praktik terbaik atau alasan lain untuk melakukan apa yang Anda lakukan. Saya benci ketika saya tidak melihat bayaran sampai pada akhirnya hanya untuk memiliki tenaga penjual mengatakan kepada saya itu standar dalam industri. Seharusnya aku tidak diharapkan mengetahuinya. Tanggapan saya adalah, "Apakah membuat saya merasa seperti orang bodoh juga standar?"

Saat Anda bersama klien, lebih memperhatikan mereka daripada siapa pun atau apa pun di ruangan itu. Anjing yang didomestikasi jenius dalam hal ini; terutama jika Anda memiliki makanan.

Ini manajemen persyaratan yang buruk atau analisis yang buruk. Analis bisnis Anda (jika Anda memilikinya) atau siapa pun yang mendapatkan persyaratan harus duduk dengan klien dan mencoba untuk mendapatkan semua persyaratan, bahkan yang tidak terpikirkan oleh klien. Klien biasanya tidak tahu semua yang mereka inginkan, seorang analis bisnis yang hebat akan membantu mereka mencari tahu semuanya.

Ini sebabnya Anda harus selalu mendapatkan pengaturan Dokumen Persyaratan Bisnis dan keluar sebelum aplikasi apa pun melampaui tahap prototyping / riset.

Sekarang, gagasan bahwa dokumen ini sebenarnya final sudah keliru, tetapi ini akan membantu Anda mendapatkan ide yang lebih baik tentang apa yang sebenarnya diinginkan pelanggan. Dan selama Anda menulis kode Anda dengan rawatan, Anda dapat menjaga masalah Anda seminimal mungkin.

Dan jika Anda membutuhkan alasan untuk kembali, Anda dapat menyalahkan keterlambatan pada BRD, bahwa klien menandatangani, tidak termasuk fitur ini dan itu, dll.

(Tentu saja, ini hanya alasan jika Anda membutuhkannya. Anda harus selalu merencanakan mereka mengubah sesuatu )

Dalam kutipan Emerson, "Konsistensi bodoh adalah hobgoblin pikiran kecil ..." kata yang paling sering diabaikan adalah bodoh . Konsistensi tidak dapat dinegosiasikan dalam pengaturan tertentu, tetapi itu semua sering menggantikan pemikiran kritis dan analisis.

Di satu sisi, banyak model pengembangan dirancang khusus untuk membantu dalam lingkungan yang Anda gambarkan; jadi jika Anda mendapati diri Anda harus melanggar model Anda, berarti Anda tidak mengimplementasikannya sejak awal, atau Anda mendapatkan model yang salah.

Tetapi di sisi lain, jika Anda memiliki alasan yang masuk akal dan dapat didukung untuk melanggar aturan Anda, dan Anda dapat menunjukkan bahwa metode jahat Anda menghasilkan kode yang lebih bersih dan lebih dapat dipertahankan, maka Anda tidak perlu takut mengambil rute yang masuk akal.