リファクタリング中は考えることを止めようSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
立ち止まってリファクタリングをする？
原文(投稿日：2009/6/15)へのリンク Joshua Kerievsky氏はリファクタリングYahoo!グループにおけるディスカッションを次のポストから始めている。 ここ数年、リファクタリングを行うべきなのはユーザストーリーに関する作業を行っている時だけだという話を耳にしますが、その考え方にはまったく賛成できません。それというのも、単純に技術的負債を返済するべき時があると考えられるからです。この数日間、同僚と私はeラーニングのコードをリファクタリングしていますが、これを導くユーザストーリーはありません。想定した以上に技術的負債が増えてしまっていて、今はそれを返済するのにちょうど良い時期なのです。コードの中で中心的な役割を果たしているシングルトンが有害なものになっているので、それを取り除いています。それによって設計を改善する可能性がより広く開かれるからです。この作業は楽しいものです。こ
技術的負債(Technical Debt) - masayang's diary
先日参加したBayXP Meetingにて、座長のJeffreyがCruiseControl 2.8について「新たな付加価値はゼロだけど、リリースした」という話をしていた。Jeffryのブログ「CruiseControl 2.8 Released」を読むと、そのココロがわかる。 This release felt like we were paying off technical/hygiene debt at the same time, at least in a small way. Not major refactorings, just lots of small changes to make things better. 大規模なリファクタリングではないが、細かい変更をたくさん加えた。 「技術的負債(technical debt)」をちょっとだけど返済したようなもの。 技術的
技術的負債(Technical Debt) - masayang's diary
今日の午前受講したリファクタリングのクラスで一番印象に残ったのは「Technical Debt」という表現。技術的負債。 「なんか不自然」「読みにくい」「テストしきれてない」...そういうコードは、「技術的に借りを作ってしまった」ということ。 負債を抱えたら、道は３つしかない。 返済する→返済分、可処分所得は減る 借り換える→雪だるま式に負債が増える可能性あり 破綻する 技術的負債を抱えたソフトウェアも同様 発覚する都度、バグを取っていく→本来の仕事に回す時間が減る ソースを触るのは怖いので、コピペ＋改造で機能を追加していく→ますます保守性が下がっていく 破綻する 技術的負債が膨らまないうちに返しておく。それがリファクタリング。
Martin Fowler's Bliki in Japanese - 進化的設計
Bill Venners: 「設計の終焉?」の中で計画的設計について述べられていますよね。計画的設計とはどういったものでしょうか？ Martin Fowler: 私は計画的設計と進化的設計とを区別しています。計画的設計とは、ソフトウェアを作る際にまず設計を行い、それからコーディングするようなことを指します。計画的設計はUMLダイアグラムの形をとることがあります。システムをサブシステムに分解し、サブシステム間のインターフェイスを定義するものだといえるかもしれません。計画的設計を用いれば、設計とコーディングとの間に明確な「スイッチ」が存在することになります。それぞれのタスクは普通、別々の人間が行います。設計者が設計を行い、開発者がコーディングを行うのです。必ずしも完全に確定したものではないにせよ、設計はほぼ確定したものとして扱われます。設計が優れていれば、コーディング時の変更が少なくなると言っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オピニオン: リファクタリングは必要な無駄
