ケントベック-ソフトウェア開発者、エクストリームプログラミング（XP）やテストによる開発（TDD）などのソフトウェア開発方法論の作成者。 現在、Facebookで機能しています。 あなたの注意は、あなたの仕事をより効率的にする方法に関するアウトラインのアイデアの翻訳に招待されます。 記事全体で使用されているプログラマーのマスターと見習いへの分割は、Kent BeckがAndrew HuntとDavid Thomasの著書「Pragmatic Programmer」から取ったものです。長年にわたり、最高のマスタープログラマーを見て、私は彼らの作業プロセスのいくつかの一般的なパターンに注目しました。 同時に、長年訓練された見習いプログラマーを訓練している間、私は彼らがそのような習慣を持たないことに気付きました。 私は自分の目で、その違いが他の人に彼らの作品でマスターが使用するパターンに親しみを与えることができることを見ました。
以下は、効果的なプログラマーが私たちの惑星で貴重な3e9秒を最大限に活用する方法です。
アウトラインの主な動機は、脳の可能性を解き放つことです。 見習いは、一度にいくつかの小さな問題を解決することにより、大きな問題を解決することを学びます。 マスターは、しかし、一度に少ないタスクを解決することにより、見習いよりもさらに大きな問題を解決することを学びます。 ここでの知恵の重要な部分は、すべての問題を一緒に解決するよりも独立したソリューションを統合する方が問題が少なくなるようにタスクの内訳を行う必要があるということです。
時間
- タスクの内訳（ スライス ）。 大規模なプロジェクトを取り、それを「薄い」断片に切り取り、状況に応じて自分に合うように再配置します。 私は常にプロジェクトをさらに小さなタスクに分割することができ、他のニーズを満たすこれらのタスクの新しい順列を常に見つけることができます。
- 一度に一つのこと。 私たちは効率に非常に重点を置いているため、オーバーヘッド（オーバーヘッド）を削減するためにフィードバックサイクルの数を削減しようとしています。 これにより、後で困難なデバッグケースが出現し、その推定コストは、以前に回避したサイクルのオーバーヘッドよりも大きくなります。
- 動作させます。 正しいスペルにします。 速く動作させる （ 実行させる、正しく動作させる、高速にする ） （ここでは、「一度に1つのこと」、「タスクの内訳」、「変更のしやすさ」の例を挙げます）
- 変更の容易さ。 複雑な変更に遭遇した場合、最初にそれを単純にします（注意：難しい場合があります-技術的負債のリファクタリングと返済は除外されません）、次に単純な変更を行います（タスクの内訳を使用して、一度に1つのケースを変更し、集中と分離）。 ほとんどの場合、これはタスクをより単純なものに分解することを意味します。
- 濃度。 複数の要素を変更する必要がある場合は、最初に1つの要素のみを変更する必要があるようにコードを再作成します。
- 分離。 要素の一部のみを変更する必要がある場合は、サブ要素全体が変更されるようにこの部分を抽出します。
- 基本レベルの測定 （ ベースライン測定 -変更が行われる前のプロセスの機能の正確な測定）。 世界の現在の状態を測定してプロジェクトを開始します。 これはエンジニアの本能に反するものであり、すぐに「修正」するものを決定します。ただし、プロジェクトの基本的な調査を実施して初めて、本当に何かを修正しているかどうかがわかります。
トレーニング
- 何をしたいかを知っています。 コードを実行する前に、何が起こるかを明示的に予測します。
- 特定の仮説。 プログラムの動作がおかしい場合は、変更を加える前に、プログラムのどこがおかしいと思うかを正確かつ明確に表現してください。 1つ以上の仮説がある場合、 鑑別診断が役立ちます。
- 異物を取り除いてください。 バグを報告するとき、それを再現するために必要な手順から最短パスを見つけます。 バグを特定する場合、最小限のテストケースを見つけます。 新しいAPIを使用する場合、最も単純な例から始めます。 「このナンセンスはすべて問題ではない」というのは、最終的に何かがおかしくなったときにあなたに背を向けることができる高価な仮定です。 例：モバイルアプリケーションにバグがある場合は、curlで再生してみてください。
- 別のスケールを試してください。 プロジェクトの「スケーリング」のレベル間を自由に移動します。 おそらく、テストではなく設計上の問題を扱っているのでしょう。 おそらく、問題は技術ではなく人にあります[ この記述は常に真実であるため、不正行為です ]。
ロジックを超えて
- 対称性 外観がほとんど同じものは、同じ部分と、正確に（そして明確に）異なる部分に分けることができます。
- 美学。 美しさは、登るのがとても難しい壮大な斜面です。 それを無視することで救いが減ることは驚くことではありません（たとえば、1つの巨大なコードに大量の関数を埋め込むと、もはや理解できなくなります）。
- リズム。 適切なタイミングを待つことで、エネルギーを節約し、混乱を避けることができます。 行動する時が来たら、行動は集中的でなければなりません。
- 妥協。 すべての決定は妥協の対象となります。 すぐに必要であるという理由だけで選択を行うよりも、決定が正当化されるものを知る方が重要です（後者の場合、全体像を理解する代わりに、過去に行った特定の選択を常に覚えておく必要があります）。
リスク
- エンターテイメントのリスト。 「左」のアイデアが「接線方向」に来たら、それらを書き留めてすぐに仕事に戻ります。 このアイデアのリストを少し後で確認します。現在のケースでは、滞在できる場所に到達した後です。
- フィードアイデア。 アイデアは小さな鳥のようなものです-また、簡単に怖がってしまいます。 そして、あなたがそれらを定期的に怖がらせると、彼らはあなたへの飛行を止めます。 あなたがアイデアを持っているとき、それを少し供給してください。 アイデアができる限り迅速に受け入れられない（つまり、無効にされる）ことを確認してください。ただし、自尊心の欠如ではなく、データの助けを借りて取り組むことを拒否することを正当化してください。
- 80/15/5。 低リスク/十分なリターンで作業時間の80％を費やしてください。 ハイリスク/ハイリターンで作業する時間の15％を費やしてください。 潜在的な利益に関係なく、5％をあなたの悩みに費やす。 仕事の80％を行うように次世代をトレーニングします。 誰かがこの負担を自覚する準備が整うまでに、15％の実験の1つ（または、それほど頻繁ではないが5％の実験の1つ）が結果を返済し、新しい80％になります。 その後、もう一度繰り返します。
おわりに
スケッチは、時間管理とトレーニングを使用してリスクを軽減することから、脳全体の潜在能力とアイデアのシーケンスをすばやく整理する能力を使用して意識的なリスクを取ることに至る順序で作者によって配置されました。