リーダブルコード読書感想文 （小並感版）#1
の続きです。
だいぶ時間がたってしまいました・・・・
#1では、第Ⅰ部について、書きました。
今回は、Ⅱ～Ⅳ、最後までを対象としています。
いきなりまとめから入るという荒業を今回はしちゃいます！
[まとめ]
この本はコードの書き方テクニックだけでなく、目的が明確にかかれており、その目的がソフトウエア開発の中で用いられているモデルなどと容易に関連つけて読むことが出来ます。もちろん、読み手にも必要最低限の知識が必要です。
モデルなどの名前ばかりが先行しがちな中、
こういうもっと根本にある目的からそういうモデルが生まれているのだという事実を知るきっかけにもなる いい本ですね。
では、#1の続きを・・・
「序」では、「リーダブルコードとは？」という本の題名の定義・目的について書かれた部分の紹介をしました。
続いて、「破」ではその序の内容の応用編、
「急」では、”リーダブルコード” であることを貫くと、こんなことにも関係しますよ、という流れについて紹介します。
自己流の解釈なので、ご容赦くださいませ。
破
リーダブルコードとは、「読みやすさを備えており、誤解されず、一貫性を持った美しさを持ったもの。」でしたね。
読みやすさ・単純さを求めていくと、コード複雑度などは低いものになっていきます。
そういった 複雑度・単純さを追求する内容が書かれていて、「複雑度」に関するメトリクスが頭に浮かんできました。
複雑度の閾値を用いて、値の高いものから優先的にコードレビューをしたり、単体テストのテストケース設計を考慮したり、という工夫を知り合いが行っているのを耳にします。
本書の内容から、それが妥当であることが読み取れます。
一方、メトリクスに振り回されるプロジェクトを見かけることもあるので、複雑度メトリクスの使い方を間違わないように、本書内容を参考に改善事例等の展開をしていく必要性を感じています。
急
コードについて
しつこいですが・・・この本では、リーダブルコードは、読みやすく、 誤解されず・・・というものと定義されていました。
リーダブルであることを保ちつつコードのメンテナンスを行うこと。
XDDP、SPL等の目的が、ここに書かれているように思いました。
極論ですが、
できるだけコードをかかない。（＝最小の量で済ます）
新しいコードには文書・テスト・保守作業が必要になる。
そのために、コードの定期的なメンテナンスが必要である。
それは、以下のような試みを続けていくことだ、とかかれていました。
・不要なコードの削除
・要求の変更などをトリガーにコードの簡素化（リファクタリングなど）を検討する
・使用しているAPIや関連する最新情報のトレースをする
上記の内容を実行していくことで、派生開発する際、どれだけ楽になるか想像できますね！
テストについて
テストと読みやすさについても書かれていました。
コードを保守するということは、テストも保守する必要がある。
テストコードを「いつ書くか」には言及していないが、テストコードを書くことは必要で、そのテストを読み書きしやすくすることが、この章の目的として書かれています。
テストコードがあることで、文書・テスト・保守作業等を安心して実行することが出来ます。テストできる状態のものが既にあることで変更の妥当性チェック、デグレード等のリスクを早期に検知することができるからです。
そのためには、テスト資産を変更に合わせてメンテできている必要があることは言うまでもないでしょう。（変更などの作業のリスクが高すぎます。）
リスクを減らすためにも、テストコード（not試験手順書）を書いて、実行できる環境を常に持っていることが大切だと思っています。
最後の小並感
今後は、文書をどのタイミングで保守し続けるのか？ということについて考えていきたい。
開発手法によっていろいろあるかもしれないけど、必要な情報がちゃんと残ること、が目的で、この本に書かれている内容を文書にも適用していくことも大事だなと
いう小並感なしめくくりでおわります。
最後まで読んでくださった方、ありがとうございました（*＾－＾*
