Faktor apa yang harus memengaruhi cara saya menentukan kapan harus meninggalkan proyek kecil dengan seorang teman? [Tutup]


30

Saya menemukan diri saya di tempat yang sulit akhir-akhir ini. Sudah mengerjakan game dengan teman pemrograman selama hampir 8 bulan sekarang. Kami berdua mulai sebagai pendatang baru dalam pemrograman sekitar Agustus tahun lalu, ia adalah siswa CS tahun ke-2, saya seorang IT support technology by trade dan seorang programmer otodidak dengan banyak buku dan langganan online.

Masalah yang terus-menerus saya lihat adalah bahwa ketika kita menulis sejumlah kode, sering kali akan sedikit diretas bersama, mengalami banyak kegagalan, dan jika itu adalah konsep baru bagi salah satu dari kita, penuh dengan solusi naif. Ini baik-baik saja, kita sedang belajar, saya berharap kedua kode kita menjadi sedikit diretas bersama pada firs atau pass kedua. Masalahnya muncul dengan sendirinya ketika benar-benar memperbaiki dan refactoring perilaku yang diretas bersama.

Pasangan saya akan berpegang teguh pada perilakunya yang baru saja dirakit, dengan terang-terangan menolak untuk melihat kesalahan pada saat itu mulai bekerja. Mengakui kesempurnaan dari sepotong struktur yang bahkan tidak dapat saya coba gunakan meskipun memiliki komentar dan dengan tepat menyebut metode & bidang. Tidak peduli sekeras apa pun saya berusaha, saya tidak bisa membuatnya melihat kelemahan yang jelas yang akan mencegah setiap perubahan lebih lanjut atau perluasan perilaku tanpa sepenuhnya merusaknya dan segala sesuatu yang begitu erat dipasangkan dengan mereka mungkin berada di kelas yang sama. Solusi yang diretas terus-menerus diretas, desain yang dipikirkan dengan buruk akan tetap seperti saat pertama kali disusun dan diuji.

Saya menghabiskan banyak waktu menjaga kode baru seperti halnya saya menulis sendiri, saya bingung apa yang harus dilakukan. Rekan saya kehilangannya malam ini, dan memperjelas bahwa apa pun yang terjadi, apa pun patokannya, tidak peduli praktik umum, tidak peduli bukti yang tak terbantahkan, kode-kodenya akan tetap seperti yang pertama kali ia lakukan. Bahkan jika seluruh buku telah ditulis tentang mengapa Anda ingin menghindari melakukan sesuatu, ia akan menolak untuk mengakui validitasnya dengan mengklaim itu hanya pendapat seseorang.

Saya memiliki kepentingan dalam proyek kami, namun saya tidak yakin apakah saya dapat terus bekerja dengan mitra saya. Sepertinya saya punya tiga opsi terbuka untuk saya.

  • Berhenti peduli tentang basis kode yang berfungsi melewati titik kompilasi, dan hanya berurusan dengan mencoba mempertahankan dan mengurai perilaku yang hampir tidak tertatih-tatih. Berharap bahwa sekali hal-hal mulai serius pecah dia akan melihat itu dan mencoba melakukan lebih dari sekedar meletakkan bandaid di atas desain cacat mendasar.
  • Pertahankan argumen tak berujung tentang masalah yang telah ditemukan satu dekade yang lalu oleh individu yang jauh lebih mampu.
  • Hentikan pemrograman pada proyek ini, tinggalkan hampir 10.000 baris kode saya dan banyak waktu yang harus saya habiskan untuk merancang dan coba dan temukan proyek baru sendiri.

Pendekatan apa yang bisa saya ambil untuk menentukan apakah layak melanjutkan proyek ini dengan orang ini? Atau faktor apa yang harus memengaruhi keputusan saya? Kami telah menulis banyak kode dan saya tidak ingin menyerah kecuali diperlukan.


3
Bagaimana dengan membuat pedoman gaya pengkodean yang disepakati dan proses peninjauan kode? Hindari masalah yang diperdebatkan, cukup masukkan dalam standar yang Anda berdua bisa menyetujuinya.
Brandin

25
Opsi keempat (jika itu di bawah lisensi permisif): garpu kode dan terus bekerja sendiri.
Robert Harvey

4
Bagaimana kode ini dilisensikan? Bisakah Anda memotongnya dan melanjutkan dengan orang lain?
Jaydee

14
Seperti @enderland menyebutkan dalam jawabannya, ada bendera merah yang sangat besar dalam apa yang Anda tulis: "Pasangan saya kehilangannya malam ini, dan membuatnya jelas bahwa tidak peduli apa, apa pun patokannya, tidak peduli praktik umum, tidak peduli bukti yang tak terbantahkan, kodenya akan tetap seperti semula dia membuatnya. " Jika Anda bisa lolos dari ini, lakukanlah. Siapa pun yang benar-benar layak bekerja sama akan memiliki kerendahan hati untuk menerima bahwa kadang-kadang mereka akan melakukan kesalahan.
Richard J Foster

3
Tidak peduli apa yang Anda putuskan, 10k baris kode tidak hilang: pikirkan apa yang Anda pelajari dari menulisnya; pikirkan kesenangan yang Anda miliki selama pengkodean waktu; dan, menerapkan apa yang telah Anda pelajari dalam iterasi (paksa) ketiga / keempat / n + 1 bahkan mungkin membuatnya lebih baik daripada versi saat ini. Selain itu jika Anda tahu apa yang harus ditulis 10k baris kode, Anda dapat menulis 10k baris dalam waktu yang relatif singkat; seringkali yang mengetahui apa yang harus ditulis untuk membuat segala sesuatunya bekerja adalah yang paling memakan waktu.
Kasper van den Berg

Jawaban:


26

Dikirim, kode tidak sempurna lebih baik daripada kode sempurna di papan tulis yang tidak pernah dikirimkan.

Yang telah dibilang...

Anda yang memiliki lebih banyak pengalaman, atau yang berada dalam situasi yang serupa. Apa yang kamu lakukan? Apa yang akan Anda rekomendasikan saya lakukan?

Saya akan mempertimbangkan yang berikut ini.

  • Apa tujuan dari proyek ini? Menyenangkan? Uang? Untuk mempelajari?
    • Apakah Anda benar-benar mencapai tujuan ini?
  • Apakah orang ini benar-benar memungkinkan Anda untuk mencapai tujuan Anda dengan lebih baik?
  • Seberapa dekat Anda dengan pengiriman sebenarnya?
  • Apakah masalah ini mencegah Anda meluncurkan? Atau apakah itu masalah kebanggaan pribadi?
  • Apakah ada manfaatnya bekerja dengan seseorang secara sukarela ketika frustasi?

Hentikan pemrograman pada proyek ini, tinggalkan hampir 10.000 baris kode saya dan berjam-jam yang tak terhitung jumlahnya mengandalkan desain dan mencoba dan menemukan proyek baru sendiri

Pertimbangkan hal di atas, cobalah untuk memikirkan pekerjaan tambahan yang diperlukan.

Anda perlu mengetahui prioritas Anda dan menentukan apakah masalah yang berhubungan dengan bekerja dengan orang ini layak dilakukan. Kami tidak dapat menemukan ini untuk Anda.

Rekan saya kehilangannya malam ini, dan memperjelas bahwa apa pun yang terjadi, apa pun patokannya, tidak peduli praktik umum, tidak peduli bukti yang tak terbantahkan, kode-kodenya akan tetap seperti yang pertama kali ia lakukan.

Anda tahu Anda tidak ingin bekerja dengan orang seperti ini.

Anda sedang melakukan proyek seperti ini mungkin karena Anda ingin belajar pemrograman dan menemukan keanggunan dalam kerajinan itu sendiri.


1
Terimakasih atas balasan anda. Saya mencapai tujuan bersenang-senang (ketika tidak bertengkar) dan belajar. Cuaca uang yang dihasilkan adalah cerita yang sama sekali berbeda. Dia memang membantu mencapai tujuan saya, namun saya percaya saya masih bisa mencapainya sendiri, dia membantu dengan motivasi. Permainan ini adalah contoh yang bagus dari fitur creep, jujur ​​saya tidak tahu kapan itu bisa dikirimkan. Pasangan saya telah mencoba untuk mendorong perubahan dari 2D ke 3D selama berbulan-bulan sekarang, saya menolak karena kami sudah lama melampaui ruang lingkup kami.
Douglas Gaskell

1
Saya akan rela membatalkan proyek itu, jika hanya proyek saya sendiri, proyek itu akan dibatalkan beberapa bulan yang lalu. Faktor pendorong saya untuk terus adalah memiliki orang lain untuk diajak bekerja sama, bahkan jika pertikaian membuat saya mempertanyakan itu suatu hari nanti. Satu-satunya hal yang menghalangi saya untuk meninggalkannya adalah persahabatan seperti koneksi dengan dia di luar pengkodean, saya lebih suka menghindari melemparkan itu dengan proyek. Tentu saja ini bukan penjelasan yang sangat logis, karena perasaan pribadi mereka yang terlibat. Ini benar-benar mengaburkan kemampuan pengambilan keputusan saya.
Douglas Gaskell

1
cara tercepat untuk kehilangan teman adalah bekerja dengan mereka secara setara!

58

Ini mungkin hal budaya. Dalam beberapa budaya, mengakui bahwa Anda melakukan kesalahan adalah hal yang tidak pernah terdengar, dan meminta seseorang untuk mengaku melakukan kesalahan adalah hal paling kasar yang dapat Anda lakukan. Jika itu situasinya, larilah.

Dalam pengalaman saya dengan orang-orang yang sangat pintar, jika Anda memberi tahu mereka bahwa sesuatu yang mereka lakukan kurang sempurna, mereka akan (1) memberi Anda alasan yang benar dan mudah dimengerti mengapa apa yang mereka lakukan sebenarnya benar, (2) memberi tahu Anda yang mereka tahu itu salah, tetapi mereka tidak punya waktu untuk memperbaikinya karena prioritas, atau (3) terima kasih telah menunjukkan dan memperbaikinya.

Menolak untuk belajar adalah tentang atribut terburuk yang bisa dimiliki oleh pengembang perangkat lunak. Biarkan dia melakukannya. Hidup ini terlalu singkat dan berharga untuk menghabiskan waktu Anda dengannya.


Terima kasih Gnasher, saya memang melihat # 2 secara berkala, meskipun kami tidak memiliki jadwal yang sebenarnya jadi saya tidak yakin seberapa valid tanggapan itu. Saya akan membahas hal ini dan melihat apa yang saya pikirkan di AM ini perlu banyak pertimbangan sebelum membuat keputusan.
Douglas Gaskell

1
"Jika itu situasinya, larilah." - dan secara umum, jika Anda tidak dapat mencapai dekat dengan konsensus apa tujuan Anda maka Anda tidak dapat bekerja sama dengan seseorang. Sepertinya dia tidak akan menyetujui Anda mengubah kode "nya", apa pun alasannya.
Steve Jessop

Sepertinya tekanan waktu bukanlah alasan untuk menolak perubahan.
gnasher729

1
Ini jawaban yang bagus. Anda tidak dapat memaksa seseorang untuk mengubah cara mereka! Namun, sepertinya ada banyak waktu dan usaha yang dimasukkan ke dalam proyek pada akhirnya dan juga Anda. Pemikiran saya mungkin bahwa dia mungkin tidak ingin mengubah kodenya karena dia tidak mengerti cara yang menurut Anda harus dilakukan. Entah itu atau dia sudah gila, tetapi jika itu IS dia tidak memahaminya, cobalah untuk diingat bahwa dia mungkin frustrasi dan berpikir bahwa Anda "merendahkan" kepadanya, meskipun maksud Anda sangat baik. Saran saya adalah mencoba membicarakannya dengannya ketika Anda berdua siap untuk itu.
zfrisch

^ + Sangat mudah untuk tersinggung oleh seseorang ketika Anda memulai pada tingkat yang sama dan mereka melampaui Anda dalam keterampilan. Saya tidak mengatakan itu pasti masalahnya, tapi sepertinya itu mungkin ada hubungannya dengan itu.
zfrisch

12

Mungkin cara termudah adalah membawa orang lain ke dalam proyek - entah Anda salah dan basis kode-nya terlalu pintar untuk Anda, atau Anda benar dan terlalu pintar untuk semua orang. Anda akan segera mengetahuinya, dan akan mendapatkan cadangan jika ternyata itu adalah kode tingkat junior-sampah, berbelit-belit.

Di sisi lain, produk yang bekerja bernilai beberapa tahun dengan kode yang disetel halus, elegan, dan jelas. Buat gim, kirimkan, berjalan pergi - tinggalkan dia untuk mempertahankannya dan jangan bekerja pada v2.


2
Terima kasih atas balasannya. Lucu bahwa Anda menyebutkan poin pertama Anda. Dia berusaha mencari dan membawa seorang programmer pemula yang dapat dia ajar untuk membantu proyek tersebut. Saya hanya bisa berharap ini menjadi mengerikan jika ada dua orang yang mengikuti gaya hack yang sama dan lupa. Saya suka opsi kedua, membuatnya, mengirimkannya, dan kemudian meninggalkannya. Masalah yang mungkin saya temui adalah bahwa kami sebagian sedang membuat LLC sehingga kami memiliki nama untuk mengirimkan permainan kami. Kedua penggunaan akan memiliki pangsa 50% tentu saja. Namun, saya bisa menyelesaikannya dan kemudian melanjutkan. Proyeknya besar, bisa lama.
Douglas Gaskell

20
Anda tidak dalam keadaan apapun ingin masuk ke hubungan bisnis yang mengikat secara hukum dengan orang seperti itu.
gnasher729

3
@ douglasg14b membawa junior untuk mengajar .. anak malang. Sarankan Anda membawa orang yang berpengalaman "karena ia akan naik dengan kecepatan lebih cepat dan membantu menyelesaikan produk". Tetapkan pandangan Anda pada garis finish - atau apakah Anda berdua berniat mengerjakan hobi ini selamanya? (lihat itu terjadi, sampai dibatalkan)
gbjbaanb

Saya berencana menyelesaikannya, pasti. Meskipun saya percaya itu adalah proyek yang terlalu besar untuk ditangani sebagai proyek pertama kami. Ini dimulai sebagai desain yang sederhana, tidak seharusnya mendekati skala sekarang. Batas ruang lingkup kami terus-menerus didorong oleh fitur creep oleh pasangan saya, saya sebagian harus disalahkan untuk itu karena saya membiarkannya terjadi dan bahkan setuju dengan beberapa fitur. Cakupannya sampai pada titik bahwa jika dibiarkan sendirian, kita mungkin melihat penyelesaian dalam waktu satu tahun. Untungnya dengan cara saya memprogramnya, bagian-bagian dapat dengan mudah diambil dan dimasukkan ke dalam proyek lain di kemudian hari.
Douglas Gaskell

4
Pikirkan kode tersebut sebagai milik proyek, bukan milik Anda. Jika Anda memiliki kepemilikan bersama atas produk tersebut, Anda dapat menggunakan kembali semua kode untuk proyek berikutnya. Jika Anda tidak tahu siapa yang memiliki apa, lakukan diskusi itu sekarang. Semoga berhasil.
gbjbaanb

9

Berikut adalah beberapa ide walaupun beberapa dari mereka saling eksklusif.

  • Pisahkan tanggung jawab sumber. Jika Anda mengerjakan Modul A dan dia di Modul B Anda dapat bersaing dengan gaya Anda yang berbeda. Apakah dia sering merilis fitur yang berfungsi? Apakah dia mencapai titik di mana dia perlu menulis ulang kodenya dari awal? Perbaiki kode dari modul Anda dan jangan sentuh dia,

  • Biarkan dia melakukan pemeliharaan kode terburuknya. Jika dia berhasil, Anda telah menghindari tugas yang mengerikan. Jika dia tidak mampu, dia akan merasakan sakitnya.

  • Pertimbangkan dari sudut pandang pengguna atau bisnis. Dalam beberapa kasus, Anda hanya perlu produk yang dapat dibeli oleh google atau Microsoft. Di lain Anda meluncurkan produk ke pasar dan mendukung ribuan klien dengan kode kereta atau diretas akan menjadi neraka. Tidak sama jika kode Anda mengontrol drone dengan rudal nuklir atau membuat video yang menyenangkan untuk remaja.

  • Dia melakukan kelas, Anda melakukan tes. Kode refactoring dengan tes lebih mudah dan aman. Dengan cara ini Anda tidak perlu melihat ke dalam kode hanya di bar Junit. Ini mengasumsikan bahwa A) Anda memprogram tes, B) kode kolega Anda dapat diuji. Jika Anda merasa sulit untuk membangun tes selama fase pengkodean yang terakhir akan lebih buruk.

  • Pergi bersama ke pelatihan atau acara. Ketika Anda tidak tahu cara yang benar adalah wajar gunakan satu-satunya cara Anda tahu. Melihat kode orang lain mungkin tidak menyelesaikan semuanya tetapi tidak ada salahnya untuk mencoba.

  • Temukan kekuatan pelengkap Anda. Refactoring terkadang menyenangkan. Jika dia menulis hal-hal yang paling tidak berhasil, Anda bisa melakukan refactoring. Dia dapat melakukan paku untuk mengeksplorasi solusi yang tidak berakhir pada kode produksi.

  • Dia mungkin tidak ingin menulis ulang kode tetapi dia mungkin setuju untuk menulis kode baru dengan lebih baik. Saya mengerti bahwa menulis ulang itu sulit, membosankan dan dapat merusak banyak hal. Tumbuhkan beberapa pulau berkualitas. Dengan cara ini ia akan memiliki contoh yang baik tentang bagaimana melakukan sesuatu.

  • Gunakan aturan pramuka . Jangan biarkan barang-barang tersentuh kecuali Anda perlu mengusahakannya. Jika modul ditulis dengan buruk tetapi berfungsi dan tidak perlu diubah biarkan seperti itu. Jika Anda perlu memperbaiki bug atau menyelesaikan fitur, tingkatkan sedikit. Setelah beberapa waktu, 20% kelas yang Anda ubah 80% dari waktunya akan meningkat. Lebih banyak pulau berkualitas.

Kami tidak dapat menyarankan solusi apa yang terbaik tanpa mengetahui Anda berdua. Semoga berhasil.


4

Oke, ini jawaban yang mungkin tidak Anda sukai.

Jangan 'memperbaiki' kode kecuali jika gagal mengimplementasikan fitur.

Inilah alasan saya. Anda mungkin mencoba menghasilkan uang. Untuk menghasilkan uang, Anda harus mengirimkan fitur yang sudah selesai dengan cepat. Tidak ada yang akan membayar Anda lebih banyak untuk game komputer yang 'dikodekan dengan baik'.

Sebagian besar perusahaan memiliki masalah yang sama. Refactor kode yang ada untuk membuatnya lebih baik, kadang-kadang bahkan secara objektif lebih baik dalam hal kecepatan atau keandalan ATAU menulis fitur baru.

99% dari waktu mereka memilih untuk menulis fitur baru karena hasil analisis manfaat biaya yang sederhana.


15
Ini masuk dalam argumen "utang teknis" keseluruhan, kan? Ketika Anda menulis fitur baru itu (atau memodifikasi yang sudah ada), apakah perlu tiga kali lebih lama dan menghasilkan sepuluh kali lebih banyak bug daripada jika Anda terus menggunakan refactoring Anda? Jika demikian, maka mungkin melewatkan refactoring adalah ekonomi palsu.
Ben Aaronson

1
Anda akan berpikir begitu, tetapi saya telah bekerja di banyak perusahaan yang sukses dan saya (hampir) tidak pernah melihat refactoring pada prioritas tinggi. Kesimpulan saya adalah bahwa itu hanya membayar.
Ewan

Itu cukup adil dan saya yakin ada berbagai pendapat tentang ini, sepertinya tidak membahas bahwa satu atau lain cara adalah penghilangan yang signifikan dari jawabannya. Saya juga mungkin salah tetapi membaca yang tersirat dalam pertanyaan, saya pikir kode buruk OP khawatir tentang mungkin jauh lebih buruk daripada jenis kode yang Anda pikirkan.
Ben Aaronson

heh, yup! tetapi juga sepertinya biaya untuk membuat perubahan sangat tinggi. Dalam jawaban saya, saya mencoba memberikan tujuan 'apakah Anda dalam hal ini demi uang?' jawab, ditambah pandangan subjektif saya tentang di mana keseimbangan probabilitas terletak
Ewan

1
Ini masuk akal dalam beberapa kasus, tetapi jika "kode kerja" seseorang menyebabkan orang lain menghabiskan waktu 2x lebih banyak pada kode mereka atau mengintegrasikan sistem bersama-sama atau pekerjaan di masa depan, itu tidak lagi merupakan keputusan sederhana "kapal vs tidak-kapal". Banyak proyek skala besar mati karena mereka tidak membuat keputusan untuk melakukannya dengan benar daripada cepat.
enderland

3

Saya suka semua jawaban sejauh ini. Mengambil salah satu poin dari jawaban enderland :

Apakah ada manfaatnya bekerja dengan seseorang secara sukarela ketika frustasi?

Saya ingin mengambil waktu ini untuk plug untuk pertukaran kode ulasan . Ini adalah tempat yang indah di mana Anda bisa mendapatkan kode Anda dikritik oleh para profesional. Dan jujur, banyak ulasan kode ada sangat membantu bagi mereka yang terlibat - para penanya, penjawab, dan mereka yang tersandung oleh dan membacanya. Anda jarang mendapatkan ulasan yang bermanfaat dalam pengaturan profesional (yang mungkin hanya terjadi di tempat saya bekerja karena alasan apa pun).

Saran saya adalah memposting beberapa kode Anda untuk ditinjau. Saya tidak akan menyarankan menggunakannya sebagai amunisi untuk membuktikan orang ini salah - saya ragu dia akan membawanya ke hati - tetapi Anda bisa mendapatkan informasi yang sangat berguna baik pada kode yang Anda tulis dan kode yang ditulisnya. Saya akan merekomendasikan mengirimkan potongan-potongan kode yang paling Anda pertengkarkan. Dalam semua kemungkinan, Anda berdua salah sampai taraf tertentu dan Anda dapat menggunakan ulasan ini sebagai cara untuk melibatkan pihak ketiga yang objektif. Ini akan mencapai beberapa hal:

  • Anda dapat memutuskan hubungan dari ketegangan emosional situasi.

  • Anda mendapatkan saran profesional waktu nyata. Sebuah dorongan besar untuk apa yang Anda pelajari.

  • Seseorang akan memberi tahu Anda bahwa Anda salah. Itu bagus, karena siapa pun yang melakukan pemrograman untuk waktu yang lama akan mendengar ini. Anda bisa menanganinya dengan buruk seperti orang yang bekerja sama dengan Anda, atau Anda bisa belajar menghadapinya.

Saya pikir jika Anda menggunakan ulasan kode dengan cara yang benar, Anda memiliki banyak keuntungan dengan berurusan dengan orang yang sangat frustasi ini. Dan itu jauh lebih interaktif daripada buku atau situs web yang mengatakan "lakukan ini, karena itu adalah cara yang benar sebagian besar waktu".

Demikian pula, ada pertukaran stack pengembang game . Bukan tempat untuk memposting kode untuk ditinjau, tetapi untuk bertanya tentang konsep / ide yang Anda perjuangkan. Sekali lagi, tempat itu sangat membantu semua yang terlibat.

Anda mungkin pernah melihat kedua situs ini sebelumnya; Saya hanya ingin memastikan mereka bagian dari perangkat Anda.


2

Kedengarannya tidak ada harapan. Saya mungkin akan menyerah dan terus maju jika saya merasakannya seperti Anda; pasti ada saatnya untuk pergi dan Anda mungkin ada di sana.

Jika Anda belum siap untuk pergi, Anda perlu menemukan cara untuk mencapai kesepakatan yang lebih baik tentang proses Anda. Sepertinya Anda memiliki standar pengkodean, tetapi tidak standar yang disepakati. Lain kali Anda datang ke persimpangan jalan, lain kali Anda ingin monyet dengan sedikit kode dan teman Anda ingin meninggalkannya sendirian, tembak untuk percakapan di sepanjang baris berikut:

douglas: Saya ingin mengubahnya karena X, yang ada di sini di pedoman kami.

sobat: Tidak masalah bagaimana itu.

douglas: Jadi maksudmu kita harus mengubah pedoman?

sobat: Tidak, saya pikir tidak apa-apa.

douglas: Jadi untuk apa pedomannya?

Sobat: Saya tidak tahu - Anda yang menulisnya.

douglas: Pedoman apa yang akan Anda tulis?

Sobat: Saya tidak akan menulis pedoman. Buang-buang waktu.

douglas: Jadi kita harus membuang pedoman dan menulis omong kosong apa pun yang kita pikirkan saat itu?

sobat: Ini bukan omong kosong.

Douglas: Apakah sempurna? Apakah ini ideal?

sobat: Ini menyelesaikan pekerjaan; mari beralih ke fitur selanjutnya.

douglas: Adakah yang bisa kita sepakati, bahwa X adalah kode yang baik dan Y adalah kode yang buruk?

teman: tinggalkan aku sendiri; Saya hanya ingin kode!

Ya, itu tidak berjalan dengan baik, bukan? Saya kira perasaan yang saya miliki adalah bahwa Anda dan Buddy menginginkan hal yang berbeda. Jika ada yang bisa Anda setujui, bagus; mulai dari sana dan bangunlah. Tetapi Anda tidak dapat membuatnya setuju untuk menginginkan apa yang Anda inginkan - lebih dari Anda dapat membuat diri Anda menginginkan apa yang tampaknya diinginkannya. Jika Anda dapat menemukan keinginan bersama itu, dan mencapai kesepakatan bersama dari sana, mungkin Anda dapat bekerja sama.

douglas: Apa yang kamu inginkan?

Sobat: Saya hanya ingin kode.

Douglas: Saya ingin kode juga, tapi saya ingin merasa bangga dengan kode saya.

sobat: Saya bangga dengan kode saya.

douglas: Inilah fungsi yang saya banggakan - apa pendapat Anda tentang itu?

sobat: Baiklah, tidak apa-apa, tetapi Anda tidak harus menghitung ulang X di dalam loop; itu tidak efisien.

douglas: Jadi, apakah Anda mengatakan kami harus selalu menghitung nilai konstan di luar loop?

teman: ya, duh!

douglas: Apakah menurut Anda itu ada dalam pedoman kami?

sobat: tentu saja.

douglas: Oke, saya akan menambahkannya ke pedoman kami, dan saya akan memperbarui kode saya ...

Douglas: Bagaimana sekarang?

sobat: Baik.

Sekarang Buddy berkontribusi pada pedoman (namun secara tidak langsung), dan dia punya sedikit rasa kepemilikan. Mungkin - mungkin saja - dia akan mulai menganggap mereka lebih serius. Saya pikir saya akan cenderung untuk menghapus batu tulis dan memulai kembali dengan pedoman, membiarkan sebagian besar atau semuanya berasal dari Buddy pada awalnya. Silakan tulis kode omong kosong sehingga dia merasa perlu menambahkan pedoman; biarkan mereka datang darinya. Mungkin kemudian dia akan mulai memahami alasan mereka.

Tetapi jika Anda lebih suka menyerah dan melanjutkan - itu mungkin bukan opsi yang buruk juga.


2

Dengan asumsi Anda memutuskan untuk meninggalkan proyek:

  • Buat kode dan refactor, gunakan sebagai item portofolio 'sebelum / sesudah'
  • Karena tujuannya adalah (terutama atau sebagian) untuk belajar pemrograman dan karena belajar sesuatu membutuhkan 2-4x selama melakukan sesuatu yang Anda tahu sudah, pekerjaan itu tidak benar-benar sia-sia.
  • 'Sunk cost attachment' (investasi yang sudah Anda buat dalam sebuah usaha sebelum mempelajarinya adalah ide yang buruk) adalah salah satu kesalahan manusia yang paling umum dalam pengambilan keputusan
  • Untuk menjaga persahabatan, bingkai keputusan Anda sebagai memprioritaskan pertemanan di atas pengkodean

1

tl; dr Anda harus meninggalkan proyek ini.

Tanpa mengetahui lebih banyak tentang ini maka Anda sudah memberi tahu kami, saya berspekulasi bahwa gesekan yang Anda alami terkait dengan pengalaman.

Meskipun Anda bukan seorang programmer yang berprofesi sebagai seorang profesional TI, Anda mungkin telah belajar cara paling sulit untuk melakukan hal-hal dengan benar pertama kali, referensi Anda ke diri masa depan Anda menunjukkan Anda telah mengacaukannya di masa lalu dan belajar tidak untuk.

Siswa CS tahun ke-2 Anda, meskipun cukup berbakat, mungkin tidak memiliki perspektif untuk melakukan itu (jika Anda seperti saya, berulang kali :).

Dia tidak akan pernah benar - benar percaya pada nilai memperbaiki hal-hal saat Anda pergi sampai dia membakar bekas luka dari kegagalan untuk melakukannya atau dibimbing dalam budaya dengan disiplin teknik yang luar biasa, atau keduanya.

Orang ini mungkin rekan pemrograman Anda, tetapi bukan rekan proyek Anda, jadi melakukan permainan ini sebagai proyek rekan mungkin merupakan penyebab yang hilang. Kecuali Anda siap untuk hanya memakan biaya masa depan. Mungkin hubungan itu cukup berharga bagi Anda. Dalam hal ini berikan hem / tali yang cukup untuk menggantung dirinya sendiri dan masuk untuk membantu membersihkan kekacauan ketika orang itu dipaksa untuk mengakui masalahnya.

Kalau tidak menjamin dan melakukan proyek dengan rekan, atau melakukan proyek mentor / mentee di mana itu dinamika dari awal.


1

Untuk menambahkan poin tambahan ke semua jawaban hebat:

  • Berapa banyak lagi upaya yang diperlukan untuk menyelesaikan proyek? Perhatikan bahwa menyelesaikan "10% terakhir" membutuhkan waktu lebih lama dari yang diharapkan orang. Itu termasuk pengujian bermain / penyetelan, memperbaiki kegunaan, mengatasi berbagai platform target, melepaskan, ... Jika itu adalah permainan iOS, maka ada penandatanganan kode dan melewati ulasan Apple. Jujur, finishing bisa memakan waktu selama "90%" pertama. Dan akan sangat sulit jika kodenya seburuk yang Anda sarankan. (Bisakah Anda mulai bermain mengujinya sekarang?)
  • Secara realistis, seberapa besar kemungkinan orang akan menikmati permainan Anda?
  • Waspadai " heuristic sunk cost ". Evaluasilah bahwa investasi 10.000 baris kode mengingat gambaran besar, melihat kembali pada produk jadi, dan tanpa optimisme yang tidak semestinya.
  • Bisakah Anda terus berjalan jika perlu 3 tahun lagi? Anda berdua memiliki gaya pengembangan yang berbeda (bukan pertandingan tim yang baik). Kedengarannya Anda sudah mendekati akhir kesabaran Anda dan jika Anda terus berjalan, bisa jadi sulit untuk tetap berteman.

3
"10% terakhir" membutuhkan banyak waktu lebih lama jika 90% dari kode adalah sampah :-(
gnasher729

0

Anda harus terus melakukan kode Anda dengan cara yang Anda anggap benar, dengan komentar dan semacamnya dan membuat salinan kode versi Anda (jika dia mengubah kode Anda).

Jangan berkelahi, jangan marah, hanya tersenyum ketika Anda melihat keputusannya yang buruk.

Hanya mengeluh sebagai pengguna, jika berfungsi jangan mengeluh.

Jangan menyerah, penting untuk membiasakan diri dengan orang yang berbeda dari Anda, yang akan terjadi dalam pekerjaan nyata.

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.