個人的コードを早く書くための覚書

なんとなく書いてみた。というか書いてみると作業方針ぽくなったし、チケットの捌き方みたいになった。

IDEを駆使して自分の作業をoptimizeする

ショートカットキーとコード補完などは覚える。
操作を行う頻度の多いもの、処理に時間がかかっているものを最適化するのが目的。
IDE自体の処理スピードがネックになる場合はチューニングすること。
タイピングからのレスポンシビリティが下がる、
ビルド・デプロイにコードベースの量から想定される以上に時間がかかる。
などと行った場合はなんらかのゾンビプロセスなりが存在しているかもしれない。

なるべくチケット化する

これはプロジェクト方針と合致するかということも大いにあるけど、
基本的にチケットは細かくあったほうが良いと考える。
明らかに作業に対してチケットのタイトルが合致していない場合、
チケットにない作業をしている場合などが該当する。

タスクを細かく切る

「if文を追加する」というレベルでは要らない。
「XX機能に対して」「XXのParserを作成する」とかいうのは細かく切っていたほうが良いと思う。
構成要素をそれぞれリストアップして片付けていく感じ。

チケットを切る必要のない細微なタスクはチケット上に残す

これ以上チケット切るのもどうかなぁという場合は、チケットに対する内容である、ということ妥当思う。
チケットに対して細かなタスクをぶら下げていく。
個人メモとかテキストベースのやりとりとかで片付けていくのも良いのだけど、
そういったものは揮発性が高かったり検索性が低かったりとかするので推奨されない。

最小粒度のタスクに対してコミットを行う

コミットコメントで1〜2行で書き表せる変更を粒度とすべきと思う。
コミットコメントが書きにくいということはコミットがでかいことと思う。

常に時間を計測する

息が詰まるほど計測する必要はないが、可能な限り計測する。計測はその後の分析につながる。
計測だけで振り返りをしない場合はあまり意味がないが、データとして残るという価値はある。
チケットに対してアクションを起こす際、その都度作業時間を更新するのが良いかもしれない。

ハマる時間を決める(長くて30分)

ハマる時間は予め決めておく。あぁ、これは分からないという場合
「本当に難易度の高いもの」
「認知バイアスによって簡単なのに気づけていないこと」
「前提情報が不足していて探索してアタリをつけないといけない」など様々であるが、
あまり長く時間をかけても意味がない。
長く時間をかける必要があるなら「調査」というチケットにするほうが良さそう。

相談する

ハマった後は相談する。ハマっていますよというシグナルを出すのと、
客観的意見や情報を得る。簡単に解決する場合や周りも知らない場合もある。
「周りが知らない」というのも1つの情報。

相談している間は別のタスクを行う

相談している間もなるべくパラレルに他の作業を行って立ち止まらない。

1時間半ルール

人間の集中力は1時間半だと聞いたことがあるので、そのスパンを意識してみると良いかもしれない。
別にこれに縛られる必要はない。
ただ、健康上は1時間おきに離席するぐらい（座りっぱなしではない）方が良いらしいとか。

ある程度タスクを終えたタイミングでリファクタリングをして再テストする

タスクを片付けるというのはある種、
「やることをやった」という状態なだけであり、整理整頓は出来ていない事が多いと思う。
それ自体は仕方ない。タスクの完了が目的であって整理整頓は目的ではないので。

なので一旦やり終えた後リファクタリングするのが経験上良いと思っている。
配置するのが作業だとすると、配置したものを磨いたり拭いたりするのがリファクタリングみたいに思っている。
そしてリファクタリングを怠るとどこかで見通しが悪くなって処理効率が下がるタイミングがある。
過度なリファクタリングもただの綺麗好きになりかねないので注意が必要。