仕事でコードを書くときに意識していること

2021/02/04 13:49:11

達人プログラマーを読んだせいか、最近よく考えてることでもあるので、この際なのでポエムにしてみた。

受託の会社バイアスはあるかもしれないけど、基本的にコードを書くエンジニアには通ずるところがあるはず。

これは、「いきなりエディタに向かってコードを書き始めない」ということ。

フォーマットはなんでもいいけど、

などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。
そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。

もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。
コードを見てコードを治そうとすると、あちらを立てればこちらが立たず状態になることもよくあるし、一度落ち着いて俯瞰して考えるほうがうまくいくことが多いかなと。

そもそもイメージできないのであれば、コードとして具現化できるわけがないのである。
スポーツで頭の中でイメージできない動きが実際にできるわけがないのと同じ。

いきあたりばったりでとりあえず思いついた案をできました！ってコードレビューに出したりするのはやめて、一晩寝かすくらい時間をかけてもよいはず。

そしてこれだ！っていう設計は、だいたいお風呂で舞い降りてくるし・・。

ようは、脳内メモリを使わなくてもいいコードを書くように心がけるということ。

たとえば、

のように、記述方法が選べる場合に、より素直な方法を選ぶということ。

変数名をわかりやすくするとか、コメントを適宜ちゃんと書くとか、DRYに気をつけるとか、そういう当たり前のことができるようになった上での、もうひと手間のステップではあるけど。

別件で、「余計なコードを書かないようにする」っていうのはある種のスキルかもなって思ったので、いつかそういうポエムを書こうと思った。

ライブラリの機能を、正しく理解して、余すところなく使いこなそうという話。

そもそもライブラリ（依存）は、なにか成し遂げたい目標や、やりたいことがあるから導入するもの。

なんか使い方があってるか不安・・って場合は、そもそもそのライブラリはあなたには早すぎたということ。
導入したけどそのライブラリの30％くらいしか使えてないなら、その30％だけを達成する別のライブラリを選べばよかったということ。

後からコードを見た人が、「なんで○○を採用してるのに、あの機能を使ってないん？」ってならないようにするということ。

ここまで手を動かす段階の話をしてきたけど、これはその更に前。

こういうことを実現したいという要件自体に切り込んで、可能ならわかりやすく仕様を変えてしまう。

受託の場合、依頼元とちゃんと話すということがとにかく重要で、納得感のある変更にすることが大事。
（ただしそもそもそういう話ができる関係性の場合に限る）

などなど、仕様が変わる理由はいろいろあるけど、個人的な都合にならないよう、そもそもの要求からかけ離れないように。

こんなんどうやって実装すんねん！っていうやつ、だいたいは言い出した側も苦肉の策だったり考慮漏れがいっぱいあったりするので、これって実はこうすれば簡単だったりします？的な提案をしていくといいって話。
自分の思慮が足りないだけの場合は、軽く一蹴されるかもしれんけど、それはそれで経験値になるはず。

というか、こういう一連の流れこそを、エンジニアリングと呼ぶのでは。

というのは建前で、実際は複雑怪奇な謎仕様をこの世に具現化しないようにしましょうね、エンジニアの威信にかけて・・ってだけ。

人によって、リファクタに対するイメージが違うと思っていて、

みたいに考えてる人が多い気がする。

けど、そういうものではないよね？って話。

一点の非の打ち所もない完璧なコードって、自分ひとりで書いたコードベースであっても、そうそうないはず。
つまりリファクタする余地なんかどこにでもあるということで、それをあなたがやってないだけって話。

スキあらば「ここ直したいリスト」をしたためておいて、机のホコリを払うくらいの感覚で、目についたらすぐやるようにする。
時間がなくて・・って言えないように、いかに自分の日々の中に自然と組み込んでいくかの問題。

とまあ他にもいろいろと思うところはあるけど、とりあえずすぐ思いついたのだけ書き出しておいた。

文字にするとなんか当たり前のことしかいってないけど、それを仕事プログラミングで成果として出せるようになるまでには、それなりに時間がかかった気がする。

そういう意味で、いい渋さを出せるおじさんエンジニアになりたいと思います。