レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

4.17
  • (18)
  • (21)
  • (6)
  • (2)
  • (0)
本棚登録 : 315
レビュー : 28
amano225さん 中古を購入   読み終わった 

2020年ITエンジニア本技術書部門大賞ということでずっと気になっていたのだけど、ようやく購入する決心がついて読んでみた。
ソフトウェア開発において、バグというのはどうしても避けられないものではあるけど、それをできるだけ少なくすむ手法について9つのプラクティスにわけて書かれてあるように思った。
レガシーコード。それは、修正や拡張が非常に難しいコードだそうだけど、自分が普段書いているコードはレガシーコードなのだろうなと思う。書いてるときにはとにかく先に動くコードを書いて後から修正しようと思い、コードの品質がおざなりになり、しかもそのコードを見返さずにテストをするものだから、リリース後に「もっとリファクタリングすればよかった」と思う今日この頃です。
コメントについては、前から「なぜそうしているのか」を書いた方がいいというのは聞くしこの本にもそう書いてあるのだけど、どうしても「何をしているか」を書いちゃうという。最悪この本にも書いてあるように、コードを修正してもコメントを修正しない(同期がとれていない)という、コードを読む人にとってはどっちが正しいのか分からない状態になってしまうという。本当、ここは反省する。
CHAOSレポートというのは初めて知った。ソフトウェア開発プロジェクトが成功したか(当初想定した機能を想定期間と予算内に抑えてリリースした)、問題ありだったか(リリースしたが予算超過や機能を削った)、失敗だったか(リリースできずに中止した)を調査したものらしい。年々このレポートでの成功の割合は増えているのだとか。著者によるとその理由は、アジャイル開発手法が普及したからだろうとのこと。アジャイル開発ってやっぱり重要なんだなぁ。
ただし、この「成功」の定義を見ていて思ったのは、「これって、バグが大量にあっても成功になってしまうような?」と思ったら、まさしくそうらしい。そういう意味で、何が成功といえるのかを定義するのは難しいのだろうなと思う。
ソフトウェアは変更可能なように書かれていなければならないというのはまさにそうだろうなと思うけど、コードを書いているときにはそんなこと考えもせず書いてしまいがちなのでなんとかしたい。そういう意味では、後で読みやすいコードを書くというのは本当に重要なのだろうなと思うのだけど、それは日本語で書く文章と同じで、そうしたいと思うだけじゃ、なかなかうまくいかないのだろうなと思う。
後、前からちょっと興味はあるけどできていないペアプログラミングについて。どうも、もっとも価値がありながら、もっとも誤解され過小評価されているプラクティスだそう。一見、二人で同じことをやってると同じ時間で半分しかできないのではないかと思うしね。実際、早くできても1.5だそうなので、2人で別々の作業をやるよりは少ないらしい。ただし、そのコードにはバグが少ないので、デバッグの時間まで考慮するとペアプログラミングをしたほうが合計時間は短くなることが多いのだとか。自分も1回、どういう感じかはやってみたいとは思うのだけど、なかなか機会がない。
リファクタリングについて、確かに重要なのだろうなと思う。なぜか、テスト期間中は修正しようと思わないのに、リリース直後に「リファクタリングしとけばよかった!」と後悔することがよくある(というより今現在がそう)。リリースしてからもバグが見つかったらそのタイミングで修正はできるけど、なんとなくリファクタリングしたら別のバグがうまれそうで怖いと思う(実際、リファクタリングしたせいでバグが増えたということはある)。
ところで、バグをださないという点ではテストが非常に重要になってくるのだけど、この本でもテストの重要性についてもちゃんと書かれていた。ただし、手動でのテストではなく、テストコードによる自動テストなので自分はほとんど全くといっていいほどできていないことだ。
著者が知っている優秀な開発者の中には、20秒ごとにテストを実行している人もいるのだとか。正直、ここについては意味が分からなかった。コードを修正するのに、20秒以内にコンパイルが通るコードを書く必要があるというなのか。結構難しくないかと思った。
テストコードについては実際のプログラムコードを書くより先に書いた方がいいらしく、それがそのまま仕様と呼べるものにしたほうがいいそうだ。
テスト駆動開発とかテストファーストとかは用語はよく聞くし、なんとなく重要なのだろうなと思うのだけど、全く書いたことがないし、書きたいともあまり思ってこなかった。だって、テストがうまく動かなかったら、プログラムコードのバグだけではなく、テストコードのバグも考えられるわけだし、変更が発生した場合も両方を修正しなければいけない可能性もあるという非常に面倒くさいイメージがある。ただ、これもやったことがない人の言い訳なようにも思うので、一度テストファーストでコードを書いてみたいなとはこの本を読んで思った。具体的な方法について、もっと勉強したほうがいいのだろうな。
そういえば、トヨタ生産方式のカイゼンというのはよく聞くけど、それはもともとアメリカ人のエドワード・デミングによるアイデアだったというのは初めて知った。てっきりトヨタ内の日本人の誰かが考えたものなのかと。なんだかんだいって、日本の高度成長が実現できたのは、アメリカの助けもあったからなのかなと思った。

レビュー投稿日
2020年5月16日
読了日
2020年5月16日
本棚登録日
2020年5月16日
0
ツイートする
このエントリーをはてなブックマークに追加

『レガシーコードからの脱却 ―ソフトウェア...』のレビューをもっとみる

『レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』のレビューへのコメント

まだコメントはありません。

コメントをする場合は、ログインしてください。

『レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』にamano225さんがつけたタグ

ツイートする