この記事は、比較的経験の浅い開発者が新しい開発者と話しているので、共有する価値があると思いました。しかし、私がそれを読んでいると、1つのアドバイスが突き出ており、強調する価値があります。
最初に計画し、次にコーディングする
ロベルト・ヘルナンデス
これが基本です。大工仕事とは異なり、計画が重要なのは、そうしないと材料を無駄にするためですが、コーディングは「始めたばかり」のように感じることがあります。結局のところ、間違えた場合は、コードを削除して最初からやり直すことができます（本番環境ではなく、独自の開発環境で操作している場合）。あなたが構築しているものを見るのは、ビルダーとしてのあなたにとっても、あなたがあなたの仕事を共有する他の誰にとっても、満足のいくものです。
ただし、開始するのがコードの記述である場合、「開始するだけ」は無駄のレシピです。
1行のコードを書く前に最初にすべきことは、問題を理解することです。問題の規模と規模によっては、この理解を確認するのは、「ボタンのテキストを青に変更してほしい」というリクエストを作成者に繰り返し返すだけの簡単なものです。影響：「フォームAとBで機能しますが、フォームCはどうですか？」
または、提案された変更とアーキテクチャを使用して仕様書を作成し、フィードバックを取得し、適切な担当者または委員会によって実行し、経営幹部や顧客を含む利害関係者から承認を得るのと同じくらい複雑になる可能性があります。
次に、問題と提案された解決策を理解したことを確認した後、それに対してどのように実行するかを計画します。小さな問題の場合、これには、実行するタスクのリストを作成または検討することからすぐに開始することが含まれますが、多くの場合、このタスクが他の海の中で失われないように、タスクリストまたはカレンダーに追加する必要があります。あなたが持っているタスク。より大きな問題の場合、チーム間の調整が必要になる場合があります。つまり、会議とドキュメントです。
問題を理解し、この目標を達成する方法について計画を立てたら、コードの記述を開始できます。
フィードバックまでの時間が長いので、飛び込んでコードを書くことは避けてください。何と比べて？テキスト、画像、会議と比較して。これらは非常に簡単に繰り返すことができます。間違った問題を解決したり、間違った方法で対処したりするためのコードを書いた場合、問題について話し合った場合よりも多くの時間を費やしてしまいます。
また、特に技術者以外の同僚と、概念をコードで伝達することも困難です。仲間のエンジニアであっても、図や会話は、書かれたコードよりもアイデアを説明する簡単な方法です。私は、ソリューションのプロトタイプを作成するのにかかる時間の何分の1かでソリューションをホワイトボード化することがよくありました。コードはより正確であり、問題を手で振り払うことはできませんが、多くのコードベースでアイデアの芽の周りにたくさんのもみ殻があります。
ただし、コードを書くことが正しい開始方法である場合があります。これはプロトタイピングと呼ばれ、問題を読んだり、学習したり、話し合ったり、その他の方法でアプローチしたりして問題を理解する方法がない場合は、コードを記述して問題を調査します。ただし、このコードはナプキンに急いで引っかいたメモに相当するため、破棄する準備をしてください。
この理解と計画のプロセスは、必ずしも重量級で正式なものである必要はないことを強調したいと思います。実際、小さなタスクの場合、このプロセスを内部化しても、それを実行していることに気付かない場合があります。
次回、小さなタスクに取り組んでいるときは、少し時間を取って、それをさらに小さな作業に分割する方法を考えてください。「わかりました。このフォームを追加する必要があります。したがって、モデルとビューも必要です。入力を検証するために追加する必要があるメソッドは何ですか？」
すべての決定についてドキュメントや成果物を作成する必要はありませんが、少なくとも自分の頭の中で、タスクとそれらのタスクの影響について考えることをお勧めします。これはソリューションが原因で発生する可能性のある問題を確認するのに役立ちます。その場合、コードを記述する前に、ソリューションを再度変更できます。
よろしくお願いいたします。
