Küçük bir projeyi bir arkadaşımla ne zaman terk edeceğimi nasıl belirleyeceğim? [kapalı]


30

Geç kaldığım için kendimi zor bir noktada buldum. Neredeyse 8 aydır programlama arkadaşıyla bir oyun üzerinde çalışıyorum. İkimiz de geçen yılın Ağustos ayındaki programlamaya yeni başlayanlar olarak başladık, 2. sınıf CS öğrencisi, ticaretle ilgili bir BT destek teknisyeniyim ve çok sayıda kitap ve çevrimiçi aboneliği olan kendi kendine yeten bir programcıyım.

Sürekli olarak gördüğüm mesele, bir yığın kod yazdıkça, çoğu zaman birlikte ele geçirilecek, birçok başarısızlığa neden olacak ve eğer birimiz için yeni bir kavramsa, saf çözümlerle dolu olacak. Bu iyi, öğreniyoruz, her iki kodumuzun da köknarlarda veya ikinci seferde biraz kırılmasını bekliyorum. Sorun, birlikte ele geçirilen davranışları düzeltmek ve düzeltmek söz konusu olduğunda ortaya çıkıyor.

Ortağım, yeni bir araya toplanmış birlikte davranışını sürdürecek ve çalışmaya başladığı anda herhangi bir hatayı görmeyi kesinlikle reddedecek. Bir yapı parçasından yakın mükemmellik iddiasında bile yorum ve uygun şekilde adlandırılmış yöntemler ve alanlar olsa bile kullanmaya çalışamıyorum. Ne kadar uğraşırsam çalışayım, davranışta herhangi bir değişiklik veya yayılmayı önleyebilecek göze çarpmayan bariz kusurları göremem ve aynı sınıfta olabileceği kadar sıkı bir şekilde bağlı olduğu her şeyi. Hacked çözümler sürekli saldırıya uğramış, kötü düşünülmüş tasarımlar ilk gebe kaldıklarında ve test edildiklerinde kaldıkları gibi kalıyorlar.

Yeni kod yazarken, kendim yazdığım kadar çok zaman geçiriyorum, ne yapacağımı kaybediyorum. Eşim bu gece kaybetti ve ne olursa olsun, ne olursa olsun, referans ne olursa olsun, genel uygulama ne olursa olsun, reddedilemez kanıt ne olursa olsun, kodunun ilk yaptığı şekilde kalacağını açıkça belirtti. Tüm kitaplar neden bir şeyi yapmaktan kaçınmak istediğinizi yazmış olsa bile, bunun sadece birinin görüşünün olduğunu iddia ederek geçerliliğini kabul etmeyi reddedecektir.

Projemize kazanılmış bir ilgim var, ancak ortağımla çalışmaya devam edip edemeyeceğimden emin değilim. Bana açık üç seçenek var gibi görünüyor.

  • Derleme noktasından geçen kod temeli ile ilgilenmeyi bırakın ve sadece zorlukla kaybolan davranışları sürdürmeye ve ayrıştırmaya çalışın. İşler bir kez ciddi şekilde kırılmaya başladığını umarak bunu görecek ve temelde kusurlu tasarıma bir bandaj koymaktan daha fazlasını yapmaya çalışacaktır.
  • On yıl önce çok daha yetenekli bireyler tarafından tespit edilen konular hakkındaki bitmeyen tartışmaları sürdürün.
  • Bu projede programlama yapmaktan vazgeç, kodumun yaklaşık 10.000 satırını ve tasarımın üzerine geçen sayısız saatimi terk et ve kendi başıma yeni bir proje bulmaya çalış.

Bu kişiyle bu projeye devam etmeye değip değmeyeceğini belirlemek için hangi yaklaşımı kullanabilirim? Veya kararımı hangi faktörler etkilemeli? Çok fazla kod yazdık ve gerekmedikçe bu pes etmek istemiyorum.


3
Mutabık kalınan bir kodlama tarzı kılavuz ilkeleri ve bir kod inceleme süreci ortaya çıkarmaya ne dersiniz? Çekişmeli herhangi bir sorundan kaçının, standarda her ikisini de kabul edebileceğiniz kadar koyun.
Brandin

25
Dördüncü seçenek (izin verilen bir lisans altındaysa): kodu girin ve kendi başınıza çalışmaya devam edin.
Robert Harvey,

4
Kod nasıl lisanslanır? Çatallayıp başka biriyle devam edebilir misin?
Jaydee,

14
@Enderland'ın cevabında belirttiği gibi, yazdıklarınızda kesinlikle çok büyük bir kırmızı bayrak var: "Partnerim bu gece kaybetti ve ne olursa olsun, kriter ne olursa olsun, ortak uygulama ne olursa olsun, reddedilemez kanıt, onun kodu ilk yaptığı şekilde kalacak. " Eğer varsa olabilir bunlardan uzaklaşmak Bunu yapmak. Gerçekten birlikte çalışmaya değer olan herkes, bazı şeyleri yanlış anlayabileceklerini kabul etme kabiliyetine sahip olacaktır.
Richard J Foster,

3
Neye karar verirsen ver, 10k kod satırı kaybolmaz: bunları yazarak ne öğrendiğini düşün; kodlama sırasında harcadığınız keyfi düşünün; ve (zorunlu) üçüncü / dördüncü / n + 1. yinelemede öğrendiklerinizi uygulamak, onu mevcut sürümden daha iyi hale getirebilir. Ayrıca, ne 10k kod satırı yazacağınızı biliyorsanız , 10k satırını nispeten kısa sürede yazabilirsiniz; Çoğu zaman işleri yürütmek için ne yazacağını bilmek çoğu zaman gereken şeydir.
Kasper van den Berg

Yanıtlar:


26

Gönderilen, kusurlu kod hiçbir zaman gönderilmeyen beyaz tahtadaki mükemmel koddan daha iyidir.

Söyleniyor ki...

Daha fazla deneyime sahip olanlar veya benzer durumlarda olanlar. Ne yaptın? Ne yapmamı önerirsin?

Aşağıdakileri düşünürdüm.

  • Bu projenin amacı nedir? Eğlence? Para? Öğrenmek?
    • Aslında bu amacı gerçekleştiriyor musunuz?
  • Bu kişi aslında hedeflerinizi daha iyi gerçekleştirebilmenizi sağlıyor mu?
  • Nakliye için ne kadar yakınsınız?
  • Bu sorunlar başlamanızı engelliyor mu? Yoksa kişisel gurur meselesi mi?
  • Sinir bozucu birisiyle gönüllü olarak çalışmanın faydaları var mı?

Bu projede programlama yapmayı bırakın, kodumun yaklaşık 10.000 satırını ve sayısız saatin tasarım üzerinde durmasını bırakıp kendi başıma yeni bir proje bulmaya çalışın

Yukarıdakileri düşünün, gereken ek çalışmaları düşünmeye çalışın.

Önceliklerini belirlemeli ve bu kişiyle çalışmakla ilgili konuların buna değip değmeyeceğini belirlemelisin. Bunu sizin için çözemeyiz.

Eşim bu gece kaybetti ve ne olursa olsun, ne olursa olsun, referans ne olursa olsun, genel uygulama ne olursa olsun, reddedilemez kanıt ne olursa olsun, kodunun ilk yaptığı şekilde kalacağını açıkça belirtti.

Bu tür bir insanla çalışmak istemediğini biliyorsun.

Muhtemelen böyle bir proje yapıyorsunuz çünkü programlamayı öğrenmek ve zanaatın kendisinde zarafeti bulmak istiyorsunuz.


1
Cevabın için teşekkürler. Eğlenmeyi (kavga etmediğinde) ve öğrenmeyi hedefliyorum. Her para kazanılacak para tamamen farklı bir hikaye. Hedeflerimi gerçekleştirmede yardımcı oluyor, ancak hala kendi başıma başarabileceğime inanıyorum, motivasyona yardımcı oluyor. Oyun özelliği sürünen harika bir örnek, ne zaman gemi olabilir dürüstçe hiçbir fikrim yok. Ortağım aylardır 2D'den 3D'ye değişiklik yapmaya çalışıyor, şimdiden kapsamımızı çoktan aştığımız için reddediyorum.
Douglas Gaskell

1
Projeyi bırakmak isterdim, eğer sadece kendim olsaydım, aylar önce bırakılmış olurdu. Devam etmek için motive edici faktörüm, birlikte çalışmamın bazı günler beni sorgulamasına neden olsa bile, birlikte çalışacak başka birisinin olması. Beni terk etmekten alıkoyan tek şey, onunla birlikte kodlamanın dışında bağlantı kurmak gibi bir arkadaşlıktır, bunu projeyle karıştırmaktan kaçınırdım. Tabii bu çok mantıklı bir açıklama değil, kişisel duyguları olduğu için karar verme becerilerimi gerçekten bulandırıyor.
Douglas Gaskell

1
Bir arkadaşını kaybetmenin en hızlı yolu, onlarla eşit olarak çalışmaktır!

58

Bu kültürel bir şey olabilir. Bazı kültürlerde, bir hata yaptığınızı kabullenmenin duyulmamış olduğunu ve birinden bir hata yaptığını itiraf etmenizi istemek yapabileceğiniz en kaba şeyle ilgilidir. Bu durumda, kaçın.

Çok akıllı insanlarla olan tecrübelerime göre, onlara yaptıkları bir şeyin mükemmel olmaktan az olduğunu söylerseniz, ya (1) size yaptıklarının gerçekte doğru olmasının nedenini doğru ve kolay bir şekilde söyleyebilecekler (2) Bunun yanlış olduğunu bildiklerini ama öncelikleri nedeniyle düzeltmek için zamanları olmadığını veya (3) işaret ettiğinizi ve düzeltdiğiniz için teşekkür ederiz.

Öğrenmeyi reddetmek, bir yazılım geliştiricisinin sahip olabileceği en kötü özelliktir. Onu ona bırak. Hayat onunla zamanını boşa harcamak için çok kısa ve değerli.


Teşekkür ederim, Gnasher, periyodik olarak # 2'yi görüyorum, ancak gerçek bir programımız olmamasına rağmen, yanıtın ne kadar geçerli olduğundan emin değilim. Bunun üzerinde uyuyacağım ve karar vermeden önce AM’de ne düşündüğümü düşünüyorum.
Douglas Gaskell

1
“Eğer bu durum buysa, kaçın.” - ve genel olarak, hedeflerinizin ne olduğu konusunda fikir birliğine yaklaşamıyorsanız, o zaman biriyle işbirliği yapamazsınız. Nedeni ne olursa olsun, "kodunu" değiştirmenize izin vermeyecek gibi görünüyor.
Steve Jessop

Öyle görünüyor ki, zaman baskısı değişiklikleri reddetme nedeni değil.
gnasher729

1
Bu harika bir cevap. Birisini yollarını değiştirmesi için zorlayamazsın! Ancak, projenin kendisinde olduğu gibi projenin içine çok fazla zaman ve çaba harcanmış gibi görünüyor. Benim düşüncem onun kodunu değiştirmek istemeyebileceği olabilir, çünkü yapılması gerektiğini düşündüğünüzü anlamıyor. Ya öyle ya da kafadan atıldı, ama anlamadıysa, sinirlenebileceğini aklınızdan çıkarmaya çalışın ve çok iyi niyetli olsanız bile, onunla "konuştuğunuzu" düşünün. Benim tavsiyem, ikiniz de kaldığınızda onunla konuşmaya çalışmak.
zfrisch

^ + Aynı seviyede başladığın zaman birisi tarafından rahatsız edilmek kolaydır ve yeteneklerini aşarlar. Bunun kesin bir durum olduğunu söylemiyorum ama kesinlikle onunla bir ilgisi olabilir gibi geliyor.
zfrisch

12

Muhtemelen en kolay yol, bir başkasını projeye dahil etmektir - ya yanılıyorsunuz ve onun kod temeli sizin için çok zeki ya da haklısınız ve herkes için çok zekisin. Yakında öğreneceksiniz ve çöp, kıvrımlı, junior-programcı seviye kodu olduğu ortaya çıkarsa yedekleme alacaksınız.

Öte yandan, çalışan bir ürün, ince ayarlanmış, şık ve net bir kod olan herhangi bir yıl değerindedir. Oyunu yapın, gönderin, sonra yürüyün - sürdürmesini sağlayın ve v2'de çalışma.


2
Cevabınız için teşekkürler. Komik, ilk noktandan bahsetmen. Projeye yardım etmeyi öğretebileceği bir acemi programcı bulmaya ve getirmeye çalışıyor. Bunun sadece korkunç bir şekilde ortaya çıkmasını beklerdim, eğer aynı tarz hack ile unutulan iki insanın olduğu yerde. İkinci seçenekten hoşlanıyorum, yapıyorum, gönderiyorum ve sonra bırakıyorum. Karşılaşabileceğim konu, bir LLC oluştururken yarı yolda olmamız, böylece oyunumuzu altında taşıyacak bir ismimiz olması. Her iki kullanım da% 50 oranında bir kursa sahip olacak. Ancak, sadece bitirebilir ve devam edebilirim. Proje büyük, bu bir süre olabilir.
Douglas Gaskell

20
Sen do not herhangi bir durum böyle bir kişiyle yasal olarak bağlayıcı bir iş ilişkisi girmek istiyorum altında.
gnasher729

3
@ douglasg14b öğretmek için bir junior getirmek .. zavallı çocuk. "Çok daha hızlı hızlanıp ürünü bitirmesine yardımcı olacağı için" deneyimli bir adam getirmenizi öneririm. Bakışlarını bitiş çizgisine koy - ya da ikiniz de bu hobide sonsuza dek çalışmayı mı düşünüyorsunuz? (iptal edilinceye kadar bunun gerçekleştiğini gördü)
gbjbaanb

Kesinlikle bitirmeyi planlıyorum. Yine de, ilk önce ele almamız gereken bir projenin çok büyük olduğuna inanıyorum. Basit bir tasarım olarak başladı, şimdi olduğu gibi ölçeğe yakın bir yerde olmaması gerekiyordu. Kapsamımızın sınırı sürekli olarak ortağım tarafından sürünen özelliklerle itiliyor, bunun için kısmen suçluyum çünkü bunun olmasına izin veriyorum ve hatta bazı özelliklerle aynı fikirdeyim. Kapsam, eğer yalnız bırakılırsa muhtemelen bir yıl içinde bitirme hedefine bakıyoruz. Neyse ki nasıl programladığımla, parçalar daha sonra kolayca çıkarılabilir ve başka projelere yerleştirilebilir.
Douglas Gaskell

4
Kodu size değil, projeye ait olarak düşünün. Ürünün ortak mülkiyetine sahipseniz, bir sonraki projeniz için tüm kodu yeniden kullanabilirsiniz. Neyin sahibi olduğuna dair bir fikriniz yoksa, şimdi bu tartışmayı yapın. İyi şanslar.
gbjbaanb

9

Bazıları birbirini dışlayan olsa bile işte bazı fikirler.

  • Ayrı kaynak sorumlulukları. A Modülünde ve onun B Modülünde çalışıyorsanız, farklı stillerinizle rekabet edebilirsiniz. Çalışma özelliklerini sık sık serbest bırakıyor mu? Kodunu sıfırdan yeniden yazması gereken bir noktaya mı ulaşıyor? Kodu modüllerinizden yeniden tanımlayın ve koduna dokunmayın,

  • En kötü kodunun bakımını yapsın. O başarılı bir şekilde yaparsa, korkunç bir görevden kaçındınız. O mümkün değilse acıyı hissedecektir.

  • Bir kullanıcı veya iş açısından düşünün. Bazı durumlarda yalnızca google veya Microsoft'un satın alabileceği uygun bir ürüne ihtiyacınız vardır. Diğer yandan pazara sürecek bir ürünü piyasaya sürüyorsunuz ve binlerce müşteriyi buggy veya hacklenmiş kodla desteklemek cehennem olacak. Kodunuz nükleer füzelerle dronları kontrol ediyorsa veya gençler için mutlu videolar çekiyorsa aynı değildir.

  • Sınıfları o yapıyor, testleri sen yapıyorsun. Testlerle yeniden düzenleme kodu daha kolay ve daha güvenlidir. Bu şekilde sadece Junit bar koduna bakmak zorunda kalmayacaksınız. Bu, A) Testleri programladığınızı, B) İş arkadaşınızın kodunun test edilebilir olduğunu varsayar. Kodlama aşamasında testleri yapmakta zorlanırsanız, ikincisi daha kötü olacaktır.

  • Eğitime veya etkinliklere birlikte gidin. Doğru yolu bilmediğinizde oldukça doğal olduğunu bildiğiniz tek yolu kullanın. Başkalarının kodunu görmek her şeyi çözmeyebilir, ancak denemeye zarar vermez.

  • Tamamlayıcı yönünüzü bulun. Yeniden düzenleme bazen eğlenceli olabilir. En azından işe yarayan şeyler yazarsa, yeniden düzenlemeyi yapabilirsiniz. Üretim kodunda bitmeyen çözümleri keşfetmek için çiviler yapabilir.

  • Kodu yeniden yazmak istemeyebilir ancak yeni kodu daha iyi yazmayı kabul edebilir. Yeniden yazmanın zor, sıkıcı ve işleri bozabileceğini biliyorum. Bazı kaliteli adaları büyütün. Bu şekilde işlerin nasıl yapılacağına dair iyi örneklere sahip olacaktır.

  • İzci kuralını kullanın . Üzerinde çalışmanız gerekmediği sürece dokunulmaz şeyler bırakmayın. Eğer bir modül yanlış yazılmışsa fakat çalışıyorsa ve değiştirmenize gerek yok ise öyle bırakın. Bir hatayı düzeltmeniz veya bir özelliği tamamlamanız gerekirse, onu biraz iyileştirin. Bir süre sonra değiştirdiğiniz sınıfların% 20'si zamanın% 80'ini geliştirir. Daha fazla kalite adaları.

İkinizi de tanımadan en iyi çözümün ne olduğunu öneremeyiz. İyi şanslar.


4

Tamam, işte muhtemelen sevmeyeceğiniz bir cevap.

Özelliği uygulamada başarısız olmadıkça kodu 'düzeltmeyin'.

İşte benim mantığım. Muhtemelen para kazanmaya çalışıyorsunuz. Para kazanmak için tamamlanmış özellikleri hızlı bir şekilde göndermeniz gerekir. 'İyi kodlanmış' bir bilgisayar oyunu için kimse size daha fazla para ödemez.

Çoğu şirket aynı problemi yaşıyor. Refactor mevcut kodu 'daha iyi' yapmak için, bazen hız veya güvenilirlik açısından objektif olarak daha iyi hale getirmek VEYA yeni özellikler yazmak için.

Zamanın% 99'u, basit maliyet avantajı analizinin sonucu olarak yeni özellikleri yazmayı seçtiler.


15
Bu olsa da, tüm "teknik borç" argümanı altında, değil mi? Bu yeni özelliği yazdığınızda (veya mevcut olanı değiştirdiğinizde), yeniden yönlendirme işleminize devam etseydiniz, üç kat daha uzun sürer ve on kat daha fazla hata üretiyor mu? Öyleyse, yeniden yapılanmayı atlamak belki yanlış bir ekonomiydi.
Ben Aaronson

1
Öyle düşünürdünüz, ancak birçok başarılı şirkette çalıştım ve ben (neredeyse) hiçbir zaman yeniden önceliklendirmeyi refactoring olarak görmüyorum. Benim sonucum, basitçe işe yaramadığı.
Ewan

Yeterince adil ve bu konuda çeşitli görüşler olduğuna eminim, bir şekilde ya da diğerinin cevabın önemli bir ihmali olduğunu söylemiyor gibiyim. Ayrıca yanlış olabilir ama söz konusu satır aralarını okuma, ben OP hakkında endişeli kötü kodu olabilir düşünüyorum yolu kod hakkınızdaki düşünme tür daha kötü.
Ben Aaronson

heh, evet! ama aynı zamanda değişiklik yapmanın maliyeti de çok yüksek gibi geliyor. Cevabımda 'Bu işte para için misin?' Hedefini vermeye çalışıyorum. cevap, artı olasılık dengesinin nerede olduğu konusundaki öznel görüşüm
Ewan

1
Bu, bazı durumlarda makul olabilir, ancak birinin "çalışma kodu" başka bir kişinin koduna 2 kat daha fazla zaman harcamasına veya sistemleri birlikte veya gelecekteki çalışmalara entegre etmesine neden oluyorsa, artık basit bir "gemi vs gemi değil" kararı değildir. Çok sayıda büyük ölçekli proje ölüyor, çünkü hızlı yapmak yerine doğru kararları veremiyorlar.
enderland

3

Şimdiye kadar cevapların hepsini seviyorum. Enderland en dan noktalarından birini alarak cevap :

Sinir bozucu birisiyle gönüllü olarak çalışmanın faydaları var mı?

Kod inceleme yığını değişimi için bu süreyi almak istiyorum . Kodunuzu profesyoneller tarafından eleştirilebileceğiniz harika bir yer. Ve dürüst olmak gerekirse, kod incelemelerinin birçoğu, katılımcılara, cevap verenlere ve uğrayan ve okuyanlara büyük ölçüde yardımcı olmaktadır. Profesyonel bir ortamda nadiren böyle yararlı yorumlar alırsınız (bu, ne sebeple olursa olsun çalıştığım yerlerde geçerli olabilir).

Tavsiyem biraz kodunuzu gözden geçirilmek üzere göndermektir. Bu adamın yanıldığını ispatlamak için cephane olarak kullanılmasını tavsiye etmem - onu kalbe alacağından şüpheliyim - ama hem yazdığınız hem de yazdığınız kod hakkında çok yararlı bilgiler edinebilirsiniz. En çok dövüşeceğiniz kod parçalarını göndermenizi tavsiye ederim. Her iki durumda da, ikiniz de bir dereceye kadar yanılıyorsunuzdur ve incelemeyi, adım atmak için üçüncü bir taraf bulmanın bir yolu olarak kullanabilirsiniz. Bu, birkaç şeyi başaracaktır:

  • Durumun duygusal geriliminden kopabilirsin.

  • Gerçek zamanlı profesyonel danışmanlık alırsınız. Öğrendiklerin için büyük bir destek.

  • Birisi sana hatalı olduğunu söyleyecek. Bu iyi, çünkü herhangi bir süre için programlama yapan herkes bunu duyacak. Çalıştığınız adam gibi kötü bir şekilde başa çıkabilir veya başa çıkmayı öğrenebilirsiniz.

Kod incelemelerini doğru şekilde kullanırsanız, bu son derece sinir bozucu kişiyle ilgilenerek kazanacağınız çok şey olduğunu düşünüyorum. Ve "bunu yapın, çünkü çoğu zaman doğru yoldur" yazan bir kitaptan veya web sitesinden çok daha etkileşimlidir.

Benzer şekilde, oyun geliştiricisi yığın değişimi var . İncelemek için kod göndermek için çok fazla bir yer değil, ancak uğraştığınız kavramları / fikirleri sormak için. Yine, bu yer katılan herkes için son derece faydalıdır.

Bu iki siteyi daha önce görmüş olabilirsiniz; Ben sadece senin aletinin bir parçası olduklarından emin olmak istedim.


2

Kulağa oldukça umutsuz geliyor. Muhtemelen pes eder ve senin gibi hissedersem devam edersem; kesinlikle uzaklaşmak için bir zaman geliyor ve orada olabilirsin.

Henüz çekip gitmeye hazır değilseniz, işleminizle ilgili daha iyi bir anlaşmaya varmak için bir yol bulmanız gerekir. Kodlama standartlarınız var gibi görünüyor, ancak üzerinde anlaşılan standartlar yok. Bir dahaki sefere bir kavşağa geldiğinde, bir dahaki sefere biraz kodla maymun yapmak istiyorsan ve arkadaşın yalnız bırakmak istiyorsa, aşağıdaki satırlar boyunca bir konuşma yapmak için ateş et:

douglas: Bunu değiştirmek istiyorum, çünkü tam burada, kurallarımızda.

dostum: Nasıl olduğu iyi.

douglas: Yani kuralları değiştirmemiz gerektiğini mi söylüyorsun?

dostum: Hayır, sadece nasıl olduğunu iyi düşünüyorum.

douglas: Peki kurallar neler?

dostum: Bilmiyorum - sen yazdın.

douglas: Hangi kuralları yazardın?

dostum: Ben kural yazmazdım. Bu zaman kaybı.

douglas: Öyleyse sadece kuralları kaldırmalı ve o zaman ne düşündüğümüzü yazmalıyız?

dostum: Bu saçmalık değil.

douglas: Mükemmel mi? İdeal mi

dostum: İşi halleder; Bir sonraki özelliğe geçelim.

douglas: Üzerinde anlaşabileceğimiz herhangi bir şey var mı, X'in iyi kod ve Y'nin de kötü kod olduğu?

dostum: Beni yalnız bırak; Sadece kodlamak istiyorum!

Bu iyi gitmedi değil mi? Sanırım sahip olduğum duygu senin ve Buddy'nin farklı şeyler istediği. Kabul edebileceğiniz bir şey varsa, harika; oradan başla ve üzerine inşa et. Ama istediğini istediğini kabul etmesini sağlayamazsın - istediğini istediğini istediğinden daha fazlasını yapabilirsin. Bu ortak arzuyu bulabilir ve oradan ortak bir anlaşmaya varırsanız, belki birlikte çalışabilirsiniz.

douglas: Ne istiyorsun?

dostum: Sadece kodlamak istiyorum.

douglas: Ben de kodlamak istiyorum ama kodumla gurur duymak istiyorum.

dostum: Kodumla gurur duyuyorum.

douglas: İşte gurur duyduğum bir fonksiyon - bunun hakkında ne düşünüyorsun?

dostum: Pekala, sorun değil, ama döngü içinde X'i yeniden hesaplamamalısınız; verimsiz.

douglas: Yani her zaman döngülerin dışındaki sabit değerleri hesaplamamız gerektiğini mi söylüyorsunuz?

dostum: Eh, hah!

douglas: Bunun kurallarımızda olması gerektiğini düşünüyor musunuz?

dostum: Tabii ki.

douglas: Tamam, yönergelerimize ekleyeceğim ve kodumu güncelleyeceğim ...

douglas: Şimdi nasıl?

dostum: Güzel.

Şimdi Buddy, yönergelere katkıda bulunuyor (ancak dolaylı olarak) ve bu nedenle, bir miktar sahiplenme hissi var. Belki - sadece belki - onları daha ciddiye almaya başlayacak. Sanırım kayrakları silme ve ilke olarak çoğunun Buddy'den gelmelerine izin vererek kurallara başlamalıyım. Devam et ve shit kodu yaz, böylece kurallara ekleme ihtiyacı hissedecek; Onlardan gelmelerine izin verin. Belki o zaman nedenini anlamaya başlar.

Fakat vazgeçip devam etmeyi tercih ediyorsanız - bu da fena bir seçenek olmayabilir.


2

Projeyi terk etmeye karar verdiğini varsayarsak:

  • Kodu çatallayın ve yeniden adlandırın, 'önce / sonra' portföy öğesi olarak kullanın
  • Amaç (esas olarak veya kısmen) programlamayı öğrenmek olduğundan ve bir şey öğrenmek zaten bildiğiniz bir şeyi yapmakta olduğu sürece 2-4x sürdüğü için, bu iş gerçekten boşa gitmez.
  • 'Batık maliyet eki' (öğrenmeden önce bir girişime yaptığınız yatırım kötü bir fikirdi) karar vermedeki en yaygın insan hatalarından biriydi
  • Arkadaşlığı sürdürmek için, kararınızı arkadaşlık kodlamasına göre öncelik sırasına koyunuz.

1

Projeyi tartışmalı bir şekilde terk etmelisin.

Bununla ilgili daha fazla bir şey bilmeden bize anlattıklarında, yaşadığınız sürtüşmenin deneyimle ilgili olduğunu tahmin ediyorum.

Bir BT uzmanı olarak mesleğe göre bir programcı olmasanız da, muhtemelen ilk kez doğru şeyleri yapmanın zor yolunu öğrendiniz, gelecekteki benliğinize referansınız geçmişte onu mahvettiğinizi ve öğrendiğinizi gösterir. değil.

2. sınıf CS öğrenciniz oldukça yetenekli olsa bile, muhtemelen bunu yapma perspektifinden yoksun (benden hoşlanıyorsanız, art arda :).

O , başarısızlıktan yara izlerini yakana kadar ya da istisnai mühendislik disipline sahip bir kültürde ya da her ikisinde de, bu tarzın izini sürene kadar işleri sabitlemenin değerine asla inanmayacaktır.

Bu kişi sizin programlama eşiniz olabilir , ancak proje eşiniz değil , bu yüzden bu oyunu bir eş proje olarak yapmak muhtemelen kaybedilmiş bir nedendir. Sadece gelecekteki maliyeti yemeye hazır değilseniz. Belki ilişki senin için yeterince değerlidir. Bu durumda, kendisini asmak için yeterli ipi verin ve o kişi sorunu kabul etmek zorunda kaldığında pisliği temizlemeye yardımcı olmak için adım atın.

Aksi taktirde kefaletle bir proje yapın ya da başından beri dinamik olan bir mentor / mentee projesi yapın.


1

Tüm harika cevaplara ek puan eklemek için:

  • Projeyi bitirmek için daha ne kadar çaba harcanacak? "Son% 10" u bitirmenin insanların beklediğinden çok daha uzun sürdüğünü unutmayın. Bu, test etme / test etme, kullanışlılık düzeltme, çeşitli hedef platformlarla başa çıkma, serbest bırakma, ... içerir. Eğer bir iOS oyunuysa, o zaman Apple'ın incelemesini imzalama ve onaylama kodu vardır. Açıkçası, terbiye ilk "% 90" kadar uzun sürebilir. Kod, önerdiğiniz kadar kötü ise, bu çok zor olacaktır. (Şimdi test etmeye başlayabilir misiniz?)
  • Gerçekçi olarak, insanların oyununuzu beğenme olasılığı nedir?
  • " Batık maliyet sezgisel " e dikkat edin . Bu 10.000 kod satırı yatırımını, büyük resmin ışığında, bitmiş bir ürüne bakarak ve aşırı iyimserlik olmadan değerlendirin.
  • 3 yıl daha sürerse devam edebilir misin? Siz ikiniz farklı gelişim stilleriniz var (iyi bir takım maçı değil). Sabrınızın sonuna yaklaşıyor gibisiniz ve devam ederseniz arkadaş kalmak zor olabilir.

3
Kodun% 90'ı çöp ise "son% 10" çok daha uzun sürer :-(
gnasher729

0

Kodunuzu doğru olduğunu düşündüğünüz şekilde yapmaya devam etmelisiniz, yorumlarınız ve bunun gibi ve kodun bir kopyasını çıkarmalısınız (kodunuzu değiştirmesi durumunda).

Kavga etmeyin, kızmayın, onun kötü kararlarını gördüğünüzde gülümseyin.

Sadece kullanıcı olarak şikayetçi, eğer çalışıyorsa şikayet etmeyin.

Asla pes etme, senden farklı, gerçek bir işte olacak insanlara alışmak önemlidir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.