プログラミングの目的はコーディングではなく、問題解決です！
なので、今回選出するプログラミングにおける4大ツールは、問題解決をするためのツールということになります。どれもプログラミングだけに限らない、様々な問題への取り組み方を示す考え方です。
だからプログラミング=コーディングという捉え方はミスリーディングなわけで、それ以前の能力が求められている、っていうことは周知させるべきじゃなかろうか、と思います。
プログラミングにおける問題解決のためのアイディアや方法論の多くは、この4つの基本ツールの実践、あるいは拡張であり、つまり、これらを押さえておけば大体クリアできるんじゃね？という仮説を元にその考察を書いてみました。
要するに問題解決における4大基本パターン、がこれなのではないのかと。今回はこの4つの考え方について、概要をまとめると同時にその課題や問題点についてもまとめました。万能な解決法はない、ということですね。
分割統治
大きいもの、難しいものは分割して、統治せよ。これはもうプログラミングのあらゆる場面で出てくる基本的な考え方だと思います。
コードを切り離し、独立させれば、再利用できるモジュールになります。ある処理を切り離してモジュール化すれば、それは関数であり、データと振舞いをまとめればクラスとなります。
オブジェクト指向はコード全体をクラス単位に分割し、クラスに仕事と責任を分割するという考え方ですし、パイプライン化やCPUのマルチコア化も分割統治ですよね。
つまり、この考え方はあらゆる問題解決に使われている最重要ツールということが出来ると思います。
抽象化（及び、情報隠蔽）
細かい部分を考えなくて済むように物事を一般化して、いろんなケースに使えるようにする、という考え方。
コンピュータの本質的な厳密さを人間の認知能力、思考能力に合うように緩和させるためのツールです。人間の曖昧な命令をコンピュータが適切に判断して、臨機応変に処理してくれたらいいな～という願いをかなえてくれる、かもしれません。
前項で関数は分割統治法の一つとしましたが、同時に関数化というのは、詳細な処理を隠し、その一連の処理を概念化する名前を与える作業でもあり、抽象化というアイディアの体現でもあります。
単純化
難しい問題をどう解決するべきでしょうか。とりあえず、簡単な問題に変換して、まずはそれを解いてみると解決の糸口が見つかるかもしれません。難しいことを難しく解決するのは、はたして良いことなのだろうか、という問題提起です。
分割することもある意味で単純化ではあるので、分割統治法と少し被ってる部分もあるかと思いますが、基本的には何かを削ったり省略することがこのツールの本質的な実施方法だと思います。
例えば、数学モデルを作る際に、どこまで精度を求めるのか、大体あってれば良いなら、そこまで厳密な計算をしなくてもいいんじゃないか、というような考え方です。
You Ain't Gonna Need It
YAGNIとされる考え方です。余計なことをしない、必要のないコードは書かない、というもので、プログラミングで問題になる、大量のコードの管理についてのアイディアです。
明らかにプログラミングというのは、開発が進むにつれて既に書き上げたのコードと向き合う時間が増え続けます。どうしたって、既存のコードを読んだり、手直ししたり、拡張したりするのが作業の大半を占めるようになるのです。
この負担を出来る限り減らすための考え方がYou Ain't Gonna Need It（多分、それは必要ない）です。
これまでの三つのツールを上手く使えば、単純で小さなコードは書けるはずです。しかし、小さなコードは積み重なっていけば、それは巨大なコードになり、その管理が問題になります。
余計なコードを書かない、重複させないためのテクニックの一つとして、継承があり、これはクラス間の上下関係を作ることで、新しいクラスで書く必要のあるコードだけ書けば済むようにするアイディアであり、これもYAGNIの実践だと考えられます。
無駄な努力はしない、必要のない苦労はしない、ということ。
これら4つが経験論的に、問題解決において頻出するな考え方なのかなと思いました。というわけで、ここからは各ツールの問題点や課題について書いていきます。
分割統治法の問題点
どう分割すればいいのか、という線引き。バラバラに分割されたコードは当然分かりにくい。分割されたコードの依存関係の管理。
プログラミング言語とかコーディング以前の、物事への洞察力や知識、分析力が問われる。
コードが分割されることによって、実際の処理の流れはあちこちを飛び回るようになり、人間にとってそれを追うことが難しくなります。
正しくコードがクラスに分割されないと、各クラスが負うべき責任の所在が曖昧になります。そして、コードを正しくクラスに分割することは困難です。
抽象化の問題点
抽象化する、ということは詳細が隠される、ということであり、具体性を欠き分かりにくいものになっているかもしれません。
アレとかソレと言って物事を示すのは抽象化だけど、それが理解できるのは普段の関係性とか文脈が分かっているからで、急にアレやって！とか言われても分からないよね、という話です。
抽象化は実体を隠して、物事を大枠で捉える考え方なのだけど、そこで省かれる詳細を理解しなくても良い、というわけではないよね、ということなのだと思います。
単純化の問題点
単純化のために省かれたせいで、正確性が損なわれるかも！省いていいものかどうかをどう判断するか。精度問題。
単純化の問題はシンプル（単純）で、当然シンプルにし過ぎたら、精度落ちるよね、って話で、これは比較的対応しやすい課題なのかなと思います。
YAGNIの問題点
必要か、そうでないかを誰がどう決めるのか。仕様書？なにそれおいしいの？これも結局、線引き問題なのかもしれません。
ただ、ゲーム開発においては遊びで作ってたミニゲームなどが実際に本編に組み込まれる、なんて事例がかなりあるので、そこら辺は難しいですよね。
余計なコードを書かないために抽象化を使って、その結果分かりにくくなるのであれば、冗長なコードの方がいいかもしれません。
この時に無駄に長いコードがむしろ必要なケースということになります。なんでもかんでも減らせばいいというものではない、ということです。
まとめ
というわけで、四大基本ツールについて考えてみました。経験論的に、体感として良く使う考え方から選出してみました。
