過失によって引き起こされる破局を回避するための最良の方法は何ですか？
私はほぼ1年間プログラマーでした。
ADHDの成人である私は、当然のことながら、同僚と同じように普通のものに注意を向けていません。
そして、私が起こした破局は、通常、些細な過失によって引き起こされていることがわかります。
今日と同様に、サーバーのcronプロセスが午前中に折りたたまれているのがわかりました。
デバッグの30分後。 cronで書いたことがわかりました
* 4 * * * sh daily_task.sh
の代わりに
0 4 * * * sh daily_task.sh
これは、意図された1回ではなく、朝に59回巨大シェルを実行します。
少なくともそのような間違いを減らすのを助けることができるある種の栽培可能な行動またはいくつかのツールまたは何かがありますか？
このような間違いを避けるにはどうすればよいですか。
少なくともそのような間違いを減らすのに役立つ、ある種の栽培可能な行動がありますか[...]
絶対に、それはfour-eyes-principleと呼ばれます。
Crontabエントリを2人目（もちろんcronを知っている人）に見せた場合、間違いは避けられたはずです。
プログラミングでは、これに関してはほとんどの場合、コードレビューを思い浮かべますが、それは実際には同じことです。
この問題にADHDは必要ありません。頻繁に中断されたり、同時に多くのことに取り組む必要がある環境で作業している可能性があります。そのため、進捗状況を失うか、小さな間違いをすることがほぼ保証されます。
これらのエラーを減らすためにできることが1つあります。仕様に基づくテストです。
まず、できる限り詳細な方法で仕様を書き留めます。コードの場合、これは自動テストの形式である必要があります。最良の方法はTDDに従うことです。したがって、突然気が散ると、テストによってすでに実行したことがわかり、終了した場所をすばやく見つけることができます。また、回帰テストが簡単になります。
コードのテストが不可能な場合は、作成した内容を他の誰かに確認してもらい、仕様に従ってソフトウェアをテストしてもらうようにしてください。本番環境に移行する前に、常にテスト環境でソフトウェアをテストする必要があります。あなたが話している問題は、テスト環境で1日間実行してログを確認することで簡単に見つけることができます。
災害から少なくとも2歩は離れている必要があります。つまり、書いたものを本番環境に直接プッシュすることはありません。テストするか、テストするか、レビューするか、災害への2つのステップを実行する他の方法を見つけます。時々私は次の日に何かを残して、コミットする前に私の仕事をもう一度見直します。
何かが本当に重要な場合は、3番目のステップを追加します。2番目のレビューア、2番目の独立したテストなどです。
誤るのは人間です。私たちの脳は正確さのために構築されていません。間違いを犯したり、バグを書いたりする人もいますが、他の人よりも多くの人がいます（ただし、注意を払えばなお支払われます）。あなたは、個人の仕事に欠陥があるという仮定に基づくプロセスを理解する必要があります。
以前の回答は2つのポイントを述べました：
レビュー
テスト
しかし、役立つ可能性のある3つの追加要素もあります。
視覚化の向上
自分が何をしているのかをよりよく視覚化できるツールを使用することにより、エラーを早期に発見できます。これは特にcronジョブの例です。定義したcronジョブが実行されたときにグラフィカルに表示する視覚化ツールがあるとします。すぐに、何か問題があることがわかります。
たとえば、構文の強調表示は最も人気のある開発者の視覚化ツールであり、実際には 非常に早い段階でエラーを見つけるのに役立ちます （多くの場合、何か間違っていると書いてから数秒以内）、コンパイラまたはテストが実行されます。
継続的な監視
なぜサーバーが崩壊したのですか？何かがうまくいかないことを確認する方法はありませんでしたbefore悪いことが起こりましたか？
サーバーは適切に監視されているはずです。人またはアプリのいずれかが、最後の変更後、CPU使用率が平均42％から平均100％に増加したことを確認し、サーバーの崩壊を防ぐために何かをすることができたはずです。
これにより、継続的な統合、具体的には継続的な展開につながります。継続的デプロイメントでは、コミットを行うと、新しいリビジョンが構築され、テストされて、いくつかのサーバー上の本番環境にデプロイされます。次に、それらのサーバーはアプリによって監視されます。これらのサーバーからのリソース使用量の異常な増加またはsyslog内の異常な量の警告がアプリで検出された場合、サーバーは以前の状態に戻ります。
厳格さ
ガイドラインとルールは通常厄介です（納得できませんか？StyleCopとコード分析に準拠し、コードメトリックスで良好な結果が得られ、コードカバレッジが適切な小さなC＃アプリを作成してみてください）。これが、一部のプロジェクトが静的チェッカーによるゼロ警告とコンパイラーが最大レベルに設定されたゼロ警告を対象とする理由です。以前に検出されたエラーは、手遅れになるときに解決する必要のないエラーです。
これはcronジョブには役立ちませんが、コードを書くときに役立ちます。
特に例示した種類の問題に対する直接的な解決策は、間違いを目立たせることです。
与えた2つの行を見ると、違いは実際には非常に微妙です。間違いを見つけたければ、それを読むときに「心の中で」多くの詳細で微妙な構文を持たなければなりません。また、見にくいビジュアル機能（*および0は混乱しやすい場合があります）。
たとえば、あなたの例で、cron構文が次のような場合：
minute=0 hour=4 day=every week=every month=every year=every
あなたはそれを以下と混同する可能性が低くなります：
minute=every hour=4 day=every week=every month=every year=every
実際にcronの構文を変更することはできませんが、could上記のような名前付き引数を取る簡単なCLIプログラムを自分で記述し、それらを実際のcron。名前付き引数から変換するコードを注意深く確認する必要がありますが、それを行う必要があるのは1回だけなので、エラーチェックに集中して、コードを印刷し、読んで説明するだけで十分です。それを声に出して自分自身に。
このようなプログラムがある場合は、健全性チェックを追加することもできます。新しいcronジョブを作成したら、それを出力します。
This new job will run 1 times a day.
（おそらく、整数になるような最短の期間を見つけようとします）
今、あなたが同じ過ちを犯すことは本当に難しいでしょう。あなたのトレードオフは：
- コマンドを入力するのにより多くのキーストロークが必要になり、より忙しく見えます（これがおそらく
cronに最初から構文が与えられた理由です）。 - エラー耐性のあるインターフェースモデルと健全性チェックのセットアップに時間と労力を費やしました（ただし、この場合は、おそらく1〜2時間で実行できます）。
さて、必ずしもcronに対してこれを行うことを提案しているわけではありません。 cronでタスクを非常に頻繁に設定および編集しない限り、それは少しやり過ぎのようです。私はあなたの例を2つの有用なトリックを説明するために使用しました：サニティチェック、およびそれらを探しなくてもエラーを非常に目立たせる構文を優先します。間違いは、間違いを確認することです 匂い 。
構文を使用すると、次の2つのことを実行できます。
- エラー耐性の高い構文を持つツールと言語を選択します（C＃とPerlなど）。間違いをすばやく見つけることと、より多くの作業を行わなければならないことのトレードオフにもう一度注意してください。
- 貧弱な構文をより良い構文にラップします。たとえば、あいまいな引数名を持つ、名前が正しくない関数に対して独自のラッパー関数を作成したり、難解なツールのために独自のラッパープログラムを作成したり、色の強調表示をサポートするエディターを使用したりします。
これらを常に行うことは意味がありません。あなたは自分自身に質問したいと思います、与えられたタスクで何がより重要ですか：正確さ、またはあなたの時間？ Perlで簡単なスクリプトを一緒にハッキングすると、明確なOOP階層を使用して適切に構造化されたC＃プログラムを作成するよりも速く仕事ができることは間違いありません。間違いを心配していなければ、そして、あなたは急いでいます、なぜわざわざですか？しかし、あなたがこの近道をとるたびに、あなたは賭けをしていることを覚えておいてください：あなたは戻って行く必要がないことを願って、多くの欲求不満と歯ぎしりを賭けます遠い将来、プロジェクトがどのように機能するかを忘れた後（または、元のデザインが機能しないことを途中で認識できず、根本的に変更する必要がある場合）に拡張します。
他のすべての回答に同意しますが、防御的コーディングの考え方もここで役立ちます。
ディフェンシブコーディングを実践するときは、誤って使用されることを想定してコードを記述します。私たちであろうと誰かであろうとこの場合、シェルスクリプトが誤って使用されています（1回ではなく59回実行されます）。
どうすればそれを防ぐことができますか？単純ですが大雑把な方法は、実行の開始時にどこかにタイムスタンプを記録し、タイムスタンプが見つかり、たとえば20時間以上経過した場合にのみ実行することです。
この大まかなアプローチの問題は、スクリプトを手動でトリガーしたい場合があることです。その機能の一部を再実行する必要があるが、すべてを実行する必要がない場合。その場合、よりきめの細かいアプローチがより良いでしょう。 「最新のDBバックアップが20時間以上前の場合は、DBをバックアップします」、「最後のアナウンスが20時間以上前に送信された場合は、アナウンスを送信します」など。
テストだけでなく...
紙にコードを印刷してから、デバッガーでコードを実行し、すべての値がデバッガーで期待どおりになっていることを確認したら、各行をティッカー表示するのは素晴らしい方法でした。これにより、コードをanotherの方法で確認できます。
単体テストで「デバッガチェック」を実行するのはいいことです...