これは絶望的に漠然とした質問かもしれません。しかし、新しい概念を学習したり、これまでに見たことのないようなコードを頭に入れようとしたりするときに、人々がたどる論理的思考プロセスに興味があります。
基本的に、問題を分解するためにどのような一般的な手順を実行し、「それを理解する」には何が必要ですか? コードを見たり、問題を解決しようとしたりするときの精神的プロセスがどのように機能するかをフローチャートで表すとしたら、どのように見えるでしょうか?
問題解決に役立つと思われる一般的な参照、ヒント、および精神的な仮定は何ですか?
これは異なるドメイン間でどのように異なりますか? たとえば、Web プログラマーの思考プロセスは、従来のデスクトップ アプリ開発者のプロセスとどのように似ているか、または異なるのでしょうか?
初めて見るアプリケーションの種類が何であれ、それが Web アプリ、デスクトップ アプリ、デバイス ドライバーなど、どのようなものであっても、1 人の開発者が通常従う 3 つのステップがあると私は強く信じています。それがどのように機能するかを理解するために：
全体像をつかむ :
それがどのように機能するかを見てください：
アプリが考え抜かれた方法を理解する (または少なくとも試みる):
1 番目と 2 番目のステップは純粋に技術的なものですが、3 番目のステップはできるだけ技術的でない必要があります。心理学と、アプリがどのように構築されたかを理解することが重要です。明らかに経験が必要ですが、十分によく考え、技術的な詳細で脳の時間を無駄にしない限り、最終的には理解できます。
このプロセス全体でキーボードを使用する必要はありません。紙を読んで、考えて、メモを取るだけです (冗談ではありません: ペンと紙です!)。
ホーホー、これで頑張ってください。それは素晴らしい質問です。たくさんの答えが得られると確信しています。これについて満足のいく答えを出すことはできないと言わざるを得ませんが、私の思考プロセスをフローチャートとして説明するのは最後にしますが、これには黄金の公式があるとは思いません。
私がお勧めできる問題解決の唯一のヒントは、他の人と話し合うことです。壁にぶち当たったとき、仲間と一緒に乗り越えられるのはかけがえのないものです。多くの場合、実際には議論にあまり追加されません。すべての考えを公開する過程で、解決策が明らかになる可能性があります。
人は自分の思考プロセスを調べるのが苦手なことで有名ですが、ちょっと試してみます。IQテストでは視覚空間能力が非常に高く、言語スキルは中から高、数学スキルは中程度です（私のAレベルの数学の成績を説明していると思います）。ソフトウェアの設計を始めるとき、私は形状とそれらの間の接続の観点から考えます。これらの考えを他の人に説明する (または自分で説明する) ときは、単純なブロック図または Jacobson の Objectory メソッドから取られたオブジェクト図を使用します。UML が示唆する過度に複雑なものは使用しません。私は時々、主に自分自身へのリマインダーとして、複雑なことをテキストで説明しますが、数字や数学は決して使用しません。
もちろん、これは私だけの話です。私は数学の達人で、自分と同じかそれ以上のプログラマーと仕事をしたことがあります。
問題全体をそのまま把握することから始めて、認識できるパターンを見つけ始め、一種の再帰的なプロセスで同じことを行い、より簡単に実装して従うことができる分解されたソリューションを見つけます。
私は考えません... 私は処理します。
これは、実際には思ったよりもフリップが少ないです。私はいつもタスクをコンポーネントに分解してから、これらをさらに分解します。これは、ソフトウェアを書くことだけではありません! @Mark Pim U と同じように、順番に物事を進めます。
私が夕食を作るのにとても時間がかかるので、妻は私が夕食を作るときにとてもイライラします。
これは、私が「うまくいく」と答える稀なケースの 1 つです。私はそれらを通して蒸気を巻き込むことによって物事を学びます。私にはギミックも、私を助けるための装置もありません。PHP を学ぶのに少し時間がかかりましたが、その後は Javascript の方がはるかに簡単でした。1 つのことに取り組むと、次の項目が累積的に容易になります。
個人的には、「よし、この整数のリストをループする必要がある」と内部対話を行っています。「しかし、私たちが望む価値を見つけたとき、私たちは壊れることができます。」「OK、開始時にリストは確実に初期化されますか?」
問題解決のテクニックに関する心理学的研究が行われているかどうかを知りたいです。
ジョナサン・サンプソンに似ています - それはちょっとうまくいきます。
現実の問題に取り組むとき、私はそれを乗り越える最も論理的な方法を考えようとします。次に、すべてがうまくいかない場合 (通常はそうです)、物事を成し遂げるために何百もの回避策を取らなければなりません。その最終目標、その論理的な方法に集中し続けるだけで、そこにたどり着くことができます。
しかし、最終的にはうまくいくと判断し、通常は私が計画したものとはまったく異なる完成品に行き着きます. お客様が幸せである限り、私は幸せです！
個人的には、頭の中でコードをテキストではなく絵で見ています (Neil Butterworth のように)。(STIV を引用して) 「参照の共通フレームがない」ため、説明するのは少し難しいです。
私の主なスキルは、既に知っているモデルやシステムと、目の前のタスクとの類似点を特定することです。これらのいくつかの間の接続は、非常に抽象的に見える場合があります。重要なのは、接続を見つけることです。これにより、広く適用可能な一般的なパターンとアプローチが抽象化されます。これに関連して、私がアルゴリズムについて学んだ最も重要なことは、問題は決して「X を解決するためのスマートなアルゴリズムを考え出す」ことではないということでした。それは「既存のスマートアルゴリズム Y で解けるようなモデル問題 X」です。