自分が「プログラマが知るべき９７のこと」のエッセイを読んで、勉強になるなあと思ったことの「その４」です。
今回のポイント
プログラミングをテーマにしたエッセイ集です。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
97のこと・・と言いながら、107個ものエッセイがあります。
それなりの達人プログラマの方々が書いたエッセイですから、勉強になります。
今回は、そんな自分が共感して学んだこと「その４」として
「優れたものはすべてシンプル」という心構え
にというキーワードでポイントを引用しながら書きます。
わかりやすいコード＝シンプルなコード
最近、他の人の書いたコードを読む機会が増えています。
運用やテストで発生した問題の原因調査の役目がまわってくることが増えたからです。
毎回違う開発者が書いたソースコードを見ていて思うのが。
やはり。
プログラムのソースコードは他の人が見てもわかりやすく書くべき
ということです。
それほど、読みづらいコードというのは世の中に存在します。
だから。
このコードはいずれ他人によって使用され、実行されるのだということを、つい忘れがちになります。
他人がコードを拡張することもあれば、自分の書いたコードに依存して誰かがコードを書くこともあるということを忘れてしまうのです。
という戒めとか
「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。
という心構えの必要性は、まさに実体験として痛感してます。
では。
どういうコードが「わかりやすい」かです。
自分が一番共感できたのは
「わかりやすいコード」＝＞「シンプルなコード」＝＞「美しいコード」
という図式です。
エッセイから引用すると
美しいコードとは、突き詰めれば、シンプルなコードのことです。
システムを構成する各部分が全てシンプルで、個々の部分が担う責務も最小限に抑えられていて、部分どうしの関連もシンプル、そんなコードです。
シンプルできれいなコードになっていればテストもしやすく、開発速度を落とさずに長期間に渡る保守が可能になります。
であり、美しい・良いコードとは
アプリケーションやシステムが全体としてどれほど複雑であっても、個々の部分を取り出してみると、全てシンプルになっています。
単一の責務を持ったオブジェクトは、メソッドも全て機能が絞りこまれており、名前を見ればすぐに、持っている機能がわかるようになっています。
です。
とにかく「シンプル」・・それが一番重要なメッセージです。
シンプルさは捨てることによって得られる
新規作成時はシンプルで良いコードだったのに、何年もの間に修正がはいることで、いつのまにかスパゲティコード化することも現実にはあります。
理由は簡単。
既存のコードに最低限の修正だけをして済ませたいと考えるのは自然なことです。
たとえ既存のコードがひどいものでも、それで済めばありがたい、と考えるわけです。
質の悪いものであっても、過去に書いたコードを消せないプログラマが多いでしょう。
すべてをゼロからやり直して新しいコードを書くと、修正よりはるかに労力がかかるのではないかと恐れているのです。
です。
これは絶対やってはいけないこと。
あらためて
良い部分だけを残して悪い部分は消す、ということも困難なくらいひどいコードであれば、全部消して、はじめから書き直す方がいいのです。
これが正しいやり方なんだと、再確認させてもらいました。
変数の値が変わってしまうような設計はシンプルを壊す
ちょっと技術論に近くなるのですが「参照透過性」を意識するのも重要です。
参照透過性が高いとは、関数がどこでいつ呼び出されようと、入力が同じであれば、常に得られる結果がおなじになる、ということを意味します。
前にもでてきた「個々の部分を取り出してみると、全てシンプルになっています。」にもつながる部分ですけど、
ここで本当に問題なのは、そもそも、変数の値が変わってしまうような設計をしてしまったことです。
とバッサリ書いてあるのは「目から鱗」です。
実際。
システムの運用フェーズでトラブル調査をやっていると、ある「変数の値」が予期しない値になって、ふるまいが変わっていた・・というのは、本当によくあります。
それをテスト不足と判定して怒るのは簡単なのですが。
実際にはその変数の値に影響を与える要素が、複数のソースにまたがっていたりするとテスト自体が肥大化して本末転倒な話になります。
そもそも
オブジェクト指向言語の入門書などには、変数の値が変わる設計を、暗黙のうちに助長してしまっているものもあります。
比較的「長生き」するオブジェクトたちが、互いの値や状態を変えるメソッド(mutator methods)を次々に呼び出す、というようなプログラム例が図解入りで載っていたりするからです。
これはとても危険です。
ことが原因の根っこだったりするわけです。
これは間違いじゃないんだろうかと、うすうす感じていたことが明文化されているのは気持ちがよいです。
その場しのぎのソリューションを長生きさせるとシンプルを殺す
きちんと対応するには予算も時間も足らないけど、何とかする必要がある。
トラブル対応にはよくある状況です。
そんな時は「その場しのぎの暫定ソリューション」でかわすしかありません。
暫定なので、後始末をきちんとしないといけないのですが。
暫定ソリューションで問題なのは「慣性の法則がはたらく」ことです。
いったん暫定ソリューションができてしまうと、既成事実化するのです。
すでに存在していて、一応役に立っていて、皆に一応受け入れられている。
もしそうだとすれば、その状況を今すぐ変える必要性を誰もあまり感じません。
本当は暫定ソリューションも早くシステムに統合すべきなのですが、重要な仕事は他にもたくさんあるので、どうしても後回しになります。
こういうことは本当によくあります。
でも
ソリューションをいったん暫定ソリューションにしてしまうと、後で修正するのは難しくなるということです。
ということが発生するので、心構えとしては、暫定ソリューションでなんとかなっている状況に甘えず、
最善の方法は、暫定ソリューションに修正を加えるのではなく、不要にしてしまうことです。
後から改めて、より優れたソリユーション、より有用性の高いソリューションを作るのです。
という気持ちだけは 持っとかないと駄目ですし、暫定ソリューション以外方法がなかった場合には、あとできちんと修正するスケジュールもたてておかないといけない。
その意識は持ち続けないとなあ・・と思います。
ではでは。