友人との小さなプロジェクトをいつ中止するかを決定する方法に影響を与える要因は何ですか？
私は最近、厳しい状況に陥っています。プログラミングの仲間と一緒にゲームを8か月近く続けています。私たちは2人とも昨年8月頃にプログラミングを始めたばかりで、2年目のCSの学生であり、私は業界別のITサポート技術者であり、多数の書籍とオンラインサブスクリプションを持つ独学のプログラマーです。
私が常に目にしている問題は、コードのチャンクを書き出すと、コードが少しハッキングされ、多くの失敗が発生すること、そしてそれが私たちにとってまったく新しいコンセプトである場合、素朴なソリューションでいっぱいであるということです。これは問題ありません。学習中です。最初のパスまたは2番目のパスで両方のコードが少しハッキングされることを期待しています。ハッキングされた動作を実際に修正してリファクタリングすることになると、問題が発生します。
私のパートナーは、彼の新たに石畳になった行動を保持し、それが機能し始めた瞬間にエラーを表示することを露骨に拒否します。構造の一部からほぼ完璧を主張しているのに、コメントや適切に名前が付けられたメソッドとフィールドがあったとしても、使用することすらできません。どんなに頑張っても、完全に壊さずに動作のさらなる変更や拡張を妨げる明白な欠陥を彼に見せることができず、それらが非常に密に結合されているものはすべて同じクラスにある可能性があります。ハッキングされたソリューションは、常にハッキングされたままであり、十分に考え抜かれた設計は、最初に着想されてテストされたときの方法を維持します。
私は自分でコードを書くのと同じくらい多くの時間を新しいコードのベビーシッターに費やしています。私のパートナーは今夜それを失い、ベンチマークにかかわらず、一般的な慣行にかかわらず、反駁できない証拠にかかわらず、彼のコードは彼が最初に作成した方法のままであることを明らかにしました。あなたが何かをしたくない理由について本全体が書かれていても、彼はそれが誰かの意見であると主張して彼らの正当性を認めることを拒否します。
私はこのプロジェクトに既得権を持っていますが、パートナーと一緒に仕事を続けることができるかどうかはわかりません。私には3つの選択肢があるようです。
- コンパイルのポイントを超えてコードベースが機能することを気にするのをやめ、かろうじて足りない動作を維持して解析しようとすることだけに対処します。物事がひどく壊れ始めたら、彼はそれを理解し、根本的に欠陥のあるデザインの上に絆創膏を置く以上のことをしようとするでしょう。
- 10年前に他のはるかに有能な個人によって考え出された問題についての無限の議論を続けてください。
- このプロジェクトのプログラミングをやめ、私のコードの10,000行近くを放棄し、数えきれないほどの時間を設計に費やして、自分で新しいプロジェクトを見つけてみてください。
この人と一緒にこのプロジェクトを続ける価値があるかどうかを判断するには、どのようなアプローチを取ることができますか？または、私の決定に影響を与える要因は何ですか？私たちはたくさんのコードを書いてきましたが、必要がない限りこれをあきらめたくありません。
出荷された不完全なコードは、出荷されないホワイトボード上の完全なコードよりも優れています。
言われていること...
より多くの経験をお持ちの方、または同様の状況にあった方。あなたは何をした？私は何を勧めますか？
私は以下を検討します。
- このプロジェクトの目的は何ですか？楽しい？お金？学ぶために？
- あなたは実際にこの目的を達成していますか？
- この人は実際にあなたがあなたの目標をよりよく達成することを可能にしていますか？
- 実際に発送するまでどれくらいかかりますか？
- これらの問題が起動を妨げますか？それとも個人的なプライドの問題なのでしょうか？
- それがいらいらしているときに、自発的に誰かと一緒に働くことの利点はありますか？
このプロジェクトのプログラミングをやめ、私のコードの10,000行近くを放棄し、数えきれないほどの時間を設計に費やして、自分で新しいプロジェクトを見つけよう
上記を考慮して、必要な追加作業を検討してみてください。
あなたはあなたの優先順位を理解し、この人との作業に関連する問題がそれに値するかどうかを判断する必要があります。これはわかりません。
私のパートナーは今夜それを失い、ベンチマークにかかわらず、一般的な慣行にかかわらず、反駁できない証拠にかかわらず、彼のコードは彼が最初に作成した方法のままであることを明らかにしました。
あなたはあなたがこのタイプの人と一緒に働きたくないことを知っています。
あなたはおそらくプログラミングを学び、工芸自体に優雅さを見つけたいので、このようなプロジェクトをやっています。
これは文化的なものかもしれません。一部の文化では、あなたが間違いを犯したことを認めることは前代未聞であり、誰かが間違いを認めたことを頼むことは、あなたができる最も残酷なことです。そういう状況なら逃げろ。
非常に賢い人々との私の経験では、彼らがしていることは完璧ではないことを彼らに言うと、彼らは（1）彼らがしていることが実際に正しい理由をあなたに正しく簡単に理解できるようにします（2）伝えます彼らはそれが間違っていることを知っているが、優先順位のためにそれを修正する時間がない、または（3）指摘して修正してくれてありがとう。
学ぶことを拒否することは、ソフトウェア開発者が持つことができる最悪の属性についてです。彼に任せなさい。彼にとってあなたの時間を無駄にするには、人生は短すぎて貴重です。
おそらく最も簡単な方法は、他の誰かをプロジェクトに参加させることです。あなたが間違っていて、彼のコードベースがあなたにとってはあまりにも賢いか、またはあなたが正しく、誰にとってもあまりにも賢いかのどちらかです。あなたはすぐにそれを見つけて、それがゴミ、複雑な、ジュニアプログラマーレベルのコードであることが判明した場合にバックアップを取得します。
一方、実用的な製品は、何年にもわたって微調整されたエレガントで明確なコードに値します。ゲームを作り、それを出荷し、それから立ち去ります-彼を維持してv2で作業しないでください。
相互に排他的であるとしても、ここにいくつかのアイデアがあります。
個別のソースの責任。モジュールAを担当し、モジュールBを担当する場合は、さまざまなスタイルと競うことができます。彼は頻繁に機能をリリースしていますか？彼はコードを最初から書き直す必要があるところまで到達しましたか？モジュールからコードをリファクタリングし、彼のコードに触れないでください。
彼に最悪のコードのメンテナンスを任せましょう。彼がそれをうまくやれば、あなたはひどい仕事を避けました。彼ができない場合、彼は痛みを感じるでしょう。
ユーザーまたはビジネスの観点から検討してください。場合によっては、GoogleまたはMicrosoftが購入する可能性のある実行可能な製品のみが必要です。他の場合、製品を市場に送り出し、バグのあるまたはハッキングされたコードで何千ものクライアントをサポートするのは地獄です。あなたのコードが核ミサイルでドローンを制御したり、ティーンエイジャーに楽しいビデオを作ったりする場合は同じではありません。
彼はクラスをやって、あなたはテストをします。テストを使用してコードをリファクタリングする方が簡単で安全です。このようにすると、JUnitバーだけでコードの内部を調べる必要がなくなります。これは、A）テストをプログラミングしていること、B）同僚のコードがテスト可能であることを前提としています。コーディング段階でテストを構築するのが難しい場合、後の方が悪くなります。
トレーニングやイベントに一緒に行きます。正しい方法がわからない場合は、ごく自然な方法を使用してください。他の人のコードを見てもすべてが解決されるわけではありませんが、試しても害はありません。
あなたの補完的な強みを見つけてください。リファクタリングは楽しいこともあります。彼が少なくともうまくいくことを書いたなら、あなたはリファクタリングをするかもしれません。彼は spikes を実行して、プロダクションコードで終了しないソリューションを探索できます。
彼はコードを書き直したくないかもしれませんが、新しいコードをよりよく書くことに同意するかもしれません。リライティングは難しく、つまらないものであり、物事を壊す可能性があることを理解しています。質の高い島を育てます。このように彼は物事を行う方法の良い例があります。
ボーイスカウトルール を使用します。あなたがそれに取り組む必要がない限り、物事は手付かずのままにしてください。モジュールが上手く書かれていないが動作し、変更する必要がない場合は、そのようにしてください。バグの修正や機能の完成が必要な場合は、少し改善してください。しばらくすると、80％変更したクラスの20％が改善されます。質の高い島々。
私たちはあなたの両方を知らない限り、最善の解決策を提案することはできません。幸運を。
わかりました、これはおそらくあなたが気に入らない答えです。
機能の実装に失敗しない限り、コードを「修正」しないでください。
ここに私の推論があります。あなたはおそらくお金を稼ごうとしています。お金を稼ぐには、完成した機能をすばやく出荷する必要があります。 「適切にコード化された」コンピュータゲームにこれ以上お金を払う人はいません。
ほとんどの企業が同じ問題を抱えています。既存のコードをリファクタリングして「改善」し、速度や信頼性の面で客観的に改善することもあります[〜＃〜] or [〜＃〜]新しい機能を記述します。
単純な費用便益分析の結果、99％が新機能の作成を選択する。
私はこれまでのすべての答えが好きです。エンダーランドの answer からポイントの1つを取る：
それがイライラするときに自発的に誰かと一緒に働くことには利点がありますか？
この時間をかけてプラグイン コードレビュースタック交換 に接続したいと思います。これは、プロがコードを批評できるすばらしい場所です。そして正直なところ、そこにあるコードレビューの多くは、関係者（質問者、回答者、そしてつまずいて読んだ人）にとって非常に役立ちます。あなたはめったにそのような有用なレビューをプロの設定で得ることはありません（私が何らかの理由で働いた場所ではそうかもしれません）。
私のちょっとしたアドバイスは、レビューのためにコードの一部を投稿することです。私はそれを弾薬として使用して、この男が間違っていることを証明することはお勧めしません。私はあなたたち2人が最もよく争うコードを提出することをお勧めします。おそらく、どちらもある程度は間違っており、客観的な第三者に介入する方法としてレビューを使用できます。これにより、いくつかのことが実現します。
あなたは状況の感情的な緊張から切り離すことができます。
あなたはリアルタイムの専門家の助言を得ます。あなたが学んでいることへの大きな後押し。
誰かがあなたが間違っていると言うでしょう。これは良いことです。何時間もプログラミングをする人なら誰でもこれを聞くでしょうから。あなたはあなたが一緒に働いているこの男のようにそれをうまく扱うことができません、またはあなたはそれを扱うことを学ぶことができます。
コードレビューを正しい方法で使用すると、この非常にイライラする人に対処することで多くを得ることができると思います。また、「これを行うのは、ほとんどの場合正しい方法だから」という本やウェブサイトよりもはるかにインタラクティブです。
同様に、 ゲーム開発者スタック交換 があります。レビューのためにコードを投稿する場所ではなく、苦労している概念/アイデアについて尋ねる場所です。繰り返しますが、その場所は関係者全員にとって非常に役立ちます。
あなたはこれらのサイトの両方を見たことがあるかもしれません。それらがあなたのツールセットの一部であることを確認したかっただけです。
プロジェクトを中止することにしたと仮定します。
- コードをフォークしてリファクタリングし、「前/後」のポートフォリオ項目として使用する
- 目標は（主にまたは部分的に）プログラミングを学ぶことであり、何かを学ぶことはすでに知っていることをするのに2〜4倍かかるので、その仕事は本当に無駄ではありません。
- 「沈没費用の付加」（悪い考えを知る前にベンチャーに行った投資）は、意思決定における最も一般的な人的ミスの1つです。
- 友情を維持するには、コーディングよりも友情を優先するように決定を組み立てます
それはかなり絶望的に聞こえます。もしあなたがそうしているように感じたら、私はおそらくあきらめて次へ進むでしょう。必ず立ち去る時が来て、あなたもそこにいるかもしれません。
まだ離れる準備ができていない場合は、プロセスについてよりよく合意する方法を見つける必要があります。コーディング標準はあるようですが、合意された標準はありません。次に交差点に来たとき、次にコードのコードを使って猿になりたいとき、そしてバディがそれを放っておいてほしいときは、次の行に沿って会話をします。
ダグラス：変更したいのは、Xがガイドラインでここにあるからです。
バディ：それは元気です。
ダグラス：では、ガイドラインを変更すべきだと言っているのですか？
相棒：いいえ、私はそれがどのように元気であると思います。
ダグラス：では、ガイドラインは何ですか？
バディ：わかりません-あなたが書いたものです。
ダグラス：どんなガイドラインを書けますか？
バディ：私はガイドラインを書きません。時間の無駄です。
ダグラス：それで、私たちはガイドラインを捨てて、その時に私たちが考えているどんながらくたを書いてもいいですか？
相棒：これはくだらないことではありません。
ダグラス：それは完璧ですか？理想ですか？
相棒：それは仕事を成し遂げる;次の機能に移りましょう。
ダグラス：Xは良いコードでYは悪いコードだという点で同意できることはありますか？
相棒：一人にしてください。コーディングしたいだけです！
まあ、それはうまくいきませんでしたね？私はあなたとバディが違うものを望んでいるという感じがあると思います。同意できることがあれば、すばらしいです。そこから始めて、それに基づいて構築します。しかし、あなたが彼にあなたが欲しいものを欲することに同意させることはできません-あなた自身が彼が欲しているように思われるものを欲しがらせることができる以上に。その共通の欲求を見つけ、そこから共通の合意に達した場合、おそらくあなたは一緒に働くことができます。
ダグラス：何が欲しい？
バディ：コーディングしたいだけです。
ダグラス：私もコーディングしたいのですが、自分のコードに誇りを感じたいです。
バディ：私は自分のコードに誇りを持っています。
ダグラス：ここに私が誇りに思っている関数があります-それについてどう思いますか？
buddy：まあ、大丈夫ですが、ループ内でXを再計算すべきではありません。それは非効率的です。
ダグラス：では、ループの外では常に定数値を計算するべきだと言っているのですか？
相棒：まあ、まあ！
ダグラス：それは私たちのガイドラインにあるべきだと思いますか？
相棒：もちろん。
ダグラス：OK、それをガイドラインに追加し、コードを更新する...
ダグラス：調子はどう？
相棒：結構です。
現在、バディはガイドラインに（間接的に）貢献しています。そのため、彼は少し所有感を持っています。たぶん-たぶん-彼はそれらをより真剣に取り始めるでしょう。スレートを一掃してガイドラインを最初からやり直し、最初はほとんどまたはすべてがバディから来るようにしたいと思います。先に進み、たわごとのコードを書いて、ガイドラインに追加する必要があると感じます。それらを彼から出させなさい。多分それから彼はそれらの理由を理解し始めるでしょう。
しかし、あきらめて先に進むのであれば、それもそれほど悪い選択肢ではないかもしれません。
すべての優れた回答にポイントを追加するには：
- プロジェクトを完了するのにどれだけ多くの努力が必要ですか？ 「最後の10％」を完了するには、人々が予想するよりもはるかに長い時間がかかることに注意してください。これには、プレイテスト/チューニング、使いやすさの修正、さまざまなターゲットプラットフォームへの対応、リリースなどが含まれます。iOSゲームの場合は、コード署名とAppleのレビューを通過します。正直なところ、最初の「90％」と同じくらいの時間がかかります。そして、コードがあなたが提案するほど悪いなら、それはさらに難しいでしょう。 （今すぐテストを開始できますか？）
- 現実的に、あなたのゲームを人々が楽しむ可能性はどのくらいありますか？
- " sunk cost heuristic "に注意してください。全体像に照らして、最終的な製品を振り返り、過度の楽観的な見方をせずに、10,000のコードライン投資を評価します。
- さらに3年かかるとしたら続けられますか？ 2人は異なる開発スタイルを持っています（チームマッチとしては良くありません）。我慢の終わりが近づいているように聞こえますが、このまま続けると、友達でいることは難しいかもしれません。
tl; drプロジェクトは間違いなく断念すべきです。
これについてこれ以上何も知らずに、あなたが私たちに言ったと思いますが、私はあなたが経験している摩擦は経験に関連していると推測します。
あなたはITプロフェッショナルとしての職業ではプログラマーではありませんが、おそらく最初から正しいことを行うための困難な方法を学んだはずですが、将来の自分への言及は、過去に彼を騙して学んだことを示していますしない。
あなたの2年目のCS学生は、たとえ才能があっても、おそらくそれをしたという見方に欠けています（あなたが私のようであれば、繰り返し:)。
彼/彼女はするでしょう決して彼/彼女がそうすることの失敗から火傷を負うまで、または卓越したエンジニアリング規律のある文化、またはその両方にメンターされるまで、あなたが物事を修正することの価値を本当に信じます。
この人はmayはあなたのプログラミングピアですが、-notはあなたのプロジェクトピアです。そのため、このゲームをピアプロジェクトとして実行することは、おそらく失われた原因です。あなただけの将来のコストを食べる準備ができていない限り。多分関係はあなたにとって十分に価値があります。その場合は、首を吊るすのに十分なロープを裾に付け、その人が問題を認めざるを得なくなったときに混乱を片付けるために足を踏み入れます。
それ以外の場合は、仲間と保釈してプロジェクトを実行するか、最初から動的なメンター/メンティープロジェクトを実行します。
コメントなどを含めて、コードを自分の考えている方法で実行し続け、コードのバージョンのコピーを作成する必要があります（コードが変更された場合に備えて）。
戦わないでください。怒らないでください。彼の悪い決断を見て、ただ笑ってください。
それが機能している場合は文句を言わない、ユーザーとしてのみ文句を言う。
あきらめないでください。実際の仕事で起こる、あなたとは違う人に慣れることが重要です。