より良いバグ修正ツールになる

プログラマーであることが大好きです。そこで、私はそれを言った。しかし、そうは言っても、私は本当にバグ修正に耐えられないことに最近気付きました。まったく。

実際、私は何かを開発している間、私の生産性は非常に高いです。単体テストを作成し、開発の自己テストを行う場合でも、私は一般的に本当に生産的です。私はうまく集中することができ、タスクを完了することができます。

ただし、QAの時間が来て、バグの修正に取り組んでいるとき、私のインスピレーションは非常に急降下します。何かを成し遂げるには、かなり極端な手段（BPMの高い音楽、カフェインの過剰な量など）を強制する必要があります。私の仕事は通常、既存の大規模なプロジェクトに足を踏み入れ、新しい機能を追加したり、バグを修正したりすることです。そのため、すべてのコードのユニットテストを書くのに数週間かかることを雇用主に正確に伝えることはできません:)私たちがよく使用するサーバー技術は、ユニットテストと統合テストの両方で非常に禁止されています。Javaクラスローダーの問題がかなりあるからです。私は完全にバグ修正に反対しているわけではありません。時には楽しいこともありますが、まったく楽しくはありません。 マイナーな変更を加え、それらが機能するかどうかを確認できるように30秒から3分間待機する必要がある場合（システムの動作方法による）。

バグ修正時の生産性とモチベーションを改善するにはどうすればよいですか？これはほとんどのプログラマーが対処するものですか？

小さな変更を加えて、30秒から3分待って、それらが機能するかどうかを確認する必要があるときは、まったく面白くない

これが本当の問題です。フィードバックをあまりにも長く待たなければならないとき、あなたは非生産的だと感じます。おそらく、より多くのサービスを偽造し、より良いテストツールを作成して、すぐにフィードバックを得ることが可能です。

レガシーコードのユニットテストは高価であるか、危険なリファクタリングを伴う可能性があります。ただし、より優れたテストフィクスチャを作成すると、数分に比べて数秒でテストを実行でき、新しい単体テスト可能なコードを操作するのとほぼ同じ生産性を得ることができます。

長い間フィードバックを待つのは退屈でやる気がなく、バグ自体を修正する行為ではありません。

バグ修正は、学ぶべき非常に重要なスキルです。私はどこかを読んで、通常、アプリケーションの問題の20％を修正するのに80％の時間を費やしています。

私は間違いから学ぶことを信じており、バグ修正は他の人の間違いから学ぶ機会です。あなたはそれを学ぶことができ、将来的にはより良いプログラマーになるのに役立ちます。これは、多くのバグを修正し、コードのリファクタリングを進め始めたときの動機です。

個人的には、バグを「小さなもの」と考えるのをやめることは役立ちましたが、数時間のデバッグ後に数行のコードを変更するだけでも、巨大な機能と同じくらい重要な大きなショートッパーとして考えるのはやめました。そうすれば、1日を3つのバグトラッカーエントリを殺すのに圧倒されることはほとんどありません（アプローチは、自分を信じてそれを信じる個人的な能力に少し依存します:-)。

たとえば、同僚と一緒にゲームにするのに役立つかもしれません（1日に最も多くのバグを修正しますか？または、さらに悪いことに、1日に再構築した回数が最も少ないのは誰ですか？）

私はあなたの靴を履いてきました。いつどこで自動テストを構築します。一度に全部である必要はありません。バグを見つけたら、テストケースのプログラミングを試みてください。テストケースをプログラムできない場合は、手動でテストする方法について簡単な文章を書いてください。たとえば、ここをクリックして、これを入力して、何らかのナレッジベースに入れてください。

特にあなたが書いていない複雑なコードでは、デバッグは非常に面倒です。「バグ13533を金曜日までに修正する」という目標を立てます。「金曜日の夜に仲間とパイントをつかむ」という目標を達成したら、報酬を設定します。これは、もう少しやりがいのあるものになります。

それ以外に、時々働くことはただ...仕事です。

このような状況では、何らかの創造的な挑戦が必要です。通常、コードを記述していますが、ここではそうではありません。

しかし、すべてが失われるわけではありません。メタ問題を解決し、それにエネルギーを注ぎます。 フィードバックを得るのに30秒から3分かかるのはなぜですか？ どうすればその時間を短縮できますか？（たぶん、あなたはこれを行うのに役立つ、チェックインしない何らかの種類のスクリプトまたはユーティリティアプリを書くことができます）。それがあなたの新しい問題の領域、あなたの新しい創造的な挑戦です。

個人的には、欠陥修正フェーズにいるときはいつでも、それを迅速かつ無痛で完了するための最大の障壁を特定し、それらの障壁を取り除くために自動化する必要があるものを自動化します。これにより、生産性が向上し、個人用ポートフォリオに追加されて起動することがよくあります。

要するに、私は「常に開発している」と言うでしょう。:)

問題のデバッグまたはバグ修正ですか？問題の原因となっているコンポーネントを分離するのに十分なデバッグが可能な場合は、新しい開発タスクと見なしてください。

1. 破損しているコードの一部に対して単体テストを作成します。必要な機能のすべてを検証するテストに加えて、特にバグのある動作を分離するテストがあることを確認してください。
2. 作成したすべてのテストに合格する新しいコードを作成します。
3. 古いコードを新しいものに置き換えます。
4. いくつかの統合テストを実行します。ここで3分間のサーバーの再起動が実行されますが、手順1〜3を適切に実行した場合は最小限に抑える必要があります。
5. 出来上がり！

たぶん、あなたはブライアン・ヘイズを見なければならない自分のデバッグ、あなたは（の愛用のような手順を取ることができる1995年にアメリカの科学者に登場した記事ヨーダ条件あなたが作るのバグの最も嫌わ種類を減らすか、または排除するために）。

デバッグは、関連しているものの、プログラミングとは異なるスキルであると考えています。特に、マルチスレッドプログラムのデバッグは、プログラムの作成とほぼ完全に異なります。

ソフトウェア開発が退屈な場合、あなたはそれを間違っています。言い換えれば、それはあなたの問題ではなく、プラットフォームとプロセスの問題です。サーバーの再起動を待つ必要のない動的言語（Python、Ruby、JavaScriptなど）を使用するポジションを探すことを検討しましたか？

残念ながら、それは仕事の一部です。安っぽいプロジェクトと安っぽい雇用主がいるでしょう（ここではどちらもそうではなく、単に一般化しています）。

あなたはすることができます彼らのコードに対してユニットテストを書きます。できる限り忍び込んでください。上司に見せられるものを手に入れたら、流れを変えることができるかもしれません。

デバッグツールを使用して遅延を修正し、ユニットテストを使用して新しいコードをテストし、それらを使用して既存のコードの問題を修正し、既存のコードを小さな断片に分解します。

それをチャレンジにして、プロセス改善のヒーローにすることができます。そして、それがうまくいかない場合、あなたは次の雇用主に連れて行く良い経験をするでしょう。

ほとんどのプログラマーは、キャリアのある時点でバグ修正の個人的な問題に対処する必要があります。

人と職場の距離の正しい感覚は、あなたのモチベーションに不可欠です。あなたの仕事について過大または過小認識しないでください。自分の仕事について自分を過度に特定している場合、説明したような問題が表面化する可能性があります。内なる距離を取り、問題に合理的に取り組む方法を見つけてください。

プラットフォームの特定の問題に関しては、長い展開時間とテスト時間を軽減するいくつかの方法があります（そして、一方で、あなたのものは特に長くはありません）。

まず、テスト時間が長ければ長いほど、カーゴカルトを嫌うべきです。変更する場合は、バグが修正されると確信できるまで考えてください。もちろん、どれだけ自信があるかは、テストサイクルの長さによって決まります。しかし、テストサイクルが長くなり、長いテストを避けられない場合は、より多くの時間を費やして考えると、より速く、「フィアットルクス」の良い瞬間の報酬効果があるので、あなたはデバッグでより報われて幸せになります「。

第二に、単体テストへの偏りを強め、統合テストへの偏りを弱めます。可能な限りデバッグしにくいプラットフォームからすべての障害点を削除します。

バグ修正は「素晴らしい」または「退屈な」ことができます。私は、1つのバグを修正しただけのゲームクレジットを持っています-他の誰も修正できないクラッシュバグです。しかし、Bugzillaの日々のグルーミングは気が遠くなるようなものです。マイナーなバグは退屈です。主要なバグは価値があります。

これが実現です：あなたが小さなバグの巨大なリストを持っているという事実は、それ自体が一つの大きなバグです。コードのバグではありません。そのプロセスまたは管理のバグ。

そのバグを見つけて修正してください。

良い「デバッガー/バグ修正者/問題解決者」である同僚や知識人の間で私が見つけたことの1つは、彼らが一般的にパズルを解くことを好むということです。つまり、クロスワードパズル、数字ゲーム（数独など）、ロジックパズルなどを意味します。

したがって、あなたがより良いバグ修正者になる可能性のある方法の1つは、問題解決またはパズル解決のスキルに時間を費やすことです。

ここにウィキペディアのリンクがあります。これは、あなたがより良い問題解決者になるのを助けるための良い出発点かもしれません。

気を付けてください、問題解決が得意な人もいれば、もっと楽しむ人もいます。まったく気に入らない人もいるので、自分でやることを強制するのは難しくなりますが、間違いはありません。 。

バグ修正は通常、面倒な作業のように感じられます。これは、バグがすべての時間を費やしていて、楽しい新しいものから遠ざけるように感じることができるからです。しかし現実には、バグ修正は私たちが行うことの非常に大きな部分を占めており、コードの最初の行を記述してコンパイラーを実行するのと同じくらい早い段階から始まります。初めてコードをリリースするとき、おそらくバグの修正にすでに何時間も費やしているでしょう。機能を実装するプロセスの一部としてバグを修正しているため、そのようには思えません。現実的に言えば、どんなにプログラマーが優れていても、バグがシステムに忍び寄るでしょう。

それでは、どのように楽しくしますか？あなたの個々のボートが浮かんでいるのは本当に想像できないので、私はあなたのためにそれを本当に答えることはできません。私にとっては少しツール中毒なので、答えは非常に信頼性の高いツールチェーンと、バグ修正を面倒なものにせず、より簡単に解決する問題に貢献する柔軟な開発プロセスを持つことです。早く。現在、私は主にC＃で開発していますが、ソフトウェアの作成の面倒な時間を無駄にするツールを常に探しています。StoryQと呼ばれる非常に優れたBDD APIでサポートされるテストファースト開発アプローチを使用します。Resharperを使用してリファクタリングの多くを自動化し、StyleCopを使用してコーディングスタイルなどを隠します。ツールチェーンへの私の最新の追加は、コーディング中にバックグラウンドでテストを継続的かつ同時に実行するNCrunchは、ゲームチェンジャーであることが証明されているNCrunchです。

これらすべてのツールを組み合わせることで、コンパイルや実行を待つ時間をほとんど無駄にすることなく、生産性が向上しました。IDE内で視覚的に即座にフィードバックを得て、修正すべき問題があることを知らせます。テストコードは、コードのほんの数行内で正確な場所を特定できるようにレイアウトします。失敗が発生しましたが、StoryQから得た素敵な詳細レポートのために失敗の原因が発生した場所これにより、テストのどの部分が失敗し、どの部分が失敗し、コードのどこで失敗したかが正確にわかります。すべての時間の浪費が開発時間から取り除かれたので、積極的にデバッグする時間はほとんどなく、問題の解決とテストとコードの作成により多くの時間を費やしています。離職率の高い問題は私を忙しくさせ、仕事に多くのバリエーションをもたらします。また、仕事中に興味のある他の分野を追求する時間をたくさん与えてくれたので、新しい革新的なアイデアを製品ラインやプロセスに注入することができました。