楽器の法則とプログラマの呪い

に慣れていない場合 楽器の法則、マズローのハンマー/小槌、またはゴールデンハンマーとしても知られています。

あなたの唯一の道具がハンマーであるならば、あなたはすべてを釘のように扱います。

私の理解では、楽器の法則は、使用方法がわかっている楽器やツールに制限されることを意味します。たとえば、ネジ、木、およびハンマーを使用している場合、ネジを木にうまく差し込むことができますが、ドライバーの方が適しています。

楽器の法則も意味します あなたが知っている楽器の完璧さへの執着。 Delphiが最高だったので、他のプログラミング言語に悩む必要はなかったと確信した当時を思い出します。今、私は他の多くのプログラミング言語を使用して少し時間を費やしてきたので、他のプログラミング言語の価値と使用法も確認できる一方で、Delphiが最高だと自信を持って言えるでしょう。

新しいテクノロジー、フレームワーク、言語、または方法論について学ぶ価値があると思います。次に、ジョブに適したものを選択できます。これは、それらすべての専門家である必要があるという意味ではありませんが、選択に自信があることを十分に知っている必要があります。

これの逆は、新しいエキサイティングなテクノロジーを追い求め、数年ごとに物事を再現することへの執着です。これは開発者を楽しませますが、実際にビジネス価値を提供するわけではありません。繰り返しますが、Delphiは、既存のコードを尊重しながら、新しいプラットフォーム、機能、フレームワークに移行するため、これでうまく機能すると思います。

だから何ですか プログラマーの呪い?

他のプログラマーと話していると、2つの動作が見られます。 1つ目は、彼らが生活の中で（仕事中やそれ以降に）遭遇するすべての問題は、「これを行うプログラムを書くことができた、」またはいくつかのバリエーション。ひいては、彼らはまた、それらをより良くする方法を見るために、どんなソフトウェアシステム（彼ら自身によって開発されたものでさえ）に批判的な目を向けます。その結果、問題を修正したり、問題をより適切に修正したり、または可能かどうかを知りたいという好奇心から、プロジェクトの膨大なバックログが作成されます。

これは楽器の法則に似ていますが、プログラミングの柔軟性と能力を学ぶことで、それを適用する多くの機会が見られるようになるので、私はそれをもっと見ています。私は他の業界の人々と話をしましたが、一般的な傾向はかなり普遍的だと思います。プログラミングは（私の意見では）他の多くの応用技術よりもはるかに強力で柔軟性があるというだけです。

2番目の動作は、以下に該当する場合により注意が必要です。 「図書館」または「フレームワーク」手元のプログラムを終了する代わりに。たとえば、問題を解決するプログラムを作成していて、その過程で、同様の問題を解決する必要がある場合に備えて一連のライブラリを作成します。

再利用可能なライブラリ、関数、コンポーネント、およびフレームワークを持つことには価値があります。秘訣は、それらの作成が出荷の邪魔にならないようにすることです。これに対処するために私が見つけた最良の方法は、必要なときにのみライブラリを作成することです。手元の問題を解決するために、適切なレベルの結合を使用してコードを記述します。少し再利用する必要がある場合は、再利用可能なものにリファクタリングすることを検討してください。その後、より多くの場所で使用するにつれて、本格的なフレームワークが完成するまで、リファクタリングと拡張を続けることができます。

プログラマーの呪いをあなたの人生でどのように見ていますか？すべてのプロジェクトが一連の再利用可能なフレームワークを生成しないようにするには、何を使用しますか？

ソース：http://delphi.org/2018/01/curse-of-the-programmer/