 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| レベル4を抜けるためには？ | ||||||||||||||||||||||||||
|
レベル4のプログラムから上のレベルにあがるためには以下のようなテーマに取り組む必要があります。 |
||||||||||||||||||||||||||
| オブジェクト指向を理解する | ||||||||||||||||||||||||||
|
レベル4は、C言語などの構造化言語のようなコーディングになっています。機能分割をさらに推し進めて、操作する対象を物として捉え、クラス分割を行うことがオブジェクト指向を理解する第一歩です。 まず、オブジェクト指向的な考えができるように、プログラミングスタイルを変える必要があります。 |
||||||||||||||||||||||||||
| クラス設計を実施した後に、コーディングを実施すべき」か？ | ||||||||||||||||||||||||||
|
必ずしもそうとは思いません。 コーディングの前にしっかりとクラス設計を行い文書化しておくことにより、コーディングが楽になるのは事実です。しかし、プロジェクトによっては、様々な状況からクラス設計をしっかりと行えない場合もあるでしょう。 クラス設計をしっかりと行って文書化していた場合、仕様が変更されると設計書とソースコードの両方を修正しなければなりません。納期というプレッシャーの元では、「とりあえずソースコードだけ修正して、後から設計書を修正する」とする場合が多いと思います。しかし、結果として設計書の修正を忘れてしまったり、修正内容自体を忘れてしまったりすることが常です。 これより、ソースコードから設計書をリバースエンジニアリングするという手法を取ることもあります。 |
||||||||||||||||||||||||||
| 「意識改革が必要」なのでは？ | ||||||||||||||||||||||||||
|
構造化プログラミングから、なかなかオブジェクト指向の考え方へ移行できないのであれば、それはオブジェクト指向の利点が見えていないからなのかも知れません。 構造化プログラミングの考え方をベースにクラス分割を行っても、アプリケーションからは、「if文」や「switch-case文」はなくすことができません。分岐対象が増えた時、「if文」や「switch-case文」を修正しなければならず、修正が行われる限り、バグを内包する可能性があります。 しかし、ポリモフィズムなどのオブジェクト指向の考え方を適用することにより、「ソースコードから制御文を減らす」ことができます。 なお、バグを出さない究極の真理は「コードを書かない」ことです。つまり、コードの量とバグの量は比例するのです。 |
||||||||||||||||||||||||||
| レベル5から抜けるためには？ | ||||||||||||||||||||||||||
|
ここで説明したレベルでは、レベル5が一番上のレベルですがそれでレベルが終わってしまうわけではありません。これ以上のレベルにあがるためには、規約だけではなく更なるプログラミング経験あるいは設計に関する技術をマスターしていく必要があります。その意味でレベル5が取り組むべきテーマは以下の通りになります。 |
||||||||||||||||||||||||||
| デザインパターンの設計を習得 | ||||||||||||||||||||||||||
|
レベル5はクラス分割を行い、ポリモフィズムを用いたプログラムでした。設計が変わらず、データのみが追加されるようなタイプであれば、これで問題ありません。しかし、設計が拡張された場合、現在のプログラムでは対処できません。 1つの解決策としてデザインパターンを用いるというのがあります。デザインパターンとは、過去のソフトウェア設計者が考え出した知識を、再利用しやすいように形式化したものです。設計の拡張性に対応できるデザインパターンも存在します。 デザインパターンを理解し設計に適用することで、より柔軟性／拡張性の高いプログラムにすることができるでしょう。 |
||||||||||||||||||||||||||
| 案件に応じた、ゴールの見極め | ||||||||||||||||||||||||||
|
デザインパターンを利用することは、柔軟性と拡張性をソフトウェアにもたらします。しかし、柔軟性と拡張性を見越したコーディングは、プログラムに無用な複雑さを持ち込んでしまいます 最小の投資で最大の価値を得るためには、案件に応じた最適な設計を絶えず意識しておかなければなりません。「なんとか動いて、最も無駄のないものをやれ（"Do the Simplest Thing that Could Possibly Work）」と「どうせ要らないって（You Aren't Going to Need It）」という言葉があるぐらいです。 |
||||||||||||||||||||||||||
| まとめ | ||||||||||||||||||||||||||
|
今回までで「コーディングの心得、5ヶ条」について、背景にある考えや意図を説明してきました。 良いコードを書くという行為や考えは、コーディングスタイルを守り、「他の人が読んでも分かりやすいと感じられるソースコード」「保守性の高いプログラム」を心がけるというものでした。 それは、自分本位にならず、変化が起こることを前提としてコーディングを行うということを意味しています。 設計の変更は、プログラマが思っているよりも早くやってきます。システムを設計し、実装することでそれまで見えていなかった問題が表面化するからです。そうした変化の際に、柔軟に対応できるように、「コーディングの心得」を常に意識し、実践することが重要なのです。 改めてコーディング規約を掲載します。
|
||||||||||||||||||||||||||
|
表4：コーディングの心得、5ヶ条 |
||||||||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
-
-
連載
