Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
アプリケーションコードにおける
技術的負債について考える
自己紹介
twitter
pospome
読み方
ポスポメ
職種
サーバサイドエンジニア
興味
クラス設計全般, DDD
ここら辺の技術に興味ある方は
  フォローしてくださると嬉しいです
普段思っていることをスライドにまとめてみました
具体的なリファクタリング例ではなく、
「考え方」についてのお話になります
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
仕様の変化に追従することが難しくなったコード
負債の例
・可読性が低い
 →どこで何をやっているかが分からないので、
  修正箇所の特定が困難
・修正による影響範囲が広い
 →1箇所修正すると、大量のコードを修正する必要がある
などなど色んな種類がある
以下のようなアプリケーションコード以外の負債は
対象外です
・RDBのテーブル設計のミス
・フレームワーク、ライブラリの選定ミス
・ミドルウェアの選定ミス
仕様の変化に追従することが難しくなったコードは
ビジネス要求の反映が遅れてしまい、
ビジネス成長の鈍化を招く可能性がある
どこから負債とみなすのか?
という負債の境界は個人や組織によって異なるが、
こういったコードは可能な限り避けたい
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
負債を防ぐためには
コード(設計)が仕様の変化に追従できるかどうかを
見極める必要がある
・初期実装の場合
・既存実装に修正を加える場合
初期実装の場合
・既存コードは存在しない
・将来的な仕様の変化を想定し、
 それに耐えられる設計にする必要がある
・ただ、仕様の変化を想定するの困難
・システム規模の成長、将来的に追加される機能など、
 想定できるケースは限られている
・つまり...
既存実装に修正を加える場合
・初期実装は「その時に想定した変化」にしか対応できない
・仮想定していたとしても、実際に耐えられない場合もある
・ということは、
 今回の修正はその想定内なのかを考える必要がある
・想定内であれば、そのまま修正可能
...
設計には限界がある
「その時」に想定した変化にしか耐えられない
ここで注意しておきたいのは
if による分岐を駆使すれば、
大抵の変化には対応できてしまうという点
意外と簡単に「動くもの」はできてしまう
「仕様の変化に追従できるかどうか?」という基準は
単純に「可能かどうか」で考えてはいけない
想定外の変化...
「可能かどうか」ではなく、
本来あるべき姿になっているかどうかで判断する必要がある
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
仕様の変化を想定した設計は困難なので、
その都度、想定外の変化に対応できる設計に
修正していく必要がある
負債を防ぐために必要なのは
そういった修正時間を確保できる開発体制
「負債」という言葉からも分かるように
負債を放置すると利子がつく
放置すればするほど、返済は困難になる
「限界が来たら手を入れる」というのは難しい
モチベーションも上がらない
仕様の変化に応じて継続的に見直し、
修正していく開発体制が必要
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
負債を防ぐのに大切なのは「継続的な見直し」であるが、
見直して正しい方向に修正できるスキルを持っていないと
負債を防ぐことはできない
別の形の負債を生み出すだけ
現状の何が問題で、
どのように修正すればいいのかを判断できるスキルが必要
必要なのはプログラミングの知識
・プログラミング原則
・実装パターン
・モジュール戦略
などなど・・・・
原則やパターンを知らなくても、コードは書けてしまう
動くものは作れてしまう
なので、
あまり必要性を感じないかもしれない
ただ、
もしあなたがパターンを知っていたら、
あなたが過去に書いたコードが
負債になることはなかったかもしれない
もっと良...
原則やパターンが常に正解とは限らないし、
適用できるケースも多くないかもしれない
しかしながら、
「知ってるけどやらない」と
「知らないからできない」は違う
過去の経験だけで
何の根拠もなくコードを修正するのではなく、
それらを引き出しとして持...
負債を防ぐのに必要なのは
継続的な見直しが可能な開発体制
&
正しいコードを判断できるスキル
・コードにおける技術的負債とは?
・負債を防ぐ
   設計の限界を知る
   継続的な見直し
   そのコードは正しいのか?
・返済の必要性
個人的にコードの評価軸には
「質」と「価値」があると思っている
・質
 →コード自体の質
  負債のないコード = 質が高い
・価値
 →そのコードが生み出す利益(お金)
  利益を生む = 価値が高い
・質が高い = 価値が高い とは限らない
・負債を抱えたコードの質を高くしても
 価値が変わらないのであれば、
 それは返済する必要のない負債かもしれない
・「価値」については時期や期限が重要な要素となる
・例えば、ソーシャルゲームで、
 キャ...
質よりも価値を優先するという選択肢も
現実的には十分ありえる
返済する必要があるのかどうかは考える必要がある
踏み倒すことができるのであれば、
それに越したことはないのかもしれない
まとめ
・特定の設計で仕様の変化に対応し続けるのは困難
 負債を防ぐことは難しい
・そう考えると
 「継続的な見直しが可能な開発体制」は必須
・開発体制が整っていたとしても、
 現状の問題点と正しい修正方針を判断しなければ
 別の形の負債を生み出すこと...
負債という単語に
ネガティブなイメージを持つかもしれないが
負債のないコードを保つのは難しい
常に何かしらの負債を抱えていることが多いはず
視点を変えて
ビジネスの成長を支えてきた価値のあるコード
と捉えると良いかもしれない
必要に応じて本来あ...
おわり
おまけ
これスライドの内容とあまり関係ないので、
1枚に突っ込みますが、
デザインパターンみたいな実装パターンって
「勉強しても使い所分からない」
ってのはあるあるじゃないですか?
適用例とかで船舶管理システム出されても、
船舶管理システムなん...
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

0

Share

Download to read offline

アプリケーションコードにおける技術的負債について考える

Download to read offline

社内勉強会用資料

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

アプリケーションコードにおける技術的負債について考える

  1. 1. アプリケーションコードにおける 技術的負債について考える
  2. 2. 自己紹介 twitter pospome 読み方 ポスポメ 職種 サーバサイドエンジニア 興味 クラス設計全般, DDD ここら辺の技術に興味ある方は   フォローしてくださると嬉しいです
  3. 3. 普段思っていることをスライドにまとめてみました 具体的なリファクタリング例ではなく、 「考え方」についてのお話になります
  4. 4. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  5. 5. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  6. 6. 仕様の変化に追従することが難しくなったコード
  7. 7. 負債の例 ・可読性が低い  →どこで何をやっているかが分からないので、   修正箇所の特定が困難 ・修正による影響範囲が広い  →1箇所修正すると、大量のコードを修正する必要がある などなど色んな種類がある
  8. 8. 以下のようなアプリケーションコード以外の負債は 対象外です ・RDBのテーブル設計のミス ・フレームワーク、ライブラリの選定ミス ・ミドルウェアの選定ミス
  9. 9. 仕様の変化に追従することが難しくなったコードは ビジネス要求の反映が遅れてしまい、 ビジネス成長の鈍化を招く可能性がある どこから負債とみなすのか? という負債の境界は個人や組織によって異なるが、 こういったコードは可能な限り避けたい
  10. 10. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  11. 11. 負債を防ぐためには コード(設計)が仕様の変化に追従できるかどうかを 見極める必要がある
  12. 12. ・初期実装の場合 ・既存実装に修正を加える場合
  13. 13. 初期実装の場合 ・既存コードは存在しない ・将来的な仕様の変化を想定し、  それに耐えられる設計にする必要がある ・ただ、仕様の変化を想定するの困難 ・システム規模の成長、将来的に追加される機能など、  想定できるケースは限られている ・つまり、初期実装は「その時に想定した変化」にしか  対応できない ・仮に想定して設計したとしても、  必要になった時に正しい設計である保証はない
  14. 14. 既存実装に修正を加える場合 ・初期実装は「その時に想定した変化」にしか対応できない ・仮想定していたとしても、実際に耐えられない場合もある ・ということは、  今回の修正はその想定内なのかを考える必要がある ・想定内であれば、そのまま修正可能 ・想定外であれば、既存実装を見直す必要がある
  15. 15. 設計には限界がある 「その時」に想定した変化にしか耐えられない
  16. 16. ここで注意しておきたいのは if による分岐を駆使すれば、 大抵の変化には対応できてしまうという点 意外と簡単に「動くもの」はできてしまう 「仕様の変化に追従できるかどうか?」という基準は 単純に「可能かどうか」で考えてはいけない 想定外の変化に無理やり対応してしまうと それが負債になる可能性が高い
  17. 17. 「可能かどうか」ではなく、 本来あるべき姿になっているかどうかで判断する必要がある
  18. 18. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  19. 19. 仕様の変化を想定した設計は困難なので、 その都度、想定外の変化に対応できる設計に 修正していく必要がある 負債を防ぐために必要なのは そういった修正時間を確保できる開発体制
  20. 20. 「負債」という言葉からも分かるように 負債を放置すると利子がつく 放置すればするほど、返済は困難になる 「限界が来たら手を入れる」というのは難しい モチベーションも上がらない 仕様の変化に応じて継続的に見直し、 修正していく開発体制が必要
  21. 21. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  22. 22. 負債を防ぐのに大切なのは「継続的な見直し」であるが、 見直して正しい方向に修正できるスキルを持っていないと 負債を防ぐことはできない 別の形の負債を生み出すだけ 現状の何が問題で、 どのように修正すればいいのかを判断できるスキルが必要
  23. 23. 必要なのはプログラミングの知識 ・プログラミング原則 ・実装パターン ・モジュール戦略 などなど・・・・
  24. 24. 原則やパターンを知らなくても、コードは書けてしまう 動くものは作れてしまう なので、 あまり必要性を感じないかもしれない ただ、 もしあなたがパターンを知っていたら、 あなたが過去に書いたコードが 負債になることはなかったかもしれない もっと良いコードが書けたかもしれない
  25. 25. 原則やパターンが常に正解とは限らないし、 適用できるケースも多くないかもしれない しかしながら、 「知ってるけどやらない」と 「知らないからできない」は違う 過去の経験だけで 何の根拠もなくコードを修正するのではなく、 それらを引き出しとして持っておくと 今より良いコードが書けるようになると思います
  26. 26. 負債を防ぐのに必要なのは 継続的な見直しが可能な開発体制 & 正しいコードを判断できるスキル
  27. 27. ・コードにおける技術的負債とは? ・負債を防ぐ    設計の限界を知る    継続的な見直し    そのコードは正しいのか? ・返済の必要性
  28. 28. 個人的にコードの評価軸には 「質」と「価値」があると思っている ・質  →コード自体の質   負債のないコード = 質が高い ・価値  →そのコードが生み出す利益(お金)   利益を生む = 価値が高い
  29. 29. ・質が高い = 価値が高い とは限らない ・負債を抱えたコードの質を高くしても  価値が変わらないのであれば、  それは返済する必要のない負債かもしれない ・「価値」については時期や期限が重要な要素となる ・例えば、ソーシャルゲームで、  キャラの誕生日に合わせてイベントをやる場合、  その日を逃すと  同じコードであっても価値は下がってしまう
  30. 30. 質よりも価値を優先するという選択肢も 現実的には十分ありえる 返済する必要があるのかどうかは考える必要がある 踏み倒すことができるのであれば、 それに越したことはないのかもしれない
  31. 31. まとめ
  32. 32. ・特定の設計で仕様の変化に対応し続けるのは困難  負債を防ぐことは難しい ・そう考えると  「継続的な見直しが可能な開発体制」は必須 ・開発体制が整っていたとしても、  現状の問題点と正しい修正方針を判断しなければ  別の形の負債を生み出すことになる   ・それを防ぐためには  「正しいコードを判断できるスキル」も必須 ・一方で、返済する必要があるのかを考えるのは重要
  33. 33. 負債という単語に ネガティブなイメージを持つかもしれないが 負債のないコードを保つのは難しい 常に何かしらの負債を抱えていることが多いはず 視点を変えて ビジネスの成長を支えてきた価値のあるコード と捉えると良いかもしれない 必要に応じて本来あるべき姿にしてあげよう
  34. 34. おわり
  35. 35. おまけ これスライドの内容とあまり関係ないので、 1枚に突っ込みますが、 デザインパターンみたいな実装パターンって 「勉強しても使い所分からない」 ってのはあるあるじゃないですか? 適用例とかで船舶管理システム出されても、 船舶管理システムなんて作らないので、 適用ケースが現実に転がってないと思っちゃうんですよね なので、結局 忘れる or パターン意味ないって思っちゃう  みたいなこと多いですよね 具体的な実装はネットで調べれば分かるので、 パターンの概要(目的)と適用ケースだけ頭に叩き込んでおけば 十分だと思います 「ここに xxx 使えそうだな。どんな実装だったっけな?」 「なんかこーゆー時に使うパターンあったな。なんだっけな?」 って感じになれば十分かと思います あと最初は無駄に適用してみるってのも1つの勉強方法かもしれないですね TemplateMethod を無駄に使って変な設計になった経験ある人多いんじゃない ですかね? 僕もこれやったんですが、今思うと勉強になりました。

社内勉強会用資料

Views

Total views

1,500

On Slideshare

0

From embeds

0

Number of embeds

555

Actions

Downloads

2

Shares

0

Comments

0

Likes

0

×