この記事の目的
株式会社NoSchoolでオンライン家庭教師マナリンクの開発にJOINしたので、コードや設計などの感想を述べてみる。
入社エントリがわり。テンション高めです。
この記事の想定読者
- アーリーステージベンチャーの開発に興味がある人
- PHP/Laravel + (Nuxt.js + Next.js) + Expo(ReactNative) + AWS のフルスタック開発体制に興味がある人
- 今の所バックエンドを触ることが多いためそのウェイトが高めです。
- 逆にExpoやインフラ周りについては情報少なめです。
- JOINしたチームはエンジニア4名くらいでサーバ/フロントエンド/アプリの開発をしています。
- PHP/Laravel + (Nuxt.js + Next.js) + Expo(ReactNative) + AWS のフルスタック開発体制に興味がある人
- マナリンクの開発に興味がある人
- 「@meijinの仕事って実際どんな感じなんじゃろい？」と気になっている人
- 以下のスペックのエンジニアの入社エントリに興味がある人
- エンジニア8年目くらい
- 一人目Engineering Managerとして入社
- 元々JavaScript/TypeScriptばかり書いていたなんちゃってフルスタックエンジニア
- ほぼPHP経験なし/Laravel経験なし
- DIは概念は知っていたが使ったことなし
- MVCはRailsちょっと触ったことある程度
はじめに:全体的な印象について
とにかく徹底的に何が必要かをきちんと考えて作られてるなーいう印象です。
アーリーベンチャーなのでビジネスに必要で仕方がなく許容した実装はもちろんあります。
ただ、システムの全体を理解できていなくても、テストとコードを信頼して改修ができるというラインは徹底して守られており、開発体験はかなり良いと思います。
逆にエンジニアのエゴで作られた不要に複雑に仕組みは本当にないのが本当に良いです。
早すぎた抽象化がほぼなく、素直に追うと素直に理解できる仕組みになってます。
あと、完全出社制でとにかくチームを大事にしているので、本質的な意味での心理的安全性が高く、仕事がやりやすいです。雑談ついでに技術的な深い話ができることが多くて本当に良いですね。
biz/devの信頼関係もしっかりしているので、開発効率を守る施策が必要な分だけきちんと実施できている状態だと思います。
ちなみに、私がJOINして初めてマージされたコードは、CTOが2週間前に急いで書いたコードのリファクタリングでした。
(これも対応中の私の案件に必要だったからです)
社内のメンバー、やりとりが自然すぎて誰も気づいてないと思うのですが、結構な信頼関係がないとできないことを平気でやれていると思います。
では、各モジュールについて感想を述べていきます。
バックエンド / PHP/Laravel
ドメインの設計
コードは随所にドメイン駆動設計の用語が使われていますが、厳密に言うと「ドメイン駆動設計」ではなく「ドメイン駆動設計の用語を使ったクリーンアーキテクチャ」といったところです。
「DBのテーブルとAPI(RESTのリソース)に依存関係を持たせない」ための設計として有効に作用しているように見えています。
そもそもマナリンクは「自分たちのビジネスが何なのか」を問いながら成長するアーリーベンチャーのサービスなので、戦略的DDDはコストが見合わなかったんだと思います。
(テーブル名などがどうしたってズレる / 都度マイグレーションをやると工数が見合わないなど)
「DDDと向き合って苦しんだ経緯」みたいな認識がきちんと揃っており、この辺りも本当に何が必要かを軸に作られているなーと思いました。
DB設計
サービスの拡大を見越して、Laravel WayではなくDB設計のベストプラクティスを起点にした設計がされています。
テーブル数が増えるのを不要に恐れず、「テーブルの責務を明確にする」ことを重視しています。
テーブル数自体は多いですが、認知負荷は低くできています。
200近いテーブルを持つDBにも関わらず、「理解が難しい」と感じることが今の所ありません。
トリガなど一部ハマりそうな部分もありますが、バックアップなどの「ドメインの外/トリガを使うべき箇所」に閉じているため、驚き最小になっていると思います。
また、ベストプラクティスの「底本となっている書籍」がチームに共有されており、それを読んでいると意図が理解しやすかったです。
(この本が一番影響強い気がしました)
テスト
API単位のテストが網羅されているので、改修対象のAPIのテストから処理を辿っていけば一通りの設計は理解できるようになっています。
UTは多すぎず少なすぎずといった感じです。過度に書きすぎて改修が難しくなる を嫌った結果だと解釈してます。
カバレッジを開発指標にしてはいないが、自然と健全なカバレッジになっている状態です。
あと、サービスの拡大に伴い、必要に駆られて高速化した跡があります。この辺りも何が必要かカルチャーの結果だと思います。
(おまけ)そもそものPHP/Laravelについて
なんとなーく忌避していたPHPですが、思ったよりもだいぶ良かったです。
javascirptほどの自由度がないのが逆に設計で迷うことがなく、本質的な部分に集中できるのが体験が良いです。
今まで「DI？ 高階関数使えば自分で組めるしいらなくね？」論者だったのですが、書くべき方法が決まっているのは悩むこと少なくて良いです。
PHP自体の文法にはクセ(というかjsとのギャップ)がありますが、
PHP Stormの補完 + ChatGPTへの質問を併用すると、ほぼ言語自体の学習には時間を使わずにキャッチアップできています。
強いていうなら、配列にジェネリクスが無いのはチョットダケ嫌です。チョットダケ。
フロントエンド / Nuxt.js + Next.js
決してキラキラした素晴らしい状態ではないが真っ当に向き合えば真っ当に物が作れる状態になっていると思いました。
ドメインの複雑性をサーバに寄せ切っているので、フロントエンドは「サーバから受け取ったデータを高速に表示する」だけの役割を担っている状態です。
(逆に、表示の高速化は日々健全に模索できている状態だと思います)
Nuxt.js → Next.jsの移行期のため、それならではのつらみはあるが、
開発環境にきちんと整備されているため、開発環境でハマることはほとんどなかったです。
この辺のこだわりはこちらのスライドに詳しく書かれてるのでよければどうぞ
(チームメンバーのLTスライドです)
あと、余談ですがSEOは開発だけでなくbizにも有識者が多いです。
私はtoCサービス開発経験が浅いので、日々雑談を「勉強になるなーと」思いながら聴いてます。
アプリ / Expo(ReactNative)
「Expoでできる範囲にできるだけ閉じた実装で、最も良いユーザ体験を提供をする」という方針があるように見えます。
何が必要かから自分たちに何ができるかを考えた結果だと思います。
ビジネスレベルで「アプリは作れるがネイティブアプリエンジニアは今の所いない」という共通認識が取れていそうで、
この規模のベンチャーが「アプリが絶対に必要なビジネスだ」となった場合に取れるベストな選択肢だと思ってます。
インフラ / AWSなど
入社1ヶ月ではほぼ触ってないです。Step Functionsで作られたバッチスケジューラをうっすら眺めた程度です。
低レイヤ意識しないで開発できてるのは健全な証拠だと思ってます。
(aws-cdk好きなのでそのうち触りたいとは思いつつ)
最後にあえてちょっとネガティブなことを言ってみる
とまあ、こんな感じで
コードの質やカルチャーに関しては本当に素晴らしい状態だと思います。
ただ、その反動で開発組織の仕組みはあまり洗練されていない状態です。
わかりやすい例で言うと、日々の開発フローが可視化/言語化されておらず、業務改善がうまく回せないなどです。
これは原因に一貫性がある話で、なくてもなんとかなるメンバーとコードと事業フェーズだった/ので必要なかったというカルチャーの結果だと思っています。
とはいえ規模拡大を考えるとそろそろそういったものも必要になってくるフェーズです。
というわけで、こう言う記事ばかり書いていた私がEMとして呼ばれたというわけです。知らんけど。
🤟🤟🤟ここから言語化を始めていきます🤟🤟🤟
今の開発の仕組みに変なこだわりがないため、何かを始めようとするとものすごい勢いで行くのがほんまにすごいことですね。べんちゃあ。
入社二週間でカンバン作って開発フローを可視化してやりました。早速朝会で使い倒しています。
一緒にこの組織をデカくしていきたい人、ぜひご連絡を〜〜〜
オンライン家庭教師マナリンクを運営するスタートアップNoSchoolのテックブログです。 manalink.jp/ 創業以来年次200％前後で売上成長しつつ、技術面・組織面での課題に日々向き合っています。 カジュアル面談はこちら！ forms.gle/fGAk3vDqKv4Dg2MN7
Discussion