🧊

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

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

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


設計に時間をかける

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

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

  • まずどういうものを実装しようとしていて
  • 愚直にやるならこうする
  • それによって既存のコードに影響がないか
  • 過去のコードと一貫しているか
  • 他の要件とぶつからないか
  • etc..

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

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

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

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

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

シンプルに実装する

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

たとえば、

  • 複雑な条件分岐を書くのではなく、early-returnする
  • `reduce()`や`map()`のインラインで何行も書くなら、そもそも`for`でやる
  • 真偽値を反転させて判定するより、フラグをそもそも逆に定義する
  • etc..

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

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

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

道具は使い倒す

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

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

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

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

シンプルに設計する

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

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

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

  • いろんなことを一度に達成しようとして複雑化しすぎてるから
  • プロジェクトの状況によって、スケジュールのために
  • メンバーのスキルセットを踏まえた結果、実装難易度を下げるために

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

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

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

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

日々の所作としてのリファクタ

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

  • 必要があったらやる
  • 時間があったらやる

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

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

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

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

おわりに

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

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

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