正しいものを正しく作る塾に参加しました

正しいものを正しくつくる(設計実装)に参加しました。

せっかくなので、塾の感想をブログに書き留めておこうと思います。

正しいものを正しくつくる(設計実装)とは

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を執筆された増田さんが講師となり、設計について個々の言語化を促進する塾です。

塾では、下記6冊の参考図書に存在する隠れた関係性を紐付ける過程を通して、知識を広げながら深めていきました。1

毎回の講義始めにある30分間の対話を通じたアウトプットでは飽き足らず、塾生が主体となり休日に集まるなど互いに刺激し合いながら学んでいました。

なぜ、塾に参加したのか

塾に参加する前に、社内でも技術力の高いチームに異動しました。

異動直後、技術力が高いチームメンバーが負債に苦しんでいるのがわかりました。

私もコードやアーキテクチャーに強烈な違和感を感じるが、うまく言語化できないまま数週間が過ぎました。

このままでは、自分の言葉で説明できないまま負債という安易な言葉で片付けてしまうと思い、藁にもすがる気持ちで受講することにしました。

参加して学んだこと

塾を通して、大小様々なことを学びました。少し寄り道して哲学や生物学を学んだり、生活の一部となっている習慣(整理整頓)とオブジェクト指向を紐付けてみたりと内省とチャレンジを通じて言語化できたことをまとめてみます。

オブジェクト指向とは何か

オブジェクト指向とは、高凝縮、疎結合を目指すソフトウェア開発戦略です。この戦略を確かなものとするために、抽象データ型によるモジュール構造を塾では提唱していると紐付けました。

なぜ、高凝縮、疎結合である必要があるのでしょうか。それは、人間の脳が対応できる情報量が開発するソフトウェアの発達に伴って増加しないことに根本的な原因があると考えました。

責務を正しく分割し、周辺への影響範囲を最小限に留めることにより、情報量の指数関数的な増加を防ぐことが高凝縮、疎結合を目指す理由なのではないかと思います。

ビジネスロジックとは何か

Railsは、MVCというアーキテクチャーをとります。モデルであるMには、ビジネスロジックを書くべきであると言われていますが学生時代その意味がわかりませんでした。

塾で紹介された関心の分離の4象限からビジネスロジックとは、計算・判断と意図の表現の掛け合わせなのだとわかりました。

2

CCSRとは何か

塾では、CCSR(継続的・並行的・段階的な改善活動)を行うことが発展性のあるソフトウェア開発に繋がると紹介されました。

CCSRとは、ソフトウェアで解決する課題をステークホルダーとの対話を通じながら明らかに、型による継続的な構造化を行うことだと理解しました。

CCSRは、発展性に振り切った思想です。

コトラーの競争地位戦略

塾で最も印象に残っているのが、コトラーの競争地位戦略の話です。

コトラーの競争地位戦略のポジションによって、とるべきビジネス戦略が変化します。

そのビジネス戦略によって、ソフトウェアのどこに注力すべきかが変わってくるというものでした。

例として、楽天が紹介されました。

外から見るとECのリーダーだが、中ではAmazonに対するチャレンジャーであると言われた時は、ハッとさせられました。

また、外から客観的に判断できる数字によってポジションが決まるのではなく、中の人がどう思っているかによって変化するのだという視点には驚きました。

まだビジネス戦略を考慮して開発を行えていないですが、将来的に習得したいスキルを発見できたのは大きな収穫でした。

業務での変化

命名へのこだわり

現在、Stripeを利用して開発を行っています。そこでは、2重課金を防ぐためStripeから飛んできたイベントをDataBaseに格納し存在をチェックすることで冪等性を担保しています。

塾に参加する以前だと、RailsのActiveRecord#exists?APIをそのまま利用して実装していたと思いますが、イベントが処理されたことを明示するために、exists?のaliasとしてprocessed?を定義し実装を行いました。

これは、極めて小さな変化のように見えるかもしれません。しかし、リファクタリングを通してソフトウェアに息を吹き込むことがCCSRへの第一歩なのだと実感した体験でした。

適切な責務に配置されていないコードを指摘できた

元チームのPullRequestをレビューしている際に、3つのモデルの責務が1つにモデルのメソッドとして記述されていることを発見し、未然に負債化を防ぐことができました。

変更が少ないものに、依存すべきであるのではないかと考えはじめた

成果として、GitHubのGraphQL API v4にて、EmailのScalar型を定義していない理由を考察してみたをアウトプットしました。

2020年12月にどうなっていたいのか

  • リファクタリングスキルをつけ、負債の解消する
  • 人間とソフトウェアの関係性についての深掘り

業務では、システムの理想と現実を明らかにしながら負債を解消していきたいです。

人間についてより理解を深めることで、ソフトウェアに対する深い洞察が得られるのではないかと考えています。

まずは、その足掛かりを探したいと思っています。

何をアウトプットしていたいか

  • DDDと静的型付け言語(Java)の理解を深め、GraphQLのSchemaガイドを作成

深掘りたい参考文献

塾では主専攻、副専攻2つの書籍を深めることが推奨されています。 下記2つを深め、どこかで発表したいと思います。

まとめ

会社に受講料を負担してもらいながら、社会人1年目と早い段階で設計に関して深掘りする機会を得られたのは、これからのエンジニア人生で大きな資産になると思う。これからも油断せず、継続的にアウトプットをしていきたいです。


  1. ラーニング・パターンに基づいた学習

  2. 画像の使用許可を確認済み