ユニットテストのお話。あるいは仕事中の考え。

さーて、ようやくプロジェクトが動き始めたって感じだな。要件がふわっとし過ぎて、こりゃ僕が要件定義から始めないといけないかな？　と思っていたけどディレクターさんがまとめてくれた感じ。僕は所詮、下流工程の技術屋なんでディレクターとかまとめ役のSEとか居ると安心する。交渉が苦手なんで、要望を全部断れずにいつも苦労していた。このままだと一人アジャイルに突入するなと危惧していた。

扱ってるCMSのコードもなんとか全体像がつかめてきた。あまりにもレガシー過ぎて処理が全く追えないって感じだったけど、スプラウトメソッドで処理を分離させていたら使い物になる程度には整理できた。『レガシーコード改善ガイド』は良い。レガシーコードと戦うプログラマの心構えが全部書かれている感じ。どうにもならなくなった時の考え方も書かれている。

レバレッジメモ: レガシーコード改善ガイド - 西尾泰和のはてなダイアリー

心残りとしてはPHPUnitでテストコードも書いてるけど、テスト環境依存のコードなんだよね。Model部分とか全然読めていないから、モックが全然できていない。jenkinsが設置されているから、カバレッジを見ながらニヤニヤしてやろうかと思っていたけど、それは当分先の話だろう。

プログラミング周辺だと、これが気になった。

コードを書き続けるためにやってること - Qiita

逆説的だけどある意味正しいよなと思った。だけどテストは先に書いた方がいい。即座に動作を確認できるので、実装の体感速度が違う。コーディングで小さなサイクルを起こすというのはプログラマのライフハックとして重要。自分はユニットテストの要望が無いときでもテストコードを書く。結果的にそれが早いからだ。

ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 - Qiita

後はスケジュールとの睨めっこだな。