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

More Related Content

What's hot

ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善
増田 亨
 
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイントドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
増田 亨
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
増田 亨
 
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
 
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
 
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
pospome
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
 
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
 
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
 
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
増田 亨
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
 

What's hot (20)

ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善ソフトウェア開発のやり方の改善
ソフトウェア開発のやり方の改善
 
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイントドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の学習曲線とブレークポイント
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
 
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
 
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
 
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
 
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
 
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
 
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
 

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

仕様七変化
仕様七変化仕様七変化
仕様七変化
galluda
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
 
保守とDDDと私
保守とDDDと私保守とDDDと私
保守とDDDと私
Takuya Kawabe
 
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
Shuji Morisaki
 
13_B_5 Who is a architect?
13_B_5 Who is a architect?13_B_5 Who is a architect?
13_B_5 Who is a architect?
Atsushi Fukui
 
これからの「キャリア」の話をしよう .pptx
これからの「キャリア」の話をしよう .pptxこれからの「キャリア」の話をしよう .pptx
これからの「キャリア」の話をしよう .pptx
yagizo
 
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
TomomitsuKusaba
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?
pospome
 
お客様とコードの間
お客様とコードの間お客様とコードの間
お客様とコードの間
Moriyuki Hirata
 
浪江町ハッカソンインプットセミナー20140621
浪江町ハッカソンインプットセミナー20140621浪江町ハッカソンインプットセミナー20140621
浪江町ハッカソンインプットセミナー20140621
Satoshi Maeda
 
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」Takashi Uemura
 
アジャイルジャパン2015 講演資料
アジャイルジャパン2015 講演資料アジャイルジャパン2015 講演資料
アジャイルジャパン2015 講演資料
KDDI
 
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
hiroki tanaka
 
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
日本マイクロソフト株式会社
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
Rakuten Group, Inc.
 
Htmlコーディングの効率化 前編
Htmlコーディングの効率化 前編Htmlコーディングの効率化 前編
Htmlコーディングの効率化 前編
Yasuhito Yabe
 
要注意!?効果の出ない技術研修に共通する3つのこと
要注意!?効果の出ない技術研修に共通する3つのこと要注意!?効果の出ない技術研修に共通する3つのこと
要注意!?効果の出ない技術研修に共通する3つのこと
codecampJP
 
Refactoring
RefactoringRefactoring
Refactoring
Akinori IKEDA
 
Lt40
Lt40Lt40
Lt40
GIG inc.
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
 

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

仕様七変化
仕様七変化仕様七変化
仕様七変化
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
 
保守とDDDと私
保守とDDDと私保守とDDDと私
保守とDDDと私
 
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
 
13_B_5 Who is a architect?
13_B_5 Who is a architect?13_B_5 Who is a architect?
13_B_5 Who is a architect?
 
これからの「キャリア」の話をしよう .pptx
これからの「キャリア」の話をしよう .pptxこれからの「キャリア」の話をしよう .pptx
これからの「キャリア」の話をしよう .pptx
 
保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について保守性の高いアプリケーション設計について
保守性の高いアプリケーション設計について
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?
 
お客様とコードの間
お客様とコードの間お客様とコードの間
お客様とコードの間
 
浪江町ハッカソンインプットセミナー20140621
浪江町ハッカソンインプットセミナー20140621浪江町ハッカソンインプットセミナー20140621
浪江町ハッカソンインプットセミナー20140621
 
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」
20121124 学生セミナー「基礎からわかる! IT業界とプログラミング」
 
アジャイルジャパン2015 講演資料
アジャイルジャパン2015 講演資料アジャイルジャパン2015 講演資料
アジャイルジャパン2015 講演資料
 
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
エンタープライズRuby on Rails ~エンプラでぶち当たった2つの壁と突破法~
 
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
【de:code 2020】 Power Platform いまさら聞けないモデル駆動型アプリケーション
 
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten,  core skills  neede...
楽天市場で使われている技術、エンジニアに必要なコアスキルとはTechnology used in Rakuten, core skills neede...
 
Htmlコーディングの効率化 前編
Htmlコーディングの効率化 前編Htmlコーディングの効率化 前編
Htmlコーディングの効率化 前編
 
要注意!?効果の出ない技術研修に共通する3つのこと
要注意!?効果の出ない技術研修に共通する3つのこと要注意!?効果の出ない技術研修に共通する3つのこと
要注意!?効果の出ない技術研修に共通する3つのこと
 
Refactoring
RefactoringRefactoring
Refactoring
 
Lt40
Lt40Lt40
Lt40
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 

More from pospome

トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめトランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
pospome
 
MicroServices & APIs
MicroServices & APIsMicroServices & APIs
MicroServices & APIs
pospome
 
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについてDatastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについて
pospome
 
Goのシンプルさについて
GoのシンプルさについてGoのシンプルさについて
Goのシンプルさについて
pospome
 
パッケージの循環参照
パッケージの循環参照パッケージの循環参照
パッケージの循環参照
pospome
 
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについてControllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについて
pospome
 
サーバサイドNodeの使い道
サーバサイドNodeの使い道サーバサイドNodeの使い道
サーバサイドNodeの使い道
pospome
 

More from pospome (7)

トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめトランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
 
MicroServices & APIs
MicroServices & APIsMicroServices & APIs
MicroServices & APIs
 
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについてDatastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについて
 
Goのシンプルさについて
GoのシンプルさについてGoのシンプルさについて
Goのシンプルさについて
 
パッケージの循環参照
パッケージの循環参照パッケージの循環参照
パッケージの循環参照
 
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについてControllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについて
 
サーバサイドNodeの使い道
サーバサイドNodeの使い道サーバサイドNodeの使い道
サーバサイドNodeの使い道
 

Recently uploaded

RayPen Product Description Documentation - 2024.6.19
RayPen Product Description Documentation - 2024.6.19RayPen Product Description Documentation - 2024.6.19
RayPen Product Description Documentation - 2024.6.19
GrapeCity, inc.
 
RayBarcode Product Description Documentation - 2024.6.19
RayBarcode Product Description Documentation - 2024.6.19RayBarcode Product Description Documentation - 2024.6.19
RayBarcode Product Description Documentation - 2024.6.19
GrapeCity, inc.
 
シグネチャで始めるRustプログラミング - Superteam Japan Developer Event
シグネチャで始めるRustプログラミング - Superteam Japan Developer Eventシグネチャで始めるRustプログラミング - Superteam Japan Developer Event
シグネチャで始めるRustプログラミング - Superteam Japan Developer Event
K Kinzal
 
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet DocumentationRaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
GrapeCity, inc.
 
Solanaで始めるRustプログラミング - Superteam Japan Developer Event
Solanaで始めるRustプログラミング - Superteam Japan Developer EventSolanaで始めるRustプログラミング - Superteam Japan Developer Event
Solanaで始めるRustプログラミング - Superteam Japan Developer Event
K Kinzal
 
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdfクラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
TatsuyaHanayama
 
RaySheet Product Description Documentation - 2024.6.19
RaySheet Product Description Documentation - 2024.6.19RaySheet Product Description Documentation - 2024.6.19
RaySheet Product Description Documentation - 2024.6.19
GrapeCity, inc.
 
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
Hibiki Mizuno
 

Recently uploaded (8)

RayPen Product Description Documentation - 2024.6.19
RayPen Product Description Documentation - 2024.6.19RayPen Product Description Documentation - 2024.6.19
RayPen Product Description Documentation - 2024.6.19
 
RayBarcode Product Description Documentation - 2024.6.19
RayBarcode Product Description Documentation - 2024.6.19RayBarcode Product Description Documentation - 2024.6.19
RayBarcode Product Description Documentation - 2024.6.19
 
シグネチャで始めるRustプログラミング - Superteam Japan Developer Event
シグネチャで始めるRustプログラミング - Superteam Japan Developer Eventシグネチャで始めるRustプログラミング - Superteam Japan Developer Event
シグネチャで始めるRustプログラミング - Superteam Japan Developer Event
 
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet DocumentationRaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
RaySheetで解決できるシナリオ10選-業務改善に貢献する機能 - RaySheet Documentation
 
Solanaで始めるRustプログラミング - Superteam Japan Developer Event
Solanaで始めるRustプログラミング - Superteam Japan Developer EventSolanaで始めるRustプログラミング - Superteam Japan Developer Event
Solanaで始めるRustプログラミング - Superteam Japan Developer Event
 
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdfクラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
クラウドネイティブにおけるセキュアなソフトウェア・サプライ・チェーンの考え方とベストプラクティス.pdf
 
RaySheet Product Description Documentation - 2024.6.19
RaySheet Product Description Documentation - 2024.6.19RaySheet Product Description Documentation - 2024.6.19
RaySheet Product Description Documentation - 2024.6.19
 
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
GPT - 振り返りフレームワークKPTをちょっとKAIZENしてちょうど良いフレームワークに。
 

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