カテゴリー：リファクタリング
-
【リファクタリング】「クラスのよくある命名」
08.28
クラスの名前をつける際に、単に「Model」とかだとわからなくなるので、以下の命名を意識すると良い。（クラス名は「名詞」にする。） 業務アプリ層 Action 操作そのもの。（例：ClickAction） Controller D…
-
【リファクタリング】「驚き最小の法則」
08.28
驚き最小の原則 要は、人間やユーザーやプログラマが最も自然だと思える名前を選択するべきといこと。 例 validという名前がついているのにチェック処理以外に、データ変換処理まで行ってしまっているなど名前からは想像できないものにはしない…
-
テストしにくいコード アプリの外部に依存している関数 関数の中でデータベースにアクセスしている。ファイルアクセスしているなど。 外部機器がないとテストできないコード プリンタの実機に印刷する処理など。 テストしやすいコード アプ…
-
【リファクタリング】共通処理の良い書き方
08.21
Common関数の問題点 共通化するのであれば、Common関数だったりCommonのConstなどを作ってそこに共通処理を記述すればいけます。 ただ、これには問題点があります。 チームで開発していたら「本当にみんなその関数を…
-
【オブジェクト指向】ベストプラクティス
08.17
手続き型じゃなく、オブジェクト指向っぽく書くためには。 ただ、全て守ればいいというわけではなくこれに近づけるとオブジェクト指向っぽくなるので実際に使う際はある程度緩めても良いかもしれない。 クラス設計 継承を使うのであればできるだ…
-
【リファクタリング】業務の分析手法
08.01
人（ひと） 個人、企業など。 業務の当事者、意思があって判断し行動する主体。 物（もの） 商品、サービス、店など。 人が業務を遂行する際の関心の対象。 事（こと） 発注、キャンセルなど。 業務活動では様々な事象が…
-
【リファクタリング】「データクラス」について
08.01
データクラスは以下のような呼び方をします。 名前 説明 DTO サブシステム間でデータをやり取りするための設計パターン Entityクラス データベースとデータをやり取りするための入れ物 F…
-
if文やswitch文が増えます。 対策 判断のロジック(isXXX)と、計算ロジック(calcXXX)をメソッド化する。 後述するelseを書かないというためにもこれは使えます。 elseを書かない。 できるだけ「早期リターン」…
-
わかりにくプログラムの特徴 メソッドが長い 理解するのが大変。特にif-elseが入り組んだメソッドは理解が骨が折れる。 引数が増えるたびにメソッドも長くなりif文も増える。 クラスが大きい 関心ごとを詰め込みすぎないこと。 …
-
【リファクタリング】「命名規則」の考え方
12.12
基本的な考え方一覧 具体的な単語を選ぶ 接尾辞や接頭辞を使って情報を追加する。 名前の長さを考慮する。 「変数の種類」で「名前のフォーマット」を変える。 メソッドの場合は「そのメソッド本来の目的」を名前にす…