2016/12/19 このエントリーをはてなブックマークに追加 はてなブックマーク - 個人的コードを早く書くための覚書

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

カテゴリ: ,

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





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



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



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



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



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



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



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



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



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



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



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

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



2 件のコメント:

あやぴー さんのコメント...

ただの興味なんですけど、普段相談するときってどうやって相談していますか?
相手の作業を止めるのか、あるいはチャットツールなどで困ってますとだけ書き残すのか、など。

yy_yank(やんく) さんのコメント...

〉Ayato Nさん

今は基本的に開発用のグループチャットで相談という感じです。
チャットでのやりとりで伝わりにくいようであれば口頭でのやりとりにしましょう、という流れになったりします。

コメントを投稿

GA