周りのコーディングルールについて考えた例え複数人でコードを書いていたとしても、一人の開発者が統一的に書いたように記述するべきだと思っており、この方針の優先度には個人的にはかなり重きを置いている。パターンの導出を助けるし、機械的なコードの生成にも繋がると思っている。ここでどれだけ一貫性のあるルールを素早く考えられるかというところで、プログラマのコーディング面での能力が推し量れると思う。この方針を守るためには、実現したい処理に対してコードの形が一意に定まるようなルールを設けるべきであり、実際のところ自分のコーディング作業というのは、このルールを考えること・従うことにほとんどの労力を費やしていると言っても過言ではない。アプリケーションの初期化時に行いたい処理のコードの配置方法について考える機会があり、こういうルールを持つのが良いのでは、という一案を考えた。最終段階に入った最終段階の定義を述べよ、という感じなんですが、データを投入して公開すれば全員が見られるようになるという状態まで進んだ。データ投入用の処理を実行しはじめたところだが、これは数時間掛かるので、朝起きたら完了しているか失敗しているはず。ように考えたりするけれど、タスクの選択方法をランダマイズしない限り、簡単で効率の良いタスクから選びがちになる。なると幾ら時間を掛けても進まない効率の悪いタスクが最後に残りやすくなるので、時間感覚がおかしくなるんじゃ......ということを考えていた。リリース前になって、小さいくせにめちゃくちゃ重いタスクが詰まれていることに気付き、いや知ってたけど、重いな、今日はゲームがんばったし寝るか、ということが何度かあった。成果を1ヶ月とか1年とかの期間で振り返るときは、自分主観でやったことを並べるのではなくて、自分の顧客が自分の仕事によってどういう恩恵を享受できるようになったかという変化を並べる方が、より誠実な振り返りになりやすいと思う。この場において誠実さってなんなの、おいしいの、って話だけど。後者の評価方法だと完全に逃げ場が無くて、本当はほとんど成果を挙げていないということが客観的に明るみに出てしまい、また自覚することでダメージを受けてしまう場合があるので、防衛的に前者の方に逃げがちであるという気持ちは分からなくもない。発送のお知らせが届いていた。手に入れられなかった人も含めてうちで試射会会やるのも良いかも。