2023/02/24(金)に開催された 『【初心者歓迎!】気になるテクノロジー 語り出したら止まらNight(略してかたとま)』( https://oweb.connpass.com/event/271924/ ) でおこなったLT登壇の資料です。
技術的負債がなぜ起こるのかを説明しつつ、 プログラミング初心者に向けた、技術的負債を防ぐ最初の一歩についてご紹介しています。
ٕज़తෛ࠴Λ͙ʹԣ ߐ ʢ Α ͜ ͑ ʣ͔ͨͱ·φΠτ-5ʂ
View Slide
自己紹介• 名前:横江(よこえ)• Twitter: yokoe24• ラブグラフ(好きな場所で👉のような 写真を撮ってくれるサービス)のCTO• 好きなもの:人と話すこと• 今回の資料は G's ACADEMY の 生徒さんを意識して作成しました
G ' sA C A D E M Y と は
G's ACADEMY• このイベントの主催• 「起業」をゴールとする人にもフォーカスした プログラミングスクール• 2015年にデジタルハリウッド 株式会社が設立• カミナシのCEO諸岡さんも G's ACADEMY卒業生
起業に絡む技術的問題• 最初のMVP(Minimum Viable Product)が作れない• G's ACADEMY がサポート• 最初のエンジニアが見つからない• CEO自身がコードを書けることですぐには困らない• 採用時、いいエンジニアかを見分けられるG's ACADEMY で学ぶことで解決! すごい!
起業に絡む技術的問題• 最初のMVP(Minimum Viable Product)が作れない• G's ACADEMY がサポート• 最初のエンジニアが見つからない• CEO自身がコードを書けることですぐには困らない• 採用時、いいエンジニアかを見分けられる• 技術的負債で開発速度が低下• 経験が足りないとこれは避けにくい
技 術 的 負 債 と はな に か
技術的負債とは将来のことを考えずに実装した結果、あとでしっぺ返しをくらうこと。具体的には、開発スピードの低下やインフラコストの増加が起こりやすい。
技術的負債とは将来のことを考えずに実装した結果、あとでしっぺ返しをくらうこと。具体的には、開発スピードの低下やインフラコストの増加が起こりやすい。→ 会社の成長スピードが低下!!
負債の発生の仕方例• 開発時間が足りず、将来の拡張性を考えずに実装• 企画側(PM)が作った設計書に従って、 変な分岐が増えるのにそのまま実装してしまった• 機能を削除したのにコードを一部残したままに• コードにコメントを書かない• ライブラリのバージョンを上げることなく数年経過• ストレージ容量をとりあえず大きめに契約• データベースの知識が薄く表示速度の遅いページ作成
それぞれ何が起こるか 1• 開発時間が足りず、将来の拡張性を考えずに実装 → これを繰り返した結果、コード量が多くなり、 新入社員エンジニアのキャッチアップスピード低下• 企画側(PM)が作った設計書に従って、 変な分岐が増えるのにそのまま実装してしまった → PMと相談すればマストではなかったとわかる実装に時間をいっぱいかけた上、あとから読む人にとって意図のわかりくいコードがいっぱいに・・・
それぞれ何が起こるか 2• 機能を削除したのにコードを一部残したままに → あとから見た人にとって消していいかわからないコードが残り続け、コードの可読性が低下• コードにコメントを書かない → 複雑な処理を読み解くのに時間がかかったり、実装背景のわからないコードが残って後任が困惑したり• ライブラリのバージョンを上げることなく数年経過 → バージョンアップは差分が大きくなるほど困難に
それぞれ何が起こるか 3• ストレージ容量をとりあえず大きめに契約 → AWSのEBSやRDSのストレージ容量は増やすのは簡単だが減らすのは難しい。無駄コストがかかり続ける• データベースの知識が薄く表示速度の遅いページ作成 → N+1問題と呼ばれる、データベースに大量のアクセスをしてしまってページ表示が遅くなる問題が起こる。ユーザーの不満増加、管理者画面の操作効率低下、開発スピードも低下が起こる
で も 技 術 的 負 債 はし ょ う が な い
技術的負債は生まれる 1• 開発時間が足りず、将来の拡張性を考えずに実装 一番最初に書いたこちら、実はベンチャーにとっては正義です! 作った機能をなくす結果になることは多々あります。 「せっかく作ったのにもったいない!」なんて気持ちになることを避けるためにも、拡張性はあまり考えず、とりあえずで実装するのが正解です!
技術的負債は生まれる 2• 企画側(PM)が作った設計書に従って、 変な分岐が増えるのにそのまま実装してしまった 企画側と相談すればもっと単純に実装できたはずの ものに時間をかけるのはギルティーですが、 開発的にちょっと負債になりそうでも、それが顧客を幸せにできる特殊な実装ならするべきです。 ときには技術的負債を生んででも、プロダクトの価値を最大化するのが開発チームの価値です。
今 す ぐ で き る技 術 的 負 債 の 防 止
負債を作らない第1歩• 1週間後の自分が読んでわからなそうな場所に コメントを書くようにしよう!• タスクに取りかかる前に、それが何日かかりそうな タスクかをあらかじめ概算する習慣をつけよう! → 大きな実装を小さな部品ごとに分けて考える習慣が 身につき、きれいにコードを書けるようになります• ページャーの機能を必ず実装するようにしよう!
ページャーの機能• 全てのデータを1ページで表示しようとせず、 ページャーを実装して、50件ごと表示するような 画面を作ってあげてください• これがあるだけで、表示の遅すぎるページが だいぶ生まれにくくなります• Rails でも Laravel でも かんたんに実装できます!
最後にいろいろ言ったけど・・・深く考える以上に完成させるのが1番大事!!