Einstellung効果との戦い[終了]

Einstellung効果がより良い「があっても、特定の方法で、与えられた問題を解決するために、人の素因『を指し、』問題を解決するのか、より適切な方法は。」

十分な経験を持つプログラマーとして、過去の経験から「試行錯誤した」パスから常に問題解決にアプローチするこの傾向にどのように対処できますか？

非常に具体的な例を2つ挙げると、Javascriptフレームワーク（jQueryなど）とより優れたWebアプリケーションフレームワーク（ASP.NET MVCなど）が広く使用される以前から、長い間Webアプリケーションを構築してきました。問題のあるドメインやビジネスルールからの時間の問題や緊急の問題に直面しているクライアントの仕事がある場合、解決策を達成するために知っていることだけを使用する傾向があります。これには次のような非常にいものが含まれます

document.getElementById 

または、ASP.NET MVCアプローチで物事を再構築する方法を考えるのではなく、テンプレートバインドコントロール（DataList / Repeater）でASP.NETを使用します。

私が過去に使用したテクニックの1つは、これらの新しいテクノロジーを探索するためだけに存在する個人プロジェクトを作成することですが、これを維持するのは困難です。他にどのようなアプローチが推奨されますか？

これは素晴らしい質問です。そして、これに出くわすのは上級プログラマーだけではないと思います。早期に対処することは、学習者がスキル開発を加速するための素晴らしい方法になる可能性があります。

この問題には2つの側面があります。1つは悪いこと、もう1つは実際には良いことです。

悪い-間違った解決策を選ぶ

以下に例を示します。経験の浅い開発者として、問題AとBの 2つの問題を実際に解決したことがあるかもしれません。この時点で、あなたは知らない問題があることを知っていますが、あなた自身の経験のレンズを考えると、あなたが見るものの多くはAまたはBのように見えます。

新たな問題が生じます。あなたにとって、この新しい問題は問題Aのように見えるので、通常Aを解く方法でそれを解きます。何かが正しくないと感じられ、時間がかかります。そして、あなたが仕事をするにつれて、これが新しい問題、Cであることに気づきます。それはあなたが存在することを知らなかったAのバリエーションです。

では、この間違いを二度としないために何をしますか？2つのこと：

1. この新しい問題で何が違うのかを見つけてください。どのアプローチが異なる方法で機能したのか、そしてその理由を把握します。
2. この問題をカタログ化し、さらに新しい問題の解決に進みます。

これは、この問題を自然に解決するのに役立ちます。10年の経験がある頃には、AからZまでの問題に精通しており、ソリューションのレパートリーは豊富です。

良い-効率

現実の世界では、期限と限られたリソースで、あなたが知っていることを使うことは必ずしも悪いことではありません：

1. 問題解決プロセスの開始時に、新しい問題を既知のすべての問題と比較します。
2. 兆候を認識し、これがどの問題セットのように見えるかを判断します。
3. 100％の一致が得られない場合、経験豊富な開発者は、発見により多くの時間を費やすリスクと、実行の欠陥のリスクを比較検討します。時間の浪費のリスクが高すぎる場合は、自分が知っていることをそのまま進めてください。

それは悪いことではありません-リスク分析を使用して、100％の精度を超える効率を選択しています。それは毎日行われており、私たちがやらなければどこにも行かないものに縛られてしまいます。

だから、あなたの質問に答えるために：

十分な経験を持つプログラマーとして、過去の経験から「試行錯誤した」パスから常に問題解決にアプローチするこの傾向にどのように対処できますか？

1. 新しい問題を探してカタログ化し続ける
2. 問題に適切なソリューションを選択することでより良くなる; どのソリューションを知るのではなく、なぜ正しいのかを知ってください。
3. 意思決定スキルを磨き、磨きます。 効率が正しい選択である場合があり、それらの時間の認識を向上させることは、測定可能な現実世界の利点につながります。

作業時間の20％を確保して、スキルを向上させ、速くするのではなく、正しいことを行います。そうでなければ、ゆっくりと遅れ始めます。これは、短期的には仕事量が減るが、長期的には投資が報われることを意味する場合があります。

難しい部分は、これの角を切る圧力に抵抗しています。習慣が染み込むまで、その角を切ってはいけません。このスキルへの投資が「通常」であると判断した時点で、プロジェクトをときどき急ぐことを選択できます。それまでの間、この時間をオプションと見なさないで、それに応じて見積もりを作成してください。

私の考えでは、ソフトウェア開発は常に絶対的な *最良の*ソリューションを見つけることではなく、物事を成し遂げることです。したがって、問題を常に最善の方法で解決できるとは限らない場合、それは世界の終わりではありません。

ただし、最善の方法で物事を行うことが重要であると感じている場合は、チームの一員として開発することが最善策だと思います。設計について議論し、同僚とコードレビューを行います。人々は通常、2人または3人の間で異なる背景と好みを持っているため、問題と解決策についていくつかの異なる見解を持つ必要があります。

十分な経験を持つプログラマーとして、過去の経験から「試行錯誤した」パスから常に問題解決にアプローチするこの傾向にどのように対処できますか？

定期的にリファクタリングします。リファクタリングでは、過去に作成したコードを精査する必要があります。今回は、古いコードを新鮮な視点で見るために使用できます。主要な技術の変更に対応している限り、必要に応じて更新を行うことができます。

問題のあるドメインやビジネスルールからの時間の問題や緊急の問題に直面しているクライアントの仕事がある場合、解決策を達成するために知っていることだけを使用する傾向があります。

良い。自分の目標ではなく、クライアントのニーズに焦点を合わせています。行く方法。

これには次のような非常にいものが含まれます

document.getElementById

または、ASP.NET MVCアプローチで物事を再構築する方法を考えるのではなく、テンプレートバインドコントロール（DataList / Repeater）でASP.NETを使用します。

Webformsには何も問題はありません。MVCは、Webformを置き換えることを意図したものではありません。これは新しい技術を学ぶ時でもありません。三角形を覚えておいてください。 時間があるときにリファクタリングします。また、最初のステートメントを参照してください。

私が過去に使用したテクニックの1つは、これらの新しいテクノロジーを探索するためだけに存在する個人プロジェクトを作成することですが、これを維持するのは困難です。他にどのようなアプローチが推奨されますか？

維持するのが難しいのは何ですか？うまくいけば、あなたが学ぶために設計されたプロジェクトを維持していないことを願っています。その場合は、サンプルプロジェクトを破棄します。学習目的で1回限りのプロジェクトを作成しても問題はありません。これは非常に良いことです。最初のステートメントを参照してください。

試してみた！=悪い。 「Einstellung Effect」は、ここでは文脈から少し外れています。テストは、「jarを開く」ことを最適化する人々を指します。「jarファイルを開く」方法は限られているため、時間の経過とともに向上することはありません（SFを除く）。ソフトウェアでは、「タスクXを達成する」最良の方法は時間とともに変化します。

箱の外で考えるのに役立つ何かは、それを行うための実際の練習をしていることです。エドワード・デ・ボノは、ラテラル思考と関連する主題について多くの本を書いています。

しかし、どの決定ポイントにおいても、最も重要なのはリスクを評価して受け入れることです。De MarcoとListerのBearsとのWaltzingは、ソフトウェア開発に適用した場合の主題に関する最高の本の1つです。

エクストリームプログラミングやその他のアジャイル手法では、日常的な問題として、新しい（スパイク）ソリューションを試してみてください。私はプロジェクトの立ち上げ中にさまざまなテクノロジーを使って実験を行いますが、それは何度も何度も私を助けて、真の試みに賛成し、時には新しい技術的な宝石を発見することをpedしみません。

チームとして、パターンを破る素晴らしさを認識することでグループを変更できます。私はよくこれを行うために新しい人を使用します。なぜなら、彼らは物事の通常の方法に分解されないからです。これはやや管理上の答えですが、経験豊富なエンジニアとしても、他の人の意見の偏りが少ないことを理解できると思いますので、少なくとも自分の意見と同じくらいの重み（おそらくそれ以上）のランキングで検討してください。

document.getElementByIdの代わりに置くものが、あなたがそれにどれだけ適応しても、本当に時間の無駄であるというだけではないのですか？

編集：両方の例がツールに関するものであることに気付きました。これは、ツールの変更がスキル開発の最大のマイルストーンであると考えるためかもしれません。優れたコーダーは、彼の不思議を機能させるためにチューリングの完全な言語を必要とするだけです。つまり、ツールは重要ではないということではありません。あるツールから別のツールへの移行があなたが考えることができる最大の進歩であるなら、それはあなたが基本的に定量化できない領域で行き詰ったことかもしれません。

十分な経験を持つプログラマーとして、過去の経験から「試行錯誤した」パスから常に問題解決にアプローチするこの傾向にどのように対処できますか？

自己認識

あなたの傾向、弱点、長所に注意してください。

意識的な決定

意思決定を明確かつ意識的に行います。あなたがそれをどうするかを意識して考えずに何かをするためにジャンプしないでください。

学び、申し込む

引き続き新しい手法を学び、それらを適用できる場所を検討してください。適用できる状況になったら、費用便益分析を行います。何か新しいことを試みることの利点が、既知のソリューションの利点を上回る場合があります。