Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 近年の AI の発展により、ソースコードの生成を AI に任せる時代が到来しています。ただし、最終的には人間の目による確認が必要です（耳にタコができるほど聞いたかもしれませんが）。 また、AI にすべてのドメイン知識を理解させるのは難しく、完璧なソースコードを生成するのは現実的ではありません。 そのため、今も昔もリファクタリングは不可欠です。本記事では、リファクタリングについての個人的な考えをまとめてみました。 リファクタリングとは？ リファクタリングとは、プログラムの動作を変えずに、ソースコードの内部構造を改善する作業を指し
Claude CodeやCursorでのコーディング体験をさらに高めたい方には、Apidog MCPサーバーの導入をおすすめします。統合されたAPI管理と自動化テストを通じて、開発ワークフローを効率化し、チーム全体の生産性アップ。今すぐ無料トライアルで、開発・テストの新しい標準を実感してください。 価格構造：Claude Code vs. Cursorどちらのツールが安いかを判断するには、その価格モデルを詳細に分析する必要があります。以下に、Claude CodeとCursorの両方のコスト構造を、主要なアクセスポイントに焦点を当てて概説します。 Claude Codeの価格Claude Codeは、ProおよびMaxプランのサブスクリプションベースモデルと、Anthropic APIを介した追加の従量課金制価格で運用されています。内訳は以下のとおりです。 Claude Proプラン：月額
はじめに 最近、ふと気づいたことがある。技術負債って、もう昔とは全然違うゲームになってるんじゃないか？いや、もっと正確に言うなら、ゲーム自体が終わろうとしているんじゃないか？ コーヒーを飲みながら、10年前に書いた自分のコードを眺めていた。当時は「きれいに書いた」つもりだったけど、いくつかの要望がありよく考えずに変更を加えた結果、負債の塊だ。でも、それを直すのに必要な時間とコストの計算が、根本的に変わってしまった。 いや、変わったどころか、もはや「時間とコスト」という概念すら意味をなさなくなりつつある。 syu-m-5151.hatenablog.com 私たちは技術負債を「悪いコード」として理解してきた。しかし、それは大きな誤解だった。Ward Cunninghamが1992年に生み出した原初の概念は、現在広く信じられている「技術的問題」とは根本的に異なっていた。 彼の言う負債とは、ソフ
先日、私が所属する品質コンサルティング組織「QE&A」の活動の一環として、初めて全社的なイベント「QualityConf」を開催しました。 今回は、TDD（テスト駆動開発）のエバンジェリストとして国内外で知られるtwadaさん（和田卓人さん）をゲストにお招きし、Accenture Innovation Hub Tokyoにて「質とスピード ～ソフトウェア開発の典型的な誤解を解く～」というテーマで講演をしていただきました。 普段、テスト自動化やQA活動に携わる私にとって、twadaさんとはずっとお会いしてみたいと常日頃から思っていましたので、社内向けイベントで直接お話しいただく機会を設けられたこと、非常に嬉しく思っています。 今回は、twadaさんの当日の講演の内容をダイジェストでお届けします！ なぜ今、「質とスピード」なのか？ ソフトウェア開発に携わる誰もが直面する問題、それが「質とスピー
AIにコードを生成するコードを作らせて、再現性を担保しよう！ / Let AI generate code to ensure reproducibility
TSKaigi 2025 After Night 〜セッションおかわりの会！〜 で発表したLT資料です。 https://bitkey.connpass.com/event/351174/
ユースケース層 大規模リニューアル：安全な移行のための3つのアプローチ - Techtouch Developers Blog
バックエンドエンジニア taisa です。最近腸活によって少しだけ体重が減りました。テックタッチは最近クリーンアーキテクチャにおけるユースケース層の大規模なリニューアルを行いました。本記事では、リニューアルの際に工夫した内容を簡単に紹介します。 はじめに 前提条件 1. ユニットテスト・インテグレーションテストを用いた差分検証 ユニットテストの拡充 インテグレーションテストの拡充 2. 同時実行パターンによる差分検証 同時実行パターンとは AWS AppConfig とは 3. 動的な切り替え機能を利用した段階的な移行 まとめ はじめに テックタッチのバックエンドはクリーンアーキテクチャとドメイン駆動設計（DDD）を組み合わせた構成で開発を進めています。詳細な理由や背景は割愛しますが、開発生産性の向上を目的に、クリーンアーキテクチャにおけるユースケース層のリニューアルを実施しました。その際
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…
AIと進めるテスト設計・リファクタリングの実践
以前作成した冷蔵庫マネージャー、レビューとリファクタリングをしようしようと思いながら後回しになっていたのですが、つい先日参加したイベントでAIとのリファクタリングのコツを教えてもらったので、教えてもらったことをもとにやってみることにしました。 前提（例：あなたは〜です） 目的（例：これから〜を実装します） 前準備（例：まず〜を把握してください） タスク（例：調査結果をマークダウンファイルにしてください） 制約（例：コードの変更を禁止する など） これを意識してリファクタリングをしていきます。 ちなみに今回もCursorとペアプロ形式で進めています。 1. ドキュメントを作る 生成されたコードを何の情報もなく読んでいくのは根気がいります。ということで、まずは構成とかパッケージをドキュメントに起こしてもらいます。 これをすることでCursorでチャットを新しくした場合でも「これも参照してね」で
Vibe Codingとは、AIに身を委ねて、バイブス、感覚でコーディングする手法のことだ。LLMの生成するコードを無条件に信じ、その積み重ねでソフトウェアを作る。理想的には、「こんなものを、いい感じで」とAIに頼むだけでコードができあがる、夢のノーコード開発環境のことを指すのだろう。 現実としては、そんな簡単にはいかない。AIは私たちの心を読む超能力者ではない。「いい感じ」と言っただけではAIはただ適当に振る舞う。まず実現したいことの明確なビジョンと、それを支えるしっかりした設計が必要になる。それをAIが理解できる言葉で、適切にタスク分解して伝えなければならない。今のところ、ただ要望を並べただけでまともなコードができあがることはまれだ。 Thoughtworksが行った実験が、この現実をよく示している。彼らは「システム更新プランナー」というアプリケーションをAIに作らせる実験を、３つのア
Shodhan Sheth is head of Enterprise Modernization and Principal Technologist at Thoughtworks. He is always looking to apply technology towards positive business outcomes Since the release of ChatGPT in November 2022, the GenAI landscape has undergone rapid cycles of experimentation, improvement, and adoption across a wide range of use cases. Applied to the software engineering industry, GenAI assi
一時期Ruby on RailsのERB + jQueryベースのフロントエンドをReactやVueのモダンフロントエンドにリプレイスするのが流行りました。私も現場でこういう例を複数見ています。 しかしどれも途中で止まっています。半分にも届かないぐらいのところで "ERB + jQuery"だったものが "ERB + jQuery + React + Next.js"とか"ERB + jQuery + Vue"になっています。 複雑度はむしろ明確に増しています そこで、こういう結末が一般的なのかどうか、ウェブを検索して調べてみました。 タイミー社の例 Rails (多分ERB) + jQueryが出発点 30画面 Next.jsのSPAに移行 3年間かかった （2年弱の時点で一回中断） クックパッド社の例 2020年にRails (多分ERB) + CoffeeScript/jQueryを
「modernize」パッケージとは？ 「modernize」パッケージは、Go のツール群の中でも特に注目すべき解析器（アナライザー）です。gopls（Go 言語サーバー）に統合されており、既存のコードを最新の言語機能や標準ライブラリの改善点に沿って自動的にリファクタリングするための提案を行ってくれます。たとえば、古い if/else 構文による条件分岐を、Go 1.21 で追加された組み込みの min/max 関数に置き換えるなど、コードをよりシンプルで読みやすい形に更新できます。 さらに、modernize パッケージには、提案された変更を一括で適用できるコマンドラインツールも用意されています。たとえば、以下のコマンドを実行することで、テスト対象のコードに対してすべての現代化修正を一括で適用できます。 go run golang.org/x/tools/gopls/internal/
DevinとClineをDMMで導入しました〜トライアルから見えた成果の共有〜 - DMM Developers Blog
1. はじめに 2. 制約 3. トライアル成果 発見1. 技術負債の特定とリファクタリング実装の半自動化 発見2. イベントストーミングで設計した画像をもとにドメインモデルと制約の実装 発見3. 指示範囲を明確に絞れば、人より格段に早い 発見4. 開発者の学習効率を上げる Devin or Cline？ 4. 25年3月時点での課題 5. 投資対効果と組織スケールの変化 AIツールの投資対効果 AIツールによって変化した組織スケールの方法 今後の展望 1. はじめに こんにちは。DMM.comでプラットフォーム開発本部の副本部長をしている石垣です。 今回は当社で実施したAIエージェント「Devin」と「Cline」の導入検証の結果について共有したいと思います。 DMMグループのクリエイター組織は、現在1,200名近くのメンバーを抱え、エンジニアだけでも1,000名近くのメンバーがいる組織
こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。 AIエージェントを活用し、自然言語による指示を中心にコーディングする手法が注目を集めています。特にゼロからコードを書く場面では、その効果の高さは多くの現場で実感されているのではないでしょうか？ 私たちもこの可能性に注目し、AIコードエディター「Cursor」をフルタイムの開発チームメンバー全員に導入。日々の開発でAIエージェントの活用を積極的に進めています。 一方で、既に運用中のサービスを開発しているチームにとっては、既存コードの文脈を理解させた上でどう活用するかが大きなテーマとなります。本記事では、そうした既存コードのコンテキストを踏まえたAI活用の実践について紹介します。 開発チームの前提と課題 私の所属する開発チームはAI議事録ツール「ACES Meet」を開発しています。このプロダクトは
aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code
JOHN: Hi (Uncle) Bob! You and I have each written books on software design. We agree on some things, but there are some pretty big differences of opinion between my recent book A Philosophy of Software Design (hereafter "APOSD") and your classic book Clean Code. Thanks for agreeing to discuss those differences here. UB: My pleasure John. Before we begin, let me say that I've carefully read through
Ruby: "Gilded Rose"のリファクタリングKataをやってみた（翻訳）｜TechRacho by BPS株式会社
このところ執筆の時間をろくに取れていません。夏をめどに長い記事をいくつか書くつもりでしたが、残念ながら進捗は思わしくありませんでした。しかし昨晩、かの有名な（と思うのですが、それまで知りませんでした）リファクタリングKataをたまたま知って試してみたい衝動に駆られ、試しながら自分のコードの書き方についての考察をいくつか書き留めました。 🔗 Kataとは何か Gilded Roseは、さまざまなプログラミング言語で利用できるリファクタリング"Kata"として広く知られています。内容は以下のとおりです。 最初に、リファクタリングの対象となるシステムの概要を紹介します。 すべてのitemsには、アイテムを販売しなければならない日数を示すSellInという値がある。 すべてのitemsには、そのアイテムの価値の大きさを表すQualityという値がある。 システムは1日が終わるたびに、すべてのアイ
こんにちは、グループ経営ソリューション事業部の米久保です。 はじめに リファクタリングとは リファクタリングの定義 振る舞いのサイズ 振る舞いと自動テストとの対応 リファクタリングテクニック リファクタリングサイズ 技術的負債はどうして生まれるのか コードの守備範囲 変更への対応 技術的負債を返済する 早い返済が吉 新規開発時 変更時 開発チームの裁量で返済する 説得方法 大規模なリファクタリング まとめ 参考文献 はじめに 「リファクタリングをする時間がない」「リファクタリングの必要性を関係者に説得しなくてはならない」という悩みをよく聞きます。 リファクタリングという用語が広く普及した結果、意味の希薄化が発生し、元来の意味と異なる使われ方を目にすることもあります。また、似通った用語としてリアーキテクティングというものがあり、混同されがちです。 リファクタリングの課題と向き合い、それらを解
class: center, middle # map / filter などの<br>高階関数よりも<br>古典的な for文の方が<br>読みやすいと感じる<br>あなたへ BuriKaigi 2025 2025/02/01<br> @gakuzzzz --- class: left, top ## 自己紹介 * 中村 学/Manabu NAKAMURA * Twitter: [@gakuzzzz](https://twitter.com/gakuzzzz) * [Tech to Value Co.,Ltd.](https://www.t2v.jp/) CEO * [Alp, Inc.](https://thealp.co.jp/) Tech Lead --- class: left, top ## はじめに 昨今のメジャーなプログラミング言語では、 `map` や `filter`
パッケージ名変更と参照アップデートを一挙にこなす「pachanger」を使いこなそう Goの大規模プロジェクトを運用していると、次のような悩みはありませんか？ 「パッケージ名を変えたい。でも既存ファイルで大量に参照してるから、変更が大変そう…」 「別ディレクトリにファイルを移動して名称を整理したいけど、他のファイルの参照先を書き換えるのが面倒すぎる…」 「リファクタリングするたびに動かなくなるコードの修正に追われる…」 「パッケージがでかすぎてビルドやテストが遅い」 これらを“爆速”で解決してくれるのが、pachanger です。 この記事では、pachangerの基本的な使い方と、実際のユースケースや運用上のコツを紹介します。 「パッケージ名変えるとか怖すぎ…」から「このツールでパッケージ名を自由に変更できる！」 へと意識が変われば、あなたのGoプロジェクトの開発体験が大幅に向上するでし
2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩 ~急成長するスタートアップのリアルな裏側~
株式会社ナレッジワーク/ 樋口直人 @mado (https://x.com/nnhiguchi) ※SRE Kaigi 2025での登壇資料です https://2025.srekaigi.net/ ＜セッション概要＞ スタートアップでは、生き残りをかけて機能開発のスピードが最も重要視され…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Tidy First? Kent Beckさんの本「Tidy First? -個人で実践する経験主義的ソフトウェア設計」の日本語訳版が出たので読んで色々と感想を交えながら整理してみました。 翻訳版が2024/12/25に販売された いつどこでコードを改善・整頓すれば良いのかを記述した本 3部作の1作目で、本作は"個人"に焦点を当てている 内容整理目的でいくつか気になったポイントを抜粋しつつ、自分で咀嚼し言い換えたり、感想・意見を交えて整理しています。きちん正しく理解するためには本書をぜひ一読することをオススメします。 Tidy Firs
時間がないからこそ、テストを書く
こんにちは。 株式会社ココナラ在籍のKです。 「時間がないからテストは後で書く」 そのような言葉を聞くたび、「テストを一緒に書くことでむしろ時間を節約できるのに、もったいない」と感じます。 本記事では、その理由を明確にした上で、私がよくやっているTDDをゆるく取り入れたテストの進め方をご紹介します。 対象読者 本記事は、以下のような悩みをお持ちの方に向けた記事です。 テストの重要性は理解しているものの、時間的な制約からテストを後回しにしてしまいがち TDDに興味はあるものの、難しそうでなかなか実践できない TDDのテストファーストという手法に馴染めない チーム内にテストの文化を広めたい 本記事の構成 大きく以下の2つの構成になっています。 テストを後で書くという考え方への考察 TDDをゆるく取り入れた実践手法 本記事におけるテストの定義 本記事で扱うテストは、主としてロジックのユニットテス
Tidy First?のススメ - 日々常々
薄い本なので軽い気持ちで読みましょう。 先に読むべき？→Yes！ 私は初詣の列に並んでいる1時間で読みました。寒かった。 Tidy First? ―個人で実践する経験主義的ソフトウェア設計 作者:Kent Beckオーム社Amazon 力を失ってしまった「リファクタリング」を復活させる本です。私の中のサブタイトルは「Make Refactoring Great Again」です。 第一部の冒頭から引用します。 整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。 「リファクタリング」という言葉は、機能開発の長い中断を指す言葉として使われ始めたとき、致命傷を負った。 「致命傷を負った」に「だよねー」と思ってしまう昨今。「それリファクタリングじゃねーしなー」とか思いながら「リファクタリング」という言葉が使われているのを眺めつつ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ - Mitsuyuki.Shiiba
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
「改訂新版 良いコード/悪いコードで学ぶ設計入門」を使ったリファクタリングの事例 - Findy Tech Blog
こんにちは！ファインディのプロダクト開発部でエンジニアをしているham (@hamchance0215)とEND（@aiandrox）です。 この記事はFindy Advent Calendar 2024 25日目の記事ということで、2人で共同執筆しています。 adventar.org この記事について ファインディでは日頃からお世話になっている皆さんに感謝の気持ちを込めて「Findyユーザー感謝祭 2024」を12/19に開催しました。 イベント中に、参加者の一人であるミノ駆動(@MinoDriven)さんが12/25発売の著書「改訂新版 良いコード/悪いコードで学ぶ設計入門」を参加者4名にプレゼントしてくださいました！ じゃんけんで勝った4名が書籍をゲットするルールであり、hamとENDがじゃんけんの強さを発揮して書籍をゲットし、なんやかんやあってこの記事を書くことになりました。 さら
アプリケーション開発の設計のプロからレクチャーを受けてみたら開発生産性が向上した話 - DMM Developers Blog
はじめに レクチャー前のチーム状況 レクチャー前のソースコードの状況 目標 やったこと 基本的な設計に関する学習 実務形式での設計 ユースケース図の作成 イベントストーミング ドメインモデリング 実装（モブプロ） レクチャーを受けての現在のチーム状況 反省点 マネージャーの理解 まとめ 宣伝 はじめに プラットフォーム開発本部CSPグループで主にDMMヘルプセンターのバックエンド開発を担当している、佐々木です。 私たちのチームでは、今年の8月から11月にかけてバックエンドAPIのリアーキテクチャに取り組みました。 このプロジェクトでは、アプリケーションアーキテクチャのプロフェッショナルとも言えるミノ駆動（@MinoDriven）さんから直接ご指導をいただきました。ミノ駆動さんは「良いコード/悪いコードで学ぶ設計入門」（以下ミノ駆動本）の著者としても知られています。 この期間中、私たちはドメ
「リファクタリングの時間」を確保する技術
はじめに ソフトウェア開発において、リファクタリング、つまりコードの保守性を高める活動は、ソフトウェアの価値を高める上でとても大切ですよね。 しかし、「リファクタリングの時間が確保できない」「リファクタリング実施のための同意が得られない」という話を耳にすることがあります。 リファクタリングは「絶対やった方がいいのは感覚としてはわかっている、でもその必要性ををうまく伝えられない」となりがちな性質があるのです。 この記事では、リファクタリングの時間を確保するために、どんなことを考え、何をステークホルダーに伝え、具体的にどのようなタイミングで実施していくといいのか、について解説します。 ポイントまとめ リファクタリング時間確保のポイントを端的に説明すると、以下の通りになります。 リターンとコストを明らかにする 複数の実施パターンを選択肢として持ち、柔軟に選べるようにする。 その中でも、日頃の小さ
Tidy First?
乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。 整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオプショナリティ）などソフトウェア設計の背後にある重要な要素を解説します。 また、ソフトウェア設計の基礎理論とそれに作用するフォース、システムにおけるふるまいの変更と構造の変更の違い、先に整頓したりあとに整頓することによるプログラ
~モノタロウ式~ドメインモデリングとリアーキテクチャ Vol.2 (2024/12/11 19:00〜)
登壇者（敬称略） 普川 泰如 株式会社MonotaRO CTO @taipuka0 慶応義塾大学環境情報学部卒業、SIer企業を経て2009年にオイシックス・ラ・大地に入社、2016年同システム副本部長。2019年にモノタロウに参画。2021年1月にECシステムエンジニアリング部門長、2022年4月に執行役CTO/VPoEに就任。データ活用による顧客価値を進化するべくシステムモダナイゼーションを推進中。 尾髙敏之 株式会社MonotaRO シニアアーキテクト 2023年11月にモノタロウ入社。IT職歴の大半を事業会社のIT部門で過ごし、biz/sysの関係構築や要件定義などの超上流工程に取り組んできたが、「質とスピード」という言葉に出会ってからは品質→保守性に目を開き、モノタロウ入社後は良い構造とは？を求めてチームとすり合わせる日々。最近はイベントストーミングの企画やファシリテートで声をか
生成AIにアプリを作らせるコツ｜erukiti
Claudeの3.5-sonnet最新版(20241022)は間違いなく現時点では最高性能のLLMの一つである。Claude Professional PlanならそれをウェブUI・アプリ上から無制限と言ってもいいほど使える。 もともと、ある要件を実現するためにどうするのがいいか？選択肢を知りたくて、Claude sonnetやChatGPT Plus(gpt-4o, o1-preview)などに聞いてみたら、Claude sonnetが一番好みのアイデアを返してくれたので、さらに深掘りしてアプリを作らせたみた。 OpenAI o1-previewは思いもよらないスマートな解決方法を提示してくれることがある。アイデアを知りたいときに一考の余地はある OpenAI gpt-4oは割とベタというか、微妙？ SearchGPTは現時点ではコンテキストを無視しがち（単体の検索はいいけど、それ以上を
はじめに こんにちは！あっという間に秋が終わり、クリスマスソングが流れる季節がきましたね。 今回は、どうやら多くの人が苦しんでいると聞くレガシーシステムと向き合う話です。 弊チームでは先日、15年来のレガシーシステムを、バグ0でリプレイス&新機能の追加リリースを実施することに成功しました！既存機能の改修ではなく、既存を大きく作り替えつつI/Oも変えるというものだったので、新しい検証方法やリリース手法を組み合わせてリスクを最小限に抑える方法をとりました。 今回は、その予期せぬトラブルを未然に防ぐことができた「安全に倒し切ったリリース」についてお話します。他のプロダクトでも応用可能な方法なので、システム刷新を検討している方の参考になれば幸いです！ なぜ安全に倒し切りたいか 私たちが今回触ったのは、前述の通り15年前から存在する、プロダクトの中でも最もレガシーに類される場所です。以前からパフォー
自分たちを楽にするために業務効率化を推し進めているわけだけど、結果的にはどんどん苦しくなっていくみたいな機序あるあるの話。 ネットで「タイミーやってるとあんまり洗練されてない職場の方がやりやすい」って話を見かけて、ちょうど職場で実感していたのとぴったりだなあと思って。 大手メーカーに勤めていて、以前は製品検査の部門にいたのが、1年半ほど前に生産管理の部門へ異動になった。異動してびっくりしたのが、かなりの業務をアウトソースしてるんだなってことだった。 定型的で、人の判断をあまり伴わない業務のほとんどがグループ会社に委託されていた。調達先からの物品を受け取って運んだり、受付処理をしたり、納期回答を定型文で依頼したり、一部製品を個装したり、そういった作業は全部委託されていた。 外から生産管理の部署を見てた時は、なんかいつも忙しそうで何なんだろうと思っていたので、中に入ってみたら委託できる業務はほ
技術負債は「価値の創出」を妨げる 「技術負債が事業に与える影響はさまざまな領域に波及するが、ソフトウェアに限れば、"価値あるものを作れなかった"という点に集約される」と語り始めた石垣氏。ここでの「価値」とは、売上の創出やユーザー数の増加、リテンション向上につながる機能を指す。すなわち、「価値が作れなかった」とは「事業責任者が立てた、機能やキャンペーンなどの目標を達成できなかったという状況」を意味する。 ではなぜ、多くの費用をかけても価値を創出できない事態に陥るのか。石垣氏は「期限に間に合わなかった」ケースと「作るべきでないものを作ってしまった」ケースに大別し、今回は前者に焦点を当てると示した。 数億円規模の損失をもたらし、事業へのリスクもある技術負債 価値の創出と技術負債にはさまざまな要素が関わるが、とくにソフトウェア事業における事業計画では、予算計画と開発計画が主なカギになることが多い。
CSSの新しい:hasセレクタと、これを使用したReactコードの改善方法について説明します。実用的で美しい例とともに。 大昔、とは言ってもCSSが出てきた当初の話ですが、CSSはカスケードする仕組みになっていると教えられていました。それは、Cascading Style Sheetsという名前からも分かります。CSSでは、入れ子のように要素の中の要素を指定し、さらにその中に含まれる要素を指定していくことができます。しかし、その逆はできません。したがって、子要素が親要素にスタイルを適用するには、JavaScriptを使うしかありませんでした。 今までは。 すべての主要ブラウザがCSSの:hasセレクタに対応したことで、親要素を指定できるようになりました。それだけではありません。これは世界が一変したと言えるほどの出来事です。筆者のように、要素の角を丸くするために透過GIFを使用していた時代か
読みやすいコードは「読ませない」
経験の浅い人にちょくちょくするアドバイスとして、「コードリーディングのときにはあんまコードを読まないほうがいいよ」がある。コード全体を詳細に読むのではなく、名前やインターフェイスからコードの意図を把握することで効率的にコードリーディングできる。完全に下記の受け売り。 「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」 牛尾 剛「コードリーディングのコツは極力読まないこと 」 自分なんかは、エディタの畳み込み機能と変数名ホバーを使って、名前とインターフェイスしか見えない状態で読む。中身を読みたいなーと思ったところは畳み込みを解除して徐々に読ん
開発チームの定例ミーティングで、式次第のテンプレートにはあるのに飛ばしているアジェンダがあった。１年以上、２週間に1度は目にしていたはずなのに今まで気に留めてもいなかった。 今開発しているサービスは、リリースしてから８年以上の歴史があるプロダクトで、開発メンバーの入れ替わりも多い。１年前と今ではほとんど顔ぶれが変わっている。そういう状況なので、存在するけど誰も気に留めていない幽霊みたいなアジェンダが生まれてしまったのだろう。 普通のプログラマなら自分の開発しているプログラムの中にデッドコードがあったら迷わず削除する。ミーティングで飛ばされてるアジェンダに対しても、消すか飛ばさないようにするかどっちかにした方がいいだろう。リファクタリングに似ているな、とふと思った。 デッドコードの場合は削除してもいいか自明だけど、ミーティングのアジェンダは消して問題ないか事前に知ることが難しい。あとコードを
汚いコードと対処法 - 君はコードなんか汚いと思いながら
あらすじ 徹夜明けの深夜テンションで書いた怪文書が思いの外多くの人の目に止まったようなので、実際にどういうコードが汚くて、どう改善できるのか、みたいな事を簡単にまとめてみる。 モジュール・クラス・変数の名前がおかしい 名前から全く想定できない作用がある、名前が嘘 例えば、validateForm()という名前のメソッドを実行すると、決済処理が完了してレシートが印字されるとケース。おまえはvalidationではない。でもvalidationなので、DBには保存しない。 （何を言っているんだ？？？ちなみに、外部APIやデバイスのコールはこのメソッドの中でできてしまうが、フレームワーク制約でDB更新はここではできない、みたいな状況でそういう事が起こる） const blue = "#ff0000"、おまえは青色ではない。真っ赤なウソだ。 これは、しばしば致命的なバグにつながる。既存のblueを
はじめに BASE株式会社でシニアエンジニアを務めているプログラミングをするパンダ（@Panda_Program）と申します。本連載はPHPカンファレンス2022での発表「実践！ユニットテスト入門」を再構成して記事としたものです。 対象読者 本連載の対象読者は、自動テストの必要性をわかっているもののまだテストコードを書いたことがない開発者の方です。さらに本記事では、テストコードを書く習慣が身についている中級者の方にとっても自動テストに対する理解を深める助けになるでしょう。 テストを上手に活用してソフトウェア開発を加速させる 前回は、Dev（開発）のみならずOps（運用）にまで視点を広げることにより、ソフトウェア開発の全体像におけるテストの位置付けを説明しました。ここからは視点をDev（開発）の自動テストに戻しましょう。 本連載を通して、自動テストの意義は開発者がリリース前にバグを見つけるこ
リファクタリングに向けた自動インテグレーション実装 - RAKUS Developers Blog | ラクス エンジニアブログ
背景 経費精算システム「楽楽精算」は2009年にリリースされ、15年以上にわたり運用されてきました。 その間、基本的なシステム設計はリリース当初のまま維持されています。 しかし、年月が経つにつれ、技術トレンドやビジネス的な要求は大きく変化しましたが、現状のシステムではそれらの変化に柔軟に対応することが困難になってきています。 システムの柔軟性は低く、機能追加のたびに既存機能への影響を広範に調査する必要があり、既存の処理フローを変えることができないため、イレギュラーなテクニックが必要となることも多く、追加開発のたびに多くの手間とコストがかかるようになってきました。 すべての問題が現行システムに起因するわけではありませんが、特定のミドルウェアに強く依存した構造を持っているため、将来的な技術革新や新しいミドルウェアへの移行が困難であるという課題も抱えていました。 このような背景から、ミドルウェア
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
改めてリファクタリングについて考える - Qiita
Claude Code vs Cursor: 料金比較検証 - どちらが安い？
技術的負債の変質について - じゃあ、おうちで学べる
twadaさん講演「質とスピード」@Accenture Innovation Hub Tokyo
バイブスでコーディングする難しさ - ABAの日誌
Legacy Modernization meets GenAI
フロントエンドのリプレイスに、いつまでかけるんだ？
Goの進化に乗り遅れるな！modernizeパッケージでコードを現代化するリファクタリング入門
Cursor AIエージェントによる既存コードのアップデート戦略 - ACES エンジニアブログ
リファクタリングについての彼此（あれこれ） - 電通総研 テックブログ
map / filter などの高階関数よりも古典的な for文の方が読みやすいと感じるあなたへ
Goプロジェクトの“爆速”リファクタリングを実現する！ | pyama.fun
その汚いコード、いつどこで整頓するの？"Tidy First?"を読んで解決した話 - Qiita
【C#】知っておきたい簡略化テクニック12選 - Qiita
安全に倒し切るリリースをするために：15年来のレガシーシステムのフルリプレイス挑戦記
業務効率化の苦しみでもとの濁りの田沼恋しき的な気持ち - やしお
DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防
ReactコードをCSSの:hasセレクタで置き換える | POSTD
ミーティングのデッドコードを見直す - 技術と労働のダイアリー
【実践的ユニットテスト入門】自動テストの応用的な使い方は？ リファクタリングとTDDを紹介