私たちプログラマーは楽観主義者です。 これは、期限の評価からコードと実装の作成まで、ソフトウェア開発サイクル全体を通して明らかです。 私の実践が示すように、ソフトウェア開発ではマーフィーの法則は100％のケースで機能します。 それにもかかわらず、私は何度も「楽観的なプログラマ」に出くわします。
上位の楽観的な仮定：
今週の金曜日は午後5時48分にリリースできますが、コードにエラーがあります。
いいえ、できません。 エラーの修正に加えて、次のことを行う必要があります。- このコードを押したままにします（本番環境で公開するブランチで開発を行いませんか？）
- テストベンチでコードを公開し、回帰を含むテスト
- 設定の確認、データベースの移行
- 生産を節約
- 変更を投稿
- テスト生産
- 問題が発生した場合はロールバック
すべてが自動モードで発生した場合でも、就業日の終わりまでに終了するのに十分な時間はほとんどありません。 通常、このような計算は急いで行われ、生産、夜間および/または週末の処理、前のリリースへのロールバックと計算の転送、またはこれらのポイントの組み合わせで愚かな間違いで終わります。
リリース/リリースの決定は、コードを作成してテストした後にのみ行うことができます。 エピックファイルの場合、計算、バックアップ、および以前のバージョンへのロールバックにかかる時間を正確に把握します。 常に最も悲観的なオプションを用意します。最善を尽くし、何らかの理由でロールバックする必要があります。 現在のプロジェクトでは、すべての計算とバックアップを自動化しました。 計算、バックアップからの復元に10分かかります：10分、最小スモックテスト：2時間。 つまり、生産の計算のために、3時間を費やしました。
3日かかります。 一日でできますか？ まあ、多分私はできる
管理者にフォローアップしないでください。 マネージャーは、技術的なバックグラウンドがあったとしても、すべての面を知っているわけではありません。 シンプルで素早いマネージャーのように見えるかもしれませんが、実際にはもっと多くの時間がかかります。 マネージャーは常に、新機能を実装する面倒さだけを評価します。 あなたの仕事は、リファクタリング、テスト、計算に時間を要することを主張することです。 経営陣の指導に従って、リファクタリングに取り組む方法が分からなくなるほど技術的な負債を延期します。 要件は変化しており、誰もすぐに完璧なコードを書くことはできません。 この場所の松葉杖が将来数日または数週間出回ると感じた場合は、数時間余分に費やし、少し後に機能を渡すことをお勧めします。 これをマネージャーに彼の言語で説明してください。今、このリファクタリングには8時の費用がかかります。 松葉杖を挿入すると、1か月で技術的負債は56時間かかります。 通常、マネージャーはよくカウントし、料金に時間数を簡単に掛けます。 あなた以外の誰もコードをよく知っていないので、技術的な面でもっとうまくやる方法をよく知っていることを忘れないでください。 管理プレッシャーの詳細については、記事「 2週間はどうですか？ 」を参照してください。 「。ああ、これは非常に愚かなバグです。すぐに修正し、機能します。 何も書かないテスト
いいえ、バグは単体テストを書く機会です。 表示された場合は、この動作を見逃しており、「コードカバレッジ」に穴があることを意味します。 バグを見つけましたか？ 単体テスト/統合テスト/テストケースをテスト計画に追加します。 これは「ブーメラン」からあなたを救います-何度も何度も戻ってくるバグ。これは非常にシンプルな機能であり、タスクトラッカーに追加することもできません。 私はそうします、要件は明確です
いいえ、要件は一見思われるよりもおそらく複雑です。 新しい要件が既存のシステムの動作と競合する可能性があります。 トラッカーにタスクを追加しないと、物議を醸すような状況では極端になります。 最悪の選択肢は口頭手配です。 人々は非常に短い記憶を持っています。 すべてのタスクは書面でのみ設定する必要があります。 要件管理の詳細については、記事「 仕様による仕様-プラグマティスト向けのBDD 」を参照してください。この変更をテストスタンドに公開することはできません。ローカルマシンでは正常に機能します。 テストの実行も時間の無駄です。ここではすべてがとても簡単です
いいえ、まず最初に「ターゲット」環境/ハードウェアでテストしてください。 エミュレーションは単なるモデルです。 実際の状況では、OSの異なるバージョン、他の権限、異なるプロセッサパワー、RAM、その他の開いているポートなど、予期しない状況が発生する可能性があります。 何でも。このチェックは役に立ちません。 この方法でプログラムを使用することは誰にも起こりません。
追加のチェックは行われません。 まさにそのような場合のために、例外が発明されました。 動作/シナリオをサポートしていませんか？ NotSupportedExceptionをスローします。 すべてが非常に明確になります。 しかし、 NullReferenceExceptionよりも悪いことに、何かを想像するのは困難です。 これは、コードをサポートする人に情報を提供するものではありません。 彼はスタックトレースを調べて、低レベルのエラーを探す必要はありません。 常に低レベルのエラーを処理し、理解可能な例外を使用してください。 .NETでは、例外には、下位レベルの問題に関する情報を保持するのに役立つInnerExceptionプロパティがあります。 .NETでの例外処理については、「 C＃での例外の安全な作業 」という記事に書かれています。このエラーを処理して、何も起こらなかったふりをすることができます。
通常、ソフトウェア要件に信頼性とフォールトトレランスが含まれている場合、空のtry-catchブロックが表示されます。 この動作は、カーペットの下でゴミを捨てるのと同じであるため、誰にも見えません。 フォールトトレランスが必要な場合は、緊急システムの再起動を検討してください。 最初にすべきことは、例外を記録して開発者に伝えることです。 エラーが発生した場合に開発者に手紙を送ることができ、インスタントメッセンジャーを使用できます。多くのオプションがあります。 あなたができる最悪のことは、結果が何であるかわからないので、間違いを無視することです。 「例外」という言葉は、理由のために選ばれました。 これは、動作が計画されておらず、正常ではないことを強調しています。これはバグではなく、これは機能です。テストではデータベースは空です。本番ではすべて問題ありません
いいえ、いいえ。 データをデータベースに入れる必要がある場合は、計算に含めます。 構成を変更しましたか？ 構成変換を追加します。 ケースが検証されない場合、10ケース中9ケースでエラーが発生します。 そのような立場では、デモを行うことは不可能です。 「ここで間違いが発生しますが、戦場にはありません」-ひどい音がします。 何らかの理由で本番と同じテストスタンド（金融取引、有料アカウント、セキュリティ設定など）をセットアップできない場合は、スタブ、エミュレーター、および同様のテストアカウントを使用します。 テストベンチをできる限り実稼働環境に近づけます。私は修正/更新しましたが、うまくいくようです
「いいね」はありません スタンドに何らかの種類のエラーがあった場合は、修正/更新後に他に何も壊れていないことを確認してください。 更新後、アプリケーションのヘルスチェックの最小チェックリストを取得します。たとえば、ログイン、何かを購入、数ページを表示します。 これにより、テスターとあなたの仲間の開発者はあなたに繰り返し電話する必要がなくなります。 個人衛生の要素として、このテストを当然受けてください。 毎日歯を磨き、顔を洗う理由については考えません。FIGは問題が何であるかを知っており、私は再起動し、うまくいった
いいえ、「FIGは知っています。 プログラムがクラッシュする可能性を正確に理解し、抑制する必要があります。 再起動することで問題を解決した場合、原因と戦うのではなく、結果と戦うことになります。 この問題は、最も不適切な瞬間に繰り返されることが保証されています。 夜中に目が覚め、「落ちた」のでアプリケーションをもう一度再起動します。 問題を常に完全に解決してください。 アプリは定期的に再起動する必要がありますか？ 自動再起動を設定し、問題を特定し、タスクを追加して修正します。 「憎悪」の危険性については、「 結果のために働くことの何が悪いのか 」 という記事に非常によく書かれています。上記の推奨事項の実装には、自己規律が必要です。 彼らに従うことは難しいですが、マーフィーの法則は決して私を失望させません。 例外を作成するたびに、予期しない、異常な、計画外の何かが発生します。 時間通りに、時間通りに仕事を終わらせることができないたびに、私は動揺するので、これらのルールから決して引き下がらないようにします。 その結果、ソフトウェア開発全般を見る前よりもずっと楽観的です。 「複雑すぎる」タスクはないことを知っています。 実装に多くの時間を必要とするタスクがあります。 私のチェックリストが他の開発者に役立つことを願っています。