はじめに
N1! Machine Learning Product Engineerの中村です。
普段はニュースサイトやアプリのバックエンド開発を担当し、その他機械学習をプロダクトに実装することを目的としたスペシャリスト（ニフティにはN1!というスペシャリスト制度があります）としても活動しています。
https://recruit.nifty.co.jp/interview/nakamura.htm
社内LT大会
ニフティでは2ヶ月に1回ぐらいのペースで社内LT大会をしています。
コロナ禍になり現在は完全オンライン開催に移行していますが、オフラインで開催していた時期も様々な社員が技術ネタに限らず、いろいろな話題でLTに登壇していました。
今回のこの記事では2022年5月に開催されたLT大会（テーマが技術書）で、私中村が登壇して発表した内容をなるべくそのままの状態でお届けしたいと思います。それでははじまりはじまり〜。
※一部スライドを修正しています
LTはじまり
以下、実際のLTと同じ口語調に近い形で綴ります。
中村伊吹と言います。会員システムG第2開発チームで普段はニフティニュースやマイニフティのバックエンド開発を主に担当しています。他にも、ニフティのスペシャリスト制度であるN1!でMachine Learning Product Engineerとして機械学習の研究・実装を推進していたり、チアリーディングで日本代表として世界大会に出たり、そんなことをしてます。
今回は設計の話をしたいんですけど、自分の好きな言葉を紹介したいと思います。
「良い設計」私の好きな言葉です。
良い設計というのをほとんどの人が追い求めていると思います。
そのためにクリーンアーキテクチャだったり、ドメイン駆動設計だったり、人によっては大学だったりで、デザインパターンやバートランドメイヤーのオブジェクト指向などをしっかりと勉強した人もいると思います。
ただ、こういった本って読んでみてもほとんどの場合って「お前は何を言ってるんだ」状態になりがちなんですよね。
個人的に思うのは、こういった書籍って、例えばクリーンアーキテクチャのオニオン図だったり、ドメイン駆動設計はドメイン知識をモデル化していくんだよ、とか、オブジェクト指向はオブジェクト同士がメッセージをやりとりし合うんだよ、とかそういうことは書いているんですけど
だいたいの場合は、理論は分かるんだけど結局はどう書けばいいの？ってなりがちなのが大きな原因だと思っています。
そこで今回は「良いコード」「悪いコード」で学ぶ設計入門という本を紹介していきます。
悪魔と戦う
この本では、設計を複雑にしたり変更を難しくする悪しき構造を「悪魔」と呼びそれとどうやって戦うかを解説していきます。
分かりにくい命名という初歩的な話から始まり、
関係のないクラスが雑多に置かれがちなcommon/utilクラス
何が書いているかわからなくなるとにかく巨大なネスト
例外をキャッチはするけど何もなかったかのように振る舞う握りつぶし
もっと踏み込んだ考え方として、内部でうまく責務が分割できておらず複雑になったクラス
あらゆるインスタンス変数、処理を内包した全ての処理を持つ神クラス
など、こういった悪しき構造が「悪魔」です。
そしてこういった悪魔を実際のコードと合わせてどのように退治していくかが解説されていきます。
命名の考え方では可読性を高めるだけではなく、どのような思考で考えて名前を設計するか。
共通処理クラスを作るのではなく、オブジェクト指向の基本に基づいてどのように設計をするのか。
ネストの解消では、単純な方法である早期returnの他、interfaceを使った抽象化で排除したり、デザインパターンであるストラテジパターンを使って排除するなど、かなり深い考え方も使いながら解消をしていきます。
どのようにして責務を分割するのかも具体例があるので、なぜJavaでは継承よりも委譲を使うべきといわれるようになったのか、なども実際のコードで理解できます。
人間と開発
ここまでも技術的に盛り沢山な内容だったのですが、個人的には後半の章がかなり好きで
シン・ウルトラマンのキャッチフレーズの中に「そんなに人間が好きになったのか、ウルトラマン」というフレーズがあるのですが、この「人間」に触れている章が個人的にかなりお気に入りです。
筆者の考えとして、「エンジニアにとっての本質的な資産とは技術力。貯蓄がゼロでも、技術力があればどこでも稼いでいけるのがエンジニアであり、まさに富を生み出す源泉であり、何にも代えがたい、エンジニア自身の貴重な資産」という主張があります。
なぜ変更が困難で壊れやすいコード、つまりレガシーコードを改善しなければいけないのか、それはレガシーコードは技術的成長を妨げるからだ、というのが筆者の主張になっています。
レガシーコードがあることで、既存のコードを参考にすることで技術力が向上せず、また0からなら上手く設計できたはずの高品質な設計を妨げます。また変更にも弱いため過度に注意する必要があり、開発工数を減少させます。
そのほかにも「粗悪なコードはきれいなコードを書くより常に遅い 。厳密に設計しすぎず、サイクルを回し続ける。設計ルールを多数決で決めると、コード品質は最低になる。」という人間の心理に関わる話は後半に展開されて、個人的にはこの後半がおもしろかったです。
これは最後に自分がこの本の中でなるほど～と思った話なんですが、軍事理論のランチェスターの法則が例に上げられています。クープマン目標値という値によると10%程度のシェアを持つことで影響力を無視できない存在になれるらしいです。
エンジニアチームに当てはめてみると、20人ほどのチームであれば自分以外の1人を仲間にできれば、20人のチームで影響を持つことが可能になります。つまり1人2人の働きかけから、直感よりもかなり大きな人数を動かすことができるということです。
というわけで最後に、「誰かが始めなければならない。他の人が協力的ではないとしても、それはあなたには関係がない。私の助言はこうだ。あなたが始めるべきだ。他の人が協力的であるかどうかなど考えることなく。」というアルフレッド・アドラーの言葉を借りて、自分自身から良い設計を目指していきましょう、ということで本日のLTは終わりにしたいと思います。
最後に
実はこのLT大会では投票の結果、優勝者には副賞があるのですが、自分のこの発表は同点優勝の結果、最終的に運ゲーに負けて名誉だけが残りました。（次も優勝するぞ）
ニフティでは定期的にこのようなLT大会を開催することで、それぞれの社員の知見や考えを互いに知る機会を設けています。
トークテーマフリーなLT大会の他、データ分析に特化したLTやチーム内で行われているLTも存在し、日々互いに刺激を受ける環境となっています。
カジュアル面談も行っていますので、お気軽にお問い合わせください。
