説明することで自己解決、文芸的プログラミングとフォース:問題解決力を高めるコツはプログラミングの原則・思考にあり(2)(3/3 ページ)
本連載では、さまざまなプログラミングの原則・思考の中から、特に問題解決力を高めるのに役立つものをピックアップ。プログラマーは、その思考法をビジネスに応用し、そうではない人はプログラマーと一緒に働く際に思い出してほしい。今回は「ラバーダッキング」「文芸的プログラミング」「フォース」の重要性について。
プログラミングセオリー
英語 A theory of programming
What 〜プログラミングを導く価値観
プログラミングの最大の関心事は、「最高のコード」を作りあげることです。
最高のコードとは、「拡張方法が多く存在し、余分な要素が存在せず、読みやすく、理解しやすい」コードです。
そうした最高のコードを実現するために、プログラミングには「セオリー」があります。このセオリーは、以下の3つの「価値」に支えられています。
- コミュニケーション
- シンプル
- 柔軟性
これらの価値が、よりよいコードを目指すための、あるゆる決定を左右するものとなります。
Why 〜価値観を技術の選択基準に
プログラミングには、その問題領域に応じた、様々な技術やパターンがあります。
しかし、技術そのものを知る・理解する・覚えることはもちろん重要ですが、技術だけを学習しても、小手先のテクニックを覚えたというだけで、本当の意味で「使える」ようにはなっていません。
プログラミングにおける問題解決は、ケースバイケースです。都度状況が異なるため、目的に沿った適応理由が見出せないと、適切な技術を選択できません。技術を使いこなすには「なぜこんなことをする必要があるのか?」「このことにどんな価値があるのか?」「いつこれを使用するのがよいのか?」ということを知っておかなければなりません。
そこで必要になってくるのが、プログラミングセオリーです。プログラミングセオリーで示される「価値」は、個別技術の「適用理由」となります。
How 〜価値観は原則を通じてコードに適用
プログラミングセオリーで示される「価値」を、判断基準として利用しましょう。すると、技術や手法の適用・不適用の判断が正確になります。応用も利くので、そこから派生した手法、新たな手法を発見する可能性もあります。
ただし、「価値」は、実際のプログラミングに使用するには、いささか抽象的すぎます。価値をプログラミングの実践につなげるための「橋渡し」の概念が必要です。そのために、価値とプログラミングの架け橋となる、6つの「原則」があります。
- 結果の局所化
- 繰り返しの最小化
- ロジックとデータの一体化
- 対称性
- 宣言型の表現
- 変更頻度
本書では、3つの価値と6つの原則について、個別に説明しています。
関連1 〜フォース
ある技術を適用する時に、考慮すべき観点のことを「フォース」と言います。これは、現在取り組んでいる課題に即して考えるための「視点」です。
フォースには、以下のようなものがあります。
- 解決策が満たすべき「要件」(例えば「プロセス間通信が必須である」など)
- 課題に含まれている「制約」(例えば「プロセス間通信のプロトコルは標準に則っていなければならない」など)
- 解決策に望まれる「特性」(例えば「機能の追加が容易である」「追加によって既存の機能に影響を与えない」など)
これらのフォースによって、課題を様々な側面から検討できます。また、課題そのものを詳細に把握できるようにもなります。
ただし、フォースそれぞれは、相補的であったり、相反的であったりします。そこで、必要になってくるのが、フォース間のバランスです。フォース間のバランスが取れたものが、その課題の優れた解決策です。
プログラミングセオリーは、コードの実装方法を選択する際、フォースとして使用されます。つまり、価値を「動機」とし、原則を「つなぎ」としながら、コードの実装方法を「解決策」として選択するのです。
関連2 〜今ある道具はなぜこの形をしているか?
プログラマは「情報処理技術」という道具を使って、様々な問題を解決します。その際、その技術がどのように形作られてきたかを知ることは、うまく道具を使うために必要不可欠なことです。
「形態は機能に従う」という格言があります。これは、「道具の形というものは、目的によって決まる」ということです。
技術もまた道具ですから、ある問題を解決するという目的に向かって、試行錯誤を繰り返し、磨かれ、今の形になっています。この歴史を知らずして、使用手順だけ理解して技術を適用しても、うまく行きません。解決すべき「標的」や「目的」がずれていれば、うまく適合しないからです。
また、「何のために」という目的を知らないと、知識が頭を通過するだけで、その技術を真に習得するに至りません。目的を理解していなければ、今回うまく使えても、次以降の場面で、うまく適用できないでしょう。
よって、技術を学ぶ時は、動作原理や進化の過程、設計の背景にあるものも同時に知るようにします。これで照準が合い、目的が達成されやすくなります。
よいプログラマは、時間がかかっても、言語・ツール・技術・問題領域など、分野を問わず、きちんと理解してから作業に取りかかる傾向があります。特に、プログラミングにおいては、「よくわからないけど、動いたから、これでよし」「よくわからないけど、直ったから、これでよし」とすると、後から必ず品質的な問題が発生します。きちんと理由を説明できるまで、粘り強く理解してから、コードを確定するようにしましょう。
出典書籍
『実装パターン』ケント・ベック, ピアソンエデュケーション(2008)
関連書籍
『Clean Code アジャイルソフトウェア達人の技』Robert C. Martin, アスキー・メディアワークス(2009)
『クヌース先生のプログラム論』有沢誠, 共立出版(1991)
『ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系』F. ブッシュマン他, 近代科学社(2000)
『組織パターン』James O. Coplien 他, 翔泳社(2013)
『UNIX MAGAZINE Classic with DVD』アスキー書籍編集部, アスキー(2007)
『コーディングを支える技術~成り立ちから学ぶプログラミング作法』西尾泰和, 技術評論社(2013)
書籍紹介
プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
上田勲著
秀和システム 2,200円
一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか? 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました!
Copyright © ITmedia, Inc. All Rights Reserved.