簡単なことを難しくする技術 〜またはプログラミング的思想について〜
↓こちらに転載しました
「プログラミング的思考」という言葉の文部科学省による定義を見ると、結局のところ、何かをやる際の手順をブレイクダウンして簡素化・手続き化する一般的な手法の話で、必ずしもプログラミングに限った話ではない。
なんだかバズワードを創り出したなという感じ。
ところで、プログラムを書く際は、仕様書の有無に関わらず、大体以下のようなプロセスをたどる。
やりたいこと(機能)を、まずはとにかく書いてみる
↓
さらにやりたい機能を、どんどん書き足していく
↓
たくさん書き過ぎて見通しが悪くなり、さらなる追加がしにくくなる
↓
各機能の共通部分を抽出・共通化するなど整理・簡素化する
(リファクタリング)
↓
さらに追加とリファクタリングを繰り返す
↓
最終的には機能が豊富なわりにコンパクトなプログラムになる
このプロセスの中で、リファクタリングは重要で、適切な要素分解と整理・簡素化をいかに美しくできるかが、プログラマーの腕の見せ所だ。
ちなみに、仕様書をZなどの形式仕様記述言語で書けば、理想的にはプログラミングは不要で、仕様は数学的な解法で半自動で簡潔化され、実行コードまで生成されるという夢はあるが、現実は厳しい…
それはそうと、文系・理系というのは、あまりにも雑な分類ではあるが、何かしらオフィシャルな文書を書く際のスタンスとして、 「豊富な語彙と修飾語で読みやすい文書を目指す文系」、「修飾語や重複を極力排した簡潔かつ最小の語彙で伝わる文書を目指す理系」という違いを感じることが多々ある。
どちらも、わかりやすさを目指しており、手法の方向性の違いは、論文執筆なども含めたトレーニング(教育)の違いの結果と考えられる。
ところで、プログラミングの基本要素の一つである論理条件(if)を整理・簡略化する手法の一つにカルノー図がある。
とはいえ、プログラマーにとっては、こういった手法を使うまでもなく、論理条件の整理は日々の思考の一部になっていて、もはや思想に近い。
そのカルノー図から逆説的にわかるのは、条件を冗長に書いても、核心部さえ一致していれば、結果は正しくなるということだ。
これを応用すると、簡単なことを難しくすることができる。
「わかりやすくするため」という皮をかぶせ、核心部は変えずに修飾語的な手続きや書類をオフィシャルなものとしてひたすら追加して、同じ結果を得るための労力を増大させる。簡単なことでも冗長にすることで、都度の確認や手続き・書類の理解・解釈が増え、難易度も増す。
ここまで来れば結論だが、「プログラミング的"思想"」が広まれば、新しい取り組みを進めやすくなり、さらなる未知への挑戦が加速する未来に近づく期待が非常に大きい。
12/1追記
これ書いてから、まだ何かひっかかりを感じてた正体が、「プログラミング的思考」が「手続き型言語」を基準に定義されていて、「問い合わせ言語」みたいな他のプログラミングパラダイムの存在を無視していることだと気付いてすっきりした
※プロフィールとかはこちら↓