いつ仕事を止めて道具を作るべきですか？

ソフトウェアエンジニアとして、私たちは常に生産性を高める効果的なツールを手に入れたいと思っています。そして、日々の作業では、既存のツールに満足できないことがよくあり、退屈な作業を自動化するための、より優れたGDBスクリプト設定、Vimスクリプト、およびPythonスクリプトなどのより良い方法が必要です。

ただし、ツールを作成するには時間とエネルギーも必要になるため、実際にはトレードオフになります。すぐに生産性が向上するわけではありません。したがって、仕事をやめ、将来の痛みを和らげるためのツールを作成する時かどうかをどのように判断しますか？

これらのいずれかが当てはまる場合、「ツールを作成」​​します。

1. タスクは私を悩ます
2. タスクでのヒューマンエラーのリスクが大きすぎます

2番目のオプションの「リスク」は巨大である必要はありません。1つの小さなツールを構築するコストは通常​​小さいため、節約できるのが週1回10分間のビルドを実行するリスクだけであれば、通常はとても早く返済する。

できる限りツールを小さくしようとしています。今はタスクを少しだけ簡単にして、次回はまた改善するかもしれません。

これは、毎回最大の痛みを修正するだけであり、実際にあなたを傷つけない問題の修正を作成しないことを意味します。

経験上、私は通常、うなり声の多い仕事を一生懸命押すだけで、最も時間効率が高いことがわかりました。ツールを作ることはしばしば魅力的です。私は次の場合に抵抗することをあきらめます：

• このツールには複数の目的があります。優れたチェスプレーヤーは、各移動で2つのことを達成しました。敵の駒をブロックし、司教を解放します。初心者はおそらくそれを行うために2ターンを必要とするでしょう。同様に、ツールがたった1つのことを行うか、わずかな労力で2つ行うかを検討します。たとえば、生データファイルの修正を支援し、人工的なテストデータを作成します。
• 将来の有用性。今週の作業の時間を節約できるかもしれませんが、来週の新しいプロジェクトで私や誰かの時間を節約できるでしょうか？
• 新しい言語、ライブラリ、デザインテクニックなどを学ぶ良い機会です。私はそれをする時間があります。このツールは、教育にすでに与えられた時間を使用して、何か教育を行うことの有益な副作用です。
• 物事を機能させるのに深刻な問題があるとき。パラシュートなしのスカイダイビングのように、本当に時間をかけてパラシュートを作成または購入する必要があります。有意義な実験結果が得られない場合、または新しいWebアプリがまったく機能しない場合は、停止して、見えないものを測定したり、コンポーネントを駆動したり、一部を交換したりするツールを作成または購入する必要がありますシステム。作業がツールを必要とするために完全にハングアップするとき、私は将来の使用または複数の使用を気にしません。必要性は十分に重くなります。

私の経験則では、3番目に何かをしなければならないときは、それを自動化するために小さなスクリプトを書くか、または私のアプローチを再考するときです。

私はこの時点では本格的な「ツール」を作成していません。以前は手動で行ったことを自動化する小さなスクリプト（通常はbashまたはpython。perlも動作します。PHPも）です。それは基本的にDRY原則（または本質的に同じものである単一ソースの真実の原則）のアプリケーションです-2つのソースファイルを同時に変更する必要がある場合、それらが共有するいくつかの共通の真実がなければなりません。真実は、1つの中央の場所に因数分解して保存する必要があります。リファクタリングによって内部的にこれを解決できるのは素晴らしいことですが、場合によってはこれが実行不可能であり、そこにカスタムスクリプトが登場します。

その後、スクリプトは本格的なツールに進化する場合と進化しない場合がありますが、私は通常、多くのことをハードコーディングした非常に具体的なスクリプトから始めます。

私は情熱を持って不平を言うのは嫌いですが、それはデザインが悪いか間違っていることの表れでもあると強く信じています。プログラマーにとって怠laであることは重要な品質であり、反復作業を避けるためにかなりの時間を費やすような種類であることが望ましいです。

もちろん、バランスがマイナスになることもあります。コードのリファクタリングやスクリプトの作成に3時間費やして、1時間の反復作業を節約できます。しかし、通常、バランスはプラスであるため、直接明らかではないコストを考慮すると、人間の失敗（人間は繰り返し作業が非常に苦手です）、コードベースが小さい、冗長性の低下による保守性の向上、自己文書化の向上、将来の高速化開発、よりクリーンなコード。そのため、現在残高がマイナスに見えても、コードベースはさらに大きくなり、3つのデータオブジェクト用のWebフォームを生成するために作成したツールは、30個のデータオブジェクトがある場合でも機能します。私の経験では、バランスは通常、単調な作業を優先して推定されます。おそらく、反復タスクは推定が容易であり、したがって過小評価されているためです。一方、リファクタリング、自動化、および抽象化は、予測可能性が低く、より危険であるため、過大評価されていると認識されています。通常、結局のところ、自動化はそれほど難しくないことがわかります。

そして、遅すぎるリスクがあります。3つのまったく新しいデータオブジェクトクラスをシェイプにリファクタリングし、それらのWebフォームを生成するスクリプトを書くのは簡単です。そして、それを行うと、27のクラスを簡単に追加できますスクリプトでも動作します。しかし、30個のデータオブジェクトクラスがあり、それぞれが手書きのWebフォームを持ち、それらの間に一貫性がない（「有機的成長」とも呼ばれる）ポイントに到達した場合、そのスクリプトを書くことはほぼ不可能です。これらの30のクラスをフォームで維持することは、コーディングの繰り返しと半手動の検索置換の悪夢であり、一般的な側面の変更には30倍の時間がかかりますが、問題を解決するスクリプトを作成して、プロジェクトが開始されたとき、昼休みは簡単でしたが、今はバグを修正し、ユーザーを教育し、場合によってはあきらめて元に戻すことからなる1か月の余波の恐ろしい見通しを持つ恐ろしい2週間のプロジェクトです古いコードベース。皮肉なことに、30クラスの混乱を書くことは、いつも便利なスクリプトに乗っていた可能性があるため、クリーンなソリューションが持っていたよりもずっと長くかかりました。私の経験では、繰り返し作業をあまりにも遅く自動化することは、長時間実行される大規模なソフトウェアプロジェクトの大きな問題の1つです。便利なスクリプトにずっと乗っていたからです。私の経験では、繰り返し作業をあまりにも遅く自動化することは、長時間実行される大規模なソフトウェアプロジェクトの大きな問題の1つです。便利なスクリプトにずっと乗っていたからです。私の経験では、繰り返し作業を遅らせる自動化は、長時間実行される大規模なソフトウェアプロジェクトの大きな問題の1つです。

私はこれを思い出しました：

もちろん、これに関する問題は、実際の状況では、テーブル内の適切なセルを選択するためにそれらのデータを簡単に測定できないことです。そして、他の回答で言及されたように、他の変数があります（エラーのリスク、タスクは1回でもそれを行うには退屈すぎる...）、方程式に追加する必要があります。

したがって、私の答えは、それは本当に状況に依存し、すべての状況で「正しい」答えを得ることは望めないということです。すべての料理の本があれば、人生はつまらないでしょう。

これは私の経験で大きな問題です。通常、ツールの構築は、ツールを構築するための作業を中止する意欲的な開発者に任されています。これは、価値を提供する場合でも、開発を妨害することがよくあります。ツールの構築は、開発「プロセス」の統合された部分と見なす必要があります。

ヘッダーエラーが発生して別のレビューをスケジュールするコードレビューに参加したことを覚えています。これらの多くは、ツールによって検出された可能性があります。たとえば、不正なslocカウント、要件の欠落、フォーマットエラー。perlで書かれたツールは、提供されたコードからヘッダーを生成し、Oracleデータベースの要件を検証しました。これは「プロセス」の一部ではなかったため、短期的にはツールの配信が遅れると見なされていました。

チーム全体が定期的に停止し、ツールの作成によって自動化できる以上の手動作業があるかどうかを確認する必要があります。

他の答えはすべて良いですが、小さなツールを構築するために時間を費やすことが重要であるもう1つの理由を追加します（そして、.vimrc、.emacsなどをカスタマイズします）。

創造的または動機付けで「わだち掘れ」に陥り、何かをすることは、「比 "を混ぜ合わせるために」再び「ジュースを流す」ことがあります。理想的には、それはプロジェクトを生産的に前進させるものですが、それが少し接線的であり、あなたを刺激するものであれば、それも良いことです。

空白の画面を見つめているのではなく、単に大きなタスクの進行状況を見るのに苦労しているだけかもしれません。そのような状況では、具体的な何かに刻みをつけると、どこにも行けないように感じることがなくなります。

これのバリエーションは、「バックバーナー」の上にあるべきものについて考え続けるときです。少し時間をとってそれを行うと、気分が落ちて、メインタスクに再び全エネルギーを投入できるようになります。

それはあなたがツールを作ると考えるものに依存します。間違いなく、私は私がそれらを作るので、他の開発者が...軽薄検討するという方法でそれらの負荷を作るちょうど約すべての最も基本的なファイルシステムコマンドを除きます。

これをサポートするために2つの理論的根拠を使用します。

• これはDRY原則の拡張です。何かを繰り返したい場合、手作業の努力は人的資源の最も効果的な使用ではありません。
• 私がやったことを記録する効果的な方法ですので、何かを構築した場合、私（または他の誰か）は数週間または数ヶ月後にそれをやった方法に戻って参照したいと思うかもしれません。

時折、彼らはより大きなツールに成長し、インタラクティブな機能を獲得しますが、そうでない場合でもレコードとしての価値はあります。