はじめに
こんにちは。
そろそろ初心者を名乗るのが許されなくなってきた2年目エンジニアです。
前回のテーマはジョブチェン前後に考えていたことでしたが、今回はいちエンジニアとして最近考えるようになったことについて書きたいと思います。
前回の記事はこちら↓
最近の変化として、なんか色々考えて書くようになったぞ、という自覚があります。
何事もはじめは真似るところから、とよく言いますが、私もエンジニア1年目はひたすら文法覚えゲーでした。とにかく「動くものを書くこと」に必死で、設計とか可読性とか考える余裕も興味もなく、必要性もあまり理解していませんでした。
そんな新米エンジニアも、社内外の勉強会に影響されたり、先輩に初めてのPHPカンファレンス参加へ背中を押してもらったりする中で、良いコードとは、みたいなものを少しずつ考えるようになりました。
というわけでここでは、本当に少しずつではありますが、以前と比べてコードを書くときに意識できるようになったことや、意識するようになったきっかけなどを書いていこうと思います。
その1.命名
以前の私にとって名付けは、ただのラベル貼りであってそれ以上でも以下でもない、という認識でした。しかし最近はこんなことを考えて命名するようになりました。
- 寿命の長い名前か
- 命名に時間をかける必要、価値があるか
- 最小限の文字数で、必要十分な情報が過不足なく入っているか
- 今後私の知らないところで使う人が、使い方を誤解するような名前ではないか
エンジニアという人種は、ただのラベリングに日々少なくない時間を捧げ、ただの名前に頭を悩ませるものです。なぜエンジニアがそこまで名前にこだわるのか、理解できなかった私の意識を変えたのは、やはり名著『リーダブルコード』でした。
名前は短いコメントでなければならないこと、誤解されない名前こそが読みやすい名前であること、そして読みやすいコードを書くことは良いコードに繋がること、etc。
『リーダブルコード』には多くを学びましたが、一番の収穫は私が「理由のない命名」をやめて、先人たちの命名に「作者の気持ち」を読み取るようになったことでした。
身構えずにちょっとした思考でできる日常作業が、高嶺の話だと思い込んでいた良いコードに繋がるというのは、ある種お得だなとか、そんなことを考えながら最近は命名に勤しんでいます。
（余談）
最近は命名に悩みすぎて思考が途切れたり、やたら時間を使ってしまうことも多かったのですが、ちゃちいさんの発表を拝見してからは変な力みも解消しつつあります。ちゃちいさんに出会えたきっかけの勉強会についてはこちらから↓
その2.SOLID原則
ソフトウェアエンジニアなら皆さんご存知、5つの開発原則です。その中でも"S"と"O"については、日常的に意識して書けるようになってきました。（残りの3つはまだちょっと難しいｶﾓ）
-
"S": Single Responsibility Principle / 単一責任の原則
私が目安にしているのは、書きにくさです。処理のスタートとゴールは理解しているのに、なぜか手が動き始めない、みたいな書きにくさを感じる時があります。それは大体一度に色々やろうとしちゃった時、つまり"S"を守れていない時の危険信号だと思うようにしています。 -
"O": Open/Closed Principle / オープンクローズドの原則（開放閉鎖の原則）
これは持論ですが、「修正に閉じ拡張に開く」ってエンジニアじゃないと真に理解できない感覚NO.1だと思っています。言ってる意味はわかるが理解できないという状態から抜け出すのに、本当に時間がかかりました。
やっと痛感できたのは、社内のインボイス対応でした。迫る期限、足りないリソース、複雑な要件と戦いながら限界コード書くマンをやっていたプロジェクトで、ふと「税率5%→8%→10%が、私が中→高→大の時に増えてるから、もうそろ13%が追加されてもおかしくないな」とかぼんやり思った時でした。増税反対そっちのけで「このしんどい改修もう二度とやりたくねえな」を瞬間的に思ったあの日が、私が開放閉鎖の原則をやっと痛感し、SOLIDの"O"を考えて書けるようになったきっかけでした。やはり経験しないと痛感することはできず、1の痛感は100のインプットに勝る、という学びもついでに得ました。
その3.抽象化
きっかけは弊社VPoE金城さんの、PHPカンファレンス福岡2023の登壇発表でした。
私のエンジニア生に多大な影響を与えた発表なので、ぜひ全編を全人類に見てほしいのですが、ここでは上記スライドより、ほんの一部を抜粋させていただきます。
- 不確定な神話を信じるのではなく、そもそもマインドセットを変える
- 「全ては変わる、それだけが不変」というマインドでいること
- マインドセットを変えると、戦略が変わる
- なるべく「書かない」
- なるべく「捨てやすさ」を重んじる
- なるべく「変えやすさ」を重んじる
以前はPRの緑色の値が大きいほど「よしよし今回はたくさん書けたぞ」と喜んだものですが、この発表をきっかけに「たくさん書くことは良いことなんか？」と考えるようになりました。そしてなるべく「書かない」にはどうしたら良いかを考え始めて、そうしたら自然と抽象化して書くしかなくなった、というのが最近です。
ここでの意識してるポイントは、同じ処理を探すだけではなくて、脳の使い方が同じものがないかを探すようにしています。仕様や書き方を考える段階で、ありとあらゆるパターンの考慮をしますよね。その際に、大体あるタイミングで「あとは一緒じゃん」となる部分が存在するので、そこを上手く抽象化できないかを考えるようにしています。
その4.テストの品質
きっかけは弊社開発部Mgr（これを書いた人）との1on1でした。絶賛テスト書くのイヤイヤ期だった私が、テストを書くモチベについて質問したところ、「ユニットテストはリリースが怖くなくなるためのただの手段、上手く利用なさい（意訳）」という回答が返ってきました。リリース怖いイヤイヤ期でもあった当時の私にはそれがぶっ刺さり、そこからテストへの意識がだいぶ変わりました。面倒だけど書かなきゃいけないから書くか…から、これが通れば安心してリリースできるから書こう！と思うようになりました。
具体的に、テストを書く時に最近考えるようになったポイントとしては、以下の通りです。
- このテストでは何の機能をどこまで担保すべきか
- テストダブルでいい部分はどこか
- 保守しやすいテストとは
- fixtureって書く側は楽だけど、メンテする時大変だよな…とか
- このテストは本当に必要か
- テストコードも書くだけで負債（ってぺちこんで聞いた）
- このテストは書きやすいか
- テストが書きにくいということは、プロダクトコード側に改善の余地あり
義務感でなんとなく書いていた時よりも、目的とスコープを意識してテストを書くようになった今の方が、リリース日の朝に胃をキリキリさせることがだいぶ減りました。
さいごに
良いコードを書きたいと思うようになるきっかけは、きっと人それぞれだと思います。私の場合は、コードの良し悪しが多少わかるようになってきたタイミングで、数年後に「なんだこのsakuraiってコミッター、クソみたいなコード書きやがって」と思われたくない！と自然に思い始めたのがきっかけでした。そこからはインプットをすればするほど矛盾する様々な考え方に苦しみつつも、良いコードを残したいというモチベは今も上がり続けています。
本当に少しずつの成長ではありますが、自信をもって良いコードを残せる良いエンジニアでありたいです。
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion