InfoQ

トピック・タグ別の表示

Refactoring Content on InfoQ


Refactoringに関する最新コンテンツ

.NET コード解析について Patrick Smacchia氏に聞く

コミュニティ
.NET
トピック
コード分析

Patrick Smacchia氏は15年余りの間ソフトウェア開発に携わってきた Visual C# の MVP です。彼は現場での経験から着想した .NET プラットフォームに関する書籍である Practical .NET 2 and C# 2 の著者です。

リファクタリングにありがちな誤解を解く

コミュニティ
.NET,
Agile
トピック
アジャイル技術,
Artifacts & Tools,
プログラミング

In comparison to Java, an emphasis on continuous refactoring is still relatively new in .NET. Besides having few ardent proponents, many myths linger around what refactoring really is and how it applies to the development process in general. Danijel Arsenovski, author of Professional Refactoring in Visual Basic, attempts to dispel some of these myths.

Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。

コミュニティ
Agile
トピック
ユニットテスト,
アジャイル技術,
Delivering Quality

JAOO '07 で「今時、ユニットテストを実施してないコードを納品するのは無責任な開発者だ」というBob Martin氏の主張について、議論が起こった。 このInfoQビデオは、BobとJim Coplien氏がこれに関連する話や、いくつかの他の話題について議論する様子を納めたものだ。TDDと契約による設計(Design by Contract)の比較や、システムとビジネスドメインモデルを調和させるためには、事前にどれくらいのアーキテクチャ設計をしておかなければならないのか、などが議論されている。(翻訳:近藤 修平 - (株)永和システムマネジメント)

Refactoringに関するNews

リファクタリングかリライトか?

コミュニティ
Agile
トピック
Delivering Value,
設計

リファクタリングやリライトの目的は、コードの可読性、構造、明確さを改善することでシステムの健全さを改善する点にある。クリーンなコードはメンテナンスもエンハンスも楽だろう。しかし、多くの状況下にて、アジャイルチームはリファクタリングとリライトのどちらを行うかで厳しい選択を迫られる。

より良いユニットテストためのガイドライン

コミュニティ
Agile
トピック
ユニットテスト

Jimmy Bogard氏、Charlie Poole氏、Lior Friedman氏、Charlie Poole氏らが、より可読性が高く有用なユニットテストのためのガイドラインを出している。

コミュニティ
Agile
トピック
ユニットテスト

Rails 2.3.3のリリースとRails 3.0+Merbの進行状況

コミュニティ
Ruby
トピック
Ruby on Rails,
Webフレームワーク

Railsのバージョン2.3.3がリリースされた。このリリースでは通常のバグフィックス以外に、ActiveRecordのtouch機能、JSONに関するAPIの変更といったいくつかの新しい機能が加わった。そしてRails 3とMerb 1.1の現状についても見てみよう。

Ruby on Rails プロジェクトを救助する

コミュニティ
Ruby
トピック
Ruby on Rails,
Delivering Quality

Ruby on Railsが世に出て5年ほどの間,開発者たちは数多くのアプリケーションを開発してきた。その多くがRubyないしRuny on Railsを習得しながら開発されたため,ベストプラクティスとは言いがたいが,それでもWebサイトとして製品にはなっている。これらのWebアプリケーションには問題もあるが,その解決方法を取り上げた本が新たに発行された。

立ち止まってリファクタリングをする?

コミュニティ
Agile
トピック
Delivering Value,
設計

いつリファクタリングをするべきなのだろうか?単純に技術的負債("technical debt")を返済しなければならない時もあり、そこでは立ち止まってリファクタリングをするべきなのか。そうではなくて、ユーザストーリーに関わっている時だけしかリファクタリングするべきではないのか。どちらのアドバイスが正しいのだろうか?あるいは、もしかしたら第3の選択肢が存在するのだろうか?