私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
2022-12-21 技術的負債の返済から改善する開発者体験 - Techmee vol.5 https://timeedev.connpass.com/event/268296/ 動画 https://youtu.be/tQ3BGgnvMwQ
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
2021/04/10開催 Developer eXperience Day 2021 「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。 https://dxd2021.cto-a.org/program/time-table/b-3 クソコード動画はこちら …
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが
「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意 - スタディサプリ Product Team Blog
こんにちは、Quipper iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。 実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。 スタディサプリにおける React Native の利用 Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。 iOS 版スタディサプリの、git から取り出した
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
「下手だなあカイジくん…！技術的負債の返済の仕方が下手…！」 ちゃんとシステムを構築しないと後で多く利子を払うことになる
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。 2020-06-24 07:49:11
河野と申します。2018年8月からマッハバイトで業務委託（いわゆるフリーランス）として業務に携わっており、2022年6月から、テックリード（以降、TL）という立場となりました。 TLという言葉は広く使われていますが、実際に何をするのかは、会社や環境によってさまざま。 3ヶ月の振り返りがてら、ここに一例として公開してみようと思った次第です。 TL着任以前 Join当初はRailsエンジニアとしての働きを期待されており、最初の担当はマッハバイトiOS版用に、REST APIを開発することでした。 半年少しでその業務が一段落した後は、以下のことなどを担当してきました。 Rails製アプリケーションの機能追加、Ruby、RailsのUpdate ホストOSのUpdateに伴う、deploy環境の修正や、ライブラリなどのUpdate（オンプレ環境） マイクロサービスの中心に置きたいメッセージングサー
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.h…
はじめに 最近、ふと気づいたことがある。技術負債って、もう昔とは全然違うゲームになってるんじゃないか？いや、もっと正確に言うなら、ゲーム自体が終わろうとしているんじゃないか？ コーヒーを飲みながら、10年前に書いた自分のコードを眺めていた。当時は「きれいに書いた」つもりだったけど、いくつかの要望がありよく考えずに変更を加えた結果、負債の塊だ。でも、それを直すのに必要な時間とコストの計算が、根本的に変わってしまった。 いや、変わったどころか、もはや「時間とコスト」という概念すら意味をなさなくなりつつある。 syu-m-5151.hatenablog.com 私たちは技術負債を「悪いコード」として理解してきた。しかし、それは大きな誤解だった。Ward Cunninghamが1992年に生み出した原初の概念は、現在広く信じられている「技術的問題」とは根本的に異なっていた。 彼の言う負債とは、ソフ
カミナシでの技術的負債返済プロジェクトとその決断 / Beyond tech debts at Kaminashi
Talked at 「スタートアップと技術的負債」 #SELECKLIVE https://yumemi.connpass.com/event/255925/
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)
クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です 影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです そうした方が関心の範囲が限定できるから...だけど、全体最適ではない— magnoliak🍧 (@magnolia_k_) 2022年3月12日 でも悪気はないんです 真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ— magnoliak🍧 (@magnolia_k_) 2022年3月12日 「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね でも、「継続的に同じペースが保てるか？」「スケールするか？」というと、そんなことは無いけど、そ
@aumy_f, 2024-08-10-tailwind: Tailwind CSSは特異なコードベースの見た目から負債になりそうとたまに言われるが、俺はあんまりそう思っていないので説明したい。 Tailwind CSS 1 を一目見た人、特にCSS初学者のうちけっこうな割合が「これエグい負債になりそう」と思う気がする。なぜなら実際にそのような意見をちらほら見るからなんだけども、自分はあんまりそうは思っていないし、微妙に今のCSSについて誤解があるような空気も感じるのでその理由を説明したい2。JSXと同じで嬉しさを理解して使い慣れればなんてことはないのだけど、一方でその背景にある話はJSXより複雑なので単純に使って慣れればいいという話でもなさそう。 なお、この記事は私の以下の2ツイートを膨らませたものです。 Tailwind CSS、剥がすのは大変そうだけどそれをもって重大な負債になると評
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
LLMでAI-OCR、実際どうなの？ / llm_ai_ocr_layerx_bet_ai_day_lt
Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
ソフトウェア開発の成果は、エンジニアの特性に大きく左右される。たとえば “コードを理解する能力” がその代表例だ。 こうした特性は、作業負荷や認知負荷に直結し、開発生産性に影響を与える。この観点からの評価も、成果を正しく捉えるうえで欠かせない。 もし、理解しづらいコードを書いてしまったら、現在および将来の開発生産性が損なわれる。技術的負債とは、そうした “開発生産性の低下” を「利息を支払う」ことにたとえた概念だ。 本稿は、技術的負債を10のカテゴリに整理したGoogleの文献を参考にしつつ、技術的負債との付き合い方を考える。 技術的負債を10のカテゴリで捉える ≫ 移行が必要なシステム ≫ 不十分なドキュメント ≫ 不十分なテスト ≫ 低品質なコード ≫ デッドコード/放棄されたコード ≫ 劣化したコード ≫ 専門知識不足のチーム ≫ 不安定な依存関係 ≫ 失敗した移行 ≫ 洗練されてい
2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
2023/10/31 @ Barフロントえんどう で発表した「リアーキテクトと開発生産性について」です。
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計｜ハイクラス転職・求人情報サイト アンビ（AMBI）
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計 遷移なく表示コンテンツを変更できるシングルページアプリケーションでは、ページの状態管理が重要になります。現在はReactによるUI構築とReduxによる状態管理を選択しているChatworkは、jQueryなどの技術的負債と共存しながら、フロントエンド設計の見直しを重ねてきました。クライアントサイド・アーキテクトの火村智彦（@eielh）さんと、エンジニア採用広報の高瀬和之（@guvalif）さんによる解説です。 クラウド型ビジネスチャットツール「Chatwork」は、2011年3月にローンチされて10年以上にわたり開発を継続してきました。このように長く続くサービスがユーザーに価値を提供し続けるには、時間経過による変化に適応するため設計の見直しが必要になります。 しかし、設計を
「負債にも50パーセントの時間を使ってください」は機能しなかった西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力と
技術的負債をうまくマネジメントすることは重要です。なぜなら、持続可能な長期的な利益の確保こそが競争戦略における目標であり、技術的負債への対応力はその目標に近づくための重要な組織能力だからです。EMとして組織の成果の最大化を目指す上で避けては通れない課題です。また技術的負債への対応は、単に技術的な課題ではなくそれらを包含するプロダクトの課題です。どうやって解決するかだけでなく、なぜ、いつ、どのくらいやるべきかを、事業責任者などのステークホルダーと合意して初めて対応を進めることができます。こうした課題に対しては、多職種をつなぐメンタルモデルの構築、方向付け、ファシリテーションといったソフトスキルが必要になってきます。EMはエンジニアリングの視点とそうしたスキルを併せ持つことが期待される存在で、技術的負債への対応においても重要な役割を担うと考えています。本記事では、技術的負債をマネジメントする方
お前も技術的負債にしてやろうか！ もしくは技術的負債と和田卓人さんをめぐるシンクロニシティ - YAMDAS現更新履歴
みんな大好き、技術的負債の話題である。 t-wada.hatenablog.jp まずはエチケットペーパーというか議論の前提として、和田卓人さんのブログエントリをはっておく。 技術的負債という概念の生みの親であるウォード・カニンガムの説明を読み直すと、「技術的負債」という言葉の一般的にイメージとは結構違うという話だが、ワタシ自身、技術的負債といえば、和田さんが書くように「リリース優先で雑なコードを書いたものの、結局はきれいに書き直されていないコード」や「古くなってしまった技術基盤（言語やインフラやフレームワーク）」のことだと思い込んでいた。これには蒙を開かされた。 ieeexplore.ieee.org 偶然だろうが、和田さんの文章が公開されたのと同じ今年の6月、IEEE Software に技術的負債についての文章が掲載されている。これを書いたのは、『Just Enough Softwa
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022 の 15日目の記事です。 qiita.com 筆者は過去に、中〜小規模のWebアプリケーションでレガシーフロントエンドの改善作業を業務でやっていた。その経験を元に技術同人誌を作成し、それがきっかけで「レガシーフロントエンド安全改善ガイド」という書籍を出した。 初版から数年経ってしまい、詳細な利用技術などの説明は少し古くなってしまっているのだが、ベースとなる考え方の部分は今でも変わっていないと思う。 一方で自分自身は、その経験が他の環境でも通用するのかを試してみたくなり、転職して一年強ほど大規模なフロントエンド刷新に関わっていた。 あまりにも規模が大きいため完遂を見届けたわけでもないが、現段階でも学びや得られたものは
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c7728c664ddd298cabc00615869a23f196ad5f90/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F2022-220117111455-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
クソコード動画「Userクラス」で考える技術的負債解消の観点
「技術的負債」への処方箋と「２つのDX」 - Qiita
技術的負債とステークホルダと説明責任と / The Debt
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
リーダブルコード by DDD / Readable Code by DDD
業務委託テックリードと技術的負債 - LIVESENSE ENGINEER BLOG
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
技術的負債の変質について - じゃあ、おうちで学べる
ベロシティを上手く使って 技術的負債を計画的に解消する
見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech
「Tailwind CSSめっちゃ負債になりそう」はそうでもないのでは、と思っている
サービスの持続的な成長と技術負債について
Googleが抽出した10個のカテゴリで技術的負債を捉えなおす - mtx2s’s blog
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
リアーキテクトと開発生産性について
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程 | ログミーBusiness
技術的負債のマネジメントを考える - yigarashiのブログ
規模感の違う脱レガシーで必要なこと - memo_md
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
スタメンの技術的負債解消戦略 - stmn tech blog
技術的負債が生まれる背景を理解して，アーリーからレイター向けの根本的なアプローチを考える
precious.jp
ameblo.jp/juicejuice-official
life-jump.co.jp
akio-bass.com
news.yahoo.co.jp
news.yahoo.co.jp