タグ

リファクタリングに関するMukeのブックマーク (2)

  • リファクタリング「コードの不吉な匂い」 - プログラミングの魔物

    リファクタリング 3章 リファクタリングを行うタイミングについては明確な定義を持つことが出来ない。 だから経験の中から「匂い」を感じて時期を決める。 この章との裏表紙にある表にはいつリファクタリングを行うかのヒントが書かれている。 重複したコード 言うまでもなく無駄。 同一クラスの複数メソッドに同じ式>「メソッドの抽出」 重複しているコードが複数の兄弟クラスに存在する場合>「メソッドの抽出」後、「メソッドの引き上げ」 コードが似ているけど完全に同一ではない場合>「メソッドの抽出」後、場合によっては「TemplateMethodの形成」 複数のメソッドが同じ処理を異なるアルゴリズムで実装している>「アルゴリズムの取り替え」 関係のないクラス間で重複コード>「クラスの抽出」をして新しいクラスに委譲、あるいはどちらかのクラスに持って委譲 長すぎるメソッド メソッドは長いほど理解しにくくなる。

    リファクタリング「コードの不吉な匂い」 - プログラミングの魔物
  • デザインパターンよりも、まずリファクタリングを学んだほうがいい - モジログ

    ウィキペディア - デザインパターン (ソフトウェア) http://ja.wikipedia.org/wiki/%E3%83%87 <ソフトウェア開発におけるデザインパターン(型紙(かたがみ)または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである>。 ウィキペディア - リファクタリング http://ja.wikipedia.org/wiki/%E3%83%AA.. <リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、「リファクタリング」の語にも厳

  • 1