Warning: Trying to access array offset on value of type bool in /home/r1029599/public_html/engineer-log.net/wp-content/themes/simplicity2/lib/customizer.php on line 5404

リファクタリング=読みやすいプログラムを書こう!

目次

JavaScript学習に役立つお話がありました。

「リファクタリング」でプログラムを改善する練習について紹介されています。

前回に引き続き、今回もこのお話から学んでみたいと思います。)

アプリ作成の進め方として、以下の手順が紹介されています。

  1. 最初に基本を身に着けよう
  2. 計画を立てる
  3. コード無しで書いていく
  4. 小さな部分に分けて製作する
  5. 各パーツを結合する
  6. 実験とテスト
  7. 外部の助けを求める
  8. コードのリファクタリング(再構築)

リファクタリングとは?

reの意味 – 英和辞典 Weblio辞書

re‐ 【接頭辞】

「相互,反,後,退,秘; 離,去,下,再,否,不」などの意.

接頭辞の「re」は、再びという意味

factorの意味 – 英和辞典 Weblio辞書

factorとは

(ある現象・結果を生ずる)要因、要素、原因、代理商、問屋、仲買人、因数、因子

「factor」は、要素という意味

→ re(再)+factor(要素)=プログラムの構成要素を見直す、という意味?

リファクタリング (プログラミング) – Wikipedia

リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。

特集・現場で役立つリファクタリング:そのソフトウェア資産、ずっと使い続けられますか? (1/2) – MONOist

リファクタリングの定義と目的

外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること

“ソースコードの理解度を向上させること”がリファクタリングの目的です。

f:id:jsstudy:20170409005850j:plain

リファクタリングに関する本もいろいろあるので参考になります。

[amazonjs asin=”427405019X” locale=”JP” title=”新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)”]

リファクタリングのチェックポイント

プログラムの構成を見直すとき、どこを見れば良いでしょうか?

プロジェクトを完成する前に、コードのリファクタリング(見直し・再構築)を検討してください。

以下は、改良のために自分自身に問いかけたい質問です。

  1. コードは簡潔で読みやすいか?
  2. コードは効率的か?
  3. 関数や変数の名前は分かりやすいものになっているか?
  4. 名前の衝突の可能性はないか?
  5. 編集過程でエラー原因を生んでいないか?
  6. 表示は適切になっているか?
  7. コードが無駄に冗長になっていないか?
  8. プロジェクトを新鮮な目で見るとどう見えるか?

グチャグチャで汚いコードは、「スパゲッティーコード」などと呼ばれており、その特徴は「コードの臭い」と呼ばれています。

スパゲティプログラム – Wikipedia

スパゲティプログラムまたはスパゲティコードとは、プログラムのソースコードがそれを制作したプログラマ以外にとって解読困難である事を表す俗語。

名称の由来は、皿に盛られたスパゲッティのようにロジックが絡み合っていることから。

コードの臭い – Wikipedia

コードの臭い(Code smell)とは、コンピュータプログラミングにおいてプログラムのソースコードに深刻な問題が存在することを示す何らかの兆候のことを言う。

コードの臭いが示す深刻な問題は、小さく管理された手順でリファクタリングする短いフィードバックサイクルを廻し、それ以上のリファクタリングが必要なことを示すコードの臭いがないかどうか、設計を検査しなければならない。

リファクタリングを実施するプログラマの視点からは、コードの臭いはいつリファクタリングするか、どのリファクタリング手法を用いるか、発見するための方法である。

一般的なコードの臭い

  • 重複したコード
    同一あるいは同様のコードが複数箇所に存在。
  • 長すぎるメソッド
    メソッド、関数、手続きが長くなりすぎている。
  • 巨大なクラス
    大きくなりすぎたクラス。神オブジェクト参照。
  • 機能の横恋慕
    他クラスのメソッドを過度に用いるクラス。
  • 不適切な関係
    他のクラスの実装の詳細に依存しているクラス。
  • 相続拒否
    基底クラスの規約が尊重されない形でのメソッドオーバーライド。リスコフの置換原則参照。
  • 怠け者クラス
    行うことが少なすぎるクラス。
  • 重複メソッド
    同一あるいは同様のメソッドが複数箇所に存在。
  • 不自然な複雑さ
    簡潔な設計で十分なところに、過剰に複雑なデザインパターンの使用を強制する。

先人の工夫によって、リファクタリングのノウハウがまとめられています。

不吉な匂い – オブラブ

不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。

ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。

リファクタリングの事例

上記のお話では、リファクタリングの見本として、重複の解消などを紹介していました。

コードが無駄に冗長になっていないか?

本来なら関数やループでまとめられるところを、繰り返し同じコードを書いてはいませんか? 先の処理では、出力にゼロを追加するコードは単独の関数にまとめられます。これで重複が減り、コードも読みやすくなります。

●Before

const seconds = ('0' + Math.floor((remainingTime/1000) % 60)).slice(-2);
const minutes = ('0' + Math.floor((remainingTime/(60*1000)) % 60)).slice(-2);
const hours = ('0' + Math.floor((remainingTime/(60*60*1000)) % 24)).slice(-2);
const days = ('0' + Math.floor(remainingTime/(24*60*60*1000))).slice(-2);

「ゼロ詰め」(ゼロを付ける処理)が、個別に何回も出てきます。

↓↓↓

●After

function pad(value){
  return ('0' + Math.floor(value)).slice(-2);
}

const seconds = pad((remainingTime/1000) % 60);

「ゼロ詰め」の関数を用意して、pad()と書くだけでOK=同じようなコードを減らせます。

…こんなかんじで、リファクタリングすればいいんですね!?

個人的には、プログラミングをやっていて、

なんか面倒くさいな~

と感じたら、リファクタリングが必要なサインだと思います。(笑)

[amazonjs asin=”4798046140″ locale=”JP” title=”プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則”]

投稿日:April 8th 2017

元記事:http://jsstudy.hatenablog.com/entry/javascript-refactoring

– PR –
– PR –