What is it, naokirin?

きのこ本 感想 Part4

今日はBoost勉強会があってましたね。
私はBoostについてほとんど知らないのですが、C++を使う際には幅が広がりそうです。

さて、今日はきのこ本の10〜12までのエッセイの感想を書いていこうと思います。

10 ツールの選択は慎重に (ジョヴァンニ・アスプローニ, Giovanni Asproni)

確かに既存のツールを使わずにプログラミングするなんてことは普通はまずないですよね。言語の標準機能だけでアプリケーション作成するっていっても大体がかなり小さなプログラムで、ちょっとでも大きなものを作ろうとしたら既存のツールを思いっきり使ったりします。

ただこの既存のツールも、いつ開発停止になるか、いつ仕様変更があるか、一体どんな制約があるか、といった一から作るときには気にすることのあまりない部分を気にする必要が出てきます。

しかし、使わないというのはあからさまにコストが高すぎます。

そこでやはり既存のツールを使う際にどのような点に気をつけ、どんな時に既存のツールを使用するか、ということがこのエッセイに書かれています。

いろいろと重要なことが書かれているのですが、特に私が気になるのは「ベンダロックイン」と書かれているものと、GPLの項でしょうか。

「ベンダロックイン」というのは、過度に特定のベンダのツールに依存していることを言います。
開発が進むとどんどんそのベンダのツールから抜け出せなくなって、仕様変更や価格などに振り回される結果になります。

GPLの項については監修者による注釈がついています。
GPLは確かに企業などでプログラムを「販売目的」として作成している場合はGPLソースコードを使用してしまうと、困りどころでしょう。

ただ、このあたりは使用する側が気をつけるべきところです。たとえ法律を学んでなくとも、法律違反者は罰せられるのと同じです。GPLに関しては賛否両論、と言ったところが大きいのですが、使用者が気をつけるべきというのは変わりません。GPLを見て、「これならOK」と思えば使えば良いですし、「これはダメだ」と思うなら使わないようにすればよいのです。

ちなみに「ウイルスにたとえられる」という記述は大げさですね。そう思う人もいるでしょうが、思わない人もいるはずですから。(コンピュータ)ウイルスは感染すれば誰にとっても不利益をこうむりますからね。

できれば、プログラマとして (特に公開するようなプログラムでは) 使用するツールのライセンスは知っておくべきだと思います。

11 ドメインの言葉を使ったコード (ダン・ノース, Dan North)

お、これはまさに今勉強している設計から実装への手法に良く出てくるドメインモデリングによるドメインの言葉を使っていくという話ですね。

ドメインモデリングとは、簡単に言うと「そのプロジェクトで使う言葉を明確に一意な意味をもつように定義する」ことだそうで、この言葉の集合をユビキタス言語と呼ぶそうです。

このユビキタス言語を使って設計から実装までを行っていくために行われるのがドメインモデリングだそうです。

これを無視した実装を行うと、このエッセイの初めにあるような理解しにくいコードが生まれる、ということのようです。もちろん、カプセル化や役割があまり良くないというのもこのコードの問題だと思うのですが、ドメインがしっかり定義されていればこのような問題も発生しにくくなるのも事実だと思います。

しかし、確かにこんなコードはたまに見かけますね。

if(portfolioIdsByTraderId.get(trader.getId())
.containsKey(portfolio.getId())){ … }

基本的に上のような書いた自分自身でも見にくいとか、打ち込むのが大変、と言ったコードは書かないように気をつけています。ドメインモデリング、などという以上に、自分が読みにくいとか面倒だと思うコードを書かないようにするということからでもこのようなコードは減るのではないかと思います。

12 コードは設計である (ライアン・ブラッシュ, Ryan Brush)

これは確かに最近のソフトウェア業界の話を反映していますね。

スピード重視による品質の低下。

すべてがそうであるとは思いませんが、どうにもスピード重視の要点を間違っているが故に品質の低下を生んでいる部分も少なくない気がします。ある一定のスピードを保ちつつも品質を低下させないようにする方法もないわけではないのですが…

特に自動テストを省略するのはマズいですね。品質を落としたいと言っているようなものですね。

テスト作業を怠ると、テストを行ったときに比べて多くのバグが出ることは論文などで検証されていることです。たしかに「出来た」という瞬間はテストを行う分遅れるのですが、バグの少ない状態になるまでの時間はテストを行っている場合のほうがきわめて早いです。

よく、テストなしで行われた設計、実装によるプログラムは多くのバグが放置されます。
レガシーコードの誕生ですね。

自動テストは重要です。

最後に

今回はどちらかというとプロジェクト全体に大きな問題を与えるような問題への注意が多かった気がします。

最後のエッセイなどは、品質低下というソフトウェア業界にはびこる脅威についてでした。
最近は長くプログラムが残っていく場合が多いようですので、品質低下というのはかなりの脅威ですね。

ドメインの話については最近知ったばかりのことなので、私自身全く実践したことはありません。
しかしながら、一貫した言葉を使ってプロジェクトを進めていくというのは重要だと思います。
一人一人が使う言葉が、同じ言葉なのにニュアンスや意味が異なっていたり、意味が同じなのに複数の言葉を使っていると混乱を招くので、その部分を統一してからプロジェクトを開始するのは重要でしょうね。