私は最近、自分の時間のほぼ 90% を費やしている退屈な「データよりもフォーム」作業のために手書きで書いた層ごとにクラスを生成するための小さなツールを作成しました (気のめいるようです) ... 経済が改善するにつれて、これについて詳しく説明します。 )
私の質問はこれです - このコードを毎日手で入力する代わりにこのツールを使用すると、実際に開発者として私を傷つけますか? 私は常にこのツールに変更を加えていると感じているので、使用するパターン/行った選択/などを常に把握しておく必要があります.私は間違っていますか？
ツールが何も考えずにコードを吐き出すことができれば、無意識に入力する手間を省くことができます。
最初にツールを作成するには考える必要があるため、ツールの保守と作成は「最先端」にあると思います。
それは良い！もちろん、すべての作業を行うツールを作成することは不可能であり、間違っています。
しかし、繰り返し可能なタスクを自動化することは常に良いことであり、特定のタイプのコードを書くことが繰り返し可能であることもあります。
「Pragmatic Programmer」の本でも推奨されています。
ソース管理で、コード ジェネレーターの出力ではなく、コード ジェネレーターをチェックインしたことを確認してください(後で手動でコードを変更する必要がある場合を除きます)。
あなたは間違いなく間違っていません。私はできる限りコード ジェネレーターを使用しています。現在、CodeSmith を使用して、データベースを参照して DAO を作成しています。
あなたが失うことを恐れているエッジは何ですか？私の考えでは、コード生成を行うことで、実際に優位性が得られます。
Larry Wall (Perl で有名) は、プログラミングの 3 つの重要な美徳を、怠惰、短気、傲慢であると説明しています。
おめでとう！自動化されたプロセスに渡すことができるいくつかの作業を特定し、それを実行したという点で、あなたは良い怠惰を示しました。(悪い怠惰は手抜きや先延ばしにつながり、一般的には仕事をなくすのではなく先延ばしにします。) いくつかの仕事を別のプログラムに首尾よく任せることができれば、煩わしい些細なことに費やす時間が減り、物事の達成と学習により多くの時間を費やすことができます。
あなたのコード ジェネレーター (少なくとも原則として - 私は自分で調べたことはありません) は、少なくともそれに関する限り、正しいものです。
次のステップは、この冗長なコードをすべて生成する代わりに、生成されたコードと機能が一致する基本クラスを作成し、そこからアプリケーション コードを派生できるかどうかを確認することです。生成ではなく継承を使用すると、すべてのプロジェクトでジェネレーターを再実行する必要なく、改善の恩恵を受けることができます。おそらくもっと重要なのは、生成されたコードをカスタマイズすると、ジェネレーターを再実行するとカスタマイズが失われますが、派生クラスのカスタマイズは基本クラスが変更されたときに保持されます。
あなたができるものを生成します。コード生成は、私がここ 2、3 年で手に入れた中で最高のツールの 1 つです。同じコードを何度も入力する (またはコピーして貼り付ける) と、エラーが発生しやすくなります。
何か/他の人にやってもらうことで何かをする時間を減らし、それを行うより良い方法を研究することに多くの時間を費やすことは、通常、より良い方法でそれを行うことにつながります.
これは、プログラミングだけに当てはまる必要はありません....
コード生成を書くことは、優れたアーキテクチャのニュアンスを学ぶのに役立つことがわかりました。デザインの狭い視野とは対照的に、一般的なパターンが見え始めます。とは言っても、優れたオブジェクト指向コードの代わりにコード生成を使用しないでください。新しいテクノロジーを無視するほどコード生成を愛してはいけません。たとえば、.NET を使用していて、データ アクセス用のコード生成を作成している場合は、Linq to SQL または NHibernate を使用しないための正当な言い訳が必要です。同様に、動的データは、フォーム オン データの多くのシナリオで役立ちます。したがって、私のアドバイスは、必要に応じて新しいものとコード生成をスパイクすることです。
コード生成に関する私の 2 セントは、リファクタリングでの使用にも重要だということです。部分クラスと優れたファイル比較ユーティリティ (Araxis または BeyondCompare) が不可欠であることがわかりました。
生成されたコードを 1 つのファイルに保存し、そのクラス用に作成したカスタム Tweak を別のファイルに保存します。
このプラクティスにより、これらの包括的なフレームワークの変更を迅速に実装できるようになり、カスタム ロジックを簡単に保存しながら新しいパラダイムに移行するのにも役立ちます。
コードスミスFTW！
ビルド サーバーは、すべてのコードが確実にコンパイルされるようにするのに優れていますが、ストアド プロシージャなどとの署名の違いには対応していません。コード生成を定期的に実行すると、これらの変更がいつ発生するかをより簡単に特定できます。単体テストは SP が間違っていることを示し、コード生成はそれを正しくする方法を示します。
いいえ。なぜ IDE がこれほど普及していると思いますか。Visual Studio を使用するすべての人が、IDE の助けを借りずにプログラムで GUI を作成する必要があるとしたら、それはひどいことです。VisualStudio を使用するほとんどの人は、IDE で作成しているフォームを手動で作成する方法を知らないことは間違いありません。しかし、それは何も悪いことではありません。
プログラミングの単純なタスクを取り除くために、可能な限りコード生成を行うことを信じています。優位性を失うことはありません。重要で興味深い作業により多くの時間を費やすことができるため、おそらく優れたプログラマーになるでしょう。
ところで、あなたのツールは面白そうです。どこかでリリースしたことはありますか？
コード生成は、何を生成しているのかを理解していれば問題ありません。物理学者が計算機を使用するのは、自動化している数式を理解し、貴重な時間を重要なタスクに費やすほうがよいことに気付いているからです。
コード生成は、The Pragmatic Programmer が提唱する非常に貴重なDO: の1 つです。私は本当にその本をお勧めします。これはPragmatic Programmer のクイック リファレンスです。
コードを生成しないというのは、ほとんど偽善的です。ここでは、従来は手作業で行われていたこれらのタスクをすべて自動化しています... それでも、コードを簡単に生成できる場合でも、多くの人がまだすべてのコードを手動でクランクしています。
コード生成に関する私の唯一の経験は、Common Lisp のマクロです。それらは常に使用されています。反復的なタスクを自動化するものはすべて有益です。それがプログラミングです。
マックの物語を読んでください。
ツールに変更を加えてコードを再生成するたびに、すべてのモジュールで手動で設計変更を行ったと想像してください。
コードの生成を開始して速度に慣れてきたので、生成されたコードにバグが発生することはめったにないことがわかりました。