ベストアンサー
興味深い質問。私にとって「職人技」という用語は、高レベルのシステム設計ではなく、実際のコードの記述方法に関するものを意味します。よく練られたコードは次のことを行うと思います。
- 外部標準に従う
- 内部標準に従う
- 適切なパターンを使用する
- 読みやすい
外部標準に従います。グループにコーディング標準がある場合は、それに従ってください。そうでない場合は、標準と同様に、それでもそれらに従ってください。
内部標準に従います。これは、コードが内部的に一貫している必要があることを意味します。同様のことを行うメソッドは、同じ方法でレイアウトする必要があります。 1つのメソッドがパターンに従う場合：
if (success) {
doSomething();
} else {
handleError();
}
開始する別のメソッドがありません：
if (!success)
{
handleError();
適切なパターンを使用しています。これは、デザインパターンではなくコーディングパターンを意味します。コードでは、言語に適したイディオムを使用する必要があります（たとえば、C ++のメモリ管理にはscoped\_ptrsを使用します）。C++イテレーターのポストインクリメントや作成などの明らかな非効率性を回避する必要があります。すべてのコードパスで使用されているわけではないオブジェクト。
読み取り可能。他のエンジニアがコードを読み取り、再度読み取ります。数年後には。コードはできるだけ理解しやすいものにする必要があります。上記のすべての項目は、主に読みやすさと、コード内の予期しない要素の最小化に関係しています。読者は、非標準の構造が使用された理由を解明しようとするのではなく、コードのロジックに関心を持つ必要があります。非標準の構造がある場合、読者はそれが理由でそこにあることを知っている必要があります。間違えたからではありません。 （コードを家具のように考えてください。表面は滑らかで、手をかざしても破片がつかないようにする必要があります。何らかの理由で不規則性があるはずです。）
読みやすさは、賢明なメソッドと変数名、および適切なコメントによっても改善されます。コメントをやりすぎないでください。それが明らかな場合は、わざわざ説明しないでください。しかし、読者が文脈を知ることができるように、ある種の概要を持っています。 （コードが入力Xを出力Yに変換していることは明らかかもしれませんが、読者がこれが必要な理由をある程度理解している場合に役立ちます。）
回答
マネージャーは次のようなものです。幼児。彼らは彼らが望むものを望んでおり、彼らはそれを望んでいます今！しかし、幼児とは異なり、マネージャーは、彼らの要求を正当化するために引用した Harvard Business Review の記事を（参照を提供せずに）半分覚えています。彼らは、一部の開発者を困惑させる一連の議論を学びました。
彼らは、「私たちはそれを正しく行うために余裕がないと言います。マーケットプレイス今で入手する必要があります！」それは真実ではありません。スパゲッティコードを本番環境に急いで投入すると、今すぐローンチ顧客を怒らせるチャンスがありますが、コードを拡張することはできません。それは、彼らのビジネスが崩壊する前にしばらくの間混乱していることを意味します。
彼らは、「ローンチの顧客にベータ版をリリースします」と言います。彼らが意味するのは、彼らがそれをベータテストプログラムと呼ぶことに同意したという理由だけで、彼らはあなたがそうでない場合よりも早く完璧で顧客に喜ばれるコードをリリースすることを望んでいるということです。サンタクロースを信じるような魔法の思考です。
彼らは、「あなたがくだらない、半分完成したコードをリリースしたら、後でコードを書き直すことを約束します NOW ！」これは、「テレビを見たり、甘いおやつを食べたりできるなら、後でお父さんに部屋を掃除します今のように聞こえませんか？問題は、後で来ることは決してないということです。マネージャーは毎日、新しい機能を追加するか、コードベースである散らかった部屋をクリーンアップするかを選択できます。彼らがどちらを優先するかを推測します。そして、何を推測するか、部屋はどんどん散らかっているので、掃除するのにますます時間がかかります。混乱もあるため、（新しい機能を作成するために）作業するのは困難です。
最終的には、「このコードベースに投資しすぎています。書き直すのに時間がかかりすぎます。 今の機能が必要です！」ソフトウェア開発者が技術的負債と呼ぶ厄介な部屋のため、各機能のコーディングにかかる時間は2〜3倍だけです。
忍耐強く愛情深い親のような優れた開発者は、狂気を止めなければなりません。彼らはしっかりと主張しなければなりません。「申し訳ありませんが、あなたの HBR の記事には、「収益は早いほど良いです、他のすべてのものが等しい。 あなたはそれをもっと注意深く読む必要があります。あなたが技術的負債を積み上げるならば、他のすべてのものは等しくありません。 機能を優先して、もっと早く売れるものがあるかもしれません。」
あなたは大人になって、サンタクロースのようなものはないということを彼らに打ち明けなければなりません。 すべてのバグが削除され、すべての機能が実装されるまで、完璧で顧客に喜ばれるコードなどです。
「グッドプラクティスを使用しない。 私たちは生きるか死ぬかですが、テストやドキュメントを書くなど、生きるためには特定のことをしなければなりません。 それは選択肢ではありません。」
あなたは微笑んで、「このコードを書き直すことは決してありません。 私はあなたがよく言っていることを知っていますが、コードの修正や新機能の追加に関しては、あなたが何を言うかはわかっています。 それはあなたが常に言うことです。」
しっかりした親になることで、あなたはマネージャーがあなたのようなビジネスリーダーになるのを助けます 働きたいと思うでしょう。