Saya bekerja sebagai pengembang iOS di perusahaan outsourcing kecil dalam tim yang terdiri dari 4 orang. Kami mengerjakan proyek yang dimulai beberapa tahun sebelum saya dan dua pengembang lainnya bergabung dengan perusahaan. Sebelumnya, proyek itu kebanyakan dikerjakan oleh satu orang.

Ketika saya mulai bekerja di proyek itu berantakan. Ada banyak pengulangan kode. Saya melihat 500 kode yang sama diatasi untuk 20 file berbeda dengan variasi kecil. Selain itu, itu tidak terorganisir dengan baik: semua kode pembuatan UI dicampur dalam pengontrol tampilan bersama dengan logika.

Saya mencoba yang terbaik untuk memperbaiki hal-hal di sana-sini, menghilangkan potongan kode yang berlebihan, memperbaiki struktur file proyek dan sebagainya. Rasanya seperti pengembang sebelumnya tidak terlalu peduli tentang semua hal ini atau tidak memiliki pengalaman. Ada saat ketika saya bekerja sendiri pada fitur yang cukup besar selama beberapa bulan. Karena sifat dari fitur ini saya harus menyentuh banyak kode di seluruh aplikasi, jadi saya berusaha untuk melakukan beberapa perbaikan.

Ketika pengembang lain bergabung dengan proyek ini, saya perhatikan bahwa mereka menggunakan gaya pengkodean yang berbeda (kadang-kadang gaya yang sama sekali berbeda) dan sering tidak menggunakan fitur bahasa modern seperti pengakses properti (ini relatif baru di Objective-C). Kadang-kadang mereka akan menciptakan sepeda sendiri alih-alih menggunakan fitur serupa dari kerangka kerja, atau mentransfer konsep dari bahasa pemrograman lain atau patters yang mereka pelajari ke basis kode kami. Seringkali mereka tidak dapat menyebutkan metode atau variabel dengan benar karena bahasa Inggris yang buruk (Objective-C adalah bahasa tempat Anda membuat nama panjang).

Terkadang saya berpikir jika bukan karena IDE saya pikir mereka akan menulis semua kode tanpa lekukan atau format sama sekali.

Pada dasarnya, saya benci kode yang mereka tulis. Ini berformat buruk / terorganisir, dan kadang-kadang sangat berbeda dari sisa proyek. Saya merasa sangat sedih ketika mereka menambahkan spageti mereka ke karya seni saya dan itu mempengaruhi suasana hati saya di tempat kerja dan produktivitas saya.

Rasanya semakin mereka tidak dapat diganggu untuk belajar atau tidak peduli: mereka hanya melakukan apa yang diminta dari mereka dan pulang. Saya mencoba memberi mereka beberapa tips ketika saya memiliki kesempatan (misalnya berkomentar PR mereka atau melakukan pada GitHub). Saya pernah bertanya dengan baik untuk mengikuti gaya pengkodean dan pemformatan sebagian besar kode yang ada (sayangnya kami tidak memiliki dokumen gaya pengkodean formal). Tapi itu tidak berhasil ...

Bagaimana saya bisa mengatasi situasi ini tanpa hanya berfokus pada 'budaya perusahaan yang buruk', 'lulusan yang tidak berpengalaman', dll. Dan benar-benar mulai memperbaiki situasi.

Ajarkan dan Praktekkan apa yang Anda khotbahkan.

Anda tahu hal ini penting. Anda tahu sisi buruknya jika tidak dilakukan dengan benar.

Sekarang tantangannya adalah meyakinkan orang lain. Ini tidak akan dilakukan melalui satu percakapan, rapat, percakapan lorong, kiat atau dalam Permintaan Tarik.

Ini membutuhkan:

• Publik mengakui oleh manajemen bahwa barang-barang ini penting
• Linters agar orang dapat berkumpul, berbaur dan menyetujui gaya, lalu membiarkan komputer melakukan pemolisian
• Pimpin pengembang yang sepenuhnya setuju dan bersedia untuk mengajar orang lain
• Rapat, demo, makan siang dan belajar, dll untuk mengajarkan pendekatan ini
• Orang-orang diukur pada item kualitas yang Anda sebutkan selama ulasan mereka
• Standar yang terdokumentasi dan dipublikasikan
• Tarik Permintaan memiliki banyak pengulas
• Tarik Permintaan tidak digabung sampai kualitas kode tinggi
• Pasangan kode yang sering
• Ulasan kode grup untuk PR kompleks

Dalam kata itu membutuhkan

Kepemimpinan

Kabar baiknya adalah bahwa semua kegiatan ini secara umum diakui sebagai praktik yang baik sehingga ketika Anda pergi mempromosikannya atau mendapatkan dukungan dari manajemen, Anda harus memiliki peluang sukses yang baik dan harus dapat mempertahankan diri melakukan hal yang benar. Manajemen mungkin masih belum membeli, itu topik dan pertanyaan lain.

Saya telah menulis banyak tentang hal ini di SoftwareEngineering.SE di masa lalu, dan berada dalam situasi yang sama sendiri. Karena itu, saya akan berusaha memberikan beberapa petunjuk dan menyoroti beberapa masalah yang saya catat ketika membaca pertanyaan Anda.

Tetapi pertama-tama, mari kita bicara tentang aspek penting: peran Anda dalam perusahaan.

Peranmu

Anda mungkin memiliki mandat eksplisit dari bos Anda untuk meningkatkan hal-hal, dan juga tempat dalam hierarki di mana pengembang lain harus mendengarkan pesanan Anda . Atau Anda mungkin berada di antara teman sebaya, memiliki peran dan otoritas yang sama, pilihan Anda hanya ... well ... pendapat .

Dalam kedua kasus, yang penting adalah tempat Anda lebih sedikit dalam hierarki, dan lebih banyak lagi:

• Apa yang dipikirkan pengembang lain tentang Anda. Jika mereka memperlakukan Anda sebagai pria menyebalkan yang menanyakan hal-hal bodoh, Anda tidak akan jauh. Saya telah melihat banyak kasus di mana para pemimpin teknis dan manajer proyek sama sekali tidak berpengaruh pada tim, karena tim tahu (atau berpikir) bahwa "para pemimpin" itu tidak memiliki latar belakang teknis yang diperlukan untuk mengambil keputusan yang mereka ambil. Di sisi lain, saya telah melihat beberapa pengembang yang benar-benar didengarkan oleh rekan-rekan mereka, karena mereka tahu para pengembang itu terampil dan berpengalaman.

• Seberapa solid tim Anda dan apa yang memotivasi mereka. Bayangkan sebuah perusahaan di mana setiap pengembang dibayar untuk KLOC / bulan. Apakah ada yang Anda katakan tentang gaya menjadi masalah bagi kolega Anda? Mungkin tidak, karena jarang ada orang yang ingin dibayar lebih rendah. Secara umum, jika ini bukan tim tetapi hanya sekelompok orang yang mengerjakan proyek yang sama, Anda tidak akan dapat meningkatkan apa pun.

Bergantung pada itu, Anda dapat memutuskan apakah perlu upaya untuk melakukan perubahan apa pun. Jika Anda tidak memiliki suara dan tidak ada kohesi tim, cari saja pekerjaan lain. Jika Anda dikenal sebagai pengembang yang berbakat dan dihormati dan ada perasaan tim yang kuat, Anda akan dapat meningkatkan hal-hal yang relatif mudah, bahkan jika dihadapkan dengan permusuhan dari bos Anda atau tim lain.

Dalam semua kasus, sangat penting untuk tidak menekan tim Anda. Bekerja dengan mereka, bukan melawan mereka. Jangan memberi mereka perintah, tetapi arahkan mereka ke tujuan.

Sekarang, petunjuknya.

Gaya

Saya pernah bertanya dengan baik untuk mengikuti gaya pengkodean dan pemformatan sebagian besar kode yang ada (sayangnya kami tidak memiliki dokumen gaya pengkodean formal). Tapi itu tidak berhasil ...

Tentu saja tidak, karena ini bukan cara yang seharusnya dilakukan.

• Gaya itu membosankan .

• Mengikuti gaya itu membosankan .

• Menulis dokumen gaya pengkodean itu membosankan ( dan sangat sulit ; jangan coba-coba melakukannya kecuali Anda telah bekerja dengan bahasa tersebut selama lebih dari sepuluh tahun).

• Membaca dokumen gaya itu membosankan .

• Meninjau kode untuk kesalahan gaya membosankan .

• Mengetahui bahwa gaya saya lebih baik daripada gaya Anda itu mengasyikkan , terutama ketika sama sekali tidak ada manfaat obyektif dari satu gaya di atas yang lain. Serius, setiap orang waras tahu bahwa cara menulis yang benar if (x)adalah cara saya menulisnya, bukan if(x)atau if ( x )!

Karena itu:

• Jangan lakukan tinjauan gaya. Ini adalah tugas pemeriksa gaya. Aplikasi lucu itu memiliki beberapa manfaat di otak Anda: mereka memeriksa seluruh proyek dalam hitungan milidetik, bukan berjam-jam atau berhari-hari, dan mereka tidak melakukan kesalahan dan tidak ketinggalan kesalahan gaya.

• Jangan menulis standar gaya Anda sendiri. Anda tetap akan melakukan kesalahan, dan rekan kerja Anda akan membohongi Anda bahwa Anda membuat pilihan yang salah.

• Jangan paksa pengembang untuk memperbaiki 2.000 kesalahan gaya.

• Lakukan gaya secara otomatis saat melakukan. Kode yang memiliki kesalahan gaya tidak memiliki tempat dalam kontrol versi.

• Lakukan sejak awal proyek. Menyiapkan kontrol gaya dalam proyek yang ada sulit untuk mustahil.

Untuk lebih lanjut tentang itu, membaca bagian pertama dari jawaban lain ini pada SE.SE .

Juga:

• Jangan terlalu ketat. Misalnya, menulis jslintkode-patuh cukup mengganggu, sehingga harus dilakukan secara eksklusif ketika benar-benar diperlukan (atau jika semua anggota tim Anda senang menggunakannya). Hal yang sama berlaku untuk alat pemeriksaan statis; misalnya, Analisis Kode .NET pada tingkat maksimum bisa sangat menindas dan menekan, sementara membawa sedikit manfaat; alat yang sama pada tingkat moderat, di sisi lain, terbukti sangat membantu.

Ulasan kode

Sekarang karena Anda tidak perlu repot tentang gaya selama ulasan kode, Anda dapat fokus pada hal-hal yang lebih menarik: meningkatkan (vs memperbaiki) kode sumber.

Orang yang berbeda bereaksi secara berbeda terhadap ulasan kode. Beberapa menganggapnya sebagai peluang. Yang lain membencinya. Beberapa mendengarkan semua yang Anda katakan kepada mereka, membuat catatan, dan tidak berdiskusi, bahkan jika itu benar. Yang lain mencoba berdebat tentang setiap hal. Terserah Anda untuk menemukan cara untuk berurusan dengan setiap pengembang sesuai dengan kepribadiannya. Biasanya bermanfaat untuk:

• Lakukan review kode secara pribadi, terutama ketika pengembang masih junior dan menulis kode yang benar-benar buruk.

• Tunjukkan bahwa tidak ada yang pribadi: Anda meninjau kode, bukan keterampilan orang tersebut.

• Tunjukkan sasaran sebenarnya dari tinjauan kode. Tujuannya bukan untuk menunjukkan seberapa buruk pengembangnya. Tujuannya adalah untuk memberikan peluang perbaikan.

• Tidak pernah berdebat. Anda di sini bukan untuk meyakinkan, tetapi untuk memberikan keahlian Anda.

• Jangan pernah menganggap penerima ulasan adalah satu-satunya yang dapat belajar sesuatu dari ulasan. Anda di sini untuk belajar juga, baik dengan membaca kode dan dengan menanyakan penjelasan tentang bagian-bagian yang tidak Anda mengerti.

Setelah peninjauan kode selesai, pastikan orang tersebut benar-benar meningkatkan kode-nya. Saya punya beberapa kasus di mana pengembang berpikir bahwa tinjauan kode berakhir ketika rapat yang sebenarnya berakhir. Mereka pergi dan kembali ke fitur baru mereka, mencoba menerapkan apa yang Anda bagikan dengan mereka hanya untuk kode baru. Memiliki alat pelacakan yang layak untuk peninjauan kode akan membantu.

Perhatikan bahwa terlepas dari peran khusus Anda di perusahaan dan keahlian Anda dibandingkan dengan orang lain, kode Anda juga harus ditinjau. Anda juga tidak boleh menjadi satu-satunya yang meninjau kode orang lain.

Dalam sebuah proyek baru-baru ini di mana saya bekerja sebagai pemimpin teknis, saya mengalami kesulitan menjelaskan kepada rekan kerja saya bahwa itu adalah peran mereka untuk melakukan tinjauan kode masing-masing, termasuk milik saya. Ketakutan magang yang akan meninjau kode pemimpin teknisnya menghilang begitu ia menemukan masalah pertama dalam kode — dan siapa di antara kita yang menulis kode tanpa cacat?

Latihan

Ulasan kode adalah peluang besar untuk mengajar dan mempelajari beberapa aspek pemrograman dan desain perangkat lunak, tetapi yang lain membutuhkan pelatihan.

Jika Anda bisa melatih rekan kerja Anda, lakukan itu. Jika manajemen Anda memusuhi ide pelatihan, lakukan secara informal. Saya telah melakukan sesi pelatihan seperti itu dalam bentuk pertemuan informal, atau kadang-kadang bahkan sebagai diskusi sederhana, kadang-kadang terganggu oleh manajemen dan dilanjutkan kemudian.

Selain pelatihan langsung, pastikan Anda cukup tahu buku-buku seperti Kode Lengkap McConnel , dan berbicara tentang buku-buku itu kepada rekan kerja Anda. Sarankan mereka untuk membaca kode sumber proyek sumber terbuka, berikan mereka contoh spesifik kode berkualitas tinggi. Dan, tentu saja, tulis kode berkualitas tinggi sendiri.

Fokus pada konteks, bukan pada orang

Bagaimana saya bisa mengatasi situasi ini tanpa hanya berfokus pada 'budaya perusahaan yang buruk', 'lulusan yang tidak berpengalaman', dll.

Para lulusan tersebut memiliki tujuan: memperoleh pengalaman, mempelajari berbagai hal, menjadi lebih terampil. Jika, tahun demi tahun, mereka menulis kode jelek dan tidak tahu apa-apa tentang pemrograman, itu mungkin karena tim Anda atau perusahaan Anda tidak memberi mereka kesempatan ini.

Jika Anda berfokus pada fakta bahwa tim Anda memiliki lulusan yang tidak berpengalaman, ini tidak akan membantu. Sebaliknya, fokuslah pada apa yang dapat Anda lakukan untuk mereka dan dengan mereka. Ulasan kode dan pelatihan adalah dua teknik untuk memperbaiki situasi.

Budaya perusahaan yang buruk adalah binatang yang berbeda. Terkadang, itu bisa diubah. Terkadang tidak bisa. Dalam semua kasus, ingatlah bahwa Anda adalah bagian dari perusahaan ini, jadi Anda adalah bagian dari budaya perusahaan. Jika Anda tidak dapat mengubahnya dan menemukannya secara inheren buruk, cepat atau lambat, Anda harus pergi.

Dapatkan metrik Anda dengan benar

Bagaimana tepatnya Anda mengukur kode sekarang? Apakah Anda mengukur jumlah komit per hari per pengembang? Atau KLOC per bulan per programmer? Atau mungkin cakupan kode? Atau jumlah bug yang ditemukan dan diperbaiki? Atau jumlah bug potensial yang tertangkap oleh uji regresi? Atau jumlah pengembalian yang dilakukan oleh server Penerapan Berkelanjutan?

Hal-hal yang Anda ukur penting, karena anggota tim menyesuaikan pekerjaan mereka dengan faktor-faktor yang diukur. Misalnya, di satu perusahaan di mana saya harus bekerja beberapa tahun yang lalu, satu-satunya hal yang diukur adalah waktu yang dihabiskan di kantor. Tidak perlu dikatakan bahwa ini tidak mendorong untuk memberikan kode yang lebih baik, atau bekerja lebih pintar, atau ... yah, untuk bekerja sama sekali.

Mencari penguatan positif dan negatif dan menyesuaikan faktor-faktor yang diukur dari waktu ke waktu pada dasarnya adalah pengaruh yang Anda miliki pada anggota tim. Ketika dilakukan dengan benar, itu memungkinkan untuk mencapai hasil yang tidak akan dicapai oleh hierarki sederhana.

Hal-hal yang mengganggu Anda, membuatnya terukur. Ukur mereka, dan buat hasilnya publik. Kemudian bekerja sama dengan anggota tim lainnya untuk meningkatkan hasil.

Sebagai contoh, mari kita pertimbangkan bahwa anggota tim membuat terlalu banyak kesalahan ejaan dalam nama kelas, anggota kelas, dan variabel. Ini menyebalkan. Bagaimana Anda bisa mengukurnya? Dengan parser, Anda dapat mengekstrak semua kata dari kode, dan menggunakan pemeriksa ejaan, menentukan rasio kata yang mengandung kesalahan dan kesalahan ketik, katakanlah 16,7%.

Langkah Anda selanjutnya adalah menyetujui dengan tim Anda tentang rasio target. Bisa 15% untuk sprint berikutnya, 10% untuk sprint berikutnya, 5% dalam enam minggu, dan 0% dalam dua bulan. Metrik tersebut dihitung ulang secara otomatis di setiap komit, dan ditampilkan di layar lebar di kantor.

• Jika Anda tidak mencapai rasio target, tim Anda mungkin memutuskan untuk menghabiskan lebih banyak waktu memperbaiki kesalahan ejaan. Atau tim Anda mungkin menganggap lebih baik untuk menghitung rasio per pengembang, dan menampilkan informasi ini di layar lebar juga. Atau tim Anda mungkin menemukan bahwa tujuannya terlalu optimis, dan Anda harus memeriksanya.

• Jika Anda mencapai rasio target, langkah selanjutnya adalah memastikan jumlah kesalahan dan kesalahan ketik tidak bertambah seiring waktu. Untuk itu, Anda bisa membuat tugas tambahan di build Anda yang memeriksa kesalahan pengejaan, dan gagal build jika setidaknya satu kesalahan ditemukan. Sekarang setelah Anda menyingkirkan masalah ini, layar besar Anda dapat digunakan kembali untuk menunjukkan statistik baru yang relevan.

Kesimpulan

Saya percaya bahwa setiap aspek yang disebutkan dalam pertanyaan Anda dapat diselesaikan melalui teknik yang saya sertakan dalam jawaban saya:

• Ketika pengembang lain bergabung dengan proyek ini, saya perhatikan bahwa mereka menggunakan gaya pengkodean yang berbeda (kadang-kadang gaya yang sama sekali berbeda)

  Anda harus menerapkan gaya secara otomatis saat melakukan.

• dan sering tidak menggunakan fitur bahasa modern seperti pengakses properti (ini relatif baru di Objective-C).

  Kedua tinjauan kode dan pelatihan di sini untuk mentransfer pengetahuan Anda tentang bahasa.

• Kadang-kadang mereka akan menciptakan sepeda sendiri alih-alih menggunakan fitur kerangka yang serupa

  Kedua ulasan kode dan pelatihan ada di sini untuk mentransfer pengetahuan Anda tentang kerangka kerja.

• atau mentransfer konsep dari bahasa pemrograman lain atau patters yang mereka pelajari ke basis kode kami.

  Ini adalah hal yang luar biasa. Sepertinya kesempatan bagi Anda untuk belajar dari mereka.

• Seringkali mereka tidak dapat menyebutkan metode atau variabel dengan benar karena bahasa Inggris yang buruk

  Ulasan kode juga harus fokus pada penamaan yang tepat. Beberapa IDE juga memiliki pemeriksa ejaan.

• Terkadang saya berpikir jika bukan karena IDE saya pikir mereka akan menulis semua kode tanpa lekukan atau format sama sekali.

  Tentu saja mereka mau. Gaya itu membosankan dan harus otomatis.

• Pada dasarnya, saya benci kode yang mereka tulis.

  Ingat dari bagian ulasan kode: “Tujuannya bukan untuk menunjukkan seberapa buruk pengembangnya. Tujuannya adalah untuk memberikan peluang untuk peningkatan. "

• Ini berformat buruk / terorganisir, dan kadang-kadang sangat berbeda dari sisa proyek.

  Pengecekan gaya otomatis .

• Saya merasa sangat sedih ketika mereka menambahkan spageti mereka ke karya seni saya

  Tunggu apa?! Bagian dari seni?! Tebak apa? Beberapa orang (termasuk Anda dalam enam bulan) mungkin menemukan kode Anda jauh dari sekadar karya seni. Sementara itu, mengerti bahwa menganggap pekerjaan Anda sebagai karya seni dan pekerjaan mereka sebagai omong kosong tidak akan membantu siapa pun. Termasuk kamu.

• Rasanya semakin mereka tidak dapat diganggu untuk belajar atau tidak peduli: mereka hanya melakukan apa yang diminta dari mereka dan pulang.

  Tentu saja mereka akan melakukan apa yang diminta dari mereka. Ingat: konteks, bukan orang dan perbaiki metrik Anda . Jika konteksnya mengharuskan mereka untuk menjadi yang terbaik dalam apa yang mereka lakukan, mereka akan melakukannya. Jika konteksnya mengharuskan untuk menghasilkan sebanyak KLOC per bulan sebanyak mungkin dan tidak lebih, mereka juga akan melakukannya.

Menerapkan standar pengkodean dan tetap menggunakannya, pola desain, pustaka cuplikan kode yang dapat digunakan sebagai pedoman, dll.

Standar pengkodean dapat berkisar dari memutuskan apakah akan menggunakan spasi atau tab, pola desain apa yang harus dicoba dan digunakan, penamaan konvensi, dll. Ini akan sangat membantu bahkan jika setiap orang mengkode secara berbeda.

Jika Anda bisa, terapkan standar pengkodean dan ulasan kode - untuk memulai peninjauan setiap checkin. Dengan tim kecil itu akan sulit dijual kepada orang-orang yang tidak mengerti bahwa membelanjakan 2x atau 3x tambahan untuk kode Anda di muka akan menghemat 20x atau 30x pada keseluruhan waktu pengembangan, tapi itu konsep lain yang layak untuk dibeli -di dalam.

Saya tidak akan mencoba mengimplementasikan semuanya sekaligus, dan saya akan mencoba yang terbaik untuk membuat mereka muncul dengan standar juga - tidak hanya lekukan tetapi mencoba untuk membuat mereka memikirkan hal-hal yang mereka temui dalam kode mereka yang memiliki membuat hidup mereka lebih mudah atau lebih sulit.

Pertimbangkan mengadakan rapat satu hari dalam seminggu untuk meninjau kembali apa yang salah atau benar untuk setiap orang selama minggu itu - Anda mungkin juga menawarkan kesempatan bagi setiap orang untuk mengatakan apa yang dilakukan orang lain yang paling membantu minggu itu - hal-hal seperti itu . Anda bisa melihat buku XP / Agile untuk ide-ide lain seperti ini. Menjadi tim kecil, sekali lagi, ini bisa menjadi penjualan yang sulit.

Anda menyebutkan masalah bahasa. Jika pekerja ini adalah lokal (Entah kontraktor di tempat atau karyawan penuh waktu) yang seharusnya tidak terlalu menjadi masalah tetapi jika mereka adalah kontraktor luar negeri yang bekerja dari jarak jauh - izinkan saya mengatakan bahwa dalam pengalaman pribadi saya ini tidak pernah akan diperbaiki, baik naik sampai manajemen tahu bahwa itu tidak akan berhasil atau mempertimbangkan meninggalkan perusahaan. Jangan memasuki situasi di mana Anda bertanggung jawab atas pekerjaan mereka, dan jangan buang waktu untuk memperbaiki praktik pengembangan tim. Kemungkinan besar pekerjaan Anda akan berkembang menjadi menghabiskan 100% waktu Anda membuat kode mereka berfungsi. Banyak kontraktor luar negeri adalah programmer hebat, omong-omong, saya hanya merujuk pada kasus di mana perusahaan kontraktor mengirimi Anda jenis bakat yang Anda jelaskan.

Gejala-gejala yang Anda gambarkan dengan kuat menunjukkan kurangnya kohesi tim .

Dalam situasi seperti itu, standar pengkodean, pelatihan, prosedur atau alat tidak akan menjadi peluru perak yang dapat meningkatkan kualitas secara substansial. Pertama-tama Anda harus mengembangkan semangat tim, komunikasi yang terbuka dan konstruktif dan kepemilikan bersama atas produk tersebut.

Gejala:

• "mereka hanya melakukan apa yang diminta dan pulang": suara mereka terdemotivasi. Bukankah mereka lebih antusias ketika mereka tiba?
• "mereka" menentang "kita" / "aku" / "Aku": kurangnya rasa saling percaya?
• "Saya memberikan beberapa tips: Saya berkomentar PR pada Git": nada kritik tertulis kadang-kadang disalahartikan sebagai agresif atau arogan meskipun niat konstruktif. Mengapa tidak membahasnya secara langsung?

Anda adalah tim kecil: gunakan keunggulan ini! Beberapa ide untuk memulai:

• Buat keputusan penting secara kolektif. Diskusikan ketidaksepakatan secara terbuka. "Diskusikan" bukan untuk memaksakan satu sudut pandang, tetapi untuk mendengarkan dan mencoba menemukan landasan bersama.
• Anda telah refactored bagian penting dari kode, sehingga Anda memiliki kepemilikan yang sangat kuat. Biarkan mereka membeli. Biarkan mereka bicara.
• Dan untuk topik yang sangat sensitif tetapi sangat subyektif seperti pemformatan kode, cukup outsourcing tugas ke printer cantik otomatis yang akan memformat ulang sesuai standar dan tanpa perasaan pada setiap check-in.

Kutipan hari ini:

Jika Anda ingin cepat, pergilah sendiri. Jika Anda ingin pergi jauh, pergi bersama

Pertanyaan Anda dapat dijawab dengan "Ubah perusahaan Anda atau ubah perusahaan Anda". Bagi mereka yang tidak tahu, ini berarti Anda tinggal dan berjuang untuk membawa perubahan yang ingin Anda lihat di perusahaan Anda, atau mengubah perusahaan tempat Anda bekerja (yaitu pergi dan bekerja di tempat lain).

Bagian kedua adalah yang paling sederhana. Anda pergi dan menemukan perusahaan yang memiliki nilai yang sama dengan tempat Anda bekerja. Yang pertama tidak begitu sederhana karena ... orang.

Yang perlu Anda lakukan adalah mengubah orang. Berpikir bahwa mereka rusak dan Anda perlu memperbaikinya tidak akan berhasil. Orang adalah makhluk emosional. Ini dapat dengan mudah merosot dalam perang pribadi. Begitu...

Pertama-tama, Anda perlu mencari tahu mengapa situasinya seperti itu. Bicaralah pada semua orang. Temukan. Apa yang Anda lihat sekarang adalah hasil dari keputusan yang diambil sepanjang tahun (atau mungkin tidak mengambil beberapa keputusan penting pada waktu yang tepat). Jangan menilai dan jangan langsung menyimpulkan.

Apakah ini disebabkan oleh pengembang yang tidak berpengalaman? Apakah ini disebabkan oleh manajemen yang berusaha mengurangi biaya dengan merekrut lulusan murah alih-alih pengembang yang lebih berpengalaman dan mahal? Apakah ini tentang orang-orang yang malas dan niat buruk atau orang-orang dikalahkan oleh sistem yang rusak? Apakah tenggat waktu memaksa Anda untuk melakukan "apa yang harus dilakukan" untuk membuatnya bekerja atau orang hanya membuang-buang waktu dan tidak terlalu peduli pada apa yang sedang mereka kerjakan? dll.

Masalah dengan bidang pengembangan perangkat lunak ini adalah orang belajar di tempat kerja. Jika mereka bekerja di lingkungan yang buruk, mereka akan mengambil kebiasaan buruk. Dan kebiasaan cenderung menempel dan sulit untuk diguncang. Maka mereka tidak tahu yang lebih baik karena hanya itu yang mereka tahu. Tidak semua pengembang bersemangat tentang apa yang mereka lakukan untuk menginvestasikan waktu untuk menjadi lebih baik atau berusaha untuk meningkatkan. Beberapa masuk ke bisnis ini karena berbagai alasan lain. Jadi cari tahu mengapa orang seperti apa mereka.

Lalu ada manajemen. Apakah manajemen tidak menyadari situasi atau tidak peduli? Temukan. Anda benar-benar perlu mendapat dukungan manajemen jika Anda ingin memperbaiki keadaan. Jika sesuatu yang membutuhkan 3 bulan untuk membangun tiba-tiba mulai memakan waktu 4 bulan karena Anda sekarang perlu menulis tes, melakukan review kode, berdiskusi di papan tulis dengan tim untuk memutuskan solusi yang baik, program pasangan, dll, Anda dapat yakin bahwa manajemen akan melihat perbedaan waktu. Sesuatu yang berubah dari 3 menjadi 4 bulan mudah diamati dan diukur. Memiliki basis kode yang solid, produk yang dapat dipelihara, arsitektur stabil yang baik, hal-hal yang membuat struktur produk yang lebih baik tidak mudah untuk diukur. Berapa banyak waktu praktik terbaik membeli Anda dalam jangka panjang tidak dapat diukur dimuka, mungkin bahkan setelah fakta. Di samping itu, keterlambatan satu bulan adalah tidak punya otak. Jadi, dapatkan dukungan manajemen dalam hal ini. Bersiaplah untuk melakukan penjualan yang sulit.

Lihat juga konteks bisnisnya. Apakah ini mempengaruhi cara Anda bekerja? Apakah Anda memiliki peluang yang harus diikuti dengan biaya berapa pun, termasuk mengorbankan kualitas kode atau praktik terbaik?

Mari kita ubah perspektif sejenak.

Saya merasa sangat sedih ketika mereka menambahkan spageti mereka ke karya seni saya dan itu mempengaruhi suasana hati saya di tempat kerja dan produktivitas saya.

Maaf ... kamu apa? Seni? Saya tahu sebagian besar dari kita ada di sini untuk mendapatkan pengakuan dari rekan-rekan kami dan Anda hanya mendapatkan itu jika Anda adalah pengembang yang baik, tetapi apakah kode Anda ditampilkan di museum di sebelah lukisan? Apakah itu harus menimbulkan emosi pada orang yang melihatnya? Air mata sukacita dan kebahagiaan? Ya, saya sarkastik dan saya sengaja melebih-lebihkan karena saya ingin mengatakan untuk tetap merasakan kenyataan. Jangan terikat secara emosional dengan kode Anda.

Saya dulu bekerja dengan seorang pria yang dengan senang hati akan melemparkan tim, proyek dan perusahaan di bawah bus hanya untuk memaksakan "seni" -nya pada semua orang. Dia adalah "pemegang kebenaran" dan, menurut definisi, semua orang hanya tidak berpengalaman, buta, tidak mau belajar, tidak peduli, atau hanya bodoh. Jangan menjadi pria itu. Sebagai pengembang perangkat lunak, tugas Anda adalah menulis kode yang baik, kode yang diuji, kode yang dapat dipelihara, kode yang menambah nilai bisnis dan dapat terus melakukannya di bawah perubahan konstan di masa mendatang. Dan Anda harus melakukan semua itu di bawah keterbatasan anggaran dan waktu. Itulah artinya menjadi pengembang perangkat lunak profesional. Kecuali jika Anda adalah galeri seni, seni itu buruk untuk bisnis. Bersikap pragmatis dan jaga pandangan yang seimbang. " Cara mengabaikan kode buruk yang ditulis rekan kerja saya dan hanya fokus pada pekerjaan"Tutup pertanyaanmu karena caramu membingkai masalah. Mundur dan lihat semuanya.

Bagaimana saya bisa mengatasi situasi ini tanpa hanya berfokus pada 'budaya perusahaan yang buruk', 'lulusan yang tidak berpengalaman', dll. Dan benar-benar mulai memperbaiki situasi.

TL; DR: Hati-hati melihat situasi untuk mencari tahu mengapa semuanya berakhir dalam situasi itu. Terimalah bahwa situasinya seperti itu dan lihat bagaimana Anda dapat meningkat dari sana. Cari tahu pendapat semua orang tentang ini. Pilih pertempuran Anda. Memaksa perubahan tidak berhasil. Berkolaborasi untuk melakukan perubahan. Anda harus mencoba menunjukkan bagaimana hal-hal dapat ditingkatkan bukan menunjukkan seberapa buruknya mereka. Meyakinkan semua orang bahwa apa yang ingin Anda lakukan adalah demi kebaikan yang lebih besar dalam jangka panjang. Bawa mereka.

Dan lakukan dalam langkah kecil.

Jika Anda membawa terlalu banyak perubahan sekaligus, orang akan merasa kecil hati dan menyerah. Perubahan membutuhkan waktu. Ubah perusahaan Anda atau ubah perusahaan Anda. Semoga berhasil!