より良いバグ修正プログラムになる
プログラマーであることは大好きです。そこで、私はそれを言った。しかし、そうは言っても、最近、私は本当にstandバグ修正ができないことに気づきました。全然。
実際、私が何かを開発している間、私の生産性は非常に高いです。単体テストを作成して開発のセルフテストを行う場合でも、私は一般的に本当に生産的です。私は集中でき、タスクを完了できます。
しかし、QAの時期が来て、バグの修正に取り組んでいるとき、私のインスピレーションは大いに急上昇しました。 anythingを実行するには、かなり極端な手段（ご存知のとおり、高BPMの音楽、過剰な量のカフェインなど）を自分自身に強いなければなりません。私の仕事は通常、既存の大規模なプロジェクトに足を踏み入れ、新しい機能を追加したり、バグを修正したりするため、すべてのコードの単体テストを書くのに数週間かかることを雇用主に正確に伝えることはできません:)さらに、 Javaクラスローダーの問題がかなりあるため、私たちがよく使用するサーバーテクノロジーは、ユニットテストと統合テストの両方で非常に禁止されています。バグ修正に完全に反対しているわけではありません。楽しいこともあります。 、しかしそれはまったく面白くないです。マイナーな変更を行い、30秒から3分待って（システムの動作により）機能したかどうかを確認する必要があります。
バグ修正時に生産性とモチベーションを向上させるにはどうすればよいですか？これはほとんどのプログラマーが扱っていることですか？
小さな変更を加えて、30秒から3分待って機能するかどうかを確認する必要がある場合は、まったく面白くない
これが本当の問題です。フィードバックを長く待つ必要があるとき、あなたは非生産的に感じます。おそらく、より多くのサービスを偽造し、より優れたテストツールを作成して、すぐにフィードバックを得ることができるでしょう。
レガシーコードのユニットテストは高価であるか、危険なリファクタリングを伴う可能性があります。ただし、より優れたテストフィクスチャを作成すると、分単位ではなく秒単位で手動でテストでき、新しい単体テスト可能なコードを使用する場合とほぼ同じ生産性を得ることができます。
バグを修正するのではなく、フィードバックを待つのは退屈でやる気が出ません。
バグ修正は、学ぶべき非常に重要なスキルです。私はそれをどこかで読みました通常、アプリケーションの問題の20％を修正するのに80％の時間を費やしています。
私は間違いから学ぶことを信じていますバグ修正は他の間違いから学ぶ機会です。あなたはそれを学び、将来より良いプログラマーになるのを助けることができます。これは、多くのバグを修正してコードのリファクタリングに取り掛かったときの動機です。
個人的には、バグを「小さなもの」ではなく、何時間ものデバッグの後に数行のコードを変更するだけであるにもかかわらず、巨大な機能と同じくらい重要な大きなショートッパーとして考えるのをやめることが役立つことがわかりました。そうすれば、1日を費やして3つのバグトラッカーエントリを削除するほうが、うつ病が少なくなります（このアプローチは、自分を信じて自分のことを話せるようにする個人の能力に少し依存します:-)。
たぶん、たとえば同僚と一緒にゲームを作るのに役立ちます（誰が1日に最も多くのバグを修正しますか？または、さらに悪いことに、1日のリビルドの数が最も少ないのは誰ですか？）
私はあなたの立場にいます。自動テストをいつでもどこでも作成できます。一度にすべてである必要はありません。バグを見つけたら、少し時間をかけてテストケースをプログラムしてみてください。テストケースをプログラミングできない場合は、手動でテストする方法について簡単な説明を書いてください。ここをクリックして、これを入力するなどして、ある種のナレッジベースに入れてください。
特に記述していない複雑なコードでは、デバッグが非常に面倒になる可能性があります。 「金曜日までにバグ13533を修正する」という目標を考えてください。次に、「金曜日の夜に仲間とパイントをつかむ」という目標を達成したら、報酬を設定します。これはそれをもう少しやりがいのあるものにするのに役立ちます。
それ以外は、時々仕事はそれだけです...仕事。
このような状況では、何らかの創造的な挑戦が必要です。通常、それはコードを書いていますが、ここではそうではありません。
しかし、すべてが失われるわけではありません。メタ問題の解決に取り組み、それにエネルギーを注ぎます。 なぜフィードバックを得るのに30秒から3分かかりますか？ 方法時間を短縮できますか？ （たぶん、チェックインしないスクリプトやユーティリティアプリを作成して、これを行うのに役立てることができます）。それが新たな問題領域です。新たな創造的な挑戦です。
個人的に、私は欠陥修正フェーズにいるときはいつでも、それを迅速かつ簡単に実行するための最大の障壁を特定し、それらの障壁を取り除くために自動化する必要があるものを自動化します。これにより、生産性が向上し、私の個人的なポートフォリオに追加して起動することがよくあります。
つまり、要するに「常に発展している」ということです。 :)
問題のデバッグまたはバグ修正ですか？問題の原因となっているコンポーネントを特定するのに十分なデバッグができる場合は、それを新しい開発タスクと見なします。
- 機能しなくなったコードの一部について単体テストを記述します。必要な機能のすべてを検証するテストと、特にバグのある動作を分離するテストがあることを確認してください。
- 記述したすべてのテストに合格する新しいコードを記述します。
- 古いコードを新しいコードに置き換えます。
- いくつかの統合テストを実行します。ここで3分間のサーバーの再起動が発生しますが、手順1〜3を適切に実行した場合は、最小限に抑える必要があります。
- Voila！
多分あなたはブライアン・ヘイズの Debugging Myself 、1995年にアメリカの科学者に掲載された記事を見てください。あなたはステップをとることができます（ ヨーダの常用条件 ）は、発生する最も嫌われている種類のバグを削減または排除します。
デバッグはプログラミングとは異なるスキルですが、関連はあると思います。特に、マルチスレッドプログラムのデバッグは、プログラムの作成とはほぼ完全に異なります。
ソフトウェア開発が退屈な場合、それは間違っています。言い換えれば、それはあなたの問題ではなく、プラットフォームとプロセスの問題です。サーバーの再起動を待つ必要がない動的言語（Python、Ruby、JavaScriptなど）を使用して職を探すことを検討しましたか？
残念ながらそれは仕事の一部です。あなたは安っぽいプロジェクトと安っぽい雇用者を持っています（私はここではどちらもそうであるとは言っていません、ただ一般化しています）。
あなたはcan彼らのコードに対してユニットテストを書く。できるだけこっそり入れてください。ボスに見せられるものがあれば、その流れを変えることができるかもしれません。
デバッグツールを使用して速度を修正し、単体テストを使用して新しいコードをテストし、それらを使用して既存のコードの問題を修正し、既存のコードを小さな断片に分解します。
あなたはそれを挑戦にして、プロセス改善のヒーローになることができます。そして、それがうまくいかない場合、あなたは次の雇用主に連れて行くために良い経験をします。
ほとんどのプログラマーは、キャリアのある時点で、バグ修正の個人的な問題に対処する必要があります。
人と職場の距離の正しい感覚は、モチベーションにとって不可欠です。自分の仕事を過小評価したり、過小評価したりしないでください。あなたが自分の仕事を過度に特定している場合は、説明したような問題が表面化する可能性があります。内側の距離を取得し、合理的に問題に取り組む方法を見つけます。
ご使用のプラットフォームの特定の問題に関しては、デプロイとテストの長い時間を軽減する方法がいくつかあります（一方、問題は特に長くありません）。
まず、テスト時間が長くなるほど、カルトカルトに対する嫌悪感が高まります。 変更する場合は、バグが修正されると確信できるまで考えてください。もちろん、どれだけ自信があるかは、テストサイクルの長さに左右されます。しかし、テストサイクルが長くなり、長いテストを回避できない場合は、より多くの時間をかけて考えると、より速くおよび「フィアットラックス」の良い瞬間のやりがいのある効果があります。
次に、単体テストに偏り、統合テストに偏らないようにします。デバッグが困難なプラットフォームからすべての障害点を取り除くことができます。
バグ修正は「素晴らしい」または「面倒」になる可能性があります。完全に1つのバグを修正したことによるゲームクレジットがいくつかあります-誰も修正できないクラッシュバグ。しかし、bugzillaの日々のグルーミングは非常に面倒です。小さなバグは退屈です。大きなバグは価値があります。
実現は次のとおりです。マイナーなバグの巨大なリストがあるという事実自体が1つの大きなバグです。それは単なるコードのバグではありません。そのプロセスまたは管理のバグ。
そのバグを見つけて修正します。
私が良い「デバッグ者/バグ修正者/問題解決者」である同僚や計略の中で私が見つけた一つのことは、彼らが一般にパズルを解くことを好むということです。それは、クロスワードパズル、数独（数独のような）、ロジックパズルなどを意味するかもしれません...
したがって、より良いバグ修正プログラムになるための1つの方法は、問題解決やパズル解決のスキルに取り組む時間を費やすことです。
ここに Wikipediaリンク があります。これは、より良い問題解決者になるのに役立つものの良い出発点になるかもしれません。
ちなみに、一部の人々は問題解決に優れているか、または彼らはそれをより楽しんでいます。まったく気に入らない人もいるので、自分で強制するのは難しいですが、間違いはありません-自分でパズルソルバーになることを強制すると、将来、優れたバグ修正者になりやすくなります。 。
バグの修正は通常、面倒な作業のように感じられます。これは、バグがすべての時間を費やしていて、楽しい新しいものから離れているように感じるからです。ただし、実際にはバグ修正は私たちの作業の非常に大きな部分であり、コードの最初の行を記述してコンパイラを実行することから始まります。初めてコードをリリースするときは、すでにバグの修正に何時間も費やしていると思いますが、機能の実装プロセスの一部として修正しているため、そのようには見えません。現実的に言えば、あなたがどんなに優れたプログラマであっても、バグはシステムに侵入します。
では、どうやってそれを楽しくするのですか？さて、私はあなたのために本当に答えることはできません。私はあなたの個々のボートを浮かせているのが何であるかを本当に想像することができないので。私にとって、私は少しツールのジャンキーです。そのため、非常に信頼性の高いツールチェーンと柔軟な開発プロセスがあり、バグの修正を面倒でなく、より簡単に問題を解決するのに役立ちます。早く。私は現在C＃で主に開発を行っており、ソフトウェアの作成の一部を無駄にする面倒な時間を取り除くツールを常に探しています。私は StoryQ と呼ばれる非常に優れたBDD APIでサポートされているテスト最初の開発アプローチを使用しています。私は Resharper を使用して私のリファクタリングの大部分を自動化し、StyleCopを使用してコーディングスタイルなどのふたを維持します。ツールチェーンへの私の最新の追加は、コードの作成中にバックグラウンドで継続的かつ同時にテストを実行する NCrunch を含めることであり、実際には NCrunch であることが証明されていますゲームチェンジャー。
これらすべてのツールの組み合わせにより、コンパイルまたは実行されるのを待つ時間をほとんど無駄にしていないため、最近、私の生産性が頭を悩ませています。私のIDE=内で視覚的に即座にフィードバックを得て、修正すべき問題があることを知らせます。また、数行以内で特定できるようにテストコードをレイアウトします失敗が発生するだけでなく、失敗の原因が発生する正確な場所のコードのコード StoryQ から得られる素敵な詳細レポートにより、テストのどの部分にパスするかが正確にわかります。失敗し、コードのどこに失敗があるかを示します。開発時間から無駄な時間がすべて取り除かれるので、積極的にデバッグする時間はほとんどなく、問題の解決やテストとコードの作成に多くの時間を費やしています。忙しく、私の仕事に多くの変化をもたらします。また、私が私たちの製品ラインと私たちのプロセスに新しい革新的なアイデアを注入できるように、私が仕事中に他の関心領域を追求する多くの時間を与えてくれました。