この記事で「機能」という言葉を「機能」として頻繁に翻訳したことを一度に予約したいのは、 私にとっては、これはかなり一般的な翻訳オプションです。
行きましょう。
優れたソフトウェア開発者になるには、長年の準備と実践が必要です。 しかし、適切な規律がなければ、最高のプログラマーでさえ、人間の本質に内在する最悪の特性の餌食になる危険があります。 いくつかの悪い習慣は非常に潜んでいるので、最も経験豊富な開発者の間でも何度も現れます。 これは、ソフトウェア開発の7つの大罪です。 読み進めていくと、情熱、大食い、貪欲、怠、怒り、en望、誇りが、あなたが現在取り組んでいるプロジェクトをどのように弱体化させているかがわかります。
1.情熱（過剰なデザイン）
現代のプログラミング言語は、時間とともにますます多くの機能を含む傾向があります。 抽象化をレイヤーごとに積み上げ、コードの読みやすさと再利用性を向上させるために設計された新しいキーワードと構造を追加します。ただし、それらを正しく使用する方法を学ぶのに時間がかかる場合のみです。
同時に、プログラミング知識の分野自体も近年変化しています。 今では、デザインパターンに関する膨大な量を自由に使用でき、数ヶ月ごとに新しい人が別の開発方法論を提供し、それを使用するとプログラマの間で神になると誓います。
しかし、紙の上で良さそうに見えるものが、実際に常に機能するとは限りません。 そして、あなたが何かをすることができるという事実は、あなたがそれをしなければならないという意味ではありません。 プログラミングの第一人者であるJoel Spolskyは次のように述べています。「製品リリースは機能です。 非常に重要な機能。 そして、あなたの製品はそれを所有していなければなりません。」 開発ツールをフェチするプログラマーは、必然的にこの瞬間を見失い、最も単純なプロジェクトでさえ開発地獄に陥る可能性があります。 これらの基本的な衝動に抵抗し、実際に機能するソリューションに固執します。
2.大食い（リファクタリング不能）
製品をリリースすることほど楽しいものはありません。 完成したバージョンを入手したら、次の開発イテレーションの計画を開始するのに最適です。 どのような新機能を追加する必要がありますか？ そのうちのどれが、最初のバージョンの開発中に時間がないのですか？
コードはめったに素晴らしいものではないことを忘れがちです。 機能の量は開発の反復ごとに自然に増加し、プログラマーは通常、過去の反復で犯した間違いを悪化させるだけです。 その結果、コードが肥大化して脆弱になり、コードを効果的にサポートするには混乱しすぎます。
プレートごとに新しい機能を吸収する代わりに、自分自身を保持します。 既存のコードの品質と「保守性」を評価します。 プロジェクトの新しい反復ごとに予算の別の行をリファクタリングするコードを作成します。 顧客は各リリースで新機能のみを見るかもしれませんが、時間の経過とともに、製品が脂肪で覆われすぎていないことに感謝するでしょう。
3.貪欲（開発チーム間の競争）
パワーと強さに対する過度の欲求-同僚と競争するプログラマーの動機を他にどのように説明できますか？ すべては、一部のチームがメーリングリストから単に除外され、その後集会が密室で行われるという事実から始まります。 それで、チームの1つが、以前に別のチームによって実装されていた機能のほとんどを再実装するライブラリを作成します。
プログラマーチームが悪意を持って自転車を発明することはめったにありませんが、明確に定義された目標の欠如は、実際に必要とされるよりもはるかに広範な責任領域に容易につながる可能性があります。 その結果、開発の重複によるプロジェクト予算の損失は言うまでもなく、冗長でサポートされていないコードになります。 ソフトウェア開発プロジェクトを管理する最も重要なタスクの1つは、各チームが他のチームが何をしているかを理解し、共通の目標を理解することです。 あなたのスローガンは「すべてを平等に共有する」という言葉でなければなりません。
4.怠azine（入力データの検証の欠如）
主要なプログラミングエラーのリストは非常に長いですが、入力データをチェックしないという罪は非常に有害であるため、個別に言う必要があります。 このややアマチュアなエラーが、一部の経験豊富なプログラマーによって書かれたコードに現れていることは不可解です。 それでも、システムの多くのセキュリティホールの原因の調査（バッファオーバーフローエラーからSQLインジェクションまで）は、有効性と正しいフォーマットを確認せずに入力データを操作するコードに直接つながります。
最新のプログラミング言語には、このエラーを回避するための多数のツールが用意されていますが、それらを正しく使用する必要があります。 JavaScriptを使用して入力を検証するWebフォームは、ブラウザーでJavaScriptをオフにするか、ブラウザーをまったく使用せずにアクセスすることで簡単にバイパスできることに注意してください。 入力の検証は、UIに散らばらずに、アプリケーションのコードにフラッシュする必要があります。 それ以下はすべて怠です。
5.怒り（コードにコメントする練習の欠如）
コードにコメントがないことよりも、あなたの側でどのような行動が同僚に対して敵対的になる可能性がありますか？ はい、わかっています。よく書かれたコードは、どのドキュメントよりも優れています。 知ってる？ 先週の火曜日の午前2時に書いた2つのメソッドは、あまりよく書かれたコードではありません。 （そして、あなたがPerlハッカーなら、Ave Mariaを9回歌うべきです）。
プログラマは、今日書いたコードが会社を辞めた後も何年も存続できることを簡単に忘れてしまいます。 そして、それらを成功させる人々は、各コードが何のために意図されているかを理解するという避けられない仕事に直面しています。 したがって、親切に、少なくともいくつかのヒントを残してください。
しかし、無意味なコメントは、過度のフレージングと同様に、コメントの完全な欠如よりもさらに悪化する可能性があることを忘れないでください。 「これは機能しません」または「触れないでください！」などのコメントは、他の人にとってはあまり役に立ちません。 変数の初期化などの単純な操作を説明する冗長なコメントも役に立ちません。 コードはそれが何をするのかを最もよく文書化します。 コメントが必要な理由を理解するために必要です。
6. vy望（バージョン管理システムを使用しない）
2011年には、ファイルサーバーにフォルダーのグループとして保存され、1人の「キーパー」によって熱心に保護されたプロジェクトがまだあると信じることは困難です。 これらのフォルダーのコピーは、オフィス全体の開発者のコンピューターに散らばっており、それぞれが他のものとわずかに異なりますが、誰も正確に何を知っているのではありません。
おそらく、プロジェクトにバージョン管理を実装しない理由があります。 おそらくプロジェクトは小規模でしたが、今では手に負えなくなりました。 しかし、今日では、無料で使用できる多数の強力で効果的なバージョン管理システムを自由に使用できます。 サービスプロバイダーは、最小限の費用で分散プロジェクトのコードをサーバーに投稿する準備ができています。 新しいプロジェクトを開始するときに、新しいプロジェクトを開始するときにコードリポジトリを作成しない客観的な理由はありません。 これは小さなプロジェクトにも当てはまります。 唯一の例外は、コードの変更があなた以外の誰かによってコミットされるという事実に自分自身を単純に調和させることができない場合です。
7.プライド（単体テストの欠如）
多くの場合、あなたは背中を軽くたたいて、よくやった仕事に感謝します。 しかし、それが本当にうまくできていることをどのように知っていますか ？ どのような指標を使用していますか？
このテストに特別なテストケースを使用しない限り、コードが正常に機能し、欠陥が含まれていないことを確認することはできません。 しかし、あまりにも多くの開発者は、単にコードのテストケースを作成できません。 彼らは、テストに費やした時間は新機能の実装に費やされなかった時間だと主張しています。 実際、一部の開発者はプロジェクトの予算にQAテストさえ含めていません。
プライドは常に秋を伴うことを除いて、私は何を言うことができますか？ 欠陥のあるコードが顧客の手に渡る頃には、何も変更するには遅すぎます。 コードをリリースする前に単体テストに専念すればするほど、今後回避できる問題が増えます。
PS多くのアイデアがSteve McConnellの本Perfect Codeの章全体に共鳴することを自分から付け加えたいと思います。 まだ読んでいない場合は、この省略を修正することを強くお勧めします:)