一度も行ったことのないプログラミングタスクに直面した場合の対処方法
3か月前に.NET開発者としてキャリアをスタートし、さまざまなテクノロジー、パターン、コンセプトに関する長いトレーニング計画を経て、私を監督していた開発者は、会社が扱う多くのプロジェクトの1つに参加する準備ができていると判断しました。
ようやくコーディングを始めることができて、とても興奮しています。私が参加しているチームは、新しいプロジェクトから始めていたので、今のところかなり小さいです。プロジェクトのライフサイクル全体に関わることができるので、素晴らしいことです。これは、ASP.NET MVC/ASP.NET Web APIを使用し、フロントエンドでDurandalフレームワークと関連ライブラリを使用するバッキング付きのWebベースのSPAプロジェクトです。
私の問題は、同僚とのミーティングがあり、次の月のタスクと見積もりを確立した後、自分がタスクのいずれかを引き受けることができるかどうかわからないという立場にいるということです。
作成したタスクを一度も実行したことがなく、どうすればよいかわかりません。
たとえば、作成されたタスクの1つは、アプリケーション全体の汎用エラー処理メカニズムを作成することです。
彼がこれまでに行ったことのない仕事に直面したとき、人は通常どのように進みますか？
タスクの準備をするためにできることとすべきことはいくつかあります。
- 問題について考え、いくつかの図を描きます。解決しようとしている問題が何かを知っていることを確認してください。
- あなたがやろうとしていることを研究してください。インターネットは貴重な情報源です。 Stack Overflowに質問するのではなく、他の人があなたのような問題をどのように解決したか、またはそれに対処したかを調査することを言っています。これがグーグルが思いついたものです "システム全体の懸念としての例外処理" 。個人的に、私はいつも他人から学ぶようにしています。
- 最後に、これが最も重要なことかもしれませんが、チームの他のメンバーに話し合って、何をすべきかについてより明確に説明し、指示を得ます。新しいエンジニアがプロジェクトのガイダンスを求めてくるのをいつも見たいです。
何かをする方法を知らないことは、本当に終わりません。毎日、これまで取り組んできたことのない問題に直面しています。新しい問題を解決する方法を理解する能力を持つことは非常に重要です。古い問題でさえ完全に古いわけではありません。プログラミングでは、ほとんど常に新しいひねり、またはソリューションが新しい方法や異なる方法で機能することへの要求があります。
これが私がエンジニアである理由です。新しいものを見つけるのが大好きです。
新しいことを学ぶのをやめないでください。学習はあなたをより良くするものです。
完璧な解決策はありませんが、役立つかもしれないいくつかのこと：
タスクを可能な限り最小の単位に分解します。できることになるまで、それらを分解します。
差し迫ったタスクまたは問題を再確認して、本当に理解できるようにします。次に、いくつかの分析を行い、繰り返します。
単純すぎるように見えても、最初に最も単純なタスクを選択してください勢いをつけるために。一部の人々は最も難しい仕事を好むので、「ハードワーク」は邪魔になりません。 「最も単純なタスク」は、勢いをつけようとしているだけなので、通常はうまく機能することがわかりました。また、実際に勢いがつく前に、「最も難しい」プロジェクトが停止することに気づきました。
開始するための適切なタスクとアプローチの選択について支援を求めます。
1〜2週間、一定の（理想的には毎日）フィードバックを提供できるメンターを探します。
多くの質問をしますが、チームメイトに礼儀正しくなることに焦点を当てます。彼らに時間があるかどうかを常に尋ね、彼らが時間がない彼らの通常の口頭および非口頭の兆候に注意を払います。
発生している問題の実行中のリストを保管し、毎日のスクラムまたは選択した定期的な時間に、他の人と一緒に問題を検討します。
最も基本的な質問をすることを恐れないでください。他人の仮定に挑戦するのは難しいかもしれませんが、与えられたものを続行できない場合は、もう一度質問する必要があります。
目的がわかっている場合は、行き詰まるまでできる限りのことを行ってから、進捗状況と質問をStack Overflowに投稿してください。
もちろん、「一般的なエラーメカニズム」の書き方はわかりません。 いくつかの要件が定義されるまで、「一般的なエラーメカニズム」の記述方法は誰にもわかりません。このプロジェクトを開始するには、「一般的なエラーメカニズム」が何らかの形で必要であるという考えがあるだけのようです。
個人的に、私はこの考えを押し戻します。実際のユーザー要件を実装する前に「一般的な」何かを書くことは、ほとんど常に時間の無駄です。そして、それはgenericであるため、定義上、会社またはアプリケーションに固有ではないので、おそらく約95％を満たしている何かがすでに利用可能です。ニーズ。
しかし、あなたはジュニアメンバーなので、プッシュバックするのは良い考えではないかもしれません。したがって、「一般的なエラーメカニズム」が必要だと思う人と話し、このメカニズムが提供することを期待しているサービスを見つける必要があります。次に、ネットを検索して、すでに書かれたもので十分かどうかを確認します。何かを見つけた場合は、単にそれを使用することを提案してください。 「一般的なエラーメカニズム」を要求する人は誰もがここで発明されていないという悪いケースに苦しんでいるため、彼らはおそらく同意しないでしょう。
それが失敗した場合、次のステップは、エラーメカニズムのインターフェースを定義し、それを関係者に承認してもらうことです。その後、実装はおそらく簡単になります。
=================
追伸プロジェクトを開始する方法は、アプリケーションモジュールが必要とするすべての一般的なサービスを提供する「プラットフォーム」を作成することであると考えるプログラマーもいます。これは通常、数か月間の簡単な作業から、すでに無料ですぐに利用できるものを再発明します。利用可能なソリューションのパフォーマンス制限に達するまで、「プラットフォーム」サービスを作成する理由はありません。また、既存のAPIの周りにラッパーを作成する理由もありません。継続的にリファクタリングすると、アプリケーションに必要な正確なラッパーが魔法のように表示されます。
あなたはスキル不足よりも不安に苦しんでいると思います。ある時点で、すべてが新しいものではなかったのですか？タスクを与えられ、ある程度解決できなかったことがありますか？あなたは物事を理解するために支払われます。
チームを活用する-良いチームであれば、助けを求めることができるはずです。最上級の人でさえ知らないことを知っているでしょう。助けを求めることは弱さを示すものではありません（質問サイトに出くわすだけです）。
検索-一般的なエラー処理に関するウェブ検索は何も思いつきませんでしたか？ソリューション全体が見つからない場合があります。それに取り掛かって、とにかくアプリにフィットさせる必要があります。
プロトタイプ-タスクの視点を本番からプロトタイプに変更します。何かを動かして、そこからビルドするだけです。使用できる状態になったら、それをプロダクションとして考え始めます。これで、タスクをどこから始めればよいかさえわからないものとして見ることはありません。
それを乗り越える-あなたがやる方法を知っていることをすることだけが退屈になるでしょう。また、同じことを何度も繰り返すことによって、いくつかの解決策を強引に強制するという罠にあなたを導きます（繰り返しが好きな場合は、組立ラインで作業してください）。間違いをする準備をしてください。すべてを知っていて、助けを求めたり、検索をしたりしない、と言っているのは嘘をついているだけです。
それは医者がまだ医学を「練習している」という古い冗談です。彼らはすべての答えも持っていません。
あなたが以前に100回やったことをしていないことを喜んでください。あなたはソフトウェア開発の喜びを見つけました（とにかく、YMMV）-高速道路を驚異的な速度で疾走しながら運転する方法を学びます。これは、優れた開発者が生きて得意とすることです。
私の個人的なプロセスは次のようなものです：
- 研究。この問題または同様の問題が以前に解決されたかどうか、およびその方法を確認してください。異なる言語またはプラットフォームのソリューションに関する情報しか見つけられない場合でも、それは非常に有益です。
- プロトタイプ。正しいことをするための絶対的な最善の方法は、まずそれを間違って行うことです。研究に基づいて、ソリューションを構築し、あなたが行くにつれてすべてを作り上げます。付随的な要件を考慮しながら、主要な要件に準拠するようにしてください。見栄えのする、完璧な、拡張可能な、柔軟性のある、パフォーマンスの高いものにする必要はありません。学んだ教訓-何が機能したか、何が機能しなかったか、潜在的な障害などをメモします。次に、コードを捨てます。時間がかかりすぎてばかを探すのが心配な場合は、自分の時間にこれを行ってください。それは知識の面で個人的にあなたに利益をもたらします。
- 設計。外部の知識（研究）を個人の知識（プロトタイプの教訓）と組み合わせ、それを行うには正しい方法だと思うものの設計を策定します。
- 協力する。シニアチームメンバーを見つけ、提案されたデザインを彼らに示し、フィードバックを得る。それを他の人に見せて、彼らのフィードバックをもらいましょう。デザインを改良します。
- 繰り返す。それでも解決策がわからない場合は、ピアレビューが反復サイクルの一部であることを確認してください。フィードバックを得るために、実装を定期的に上級チームメンバーに持ってきてください。
- 幸せになる-あなたはあなたの知識とあなたのキャリアを進歩させました、そしてあなたはあなたが以前に何千回も行った古いものや退屈なものの代わりに新しい面白いものをやらなければなりませんでした。次のプロジェクトをさらに大きな課題にしてください。
そして最後に、外観についてあまり心配しないでください。開発チームマネージャーとして、私たちが今やろうとしている1つのことをすでに知っていることを証明できる人よりも、必要に応じて必要なことをすべて学べることを証明できる人が欲しいです。前者は、明日、来月、来年など、何をするにも便利です。