Bagaimana Anda membuat kode tanpa menyinggung?

Yang saya maksudkan adalah, bagaimana Anda bisa mengembangkan basis kode yang Anda bagikan dengan pengembang yang telah bekerja selama bertahun-tahun dan sangat akrab dengannya?

Saya tidak ingin menginjak kaki siapa pun, tetapi saya tidak mendapatkan keluhan yang begitu halus tentang cara saya melakukan sesuatu, apakah itu bagaimana saya spasi kode saya, atau seberapa sering saya checkin ke SVN (terlalu sering). Jadi, sementara saya bisa mengubah hal-hal itu dengan mudah - saya ingin menjadi pengembang tim yang lebih baik secara umum.

Saya tidak yakin apa yang harus dilakukan, selain bertanya, tetapi mungkin kalian punya beberapa pemikiran yang bisa saya praktikkan.

MEMPERBARUI

Tidak ada panduan gaya untuk dibicarakan - hanya saja orang tidak terbiasa berbagi basis kode. Setiap orang memiliki dunia kode kecil yang dibungkam.

Ini adalah toko perl, tapi saya yakin ini berlaku untuk bahasa apa pun

PEMBARUAN 2

CTO yang kemudian menjadi CEO adalah megalomaniak yang lengkap dan merupakan sumber utama keluhan ini. Jika Anda tidak melakukan hal-hal yang ia sukai, apakah itu menggunakan Mac, atau Emacs, atau 4 spasi tab bukan 2, atau berpakaian dengan cara tertentu, Anda lebih rendah. Itu adalah situasi yang mengerikan yang saya coba koreksi, tetapi satu-satunya jawaban yang tepat bagi saya adalah pergi.

Saya yakin bahwa ini adalah contoh dari intimidasi di tempat kerja, dan kemudian, saya lebih sadar akan apa yang mungkin merupakan intimidasi halus dan perilaku yang tidak pantas di lingkungan kerja.

Kepada pengembang yang mencari jawaban untuk situasi seperti ini, segera pergi. Anda tidak dapat bekerja sama keluar dari situasi tim yang buruk.

Meminta. Yaitu, tanyakan orang-orang yang bekerja dengan Anda. Lakukan yang terbaik untuk tetap berpegang pada gaya kode yang sudah ada. Tanyakan terutama jika ada daftar dokumen standar pengkodean, dan ikuti. Jika tidak ada, tulis konsep pertama berdasarkan apa yang Anda amati dalam kode dan kemudian minta anggota tim lain untuk mengkritiknya. Anda akan melakukan layanan perusahaan (dan pengembang baru yang datang setelah Anda) dengan mulai mendokumentasikan praktik pengkodean yang diterima. Satu-satunya risiko adalah terjebak di tengah-tengah jika ternyata orang-orang tua tidak sepakat satu sama lain tentang apa yang bisa atau tidak bisa diterima.

Juga, jangan takut untuk menjadi diri sendiri . Anda mungkin orang baru, tetapi Anda adalah anggota tim, dan pendapat Anda valid. Jika Anda bisa memikirkan cara yang lebih baik untuk melakukan sesuatu, sarankan itu. Hormati anggota tim lainnya dan cara mapan dalam melakukan sesuatu, tetapi jangan biarkan mereka mendorong Anda. Perusahaan tidak akan mempekerjakan Anda jika tidak menghargai input Anda.

Ini akan banyak membantu jika Anda dapat menemukan seseorang di tim yang tampak ramah dan terutama bersedia menjawab pertanyaan. (Jika itu tim yang bagus, itu harus semua orang, tetapi tim tidak selalu seperti itu.) Atasan Anda mungkin telah menugaskan seseorang untuk membantu Anda memulai. Gunakan orang itu sebagai sumber daya. Tuliskan pertanyaan-pertanyaan ketika itu terjadi pada Anda, dan kemudian minta orang yang membantu itu untuk menjawabnya dari waktu ke waktu.

Sedangkan untuk memeriksa kode "terlalu sering," mengapa tidak membuat cabang Anda sendiri untuk melakukan periodik Anda, dan kemudian bergabung kembali ke bagasi ketika kode Anda siap? Tidak ada salahnya bagi orang lain dalam melakukan itu, dan ketika rekan kerja Anda melihat Anda mendapatkan manfaat dari SVN yang mereka inginkan, mereka mungkin mengikuti petunjuk Anda.

Mengenai spasi putih: Lakukan saja namun kode sudah melakukannya. Ikuti arus.

Mengenai checkin SVN: Dokumentasikan dengan sangat jelas. Itu membantu orang memahami apa yang terjadi dalam kode. (Tindak lanjut: Apa keberatan mereka terhadap checkin yang sering terjadi?)

Secara umum: Mulai membangun dokumen standar pengkodean. Jangan coba mengisinya dengan 100 aturan. Cukup tambahkan aturan saat mereka muncul.

Juga: Ajukan pertanyaan dari sesama pengembang Anda. Itu memberi mereka kesempatan untuk menimbang sebelum Anda melakukan sesuatu yang tidak mereka sukai. Plus, itu membangun hubungan. Plus, Anda belajar lebih banyak tentang cara kerja toko.

Sejauh gaya pemformatan kode (spasi, tab, ke mana kawat gigi pergi, dll.) Anda harus mengikuti standar yang berlaku dalam kode. Jika tidak ada, saya pikir mereka tidak perlu banyak mengeluh. Ketika sampai pada itu, apakah Anda meletakkan kawat pada baris mereka sendiri atau tidak, menempatkan spasi di sekitar daftar parameter metode, dll. Adalah preferensi pribadi, dan Anda harus menghasilkan gaya yang berlaku karena dalam jangka panjang, itu benar-benar tidak masalah . Yang penting adalah konsisten.

Ketika datang untuk memeriksa kode ke SVN, saya akan mencoba menginjili apa yang saya rasa adalah cara yang tepat untuk melakukan sesuatu, daripada membiarkan diri saya dikontrol. Saya tidak memeriksa kode saya kecuali itu membangun dan lulus tes, dan jika saya membuat beberapa perubahan yang tidak terkait, saya memecah pekerjaan saya menjadi beberapa komitmen. Jika sesuatu akan rusak sebentar, saya membuat cabang dan melakukan pekerjaan saya di sana. Komit mendapatkan komentar deskriptif. Ini bekerja lebih baik dalam pengalaman saya daripada metode "memeriksa setumpuk perubahan pada hari Jumat pukul 5:00", dan tampaknya itulah "praktik terbaik" yang berlaku menurut sebagian besar dari apa yang saya baca di sini dan di tempat lain.

Pertama baca dokumen konvensi pengkodean mereka (jika mereka tidak memilikinya maka minta mereka untuk menulisnya sehingga Anda dapat mengikutinya)

Kemudian perhatikan dan lakukan upaya sadar untuk mengikuti itu dan apa yang mereka katakan. Tampaknya bagi Anda bahwa mereka bersikap keras tetapi standar pengkodean itu penting, lebih baik untuk menunjukkan sekarang apa yang salah daripada membiarkannya berkembang menjadi masalah nanti ketika Anda membuat perubahan yang lebih besar.

Saya yakin Anda akan melakukan hal yang sama dalam waktu satu atau dua tahun ketika beberapa pemula menginjak kaki Anda :)

Minta standar kode perusahaan. Lebih memperhatikan detail. Jika Anda melihat orang lain mengikuti bentuk khusus ruang putih dan pola penjepit, maka ikutilah. Sebagai seorang Sr. Anda bisa berpendapat bahwa ini adalah rewel, tetapi sebagai Jr atau pria baru dalam sebuah proyek, Anda perlu menunjukkan bahwa Anda dapat mengikuti sebelum Anda bisa memimpin.

Juga, memahami bahwa setiap pengembang baru pada sebuah proyek memang akan memiliki yang diperlukan "jalan atas" waktu. Jadi jangan khawatirkan diri Anda sendiri tentang itu.

Hal terbaik yang dapat Anda lakukan adalah mengikuti saran yang mereka berikan kepada Anda. Tidak ada cara untuk mengatakan sebelumnya apa yang mereka inginkan. Kecuali jika Anda paranormal.

Namun, saya akan menyarankan bahwa ketika orang memberi Anda saran, Anda mendokumentasikannya. Apakah Anda punya wiki? Jika demikian, gunakan itu. Jika tidak, file teks yang dicek dengan kode sumber mungkin merupakan ide yang bagus. Buat panduan pemrograman yang terorganisir dengan baik. Ini akan membantu Anda mengingat bagaimana melakukan sesuatu, dan jika seseorang bertentangan dengan saran Anda sebelumnya, itu memberi Anda titik referensi untuk membahas ketidakkonsistenan. Plus, ketika orang berikutnya bergabung dengan tim, mereka tidak harus melalui apa yang Anda alami.

Saya sarankan Anda tidak mengaitkan saran dalam dokumen dengan individu (jadi "blok kode harus diindentasi oleh tiga spasi", bukan "Bill mengatakan kepada saya bahwa blok kode harus diindentasi oleh tiga spasi"). Namun, jika Anda dapat merekam informasi itu dengan cara yang tidak mengganggu (misalnya dalam komentar komit, tulis "aturan tambahan tentang lekukan berdasarkan saran Bill"), maka mungkin akan membantu dalam menyelesaikan kontradiksi, karena Anda dapat langsung mendapatkan dua sudut pandang pada sesuatu. Apa yang saya pikirkan di sini, sebenarnya, adalah bahwa jika Anda diberi saran yang bertentangan, Anda perlu menghindari menjadi sepak bola ditendang oleh dua rekan yang tidak setuju pada sesuatu. Ini sedikit pendekatan yang tersembunyi, tetapi mungkin lebih bijaksana.

Yang mudah adalah menemukan panduan gaya dan mengikutinya. Sebagian besar tidak memiliki sesuatu yang terlalu menyinggung mereka, dan akan mencegah Anda menyinggung orang lain.