あなたがやったことのないプログラミングタスクに直面したとき、何をしますか？

私は3か月前に.NET開発者としてキャリアを始めました。さまざまな技術、パターン、概念に関する長いトレーニングプランの後、私を監督していた開発者は、会社が扱う多くのプロジェクトの1つに参加する準備ができたと判断しました。

最終的にコーディングを開始できることを非常に楽しみにしています。私が参加したチームは、新しいプロジェクトから始めていたため、今のところかなり小さいです。これは、プロジェクトのライフサイクル全体に関わることができるので素晴らしいことです。これは、ASP.NET MVC / ASP.NET Web APIを使用し、フロントエンドでDurandalフレームワークと関連ライブラリを使用するWebベースのSPAプロジェクトです。

私の問題は、同僚と会議を行い、翌月のタスクと見積もりを確立した後、自分がタスクを実行できるかどうかわからない立場にいることです。

作成したタスクを一度も実行したことがないため、どのようにすればよいかわかりません。

たとえば、作成されたタスクの1つは、アプリケーション全体の一般的なエラー処理メカニズムの作成です。

彼がやったことのないタスクに直面したとき、通常どのように進めますか？

タスクを準備するためにできることとすべきことはいくつかあります。

• 問題について考え、いくつかの図を描きます。解決しようとしている問題が何であるかを確認してください。
• あなたがやろうとしていることについて研究をします。インターネットは貴重な情報源です。スタックオーバーフローを求めると言っているのではありません-他の人がどのようにあなたのような問題をすでに解決しているか、またはそれにどのようにアプローチしたかについて研究することを言っています。これがGoogleが思いついたものです：「システム全体の懸念としての例外処理」。個人的に、私は常に他人から学ぼうとしています。
• 最後に、これが最も重要かもしれませんが、チームの他の人々と話をして、何をすべきかについてより明確に指示します。私はいつも新しいエンジニアがプロジェクトのガイダンスを求めに来るのを楽しみにしています。

何かをする方法を知らなくても、本当に終わることはありません。毎日、私がこれまで取り組んだことのない問題に遭遇します。新しい問題を解決する方法を理解する能力を持つことは非常に重要です。古い問題でさえ、決して完全に古いものではありません。プログラミングでは、ほとんどの場合、新しい方法またはソリューションを新しい方法または異なる方法で動作させるための新しい工夫や要求があります。

これが私がエンジニアである理由です。私は新しいものを理解するのが大好きです。

新しいことを学ぶのをやめないでください。学習はあなたをより良くするものです。

完全な解決策はありませんが、役立つ可能性のあるものがいくつかあります。

• タスクを可能な限り最小のユニットに分解します。できることをするまでタスクを分解します。

• 目前の課題や問題を再度説明して、本当に理解できるようにしてください。その後、いくつかの分析を行い、繰り返します。

• 運動量を得るには単純すぎると思われる場合でも、最初に最も単純なタスクを選択します。「ハードワーク」が邪魔にならないように、最も難しいタスクを好む人もいます。私は、「最も簡単なタスク」が一般的にうまくいくことを発見しました。これは、勢いを得ようとしているだけであり、実際の勢いが出る前にプロジェクトが停滞する「最も難しい」リードを見てきました。

• 適切なタスクとアプローチを選択して開始するための助けを求めてください。

• 1〜2週間、一定の（理想的には毎日）フィードバックを提供できるメンターを探します。

• 多くの質問をしますが、チームメイトに礼儀正しくすることに焦点を合わせます。時間があるかどうかを常に確認し、その時間がないという通常の言語的および非言語的兆候に注意を払ってください。

• 発生している問題の実行リストを保持してから、毎日のスクラムで、または選択した定期的な時間に、他の人と一緒に問題を調べます。

• 最も基本的な質問をすることを恐れないでください。他人による仮定は挑戦するのが難しい場合がありますが、あなたが与えられたものを進めることができない場合、あなたは再び質問しなければなりません。

• 目的がわかっている場合は、行き詰まるまでできる限りの作業を行い、進行状況と質問をStack Overflowに投稿します。

もちろん、「一般的なエラーメカニズム」の書き方はわかりません。 いくつかの要件が定義されるまで、「一般的なエラーメカニズム」を記述する方法は誰も知りません。 このプロジェクトを開始するには、「一般的なエラーメカニズム」が何らかの形で必要であるという概念だけを持っているようです。

個人的に、私はこの概念を押し返します。実際のユーザー要件を実装する前に「一般的な」何かを書くことは、ほとんど常に時間の無駄です。また、汎用であるため、定義上、会社やアプリケーションに固有のものではないため、おそらくニーズの約95％を満たすものが既に入手可能です。

しかし、あなたは後輩なので、押し戻すことは素晴らしい考えではないかもしれません。そのため、「一般的なエラーメカニズム」が必要だと考える人々と話し、このメカニズムが提供することを期待しているサービスを見つける必要があります。次に、ネットを検索して、すでに記述されているもので十分かどうかを確認します。何かを見つけたら、単にそれを使用することを提案します。「一般的なエラーメカニズム」を求める人は誰でも、ここで発明されていないという悪いケースに苦しんでいる可能性が高いので、彼らはおそらく同意しないでしょう。

それが失敗した場合、彼の次のステップは、エラーメカニズムのインターフェイスを定義し、利害関係者によって承認されることです。その後、実装はおそらく簡単になります。

=================

PSプロジェクトを開始する方法は、アプリケーションモジュールに必要なすべての共通サービスを提供する「プラットフォーム」を作成することだと考えるプログラマーがいます。これは通常、無料ですぐに利用できるものを再発明するための、数か月にわたる些細な作業に委ねられます。使用可能なソリューションのパフォーマンス制限に達するまで、「プラットフォーム」サービスを作成する理由はありません。既存のAPIのラッパーを作成する理由もありません。継続的にリファクタリングすると、アプリケーションに必要な正確なラッパーが魔法のように表示されます。

スキル不足よりも不安に苦しんでいると思います。ある時点で、すべてが新しいものではなかったのですか？タスクを与えられて、ある程度それを解決できなかったことがありますか？あなたは物事を理解するために支払われます。

チームを活用する -優秀なチームであれば、助けを求めることができるはずです。最上級の人でさえ知らないことを知っていることがあります。助けを求めることは、弱点の兆候ではありません（質問サイトに走るだけです）。

検索 -一般的なエラー処理に関するウェブ検索で何も思いつかなかった？ソリューション全体が見つからない場合があります。とにかく作業を行い、アプリに適合させる必要があります。

プロトタイプ -タスクの視点を生産からプロトタイプに変更します。そこから何かを動かして構築するだけです。使用できるようになったら、それを実稼働として考え始めます。これで、タスクをどこから始めてもわからないものとして見ることができなくなります。

Get Over It-あなたがする方法を知っていることをするだけで退屈になります。また、同じことを何度も繰り返すことで、いくつかのソリューションを総当たり攻撃するというtrapに陥ります（繰り返しを好む場合は、組立ラインで作業を行ってください）。間違いを犯す準備をしてください。彼らはすべてを知っている、助けを求めたり、検索したりすることはないと言っている人は嘘をついています。

医者がいまだに「練習」しているという古い冗談です。彼らはすべての答えも持っていません。

あなたが百回前にやったことをしていないことを喜ぶ。ソフトウェア開発の喜びを見つけました（私にとっては、とにかく、YMMV）-異常な速度で高速道路を疾走しながら運転する方法を学びます。これは、優れた開発者が生き、優れているものです。

私の個人的なプロセスは次のようなものです。

• 研究。この問題、または同様の問題が以前に解決されたかどうか、どのように解決されたかを調べます。異なる言語やプラットフォームのソリューションに関する情報しか見つからない場合でも、非常に有益です。
• プロトタイプ。正しいことを行うための絶対的な最善の方法は、最初に間違ったことをすることです。あなたの研究に基づいて、あなたが行くようにすべてを構成するソリューションを構築します。補助的な要件を考慮して、主要な要件に適合するようにしてください。きれいにしたり、完璧にしたり、拡張可能にしたり、柔軟にしたり、パフォーマンスを向上させたりするのではなく、機能させるだけです。学んだ教訓-何が機能したか、何が機能しなかったか、潜在的な障害などをメモします。その後、コードを破棄します。時間がかかりすぎて愚か者を探すのが心配なら、自分の時間にこれをしてください。知識の面で個人的に利益をもたらします。
• 設計。外部の知識（研究）と個人の知識（プロトタイプの教訓）を組み合わせ、それを行う正しい方法と思われるものの設計を策定します。
• 協力してください。上級チームのメンバーを見つけ、提案された設計を見せ、フィードバックを得る。他の人に見せて、フィードバックをもらいましょう。デザインを改良します。
• 繰り返します。それでも解決策が不明な場合は、ピアレビューが反復サイクルの一部であることを確認してください。フィードバックのために、定期的に実装を上級チームのメンバーに提供してください。
• 幸せになります-あなたはあなたの知識とあなたのキャリアを進歩させました、そして、あなたはあなたが以前に何千回もやってきた退屈で退屈な何かの代わりに新しい何か面白いことをしなければなりません。次のプロジェクトをさらに大きな課題にしてください。

そして最後に、外観についてあまり心配しないでください。開発チームマネージャーとして、私たちが今やろうとしていることを既に知っていることを証明できる人よりも、必要なときに必要なことを何でも学ぶことができることを証明できる人が欲しいです。前者は、明日、来月、来年に何をするにしてもより便利です。