Upgrade to Pro — share decks privately, control downloads, hide ads and more …

技術的負債を防ぐには / What is the Technical Debt

技術的負債を防ぐには / What is the Technical Debt

2023/02/24(金)に開催された
『【初心者歓迎!】気になるテクノロジー 語り出したら止まらNight(略してかたとま)』( https://oweb.connpass.com/event/271924/ ) でおこなったLT登壇の資料です。

技術的負債がなぜ起こるのかを説明しつつ、
プログラミング初心者に向けた、技術的負債を防ぐ最初の一歩についてご紹介しています。

ハトネコエ

February 27, 2023
Tweet

More Decks by ハトネコエ

Other Decks in Technology

Transcript

  1. 自己紹介 • 名前:横江(よこえ) • Twitter: yokoe24 • ラブグラフ(好きな場所で👉のような 
 写真を撮ってくれるサービス)のCTO

    • 好きなもの:人と話すこと • 今回の資料は G's ACADEMY の 
 生徒さんを意識して作成しました
  2. 起業に絡む技術的問題 • 最初のMVP(Minimum Viable Product)が作れない • G's ACADEMY がサポート •

    最初のエンジニアが見つからない • CEO自身がコードを書けることですぐには困らない • 採用時、いいエンジニアかを見分けられる G's ACADEMY で学ぶことで解決! すごい!
  3. 起業に絡む技術的問題 • 最初のMVP(Minimum Viable Product)が作れない • G's ACADEMY がサポート •

    最初のエンジニアが見つからない • CEO自身がコードを書けることですぐには困らない • 採用時、いいエンジニアかを見分けられる • 技術的負債で開発速度が低下 • 経験が足りないとこれは避けにくい
  4. 負債の発生の仕方例 • 開発時間が足りず、将来の拡張性を考えずに実装 • 企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった • 機能を削除したのにコードを一部残したままに •

    コードにコメントを書かない • ライブラリのバージョンを上げることなく数年経過 • ストレージ容量をとりあえず大きめに契約 • データベースの知識が薄く表示速度の遅いページ作成
  5. それぞれ何が起こるか 1 • 開発時間が足りず、将来の拡張性を考えずに実装 
 → これを繰り返した結果、コード量が多くなり、 
 新入社員エンジニアのキャッチアップスピード低下 •

    企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった 
 → PMと相談すればマストではなかったとわかる実装 に時間をいっぱいかけた上、あとから読む人にとって 意図のわかりくいコードがいっぱいに・・・
  6. それぞれ何が起こるか 2 • 機能を削除したのにコードを一部残したままに 
 → あとから見た人にとって消していいかわからない コードが残り続け、コードの可読性が低下 • コードにコメントを書かない

    
 → 複雑な処理を読み解くのに時間がかかったり、実装 背景のわからないコードが残って後任が困惑したり • ライブラリのバージョンを上げることなく数年経過 
 → バージョンアップは差分が大きくなるほど困難に
  7. それぞれ何が起こるか 3 • ストレージ容量をとりあえず大きめに契約 
 → AWSのEBSやRDSのストレージ容量は増やすのは簡 単だが減らすのは難しい。無駄コストがかかり続ける • データベースの知識が薄く表示速度の遅いページ作成

    
 → N+1問題と呼ばれる、データベースに大量のアク セスをしてしまってページ表示が遅くなる問題が起こ る。ユーザーの不満増加、管理者画面の操作効率低 下、開発スピードも低下が起こる
  8. 技術的負債は生まれる 1 • 開発時間が足りず、将来の拡張性を考えずに実装 
 一番最初に書いたこちら、実はベンチャーにとっては 正義です! 
 作った機能をなくす結果になることは多々あります。 


    「せっかく作ったのにもったいない!」なんて気持ち になることを避けるためにも、拡張性はあまり考え ず、とりあえずで実装するのが正解です!
  9. 技術的負債は生まれる 2 • 企画側(PM)が作った設計書に従って、 
 変な分岐が増えるのにそのまま実装してしまった 
 企画側と相談すればもっと単純に実装できたはずの 
 ものに時間をかけるのはギルティーですが、

    
 開発的にちょっと負債になりそうでも、それが顧客を 幸せにできる特殊な実装ならするべきです。 
 ときには技術的負債を生んででも、プロダクトの価値 を最大化するのが開発チームの価値です。
  10. 負債を作らない第1歩 • 1週間後の自分が読んでわからなそうな場所に 
 コメントを書くようにしよう! • タスクに取りかかる前に、それが何日かかりそうな 
 タスクかをあらかじめ概算する習慣をつけよう! 


    → 大きな実装を小さな部品ごとに分けて考える習慣が 
   身につき、きれいにコードを書けるようになります • ページャーの機能を必ず実装するようにしよう!