Menginspirasi rekan kerja untuk mengadopsi praktik pengkodean yang lebih baik?


24

Dalam Menangani pertanyaan rekan kerja kuno saya , berbagai orang membahas strategi untuk berurusan dengan rekan kerja yang tidak mau mengintegrasikan alur kerja mereka dengan tim.

Saya ingin, jika mungkin, mempelajari beberapa strategi untuk "mengajar" seorang rekan kerja yang tidak tahu apa - apa tentang teknik dan alat modern, dan mungkin sedikit apatis.

Saya sudah mulai bekerja dengan seorang programmer yang sampai saat ini telah bekerja dalam isolasi relatif, di bagian lain dari perusahaan. Dia memiliki pengetahuan domain yang luas dan yang paling penting dia telah menunjukkan keterampilan pemecahan masalah yang baik , sesuatu yang tampaknya kurang dimiliki oleh banyak kandidat.

Namun, kode aktual (C #) yang saya lihat adalah kemunduran ke hari-hari VB6. Struktur prosedural, notasi Hongaria, variabel global (penyalahgunaan static), tidak ada antarmuka, tidak ada tes, tidak digunakannya Generik, melempar System.Exception... Anda mendapatkan idenya.

Programmer ini sedikit lebih tua dari saya dan, setidaknya dengan kesan pertama, tidak secara aktif mencari perubahan positif. Saya tidak akan mengatakan resisten terhadap perubahan, karena saya pikir itu sebagian besar merupakan masalah tentang bagaimana topik tersebut dibahas , dan saya ingin dipersiapkan.

Programmer cenderung orang yang keras kepala, dan masuk dengan senjata merintis dan melembagakan tinjauan kode rip-it-to-shreds dan kebijakan ketat ditegakkan sangat mungkin tidak akan menghasilkan hasil akhir yang saya inginkan. Jika ini adalah karyawan baru, seorang programmer junior, saya tidak akan berpikir dua kali untuk mengambil posisi "mentor", tapi saya sangat khawatir memperlakukan karyawan yang berpengalaman sebagai pemula yang tidak mengerti (yang bukan dia - dia hanya belum mengimbangi kemajuan tertentu di lapangan).

Bagaimana saya bisa meningkatkan standar kualitas kode pengembang ini dengan cara Dale Carnegie, melalui persuasi lembut dan insentif non-materi? Apa yang akan menjadi strategi terbaik untuk melakukan perubahan halus, bertahap, tanpa menciptakan situasi yang bermusuhan?

Apakah orang lain - terutama pengembang utama - pernah dalam situasi seperti ini sebelumnya? Strategi mana yang berhasil merangsang minat dan menciptakan dinamika kelompok yang positif? Strategi mana yang tidak berhasil dan akan lebih baik untuk dihindari?


Klarifikasi:

Saya benar-benar merasa bahwa beberapa orang menjawab berdasarkan perasaan pribadi tanpa benar-benar membaca semua detail pertanyaan. Harap perhatikan hal-hal berikut, yang seharusnya tersirat tetapi saya sekarang membuat eksplisit:

  • Rekan kerja ini hanya "senior" saya berdasarkan usia. Saya tidak pernah mengatakan bahwa jabatannya, lingkup pengaruh, atau tahun-tahun di organisasi melebihi jabatan saya, dan pada kenyataannya, tidak ada yang benar. Dia seorang programmer LOB yang telah terserap ke dalam toko pengembangan utama. Itu dia.

  • Saya bukan karyawan baru, programmer junior, atau idiot naif lainnya dengan rencana besar untuk mengubah perusahaan dalam semalam. Saya pada dasarnya bertanggung jawab atas proses perangkat lunak, tetapi karena banyak orang yang telah bekerja sebagai "lead" tahu, tanggung jawab tidak selalu berkorelasi secara tepat dengan bagan organisasi.

  • Saya tidak bertanya kepada orang-orang bagaimana cara saya, datang neraka atau air tinggi . Saya bisa melakukan itu jika saya mau, dengan hasil bersih adalah bahwa orang ini akan menjadi kesal dan / atau berhenti. Tolong coba pahami bahwa saya mencari metode sosial , kooperatif untuk mendorong perubahan.

  • Penyebutan "... variabel global ... tidak ada tes ... melempar System.Exception" dimaksudkan untuk menunjukkan bahwa masalahnya bukan hanya dangkal atau estetika . Praktik yang dapat bekerja untuk aplikasi CRUD yang relatif kecil tidak serta merta bekerja untuk aplikasi perusahaan besar, dan pada kenyataannya, tidak ada kode sejauh ini yang benar-benar telah lulus tes integrasi.

Tolong, cobalah untuk mengambil pertanyaan pada nilai nominal, menerima bahwa saya benar-benar tahu apa yang saya bicarakan, dan baik menjawab pertanyaan yang sebenarnya saya tanyakan atau pindah.

PS Ucapan terima kasih yang tulus kepada mereka yang -did- menawarkan saran yang membangun daripada berdebat dengan premis. Saya akan membiarkan ini terbuka untuk sementara waktu lebih lama karena saya berharap untuk mendengar lebih banyak dalam pengalaman dunia nyata.


9
Saya sudah dalam situasi ini dan tidak pernah melihatnya benar-benar terselesaikan dengan sukses. Banyak orang seperti yang Anda jelaskan berhenti memikirkan pemrograman bertahun-tahun yang lalu; pada titik ini mereka hanya tertarik pada solusi untuk domain bisnis mereka. Saya tidak akan bergabung dengan kereta musik di situs ini yang mengutuk orang-orang seperti itu; memang saya pikir mereka adalah garam dunia. Jika mereka bekerja dalam kode Anda, Anda harus mendorong untuk setidaknya mendapatkan konvensi Anda dipatuhi. Saya belum pernah kesulitan menjual bahwa orang harus mengikuti konvensi yang ada jika berkontribusi pada proyek.
Jeremy

1
Apa yang dikatakan atasan Anda saat Anda menyampaikan kekhawatiran ini kepadanya?

2
@Aaronaught, karena kodenya berfungsi, ini bukan masalah teknis tetapi masalah politik, dan mungkin masalah yang perlu dipaksakan dari atas jika Anda ingin mengubah apa pun. Dengan kata lain dari atasan Anda. Siapkan argumen yang bagus!

2
@Thor: Jadi Anda pikir itu benar-benar mustahil bahwa gayanya hanyalah produk dari harapan yang rendah, tidak ada ulasan sejawat, dan kehidupan yang sibuk yang tidak cocok untuk belajar mandiri selama waktu pribadi seseorang? Tidak peduli bukanlah sifat kepribadian bawaan, itu adalah produk dari lingkungan seseorang, dan itu bisa diubah. Tidak mengetahui bahkan lebih mudah untuk berubah, tetapi masih harus didekati dengan tingkat diplomasi tertentu.
Aaronaught

1
@Aaronaught, entah Anda telah gagal total menjadi inspirasi (yang tidak bisa dikesampingkan) atau dia tidak ingin terinspirasi. Apakah Anda mempertimbangkan untuk mengkodekan tes unit Anda di Lisp atau Haskell jika ada rekan muda yang memberi tahu Anda bahwa ini jauh lebih pintar daripada apa yang Anda lakukan sekarang?

Jawaban:


10

Titik awalnya adalah kenal audiens Anda . Anda tampaknya sudah memahami hal ini karena Anda tahu perbedaan antara membimbing rekan kerja junior dan memengaruhi rekan kerja senior.

Anda masih perlu mencari tahu apa yang akan memotivasi individu ini. Apa yang berhasil pada satu kakek tua (seperti saya), mungkin tidak bekerja untuk kakek tua Anda.

Jika dia suka mentor / mengajar orang lain, Anda bisa mendekati masalah dengan mengajukan pertanyaan seperti "mengapa Anda melakukannya dengan cara ini?" Itu bisa membuat dialog berjalan di mana Anda dapat memintanya untuk mengevaluasi pendekatan yang lebih baru dan memberikan pendapatnya.

Jika itu tidak berhasil, Anda bisa menunjukkan bug yang dapat dihindari dengan menggunakan praktik atau gaya yang Anda ingin dia adopsi. Ini membutuhkan lebih banyak pekerjaan karena Anda harus menemukan bug dan menunjukkan bagaimana perilaku yang ingin Anda dorong akan membantu.

Jika dia tampaknya bersedia membantu orang lain, Anda dapat menarik keinginannya untuk membantu para pemula . Jelaskan bahwa "anak-anak hari ini" tidak terbiasa melihat gayanya pengkodean dan akan lebih mungkin untuk memecahkan kodenya karena itu.

Terkadang Anda mungkin harus langsung menghadapinya dan memaksakan masalah tersebut. Anda harus memilih pertempuran ini dengan hati-hati. Pastikan Anda mulai dengan topik di mana Anda tahu Anda bisa membuktikan kepadanya bahwa Anda memiliki cara yang lebih baik.


Ini tampak seperti beberapa strategi umum yang baik. Saya harus jelas bahwa ini baru berusia VB6, bukan COBOL. Mungkin 5-7 tahun ketinggalan zaman, bukan 20-30 tahun. Jadi bukan kakek tua / dinosaurus.
Aaronaught

1
Saya tidak akan bertanya, "Mengapa kamu melakukannya dengan cara ini?" Itu bisa berdampak buruk - menempatkan dia dalam posisi bertahan segera. Bisa jadi rekan kerja itu tidak tahu dan Anda tidak ingin dia merasa bodoh. Alih-alih, tanyakan "sudahkah Anda mempertimbangkan metode ini?"
IAbstrak

@Abstrak Jika dia suka mengajar, dia tidak akan defensif, dia akan menikmati kesempatan untuk mengajar. Nada dan sikap akan membuat perbedaan besar. Jika sepertinya Anda dapat dengan mudah menambahkan "Idiot" di akhir pertanyaan, maka Anda tidak melakukannya dengan benar? :-) Dalam pengalaman saya, kebanyakan orang bersedia menjawab pertanyaan yang tulus.
jimreed

@Abstract: Saya cukup yakin jika saya bertanya sesuatu seperti, "sudahkah Anda mempertimbangkan injeksi ketergantungan di sini?" jawabannya adalah "ya?" Tentu saja ada kesempatan saya mungkin akan terkejut, tetapi saya pikir jim benar, ini adalah awal percakapan yang lebih baik untuk bertanya "apa yang membuat Anda memutuskan untuk menggunakan Fooobjek dengan cakupan global di sini?" Saya tidak melihat hal itu ditafsirkan sebagai serangan; ini saya mencoba memahami desain yang ada.
Aaronaught

@Aaronaught: cukup adil;) Sementara reaksi terhadap DI mungkin "huh?", Itu bisa memicu percakapan yang menarik seperti, "baik, saya pernah mendengarnya tapi ..." ... perhatian saya sebagian besar adalah nada (seperti yang ditunjukkan oleh jimreed) Tentu saja, seperti yang dikatakan jimreed, Anda harus memilih pertempuran - terkadang itu berarti membawa tongkat besar, kadang-kadang itu berarti bermain di kotak pasir bersama.
IAbstrak

4

Saya pikir Anda memiliki sikap yang benar. Pastikan untuk menunjuk untuk mengatakan semua hal-hal baik yang telah Anda katakan - Keterampilan memecahkan masalah yang hebat, memahami bisnis, dll dan hanya meminta sedikit waktu untuk menunjukkan kepadanya standar saat ini bahwa grup tersebut adalah menggunakan dan memberinya kesempatan untuk mengajukan beberapa pertanyaan tentang mereka.

Ketika Anda bersama-sama membawakannya kopi atau sesuatu, dan beri tahu dia bahwa bekerja dengan standar akan menguntungkannya dengan membuatnya lebih mudah untuk mendukung kode Anda yang ada dan juga membuatnya lebih mudah bagi seseorang untuk dapat membantunya jika dia tercakup dalam pekerjaan (nilai tambah yang besar untuk seseorang yang telah bekerja secara terpisah), dll.

Pastikan dia terlibat dan mendapatkan penjelasan yang baik tentang mengapa Anda melakukan hal-hal yang Anda lakukan dan tidak fokus pada mengapa dia tidak harus melakukan hal-hal yang dia lakukan, bawa orang lain jika Anda harus dan buat mereka menjelaskannya kepada Anda. Jadikan diri Anda tersedia setelah itu jika ia memiliki pertanyaan dan tindak lanjut dengan beberapa tempat yang dapat ia rujuk sebagai contoh standar Anda.

Jika dia tidak tertarik setelah itu maka Anda bisa merujuk ke pertanyaan pertama yang Anda tautkan.


4

Ini benar-benar tugas manajer Anda

  1. Sadarilah bahwa perusahaan harus memiliki standar pengkodean. Setiap perusahaan yang agak profesional memiliki ini, tidak peduli ukuran perusahaan.
  2. Suruh semua orang duduk bersama dan mulai mengerjakan standar. Dengan begitu, setiap orang dapat memiliki pendapat mereka, dan mereka kemudian akan lebih termotivasi untuk mengikuti standar.

Jika manajer Anda tidak menyadarinya sendiri, mereka tidak memenuhi syarat untuk pekerjaan mereka. Dan jika demikian, Anda harus memberi mereka dorongan di atas dua di atas. Keuntungan memiliki standar pengkodean sangat banyak, benar-benar tidak ada argumen untuk tidak memilikinya. (Jika beberapa programmer merasa bahwa mereka adalah "seniman" dan tidak boleh dibatasi oleh batas-batas profesionalisme, mereka seharusnya mendapatkan pekerjaan melakukan seni rupa sebagai gantinya.)

Standar pengkodean itu sendiri harus pertama-tama dan terutama berfokus pada pelarangan praktik berbahaya dan fungsi perpustakaan berbahaya. Berusahalah menuju bagian bahasa yang Anda gunakan lebih aman dan lebih murni. Jaga agar standar pengkodean bebas dari "gaya pengkodean", karena gaya pengkodean jauh lebih sulit untuk disetujui, dan tidak sepenting itu. Agak klasik bahwa perusahaan memutuskan untuk membuat standar pengkodean dan kemudian segera terjebak dalam diskusi omong kosong tentang di mana menempatkan {} braces.

Untuk referensi, lihat bagaimana standar MISRA-C / C ++ dan CERT C / C ++ / Java ditulis.


Ini membuat asumsi (salah) bahwa saya bekerja untuk penerbit perangkat lunak dengan struktur vertikal. Kurang dari 10% pengembang bekerja untuk penerbit perangkat lunak dan itu tidak selalu menjadi tanggung jawab eksekutif atau manajer menengah untuk mengelola mikro pengembang.
Aaronaught

2
@Aaronaught Well, kalau begitu itulah sumber sebenarnya dari masalah Anda. Jika Anda tidak berada dalam tim dengan standar pengkodean dan setidaknya satu programmer veteran untuk memimpin dan membimbing yang lain, itu adalah organisasi yang buruk. Semua orang akan kode secara acak, berpikir mereka adalah "artis", datang dengan hasil yang biasa-biasa saja, tidak stabil, tidak dapat dipertahankan, dan tidak belajar bagaimana meningkatkan.

2

Pertama-tama Anda perlu mengklarifikasi MENGAPA Anda ingin mengubah cara orang ini bekerja. Jika itu hanya untuk alasan estetika, saya pikir Anda harus mempertimbangkan kembali, karena orang ini telah menunjukkan bahwa cara kerjanya benar-benar berfungsi.

Namun, jika ada alasan teknis untuk itu, maka Anda harus mempertimbangkan mendekati orang tersebut dengan sesuatu seperti:

Saya punya saran untuk bagaimana Anda dapat menghemat waktu yang membosankan untuk Anda, dan uang untuk perusahaan. Apakah kamu tertarik?

Ketahuilah bahwa ini haruslah buah-buahan yang menggantung rendah karena kemungkinan besar akan membutuhkan perubahan kebiasaan yang ada yang selalu membutuhkan usaha ekstra.

Sekalipun Anda memiliki banyak saran, pilih saja satu atau dua, dan tunjukkan bahwa itu akan menjadi perubahan menjadi lebih baik.

Entah ini akan berhasil, dan Anda akan ditanya apakah Anda memiliki lebih banyak saran, atau tidak akan dan kemudian kerusakan terbatas pada satu atau dua saran.

Perhatikan bahwa sangat penting untuk menjadi sukses, dan melakukannya dengan cepat.

Anda juga harus berhati-hati. Mungkin ada alasan yang sangat baik untuk melakukan hal-hal dengan cara mereka dilakukan, tetapi Anda terlalu baru untuk melihat mengapa. Karena itu, hormatlah kepada penatua Anda dan tanyakan sebelum Anda menganggap bahwa saran Anda lebih baik. Anda mungkin belajar satu atau dua hal.


Terima kasih atas jawaban konstruktif - walaupun saya pikir itu bisa dilakukan tanpa paragraf pertama.
Aaronaught

@aaronaught, maaf, tapi sebenarnya ini cukup penting.

Tidak, ini benar-benar tidak penting. Itu menjawab pertanyaan yang sama sekali berbeda dan saya sudah memberikan beberapa komentar dan pengeditan untuk menunjukkan bahwa itu tidak relevan. Ketidakmampuan pengguna di situs ini (dan kebanyakan hanya situs ini) untuk memisahkan pertanyaan "Haruskah saya" dari "Bagaimana saya" adalah aktif berbahaya untuk kualitas keseluruhan dan koherensi wacana sini. Peringatan Anda valid, tetapi tidak relevan dan sedikit menyinggung. Bahkan ada pertanyaan meta yang sangat tinggi tentang topik yang tepat ini.
Aaronaught

1
@aaronaught, satu-satunya alasan Anda menyatakan ingin mengubah gaya pengkodean orang ini adalah karena berbeda dari anggota tim lainnya, dan kemudian Anda meletakkan gayanya secara tersirat yang menyatakan bahwa gaya Anda lebih baik. Demikian komentar saya. Jika Anda tidak dapat menerima gaya pengkodeannya saat ini di basis kode Anda, maka lakukan pertemuan pribadi dengannya dan katakan ini, dan bahwa Anda bersedia melakukan upaya besar membantunya mempelajari bagaimana Anda membutuhkan kodenya.

1
@Aaronaught, untuk orang yang bisa melakukannya tanpa paragraf pertama, saya menemukan pilihan Anda untuk kata-kata mengejutkan ofensif. Apakah Anda pikir menyebut orang lain menyedihkan adalah contoh untuk diikuti?

1

Saya ingin sangat mencegah Anda dari mendapatkan di wajahnya karena ini akan menyebabkan situasi menjadi lebih buruk dengan sangat cepat. Saya menyadari itu dibesarkan sebagai jenis upaya terakhir tetapi dalam pengalaman saya, pada titik ini, pengembang telah secara fungsional berhenti berpartisipasi.

Memaksa masalah bisa mengubah individu menjadi musuh di mana mereka melakukan pertempuran dengan setiap tindakan Anda. Itu benar-benar akan memiliki dampak tim negatif dan itu tidak berakhir sampai seseorang berhenti atau dipecat.

Jika orang ini benar-benar memiliki pengetahuan domain yang Anda butuhkan / inginkan maka mintalah mereka mendokumentasikan pengetahuan itu.


1
-1 Pertanyaannya sudah menyatakan bahwa OP tidak memiliki niat untuk mendekati ini dengan cara yang konfrontatif. Silakan baca pertanyaan OP secara menyeluruh dan jawab pertanyaan spesifik itu , daripada membahas topik secara umum.
HedgeMage

1

Mulai dengan membaginya dengan lembut: Saya tidak tahu seberapa berpengalaman dan seberapa baik Anda dalam memberikan umpan balik. Anda mungkin sudah tahu, mempekerjakan, atau bahkan telah menolak yang berikut, tetapi begini saja. Ada beberapa panduan untuk memberikan umpan balik ketika Anda ingin mengubah perilaku seseorang. Struktur percakapan yang telah saya pikirkan, dan masih mencoba menggunakan dalam situasi di mana saya ingin memberikan umpan balik (karena mereka bekerja) adalah sebagai berikut:

  1. Jelaskan perilaku yang Anda lihat. Ini harus perilaku konkret. Contoh: "Saya melihat bahwa Anda menggunakan banyak variabel statis dalam kode Anda"
  2. Jelaskan bagaimana hal itu berdampak pada Anda / tim Anda. Contoh: "Saya merasa kode seperti itu sulit dikelola"
  3. Tawarkan solusi yang masuk akal . (solusi yang mungkin disebutkan dalam jawaban lain, dan saya sendiri akan mencoba beberapa jawaban nanti.)
  4. Beri dia peluang untuk membahas solusinya. Tanyakan padanya apa pendapatnya tentang solusinya. Terima jawabannya pada nilai nominal. Anda telah memberinya pendapat, dan dia bebas untuk menerimanya atau tidak. *

Sumber daya cepat tentang umpan balik dapat misalnya ditemukan di http://managementhelp.org/communicationsskills/feedback.htm (meskipun ada banyak hal semacam ini di web)

Sekarang pada bagian solusinya, dari apa yang saya baca dalam jawaban Anda, saya kumpulkan dia cukup pintar, dan memiliki pola pikir yang benar, tetapi dia hanya ketinggalan dalam praktik baik modern. Mereka membutuhkan waktu dan upaya untuk menguasainya, terlepas dari mempelajari sebenarnya tentang mereka di tempat pertama, jadi Anda harus memberinya kesempatan untuk melakukannya. Itu mungkin berarti mengumpulkan sumber belajar (web, majalah, buku, apa pun) sebagai titik awal, dan memberinya waktu luang untuk mempelajarinya. Saya bisa membayangkan memberikannya setiap sore hari Jumat untuk memperluas wawasan tentang gaya pemrograman, di mana ia dapat melakukan apa pun yang ia yakini untuk mencapai tujuan-tujuan itu. Orang secara inheren ingin memperbaiki diri. Berikan bahan dan waktu, dan mereka akan memanfaatkannya dengan baik.

Mungkin yang paling penting, jangan berharap perubahan dalam semalam. Dia sudah melakukan banyak hal dengan caranya lama, dan mungkin sudah cukup baik dalam hal itu. Butuh beberapa waktu untuk menjadi lebih baik dengan cara baru dalam melakukan sesuatu, dan untuk sementara waktu, dia mungkin tidak akan melihat banyak nilai dalam cara baru, karena pada awalnya, tidak ada. Cara lamanya mungkin akan lebih efektif untuk sementara waktu.

* Catatan: lucunya tentang percakapan adalah mereka sangat sulit untuk dimodelkan. Mereka memiliki kehidupan mereka sendiri, jadi meskipun terlihat bagus di atas kertas, ia cenderung agak berlumpur.


0

Jelaskan bagaimana Anda ingin segala sesuatunya selesai dan tunjukkan kepadanya bagaimana ia bekerja dengan pilihan desain dan arsitektur yang telah Anda buat untuk proyek pada awal proyek yang Anda inginkan agar dia kerjakan. Duduk satu lawan satu (dan secara pribadi) dan jelaskan masalah yang telah Anda lihat dalam pengkodean sebelumnya dan mengapa mereka menjadi masalah untuk proyek ini. Tanyakan kepadanya apa yang harus dia lakukan untuk menjadi lebih baik, tetapi jelaskan bahwa tidak menjadi lebih baik bukanlah suatu pilihan.

Kemudian gunakan ulasan kode sebagai alat untuk membuatnya menyesuaikan metode kerjanya. Rencanakan waktu yang lama untuk yang pertama dan benar-benar bicarakan mengapa Anda lebih menyukai ini daripada itu dan biarkan dia menjelaskan alasannya. Pastikan untuk benar-benar mendengarkannya, orang-orang lebih mudah berubah ketika mereka merasa keprihatinan mereka telah diatasi. Harapkan dalam perencanaan Anda (tapi jangan katakan padanya) untuk mengerjakan ulang tugas pertama dan jangan menerimanya sampai memenuhi standar tim Anda. Begitu dia tahu apa yang Anda harapkan dan Anda tidak akan membiarkannya untuk kepentingan waktu, dia mungkin akan datang ke tempat Anda bekerja. Tetapi Anda mungkin harus menggunakan ulasan kode sebagai alat pendidikan untuk beberapa iterasi. Anda tidak harus jijik tentang tidak menerima pekerjaan sampai memenuhi standar Anda, tetapi Anda harus tegas tentang hal itu dan konsisten. Mengenakan'


-1

Pertanyaan $ 64.000 adalah apakah dia memberikan proyeknya tepat waktu dan memenuhi persyaratan fungsionalitas. Jika demikian, dia melakukannya dengan benar. Tidak ada cara yang benar atau salah dalam pengembangan perangkat lunak. Pada akhirnya ini tentang memecahkan masalah. Dan jika masalah diselesaikan untuk kepuasan klien / pelanggan, maka menurut definisi , pengembangan perangkat lunak dilakukan dengan benar.

Hal ini menjadi masalah yang sama sekali berbeda tentu saja jika proyeknya arent yang sedang diselesaikan. Pada saat itu perubahan perlu dilakukan oleh penyelia Anda, mungkin dengan masukan Anda. Tetapi hanya karena dia melanggar rasa kode estetika pribadi Anda atau kebijaksanaan konvensional hari ini tidak berarti apa yang dia lakukan adalah 'salah'. Anda bukan arbitor dari definisi 'kode yang baik'. Bagaimanapun, dia mungkin memiliki pendapat yang rendah tentang kode Anda.

Jadi ... kecuali ada benar-benar masalah dengan karyanya (yang Anda havent ditunjukkan ada), tidak melakukan apa-apa. Bagian dari menjadi pengembang yang sukses adalah belajar untuk menggabungkan kode Anda dengan gaya pengembang lain.

Lagi pula, dia bisa datang ke sini dan mengajukan pertanyaan serupa tentang berurusan dengan pengembang yang kurang berpengalaman yang lebih peduli dengan mengikuti mode daripada menyelesaikan proyek. Ini semua tentang perspektif.


2
Karena alasan inilah saya menunjukkan bahwa dia berasal dari bagian lain perusahaan. Dia tidak punya masalah memenuhi persyaratan mereka , tetapi persyaratan mereka bukan persyaratan kita . Secara khusus, persyaratan mereka tidak jauh lebih maju daripada CRUD. Dan ya, ada adalah masalah dengan kode; mungkin bekerja dengan baik dalam isolasi tetapi tidak akan lulus tes integrasi, kinerja, atau keandalan. Saya tidak percaya pada metodologi ketat seperti XP atau TDD atau apa pun, tapi ini bukan masalah estetika atau kebijakan konvensional, ini masalah persyaratan pemeliharaan.
Aaronaught

3
Saya juga tidak memilih ini karena alasan di atas, tetapi karena Anda membuat beberapa asumsi yang tidak beralasan. (a) Saya tidak kurang berpengalaman, (b) tidak ada hal yang saya bicarakan dibenarkan disebut "mode", dan (c) asumsi yang paling konyol ini - dia bukan pengembang paling produktif di tim, dan tentu saja tidak lebih produktif daripada saya.
Aaronaught

Jika sebenarnya ada masalah dengan apa yang dia hasilkan, maka seperti yang saya katakan , itu masalah bagi penyelia Anda, atau siapa pun penyelia Anda. Tapi Anda belum menunjukkan ada masalah dengan apa yang dia berikan kepada klien / pelanggan, hanya saja Anda tidak suka apa yang dia berikan kepada Anda. Yang mana maksud saya, dia tidak menulis perangkat lunak untuk Anda. Jadi sebelum Anda membuat keributan, saya akan memastikan bahwa dia tidak kalah dengan Anda.
GrandmasterB

Adapun mode, berkeliaran di industri untuk sementara waktu dan Anda akan menyadari bahwa ya, praktik terbaik saat ini adalah praktik buruk gaya VB6 masa depan. Adapun downvoting, tentu saja, merasa bebas. Saya hanya menanggapi pertanyaan yang diposting. Saya tidak bisa menanggapi detail yang tidak Anda berikan.
GrandmasterB

1
Saya tidak tahu resume Anda, saya juga tidak tahu rekan kerja Anda melanjutkan. Saya hanya tahu apa yang Anda masukkan dalam pertanyaan. Jika itu informasi penting, Anda harus memasukkannya. Dan berdasarkan jawaban Anda terhadap jawaban lain, Anda mungkin menganggap bahwa Anda meninggalkan sedikit, sehingga memerlukan banyak asumsi dari pihak penjawab. Tetapi jika Anda menginginkan jawaban, dengan anggapan Anda bukan atasannya, atasan Anda atau masalah atasan bersama Anda khawatir tentang bagaimana tidak menyebabkan keributan. Tolak saja kode yang menyebabkan masalah dalam pengujian dan laporkan apa masalahnya ke rekan kerja Anda.
GrandmasterB

-1

Sebagai pengembang junior yang berbicara dengan pengembang senior, terlalu berisiko bagi Anda untuk mencoba dan mendekatinya dengan ide yang lebih baik daripada miliknya.

Cara terbaik untuk mengatasinya adalah dengan mencoba dan meyakinkan bos Anda tentang praktik yang lebih baik, dan lihat apakah ia akan membuat keputusan bahwa semua kode harus mengikuti standar spesifik dan ditegakkan ke standar tersebut melalui ulasan kode rekan.

Sebagian besar orang (bahkan jika pada tingkat subconcious) pendendam, egois, dan defensif, bahkan jika mereka benar-benar tidak menyadari motif bawah sadar mereka sendiri, mereka akan tersinggung jika Anda mencoba mengubahnya atau menyiratkan bahwa mereka salah dalam bagaimanapun juga.

Chain of Command adalah cara paling aman untuk pergi karena dia HARUS mendengarkan bosnya, juga tidak harus menyukainya. Biarkan bos menjadi orang jahat, untuk itulah dia ada di sana.

Jika Anda tidak dapat menjual bos atau dia bosnya, maka cukup atasi bug-nya tetapi pimpin dengan memberi contoh dalam kode ANDA.


1
Ini menjawab pertanyaan yang sama sekali berbeda dari yang saya tanyakan. (a) Saya bukan pengembang junior, (b) bos saya sudah mendelegasikan sebagian besar keputusan desain dan kode penting kepada saya, (c) kodenya tidak diketahui bermasalah, hanya tidak terstruktur dengan baik untuk C # 's OOP / Paradigma campuran fungsional, dan (d) inti pertanyaan saya adalah bagaimana mendekati subjek sedemikian rupa sehingga mereka tidak tersinggung.
Aaronaught

1
@Aronaught, a) "Programmer ini sedikit lebih tua dari saya" Saya berasumsi dari pernyataan ini bahwa Anda adalah "junior" -nya. b) Kedengarannya seperti Anda memimpin teknologi itu, Anda harus meletakkan informasi itu dalam pertanyaan Anda, itu mengubah banyak hal. c) Jika dia tidak mengikuti praktik terbaik dan kodenya tidak bermasalah, lalu apa masalahnya? Kenapa mendekatinya tentang sesuatu? Jangan memperbaiki apa yang tidak rusak. d) Sekali lagi, jangan dekati dia jika dia tidak menyebabkan bug dengan kode kualitas buruk. Masalah sebenarnya adalah Anda tidak memiliki standar pengkodean dan pengembangan yang harus dipatuhi oleh semua orang.
maple_shaft

Saya pikir itu cukup jelas tersirat oleh referensi saya untuk (tidak) "masuk dengan meriam dan melembagakan tinjauan kode rip-it-to-shreds dan kebijakan ketat" - mengapa saya bahkan menyebutkan bahwa jika saya seorang junior ? Dan siapa bilang kita tidak punya standar? Dia tidak pernah bekerja dengan tim kami sebelumnya dan saya mencoba memperkenalkan standar tanpa menyebalkan .
Aaronaught

-1 Tidak menjawab pertanyaan yang diajukan.
HedgeMage

-1

Kamu tidak bisa

Anda tidak dapat menginspirasi orang untuk melakukan hal-hal yang tidak mereka sadari dalam pengembangan perangkat lunak. Saya berbicara dari pengalaman karena saya sering mencoba melakukan hal ini dalam karier saya, dan setiap kali hasil akhirnya adalah bahwa status saya sendiri berkurang di mata perusahaan; Saya bahkan dipecat atau berhenti dengan frustrasi setelah tidak terjadi apa-apa, hanya karena mencoba meningkatkan budaya pembangunan di sekitar saya menjadi praktik-praktik modern.

Jika rekan kerja Anda tidak bodoh, Anda bisa menunjukkannya kepada mereka. Karena mereka, bagaimanapun, tidak ada yang dapat Anda lakukan karena mereka tidak mampu atau cukup peduli tentang perangkat lunak sebagai pengerjaan untuk berusaha mengadopsi praktik pengkodean yang lebih baik. Kemungkinannya adalah jika Anda mencoba, mereka akan mengabaikannya atau berkeliaran tanpa benar-benar memahami, yang dari bunyi itu adalah apa yang sudah mereka lakukan ("Pengembangan Trial dan Kesalahan" yaitu hanya meretas kode sampai kesalahan berhenti) .


4
Saya menghargai tanggapannya, namun, saya menemukan ini sulit untuk dipercaya terutama karena saya adalah tipe programmer "baru saja menyelesaikannya" beberapa tahun yang lalu. Tidak ada yang menunjukkan kepada saya - saya harus menemukan semuanya sendiri - tetapi saya yakin bahwa seorang pemimpin yang cukup persuasif (jika ada) akan mampu melakukan perubahan yang sama. Hanya karena beberapa orang mempelajari semua ini secara mandiri, tidak berarti semua orang kehilangan akal.
Aaronaught

2
Itu benar, tetapi dalam pengalaman saya jika orang peduli tentang peningkatan, mereka perlu sedikit motivasi untuk terinspirasi karena keinginan sudah ada - mereka mungkin perlu dorongan atau nasihat, tetapi mereka mengerti dan ingin meningkatkan, hanya perlu bimbingan. Aku juga sama; Saya belajar cara-cara buruk dalam melakukan sesuatu dan berpikir "Harus ada cara yang lebih baik" dan memulai penelitian. Apa yang saya lihat adalah orang-orang yang tidak meningkatkan atau menunjukkan keinginan untuk memperbaiki adalah penyebab yang hilang karena mereka tidak ingin meningkat. Yang mengatakan, semoga berhasil dalam membuktikan saya salah :)
Wayne Molina

1
Saya pikir itu adalah jenis pernyataan yang perlu dibuktikan. Saya pasti akan tertarik mendengar (dan lebih banyak berkeinginan untuk memperbaiki) beberapa pengalaman dunia nyata, sehubungan dengan apa yang Anda coba tidak berhasil (dan mengapa itu tidak berhasil).
Aaronaught

1
Ini kadang benar, misalnya " anjing tua, trik baru " - coba jelaskan kepada seseorang bagaimana teknik telah meningkatkan efisiensi pengambilan data sebesar 800% dan rekan kerja hanya mengangkat bahu mereka.
IAbstrak

2
Intinya adalah, Anda bisa melakukan itu dan orang-orang akan mengikuti Anda, tetapi Anda harus peringkat lebih tinggi dalam hierarki. Anda tidak dapat melakukannya sebagai pengembang sederhana di sebagian besar tim. Banyak kolega hanya dapat menerima saran tanpa diminta dari seseorang yang lebih tinggi dalam hierarki. Jika Anda berada di level yang sama, mereka akan merasa terluka dan diserang. Ingatlah bahwa rasa hormat diperoleh. Jika Anda memperlakukan mereka dengan baik dan mengomunikasikannya dengan baik dan menyenangkan, itu bisa berhasil, jika Anda juga berada di level yang sama.
Falcon
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.