手段としてのソフトウェア

作りたいものが見つからず不安なので,せめて何か蓄積したいと思いました。

(いまさらながら)リーダブルコードを読んだ

たいへん久しぶりに更新します。

いろいろあってメンタルの調子を崩し,1年以上休職中ですが,やっと調子が上向いてきました。

全体的にレベルの低いこのブログでございますが,カレン・カーペンターも "Don't worry that it's not good enough for enyone else to hear." とうたってくれたし,そもそも自分のために書いているので,恥ずかしくても,このままいきます。

 さて,前置きが長くなりました。今回はこちらの書籍から学んだこと,感じたことをまとめておきたいと思います。

www.oreilly.co.jp

 

「コードをよく考えて書くのって,楽しかったんだなあ」と思いだすことができました。

ここ数年,仕事ではソフトにかけられる時間が一番少ないという状態が続いていたので,ただただ時間に追われ,修理しながら走り続けるみたいな,もう最後に自分がケツ持つしかないんだろ!みたいな,ああそうですね,基板はひとりじゃ無理だけど,コードはみんな帰ってからでも1人でも書けますもんね!みたいな・・・まあ,自分の話はいいのですが。

この本では,「最も読みやすいコードは,何も書かれていないコードだ」など,そもそもの話というか,身もふたもない表現もユーモア混じりにたくさん出てきます。明らかにコードを書きまくってきた人の話しぶりで,すんなりと腑に落ちます。

読みながら,果たして自分はどうだったか,と振り返ると,「このコードはもっと読みやすく書けないか」なんて考えを深める時間は,ずいぶん取れていなかったなあ,サボってしまっていたなあと恥じ入るばかりでありました。

 

この本からは,「コードを読みやすくするには,こういうテクニックや考え方があるよ。だけど, 絶対のルールなんてものはないから,いつも考えることが大事だよ」という暖かいメッセージを感じます。何かと断定的な表現をしないところに,実態をよくわかったうえで書いてくれているなと共感を覚えます。自分たちで考えるための余白が取ってあるので,いろんなプロジェクトにおいて,指針として共有するのにも適しているように思います。

 本文中でも触れられていましたが,この本の内容をまず自分自身で実践し,チームのメンバーと共有し,可能ならさらにその外へと「読みやすく書く技術」を習慣として定着させ,相互に高めあっていくことができれば,開発が本当に楽しくなるだろうと思えました。

私などがいうことでもありませんが,読みやすく良い本でした。

 

メモを取りながらゆっくり読み,たくさんの気づきがありましたが,最後に,いまの自分に特に足りないと思えたものを,自戒をこめてメモしておきます。

 

  • ライブラリを知ること。簡潔なコードを書くのに必要なのは,ライブラリが何を提供してくれるかを知ることだ。("12.2 ライブラリを知る" より)
  • あとでテストするつもりでコードを書くと,おもしろいことが起きる。テストしやすいようにコードを設計するようになるのだ! ("14.8 テストに優しい開発" より)

 

マイコン上でOSレスで,8kBのRAMをやりくりしてると,デバッガもstdioも使えないし,テストコードもなかなか・・・なんてものは言い訳でした。これからは,新たな気持ちでコードを書けそうな気がします!