Standar untuk cara pengembang bekerja di workstation mereka sendiri

Kami baru saja menemukan salah satu situasi yang kadang-kadang muncul ketika pengembang sakit selama beberapa hari di tengah proyek.

Ada beberapa pertanyaan tentang apakah dia melakukan versi terbaru dari kodenya atau apakah ada sesuatu yang lebih baru pada mesin lokalnya yang harus kita lihat, dan kami memiliki pengiriman ke pelanggan yang tertunda sehingga kami tidak bisa menunggu dia untuk kembali.

Salah satu pengembang lain masuk saat dia melihat dan menemukan kekacauan ruang kerja, banyak yang tampaknya dari proyek yang sama, dengan cap waktu yang membuatnya tidak jelas mana yang "saat ini" (dia membuat prototipe beberapa bit pada versi proyek selain "inti" nya).

Jelas ini menyebalkan, namun alternatif (yang tampaknya menjadi standar ketat untuk bagaimana setiap pengembang bekerja pada mesin mereka sendiri untuk memastikan bahwa pengembang lain dapat mengambil hal-hal dengan upaya minimal) cenderung memecah banyak arus pekerjaan pribadi pengembang dan mengarah ke inefisiensi pada tingkat individu.

Saya tidak berbicara tentang standar untuk kode check-in, atau bahkan standar pengembangan umum, saya berbicara tentang bagaimana seorang pengembang bekerja secara lokal, suatu domain yang secara umum dianggap (menurut pengalaman saya) hampir seluruhnya berada di bawah kendali pengembang sendiri.

Jadi bagaimana Anda menangani situasi seperti ini? Apakah salah satu dari hal-hal itu hanya terjadi dan Anda harus berurusan dengan, harga yang Anda bayar untuk pengembang diizinkan untuk bekerja dengan cara yang paling sesuai dengan mereka?

Atau apakah Anda meminta pengembang untuk mematuhi standar di bidang ini - penggunaan direktori spesifik, standar penamaan, catatan pada wiki atau apa pun? Dan jika demikian apa yang dicakup oleh standar Anda, seberapa ketat mereka, bagaimana Anda mengawasi mereka dan seterusnya?

Atau ada solusi lain yang saya lewatkan?

[Asumsikan demi argumen bahwa pengembang tidak dapat dihubungi untuk membicarakan apa yang ia lakukan di sini - bahkan jika ia dapat mengetahui dan menggambarkan ruang kerja mana yang dari memori tidak akan menjadi sederhana dan tanpa cacat dan kadang-kadang orang benar-benar dapat dapat dihubungi dan saya ingin solusi yang mencakup semua kemungkinan.]

Sunting: Saya mengerti bahwa melalui workstation seseorang adalah bentuk yang buruk (meskipun ini merupakan pertanyaan yang menarik - dan mungkin di luar topik - tepatnya mengapa itu terjadi) dan saya tentu saja tidak melihat akses tanpa batas. Pikirkan lebih lanjut di sepanjang garis standar di mana direktori kode mereka diatur dengan hanya-baca - tidak ada yang bisa diubah, tidak ada yang bisa dilihat dan sebagainya.

" Jika tidak ada dalam kontrol sumber, itu tidak ada. "

Ini adalah salah satu dari sedikit hal dalam profesi kami yang saya anggap dogmatis. Karena alasan berikut:

1. Meskipun workstation adalah properti perusahaan, mari kita hadapi itu - ada sedikit aturan tidak tertulis bahwa workstation programmer sendiri adalah kastilnya. Saya hanya tidak nyaman dengan budaya tempat kerja di mana setiap orang dapat secara rutin masuk ke dalamnya dan menjalaninya.
2. Setiap orang memiliki alirannya sendiri (seperti yang Anda katakan juga). Mencoba memaksa semua pengembang untuk mengatur ruang kerja lokal mereka sendiri dengan cara tertentu mungkin bertentangan dengan cara kerja khusus mereka, dan memutus aliran mereka dan membuat mereka kurang efisien.
3. Hal-hal yang tidak ada dalam kontrol sumber adalah kode yang setengah terpanggang. Jika sepenuhnya dipanggang kode yang siap untuk rilis, itu harus di kontrol sumber. Yang kembali lagi ke titik utama ....
4. "Jika tidak ada dalam kontrol sumber, itu tidak ada."

Salah satu cara yang mungkin untuk mengurangi masalah ingin melihat kode pada workstation orang adalah untuk menumbuhkan budaya checkin biasa. Saya pernah bekerja di sebuah perusahaan di mana - meskipun tidak ada mandat resmi untuk melakukannya - terlihat semacam kebanggaan untuk selalu memeriksa semuanya untuk akhir pekan. Dalam fase pemeliharaan dan pelepasan kandidat, item CR sengaja dibuat dengan sangat halus untuk memungkinkan perubahan kecil yang terlihat jelas, dan checkin reguler untuk melacaknya.

Juga, memeriksa semuanya sebelum Anda pergi berlibur adalah wajib .

TL; versi DR : Mengobrak-abrik stasiun kerja orang adalah bentuk yang buruk. Daripada mencoba menumbuhkan budaya membuatnya mudah untuk pergi melalui workstation orang untuk menemukan apa yang kita inginkan, lebih baik berlatih untuk menumbuhkan budaya penggunaan kontrol sumber yang masuk akal dan checkin biasa. Mungkin bahkan checkin hyper-reguler, dan tugas-tugas halus ketika dalam fase kritis proyek.

Daripada menegakkan standar untuk bagaimana pengembang Anda mengatur stasiun kerja mereka, menegakkan standar di mana semua pekerjaan diperiksa pada akhir setiap hari . Check-in dapat dilakukan ke cabang jika masih belum lengkap.

Dengan cara ini, tidak seorang pun perlu mengakses workstation pengembang lain.

Saya akan membayangkan bahwa kebijakan ini akan bertemu dengan beberapa oposisi, tetapi tidak ada apa-apanya dibandingkan dengan apa yang saya harapkan jika Anda menegakkan aturan tentang organisasi workstation seseorang.

Saya akan mengatakan yang sebenarnya, saya merasa tidak nyaman dengan gagasan bahwa seseorang akan masuk ke mesin saya dan menelusuri barang-barang saya. Memang, itu adalah peralatan dan properti perusahaan, tetapi itu adalah hal yang buruk untuk dilakukan.

Terakhir kali saya pergi untuk akhir pekan, orang-orang mengkonfigurasi ulang server dengan database dan kontrol sumber dan untuk beberapa alasan merasa perlu untuk masuk ke mesin saya dan mengkonfigurasi ulang sistem untuk pengaturan baru.

Sayang sekali mereka tidak tahu apa yang mereka lakukan dan mereka menghapus prototipe yang telah saya kerjakan selama dua bulan terakhir.

Itu tidak akan terjadi jika komunikasi yang tepat telah dilakukan. Itu yang Anda butuhkan juga. Dapatkan ke pengembang itu dan cari tahu keadaannya. Bahkan lebih baik, mintalah laporan kepada orang-orang sebelum mereka pergi cuti sehingga Anda mengambil keputusan berdasarkan informasi apakah Anda membutuhkan sesuatu dari mereka atau tidak.

Tapi jangan main-main dengan workstation orang.

PS Kami memang memiliki konvensi untuk struktur direktori tetapi alasan keberadaan utamanya adalah campuran dari sejarah / konfigurasi - letakkan di tempat lain dan tidak akan dikompilasi.

Beberapa bulan yang lalu saya mengerjakan proyek yang agak besar dan harus meninggalkan pekerjaan secara tiba-tiba ketika saya tahu saya dirawat di rumah sakit. Saya tidak punya waktu untuk memeriksa kode terbaru saya untuk proyek tersebut.

Untungnya, ini adalah konvensi di sini (meskipun tidak "perlu") untuk menyimpan kode /var/www/ourdomain.comuntuk meniru produksi. Dengan konvensi yang logis dan mudah diikuti, mudah bagi rekan kerja untuk masuk ke mesin saya dan mengambil perubahan terbaru saya.

Saya pikir beberapa konvensi bagus. Meskipun saya setuju dengan Bobby ketika dia berkata

"Jika tidak ada dalam kontrol sumber, itu tidak ada."

Selain itu, tambahan yang berguna untuk ruang kerja programmer bisa menjadi drive SATA hot-swap front-bay tempat menyimpan semua proyek sumber dan pengembangan. Dengan cara ini, jika masalah seperti itu muncul, seorang karyawan dapat mengambil perubahan sumber baru untuk proyek dengan mudah tanpa perlu login ke workstation pengembang.

Bagian pertama dari pertanyaan Anda mengidentifikasi masalah komunikasi dalam tim Anda dengan jelas. Sudahkah Anda mencoba standup harian ?

Saya setuju dengan Anda ketika Anda mengatakan bahwa standar mungkin akan menyebabkan inefisiensi jika terlalu ketat. Standar harus ditentukan oleh tim , yang melibatkan semua orang.

Dalam kasus Anda, saya akan menunggu beberapa hari setelah pengembang yang bersangkutan kembali bekerja. Kemudian atur rapat untuk membicarakan standar-standar itu.

Untuk menghindari hambatan psikologis dan penolakan, jangan menyebutkan nama orang atau hal-hal tertentu yang Anda lihat. Tetap umum, tujuannya di sini adalah untuk mendapatkan masukan dari semua orang, termasuk pengembang yang menurut Anda harus meningkatkan cara kerjanya. Pria itu mungkin menganggap organisasi Anda juga berantakan.

Selama pertemuan hadir masalah dan tanyakan dengan jelas bagaimana tim dapat memperbaiki situasi.

The (seluruh) tim memutuskan apa yang harus dilakukan.

Pengguna itu mungkin menderita karena kurangnya alat yang tepat. Secara khusus, penggunaan sistem kontrol versi terdistribusi akan menghilangkan baginya kebutuhan untuk memiliki direktori kode yang berbeda di berbagai negara. Dia bisa menyimpan semua itu di cabang dan jauh lebih bahagia.

Namun, pada intinya, tidak, saya tidak ingin standar diterapkan pada saya tentang bagaimana saya mengatur stasiun kerja saya sendiri. Saya saat ini mendorong kembali tentang departemen saya standardisasi pada IDE (bos saya BENAR-BENAR ingin kita semua di Eclipse karena itu yang dia gunakan dan kenal baik, meskipun IMO itu bukan alat terbaik untuk pekerjaan saya ).

Biarkan pengembang melakukan apa pun yang membuat mereka nyaman. Pengembang yang nyaman lebih produktif daripada yang tidak nyaman. Dan jika seseorang TIDAK produktif, dan Anda curiga mereka meraba-raba secara lokal dengan alat-alat tersebut, ini adalah kesempatan untuk pelatihan, bukan Waktu yang Baik untuk Membuat Aturan Baru.

Di tempat kerja saya yang lama, kami memiliki sistem di mana setiap tugas dalam bugtracking kami memiliki cabang sendiri dalam kontrol sumber. Dipahami bahwa sebagian besar waktu, satu bug / tugas ditekan oleh satu pengembang sehingga kode yang rusak diizinkan untuk diperiksa ke dalam kontrol sumber.

Setelah kode berada dalam kondisi stabil di cabang pengembangan, rebase dilakukan dengan menyeret kode dari cabang yang akan Anda integrasikan. Setelah Anda menguji gabungan itu, itu hanya akan menjadi kasus melakukan kode ke cabang integrasi - itu tidak memerlukan penggabungan karena Anda sudah melakukan penggabungan pada cabang Anda.

Dengan cara ini, Anda menyimpan masalah pengembang yang khawatir tentang melakukan kode yang rusak - dan Anda dapat mulai menerapkan kebijakan sosial membuatnya super dapat diterima untuk memeriksa kode sebelum Anda meninggalkan kantor di malam hari - bagus dan aman.

Dalam hal ini situasi panggilan tertentu orang di rumah, membuatnya sangat jelas bahwa Anda tidak meragukan bahwa dia sakit tapi Anda harus memiliki orang lain melanjutkan pekerjaannya, dan bertanya di mana barang-barang terbaru adalah dan apa yang negara.

Maka Anda perlu mempertimbangkan apa yang harus dilakukan dari sini. Jika masalahnya adalah orang jarang melakukan check-in, pertimbangkan untuk menggunakan sistem kontrol sumber terdistribusi yang memungkinkan orang untuk bekerja di cabang tanpa mengganggu satu sama lain.

Jika masalahnya adalah Anda tidak suka pengembang memiliki banyak ruang kerja di mesin mereka, maka lupakan. Gaya kerja adalah individual dan pada dasarnya Anda harus menjauh dari sistem mereka selama mereka bekerja dengan baik dengan aturan untuk repositori sumber. Secara pribadi saya sering melihat salinan baru untuk proyek yang berbeda dan hanya membersihkan sesekali.

Jika masalahnya adalah Anda tidak tahu apa yang dilakukan pengembang Anda, masalahnya adalah politis bukan teknis, dan Anda perlu mengubah gaya manajemen Anda. Harap diingat bahwa pengembang adalah pribadi yang sangat terampil yang jarang menyukai manajemen mikro dan Anda harus mendelegasikannya. Kalau tidak, Anda akan mendorong individu yang paling terampil menjauh.

Jadi, saya akan merekomendasikan mendorong cara yang lebih baik untuk bekerja dengan repositori sumber umum - katakan itu baik-baik saja bagi orang untuk bekerja di cabang, dan biarkan mereka sering melakukan komitmen selama mereka menyinkronkan salinan lokal mereka ke repositori master setiap hari (karena mereka akan selalu melakukan pekerjaan pengembangan di cabang ini tidak akan mempengaruhi orang lain).

Jadi bagaimana Anda menangani situasi seperti ini?

Anda dapat mengatasi masalah ini dengan sistem kontrol sumber yang mendukung cabang pribadi yang tidak stabil dan dengan mempertahankan komitmen yang sering. Komit tidak harus datang ketika seluruh masalah terpecahkan. Itu harus datang setiap kali Anda mendapat manfaat dari kontrol sumber. Akhir hari adalah salah satu dari banyak poin ketika sebuah komit harus terjadi sehingga Anda dapat melihat di mana perubahan Anda dibuat, mendukungnya, dan menjelaskannya kepada diri Anda di masa depan atau orang lain.

Atau apakah Anda meminta pengembang untuk mematuhi standar di bidang ini - penggunaan direktori spesifik, standar penamaan, catatan pada wiki atau apa pun?

Kami memiliki dokumen konfigurasi lingkungan yang sangat besar yang menunjukkan konvensi, tetapi bukan standar. Standar untuk kode dan lingkungan produksi. Namun banyak dari alat pengembangan kami disiapkan untuk mendukung konvensi dan sebagian besar pengembang tidak mengeluarkan usaha dari tren.