メインコンテンツまでスキップ

HexSchool Node.js 企業専門クラス

· 約6分
Pitt Wu
Software / Product Engineer

HexSchool(台湾のコーディングブートキャンプ)の Node.js 企業専門クラスを修了して、いくつか思ったことや振り返りを書いてみる。

なぜこのコースを選んだのか?何を解決したかったのか?

これはかなり高額なコースだ。しかも HexSchool の性質上(ビジネス的な理由で受講者を断れない)、カリキュラムの内容はどうしても初心者寄りの設計にならざるを得ない。

こういった条件を考えると、コスパは悪そうに見えるけど、実際にはこんなメリットがある:

チーム開発の経験

コースの最初からグループ開発が必須になっている。受講者のほとんどはフロントエンド出身でバックエンドの実務経験がないので、バックエンド開発におけるコミュニケーションや進め方を練習する良い機会になる。

別の見方をすれば、一緒に開発した仲間は将来お互いに助け合える関係になるし、人脈を広げるという意味でも悪くない。

サンクコスト効果

前述の通り、けっこう高いコースなので、僕みたいな怠け者でも「このお金を無駄にしたくない」と思えば、仕事終わりに頑張ってプロジェクトを進めざるを得ない。deadline までにプロジェクトを完成させて元を取る――ある意味、自律を促す仕組みとも言える。

新しい視点

プロジェクト全体を企画からデザイン、開発まで一気通貫でやるので、客観的に見れば内容は浅めだけど、全メンバーが PM、UI/UX、フロントエンド、バックエンドのフローを一通り経験できる。将来の仕事に対して新しい視点が得られるのは確かだ。

コース内容

カリキュラムの中で、基本的な MongoDB のコマンド操作や Node.js での API 実装を除くと、個人的に一番価値があったのはサードパーティサービスとの連携部分だと思う。ソーシャルログインや決済連携など、この辺りはドキュメントを読み込んで地道にやるしかない部分で、授業で教えてもらえるとドキュメント調査の時間を省ける。

また、コースの一部はまだ MVC パターンをベースに設計されていて、チームメンバーがプロジェクト実装時に自分たちでフロントエンドとバックエンドの分離を進める必要がある。ここもそれなりに考える時間が必要だった。

一部のコース内容は外部講師によるライブ配信形式の授業で、内容にギャップが出ることもあった。例えば今回のユニットテストの授業はフロントエンド向けの内容だったので、バックエンドのユニットテストを練習したい場合はチームで自力でやるしかなかった。

プロジェクト実践(超主観的な感想)

プロジェクト実践は、個人的にこのコースで最も価値のある部分だと思う。中でも一番大事なのは、チーム内部の協力と計画だ。

グループ分けの前に正直に

チーム分けの前にスキルの自己評価がある。不慣れな領域があるなら正直に申告すべきだ。チーム内の実力差が大きすぎると深刻な対立が生まれやすく、プロジェクトがスムーズに進まなくなる。

開発にはバッファ時間を確保する

ほとんどの人がフロントエンドからバックエンド開発に入るので、以前フロントエンドでは遭遇しなかった細かい問題が開発速度を落とすことになる。例えば決済連携の後には必ず注文処理が必要になるし、注文には取引時刻の問題なども絡んでくる。

フロントエンドだと以前はこういった問題を考える必要がなかった。API を叩いてリスト表示して操作する、基本はそれだけだったから。でもバックエンドではこれらすべてを考慮しなければならない。

プロジェクトのリリースを目標にする

以下の点を真剣に考えてほしい:

  • メンバーのほとんどは本業があり、使える時間は限られている(メンバーが仕事で緊急対応や残業を抱えているかどうかは予測できない)
  • deadline は非常にタイトで、実際の開発時間は限られている
  • ほとんどのメンバーにバックエンド経験がなく、必ず試行錯誤に時間がかかる

だから第一段階の目標は、「使えるレベルの作品」を作ることであって、「完璧な作品」ではない。この段階でアーキテクチャや最適化、テストのことを考えすぎてはいけない。それは後の話だ。

完璧を追い求めすぎると、開発が止まるだけでなく、もっと怖いのはチームが分裂する可能性があること(潜在的なさまざまな衝突、特にメンバーが昼間の仕事のプレッシャーを抱えているかどうかは分からない)。チームが分裂したら、プロジェクトは 94.87% の確率で失敗に終わる。まず見た目は悪くても動くものを作れば、お互いの自信を大きく後押しできる。

特に、チームが採用する技術をむやみに広げるのは避けるべきだ。フロントエンドで言えば、ReactVue を同時に使うようなダブルフレームワーク構成はやめた方がいい。チームに一つのフレームワークが得意な人がいたとしても、他のメンバーがすぐに習得して開発に使えるとは限らない。

拡張と最適化

プロジェクトで最初の主要機能が完成した段階で、第一フェーズは終了と考えていい。一息つけるだけでなく、他の機能の開発や、試してみたかった技術の導入、UX の改善などを考え始められる。

僕らのプロジェクトを例に挙げると、段階的に websocket によるメッセージストリーミング、PWA、アニメーション、チェックインシステムなどを追加して、サイト全体のコンテンツをより充実させていった。

おわりに

最後に、今回のプロジェクトで完成したフロント・管理画面のデプロイ URL と Repo を載せておくので、参考にしてもらえたら嬉しい。

フロント(Client)

管理画面(Admin)

<!-- test account & password -->

account : admin
password : 12345678

関連リンク

関於我成為了 2023 Node.js 軟體工程師企業專題班教練這件事