1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

議論の前に、その前提を確認しておこう!(ソフトウエアの品質とは?)

Last updated at Posted at 2020-09-25

1.問題提起

こちらのサイトでは様々な論が投稿されています。
僕は特に、プログラミング言語機能の解説や流行の開発パターンのメリットを語るものなど、根底にオブジェクト指向が潜むものに関心があります。

しかし、本来は有益な内容であったとしても曖昧な部分があって、結局は役に立たなかったり、理解できなかったりするものも少なくないように思います。惜しい気がするのです。

これは僕にとっての問題というだけでなく、おそらく、多くの人がその知識や経験を実際に応用しようとしたときに役に立てにくい、といった問題になっていると思うのです。

1-1.曖昧であったり、抽象的な説明に終始

我々善良なエンジニアは、誰しも「より良いものを作りたい」と思っているはずです。そして、このサイトでは知識や経験を共有してお互いにより良いものを作れるようになりたい、という願いがあるのだと思います。

その、「より良いもの」ってなーに? (チコちゃん風に)

これをはっきりさせないために、目標がうまく定まらず、結果的に内容が曖昧になりがちなのではないかな、と思うのです。

1-2.誰にとっての問題か?

「こうすれば良くなりますよ」とか、「ああすればより安全なコードになりますよ」とか、
それがだれにとって良くなるのか、だれにとって安全になるのかが不明瞭な説明を多く見かけます。
自明であるかのような説明なのですが、いつの間にかその「だれ」が別な人に替わってしまっている、といった文章もありがちな気がします。それを読んで理解した気になっても、いざ実践の場で応用しようとするとうまく行かなかったりします。

2.ソフトウエアの品質とは?

「より良いものを作りたい」、つまり、品質の高いソフトウエアを作りたいということですね。
では、ソフトウエアの品質とは具体的にはどういうことでしょうか。
まずはここを確認しておきましょう。

  1. 機能性
  2. 安定性
  3. 保守性

僕は、ソフトウエアの品質はこの3点に集約できると考えています。
そして、これらのどれに役立つ話なのか、しっかりと意識された文章が優れているのだと思います。

2-1.機能性

使いやすさや処理速度等の性能、ゲームなどではその面白さまで含まれます。

企画や機能設計など、プログラミング以前のフェーズが大きく影響し、プログラミングにおいては主に処理速度(場合によっては実行モジュールの小ささ)のことを指します。
安定性や保守性とトレードオフの関係になることがあります。

2-2.安定性

動作の安定性のことで、バグが含まれないことが求められます。

安定性と機能性は相反する場合がありますが、現在はハードウェアの性能が高くなった分労力を安定性に振り分ける余裕があるので、多くのプログラミングでこれがせめぎ合うケースは少ないと思われます。もちろん、リソースに余裕のないハードウェアをターゲットにしたり、処理速度に関する要求仕様が非常にシビアなジャンルもあり、全てが容易に両立できるわけではありません。

2-3.保守性

機能追加や修正のしやすさです。

他の要素に比べて見落とされがちですが、非常に重要な要素です。
機能性とはトレードオフの関係になる場合もありますが、安定性とはトレードオンの関係になる場合が多いと思われます。

3.全ての立場を見つけよう

少なくとも、以下に挙げるいくつかの立場については常に明確に意識して(あえて曖昧にすることを含め)議論を進めたいものです。足りなければ是非追加してください。
そして、どの立場にとっての話なのかを明確にすることで格段に読者の理解が進むのではないでしょうか(文章の作者にとっても思考の助けになるはずと思います)。
逆に避けたいのは、全ての立場を含んだような言い回しかも知れません。まるで、神の立場でのお言葉のような。
たとえば、そんなオブジェクト指向の聖書のような書籍は存在しそうですが、役に立て難いのです。

3-1.明日の自分は他人とみなす

人は忘れる生き物で、ソフトウエア制作の全工程を独りで行ったとしても、客観的な視点を忘れないようにしましょう、という言葉です。
ここでは客観的な視点、つまりコーディング担当者と、非担当者の2者が現れました。

3-2.各プログラム担当者

実際にAという部分プログラムとBという部分プログラムの担当者が異なる場合もありますが、同一人物だったとしてもそれは異なる立場であると考えます。

なぜなら、部分のプログラム(関数だったりクラスだったり)にはプロバイダとユーザが存在するからです。プロバイダというのは、実際にそれを造る人やそのプログラムそのもの。ユーザはそれを使ってプログラムを作る人、あるいは使う側のプログラムそのものです。
もちろん、ほとんどのプログラムはプロバイダとユーザの両方の立場を含みます。

この2者以外に忘れてならないのは、プログラムのプロバイダとユーザの両方を俯瞰する立場です。それは、3-1の非担当者とも共通する、言わば客観的な視点をもつ立場です。

3-3.その他の立場

プログラミングでは3-1、3-2等が考えられますが、完成したプログラムを前提にすれば、制作者と使用者といった立場などが考えられます。他にも見落としている立場があるかも知れませんので、随時追加して考えて見ましょう。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?