未来を据えたプログラマー

よく開発をしていると「保守性」という単語を耳にするのですが。

確かに保守性というのはとても大切で、保守性を持たないプロダクト作りに途中から関わったりすると、地獄を見ます。

とはいえ、保守性という考え方はヒトによって様々で、時には真逆のことを言われる方もいたりします。

ということで、今回は意識すべき保守性について、個人的な意見を書いていこうかなと思います。

ダメな共通化をしない

よく「保守性を上げるために共通化をしたい」という言葉を耳にするのですが。

確かに、最適な共通化は保守性を向上させます。

しかし裏を返せば、最適でない共通化を行ってしまうと、どんどん保守性が下がっていくことについては意外と気づいていないヒトが多い印象があります。

では最適な共通化とはなにか。

これ自体は難しくもなんともなくて、適切なルールの元に行われた共通化のことを指します。

では適切なルールとはなにか。

例えば Atomic Design は、適切なルールの 1 つだと言えます。

Atomic Design は本当によく考えられていて、あのルール通りにコンポーネント設計を行うと、最適な共通化が行われていきます。

イメージとしては小さい箱を収納する中くらいの箱があって、それを格納する大きな箱があって、みたいな感じです。

例として、Next.js は、それがベストプラクティスかどうかは別として、Atomic Design に落とし込みやすいフレームワークだよなーと思います。

また、Figma などのプロトタイピングツールで管理されたコンポーネント設計も適切なルールになりやすい傾向にあります。

結局共通化のエビデンスをどこに持つのか、それ次第なのかなと。

複雑なルールを作らない

何かしらの保守を行うにあたって、どんなケースであっても最低限のルールは必要です。

Atomic Design やプロトタイピングツールによるルール作りなんかはまさにそんな感じかなと思います。

一方で、たまに規模感が大きいプロジェクトになってくると、ルールをガチガチに固めることによって保守性を上げようとしていますが。

複雑なルールというのは守るのが大変です、当たり前ですね。

なので最適なアプローチとしては、意識しなくても守れるような整備を行い、そこでフォローしきれない範囲をルール化すべきかなと。

Linter や Formatter、テストなどはまさにその代表例ですよね。

ドキュメントでガチガチに固めることを快感に覚えるヒトもいるでしょうが、それは単なるオナニーでしかないよなーと思います。

将来を見据える

よく「技術選定ってどうやったら良いですか？」と聞かれるのですが。

自分が得意な技術というのも大切な理由の 1 つである一方、市場に技術者が存在することも非常に重要です。

自分が得意な技術だからという理由のみで選定してしまった場合、プロダクトの規模が上がるにつれてヒトが必要になった際に採用できないといった問題が発生しがちです。

また構成なども固くすればなんでもオッケーというわけではなく、他のヒトの技量感に合わせないと、自分しか保守できないなんてこともザラに起きます。

こういったケースはスキルが高い人や経験年数が多いヒトであればあるほど勘違いしやすい傾向にあるのかなと思います。

まさに初心忘るべからずですね。

スコープを小さく持つ

プロジェクトやチーム、会社レベルでもそうなのですが、スコープって大きく持たせがちです。

例として、100 人に対して同時に連絡事項を伝えるのと、各々に対して連絡事項を伝えることを 100 回繰り返すのでは、どちらのほうが強く印象付けられるか、という感じかなーと。

GitHub の管理などもそうですが、いかにスコープを小さく扱えるようにするか。

スコープを小さく扱うするためには、適切なロールの管理や適切な環境変数の管理などがキモになってきます。

そこの管理をめんどくさがって一括で管理！みたいなことをすると、規模が上がるにつれて融通が効かなくなり、余計なコミュニケーションコストが発生し、どんどん苦しくなっていきます。

なんでも小さく扱う、そのための手間を惜しまないようにすることが大切です。

『あ、そろそろ危ないな』と思った段階できっちり棚卸しを行うようにしましょう。

結局のところいかに属人化を排除するか、そこに対するヒューマンスキルを持ち合わせているかが重要だよなと思います。

繰り返しになるんですが、保守性に対する意識の重要性というのは意外とスキルや経験年数を問いません。

いつまでも謙虚に、周りを見つつ自分を正しいと思わないようにいることが大切だよなーと思う、今日このごろです。