アウトプットを増やす

読んだ本とか思ったこととか

BPStudy#125〜テスト駆動開発(TDD)の真髄へ参加してきた

「BPStudy#125〜テスト駆動開発(TDD)の真髄」でt_wataさんのライブコーディングが見れると聞いて行ってきました。たしか抽選だったかな?

bpstudy.connpass.com

 

資料はこちら。

bpstudy.connpass.com

書籍はこちら 。あとオーム社ebook Storeが閉店するとのこと。残念…

テスト駆動開発

テスト駆動開発

 

 

本書は写経にとても向いているというのはホントにそのとおりで、1人でもくもくやるにはとても良い教材になると思う。個人的な写経としてはPythonでやった(おかげで最近?のPythonのことをいろいろキャッチアップもできた)。

TDD/part1 at master · ktanaha/TDD · GitHub

 

 

実際にライブコーディングを見て思ったのは、迷った時にどう進むかみたいなところもや、「なぜここはこうするのか?」というところを背景や理由、歴史などを交えて説明してくださり、とてもわかりやすく実際の現場でも今日見たプロセスでやっていけそうな感じの印象を受けた。

特に最初のTODOの流れるような分解が素晴らしい。言葉や文章で書かれた「やるべきこと」を、TODOの1項目のレベルにまで分解・構造化するのは日常の業務でもやらなくちゃいけないことだと思ってるけど、なかなかうまくできないと感じている。

なんでうまくできないのかは自分自身まだわかっていなかったけど、途中で(多分)t-wadaさんが仰っていた「実際に手を動かすことが大事」というのが、実はコードを書くというところだけではなく、TODOに落とし込むというところでも実は大事なんだなーと実感した。

もしかしたら「手を動かす」以外にも「声に出す」でも良いかもしれない。でも職場だとなかなか独り言は難しいかも?

 

業務上、1からコードを書くということはほとんどないので、最近は↓のような課題に直面することが多い。

  • テストがないコードにどうやってテストコードを書くか
  • テストコードの技術的負債をどうやって解決していくか
  • 意味不明なテストの扱いをどうするか

技術的な解決策としてはレガシーコード改善ガイドとかが参考になるかもけど、多分問題はそこではなく組織的な文化やプロセスの問題な気もする。

一応自分としては、コードは自分が触る前よりも綺麗にしてコミットするということを意識してる(つもりな)ので、粛々と改善していきたい。あとJUnit5使いたい…。

 

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

 

 

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド