単独の開発者としての作業：コードを見直す

私は自分で作業する以外に選択肢がなく、自分の仕事を見渡したり、健全性をチェックしたり、アイデアをブレインストーミングしたり、ベストプラクティスについて話し合ったりするための適切な解決策を見つけることができません。

私はジェフ・アトウッドの記事で答えを得ると思った：プログラミングでは、One is The Loneliest Number、私はこのテーマで見つけることができる最高ですが、それは私の質問を繰り返したことが判明しました。

私はこのようなStack Exchangeサイトを知っており、Code Reviewは明らかに潜在的な答えですが、多くの人が理解するように、理想からは遠いです：

すべての落とし穴をリストすることはできませんが、多くの場合、質問を定式化して自己完結型の問題にまとめると、多くの作業が必要になります。それ以外の場合にかかっていたよりも時間。また、詳細を隠して明確に定義された質問をすることで、誰かがあなたが考えていなかった問題を見つける可能性を排除します。また、指を置くことはできませんが、自由な会話の応答性は、私が考えることのできるテキスト形式のインターネットディスカッションとは一致しません。最後になりましたが、明白な理由から、プロジェクト全体を世界中に投稿して、残りの永遠を探したいとは思いません。

私のコードを見直すためにコンサルタントにお金を払う以外の答えはありますか？

私はあなたの靴を履いていますが、簡単な解決策はないと思います。あなたのコードを調べるためにコンサルタントにお金を払うことは、お金を使う良い方法ではありません。あなたの問題があなたが孤独を感じ、プログラミングについて話す人がいないということであれば、私はあなたを助けることはできませんが、コードの品質を改善することに本当に興味があるなら、それを設定すること脇に置いて、1週間ほどで戻ってきます。コードが本当に悪い場合、それを理解することができず、理にかなったリファクタリングを開始できるため、明らかです。このプロセスを数回繰り返した後、コードを理解しやすくし、コードの品質が向上するコードパターンに気づき始めます。

私のコードを見直すためにコンサルタントにお金を払う以外の答えはありますか？

いや

私のアドバイスは、ローカルのdeveloper \ userグループに参加して、他の人とあなたのアイデアを話し合うことです。あなたのデザインについて話してください。特定の問題にどのように取り組んできたかを他の人に尋ねてください。

コードを見なくても設計を検証できれば、それで十分でしょう。

フィードバックを提供するのに役立つテスト駆動開発などのセルフチェック技術があります。実行が困難になった場合、アーキテクチャが正常に機能していない可能性が高いことがわかります。

質問を定式化し、自己完結型の問題にまとめることは、多くの場合、非常に多くの作業を必要とするため、十分に準備するまでに、他の方法で行うよりも長い時間で自分の質問に答えることができます。

問題が解決しました。改善するためにコードの各行ごとに外部フィードバックを行う必要はありません。道路の主要な分岐点で適切なサンプリングを行い、その間のポイントで慎重に自己チェックします。

チームで働いている誰かと同じ時間で、同じレベルの品質を単独で維持できるという考えを克服する必要があります。人々がチームで働く理由があります。良いニュースは、設計の決定に関して矛盾がないことです。悪いニュースは、設計の決定に関して矛盾がないことです。品質の維持に費やす余分な時間が、単独で作業することの利点によっていくらか相殺されることを願っています。

会議やローカルユーザーグループで可能な限り多くのネットワークを行うことをお勧めします。サニタイズされたコードスニペットをメールまたはimで何度も撮影する多くの開発者を知っています。いいえ、対面式の会話ではありません。コードをサニタイズするのは苦痛ですが、20秒のインスタントメッセージコードのレビューは、特に2番目の目が必死の場合は特に便利です。

私も同じような状況にあり、厄介な質問に対するフィードバックを得るためにStack Overflowに大きく依存しています。また、問題の説明を実際に書き留めなければならないため、答えがしばしば明らかになることもわかりました。ベストプラクティスの観点から、私は.Net開発者であり、ReSharperを使用して、作成中のコードに代わる優れたプラクティスの提案を提供します（これは無視することもありますが、少し面倒なことがあります）。もう1つの便利なツールは、静的コード分析を実行し、そのルールセットに一致しない問題を強調表示するFxCopです。

それ以外の場合は、現在の慣行を読んで最新の状態を保つのはあなた次第です。以下のようなI アルビンAshcraftのモーニングデュー新機能へと.NETの世界で改善されたリンクのため。

小さなユーザーグループを作成（または検索）することをお勧めします。コードを使用可能にし、全員がそれを機能させるためにコミットするようにします-毎日30分以上。

私の経験からの建設的なフィードバックは、開発の最初の数年間は非常に重要ですが、経験豊富な開発者がコードをレビューして基礎を築くことは必須ではありません。経験を積んだら、@ davidk01で提案されているアプローチ、つまりコードの品質を向上させるために定期的に独自のコードを確認することができます。

私はあなたの状況の詳細を知りませんが、私が今いるところには、インターンとして働き、何かを学ぶことに満足している経験豊かな学生に飢えています。

それらを処理し、これを教えることはあなたにとって余分な仕事に聞こえるかもしれませんが、私たちが最初に始めたとき、私たちはすべてそこにいたので、私たちは返済する番だと思います。

彼らは専門家ではなく、時には誤解を招くかもしれませんが、通常はすべてに挑戦し、アイデアに満ちており、コードのあらゆる詳細を守る必要がある議論に最適です。

すべての落とし穴をリストすることはできませんが、多くの場合、質問を定式化して自己完結型の問題にまとめると、多くの作業が必要になります。それ以外の場合にかかっていたよりも時間。

投稿した質問の75％以上についても同じことを経験しています。

しかし、それはそうすることを気にしないという議論ではありません。これは実質的にゴム製のアヒルのデバッグです。あなたはあなたの質問に答えて現れるかもしれないと思う質問に対する答えを見つけています。つまり、さまざまな人々の観点から問題について考えているということです。つまり、考えられるすべての方向から問題について考えているということです。これが欠陥を見つける最良の方法です。

せいぜい、ここで答えを考えることは明らかにできないことが最終的に証明されています。「最悪」で、あなたはあなた自身の質問に答えることになります。これはまったく悪くないので、引用符に注意してください。時間が少し非効率だったかもしれませんが、問題をゆっくりと解決する方が、問題に取り組むことをすぐに決定するよりも優れています 最終的に問題を解決するのが速くなります。

適例：

私が駆け出しの開発者だったとき、私は何度もASP.Netのerorページに対処しました。何が悪いのかを理解するために、メッセージをGoogleに送る必要がありました。適切な解決策を得るまでに数時間かかることがありました。私は基本的に本のすべての間違いを犯し、その後問題をデバッグしなければならない結果に対処しなければなりませんでした。

さて、エラーがポップアップしたとき、私はすでに問題の原因となっている可能性のある「通常の容疑者」を知っています。「通常の容疑者」の私の精神的なリストは、私のキャリアの中で最も問題を抱えてきた問題に効果的に基づいています。何時間ものグーグルの時間効率の悪い脚の仕事を最初にやらなければ、私はこのメンタルリストを作成したことはなかっただろう。しかし、私はその精神的なリストを手に入れたので、トラブルシューティングがかなり速くなりました。

また、指を置くことはできませんが、自由な会話の応答性は、私が考えることのできるテキスト形式のインターネットディスカッションとは一致しません。

私はここでいくぶん同意しません。あなたはインターネット通信の反応が鈍いのは正しいですが、これはあなたにとって悪いことであると（私の意見では）間違っています。

一人の開発者として、あなたはゴム製のアヒルのデバッグに依存するでしょう。RDDを機能させるための重要な要素は、ゴム製のアヒルがあなたのために持っているかもしれない質問を予想することです。ゴム製のアヒルが実際に言っていることに頼ることはできません。

低速のメッセージングシステム（StackOverflowに投稿したり、手紙を書いて通信したりする）を扱う場合、最初から正しく動作するようにインセンティブが与えられます。間違いを修正する必要があるため、時間がかかり骨の折れるプロセスになるからです。
それに比べて、高速メッセージングシステム（会話、インスタントメッセージング）では、すぐに何かを修正できると考えてください。何かを迅速に修正する能力により、人々はそれが正しいことを保証するための動機付けが少なくなります。

適切な4つのケース：

• 開発者として自分の個人的な分析/仕事リストを作成するとき、私はまだペンと紙を使用しています。私の心は「後でこれを簡単に修正できる」と考えているので、メモを入力しているときの仮定と虚偽を無視していることに気付きました。ただし、紙に書いたものを修正しなければならないのは面倒です。線を消して線の間を書く必要があります。紙に書くと、書く前に自分で事実を確認できます。これは、バグを生成するコードを作成する前に、多くの誤解を早期に発見します。
• 私の祖母は秘書（タイプライターの時代）でした。正式な文書にタイプミスをすることは、ページ全体をもう一度入力することを意味しました。私の叔母は秘書（ワードプロセッサの年齢）です。彼女は自動スペルチェッカーに頼ることができ、ミスは簡単かつ最小限の労力で修正できます。当然のことながら、私の祖母は私の叔母に比べて入力ミスやスペルミスをかなり少なくしています。
• ビデオゲームは、以前はカートリッジに印刷されていました。リリース後にバグを修正することはほとんど不可能でした。すべてのカートリッジを再印刷して、すべてのベンダーに配布し、ベンダーが何らかの形で既にゲームを購入した顧客と連絡を取ることを望んでいます。それは何トンもの費用がかかり（物理的な生産コストの2倍）、それでも一部の顧客には届きません。現在、インターネットパッチの時代には、ゲーム開発者はゲームをテストするための投資をかなり少なくしており、リリース日のバグを回避できることが示されています。間違いを犯した場合の影響は、すべての可能性をテストするよりも、事実の後にいくつかの問題を修正した方がよい点まで最小限に抑えられます。 発生する可能性のあるエラー。
• 私は以前はエレベーターのない3階建てのアパートに住んでいましたが、建物から1つか2つの通りを頻繁に駐車しなければなりませんでした。私は自分の車から何かを取り忘れることはほとんどありませんでした。今、私は車を運転している家に住んでいます。いつも車から物を取り出すのを忘れています。

ここでの根底にある考え方は、困難な交換システムが人々に正しい、事実を確認した交換を行うよう奨励するというものです。罰の厳しさ（=困難な修正プロセス）は、間違いを犯さないことを教えてくれます。

また、詳細を隠して明確に定義された質問をすることで、誰かがあなたが考えていなかった問題を見つける可能性を排除します。

MCVEを作成するときは、作成して質問に投稿するだけではいけません。問題を特定できるように、まず自分で作成する必要があります。そして、問題をこれ以上減らすことはできないと思うと、それでも原因がわかりません。StackOverflowの有効な質問があります。

適例：

サンドボックスと呼ばれるシンプルなコンソールアプリで2つ目のVisual Studioを常に実行しています。技術的な問題に遭遇したときはいつでも、問題のコードをサンドボックスにコピーし、それをいじり始めます。

• この設定を変更するとどうなりますか？
• コードを短くしても問題を再現できますか？
• 問題を再現することを可能/不可能にする設定はどれですか？

ケースの90％で、サンドボックスが周囲のコンテキスト（または、たとえば、コードのさまざまな部分に由来する値に関する不確実性）に気を取られることなく、問題のコードを見るのに役立ったため、問題の原因を見つけました。

他の10％のケースでは、問題を再現するための最小限のコードが残っています。これは、StackOverflowに投稿する完璧なサンプルスニペットとして機能します。

最後になりましたが、明白な理由から、プロジェクト全体を世界中に投稿して、残りの永遠を探したいとは思いません。

すでにMCVEを持っている場合、個人（または会社）の情報にあまり多くの情報を含めるべきではありません。そうした場合、コードは最小限であるため、より基本的なfoo / bar / bazの例に簡単に名前を変更できます。