「良いコードを書く技術」（ユーティリティクラスにまとめる〜

プログラミング 文法、記述方法

もうだいぶ前になってしまってずいぶん忘れてしまっているけれども
Y氏に借りて読ませてもらった

『良いコードを書く技術」

を読んで書き留めていた分を読みながら、ここに残しながら復習。
ほとんどもう忘れてることをノートにまとめたのを書きながら思い出そう。。

○ユーティリティクラスにまとめる
ユーティリティクラスは特定の処理に便利なメソッドを集めた
「状態」を持たない処理を持たせたクラス。
修飾子 static をつけてメソッドとして定義する。

※javaには　staticインポート　という便利な機能があり
この機能を使用するとユーティリティクラスでも
メソッド名だけでメソッドを呼び出す事が出来る便利。

→ピンとこない。。。

○サービス層にまとめる
サービス層についてはほとんど何もしらないや・・・
そういう設計を意識したのも初めてかも。

javaではサービス層に
xxxService　という名前のクラスを利用することが多い。

→メモ帳の原文のまま。。これもピンとこない。

○オブジェクトにまとめる
オブジェクト指向の設計は難しいな。。。
設計手法を写生したり試行錯誤していくしかなさそう。

→上記のメモしかない。。メモ見る必要もない。。。
　ただの感想やない。。。。

○定数にまとめる
特定の値の重複は定数にしたほうが俄然わかりやすい。

0=share 1 = normal　

とかなら

static final int TYPE_SHARE　static final int TYPE_NORMAL

としてあげて定数で判断したり処理さした方がわかりやすくて
後から自分で見ても何をしたいのか分かりやすい
（ 物忘れ激しいのでこういうのないとええっと・・・・？と考えなきゃいけない）

たたし、まとめすぎには注意した方がいいかも。

基本、YAGNI（予想でものを作るな、必要なものを作れ）の考え方で
最初は上記のような数字とかで書いて、
同じコードが２回出てきたらまとめるくらいから始めるくらいで良いとのこと。

確かにやたらめったら文字に定数ばっかり書いててもそれはそれでややこしそう。。

○コードのパフォーマンス
パフォーマンスは計算量で決まるとのこと。
計算量を意識するとはかどる。

クラスの選択でコストパフォーマンスは変わるとのこと。
ArrayList、LinkedListの違い等。
こちらがわかりやすかったので参考に
http://d.hatena.ne.jp/syttru/20080406/1207499238

ライブラリによってパフォーマンスが変わるとのこと。
例）JQuery　とか..
ライブラリのＡＰＩリファレンスやソースコードを読んで
効果的な使い方をするとパフォーマンスを良くすることが出来る。

→ピンときたのが、ArrayList、LinkedListくらい。。。

○パフォーマンスチューニングによる改善
やりがちなミス
ー原因個所の特定もせずにやみくもにチューニング。
ー測定せずに思い込みでパフォーマンスを判断。
やっちゃダメ。。

→パフォーマンスをどうこう以前のレベルです(；´Д｀)
　とにかくやみくもにやっちゃう癖があるので、それだけは避けるようにしよう。。。

※参考に　
メモとして残してあったので

○パフォーマンスチューニングの手順
　　　　回帰テスト　＝　リザレクションテスト　全ての機能が正しいかテスト
　　　　　　↓
　　　　　測定　　　　　ログ出力、プロファイラによる測定。SQLではEXPLAINを使用して実行計画を取得など。
　　　　　　↓
　　　　原因特定
　　　　　　↓
　→　チューニング
　　　　　　↓
　↑　　←再測定
　　　　　　↓
　　　　回帰テスト

○アルゴリズムの選択以外のパフォーマンスチューニング
業務システムやwebアプリケーションの場合、
効率の悪いSQLが原因であることがおい。
大量のデータでがたんと落ちたりしたらまず疑ってみるといい。
　→SQLやテーブル設計の修正

→SQLやテーブル設計はとても思い当たる節が(；´Д｀)。。。

○キャッシュする
DB接続情報などをキャッシュしておけば
処理の旅に接続。なんてこともなく最初の一回のみで良くなる。

→YH掲示板の接続に適用したいな。

○パフォーマンスチューニングの指針
保守性を損なわずパフォーマンスが向上する場合は
常にパフォーマンスが良い方法を採用する。
常にパフォーマンスを意識するように。
コーディング、テーブル設計、アーキテクチャの選択など、

→パフォーマンスの良い選択出来る程のレベルでもないのに(；´Д｀)
他僕の場合はツールの使いかた、管理の仕方等も効率悪い&遅いので
どちらかといえばそこらあたりから始めていくことから始めよう。。。。

○ユニットテスト
ユニットテスト、自動化でわかりやすくて機械的で良いな。
ユニットテストの効能
ー網羅的なテストを自動化できる
ー回帰テストによりコードが壊れていない事を保証
ー設計の改善につながる

ユニットテストの指針
ーテストのポリシーを決めておくこと
　どのテストをどの層にまで、どれくらいの網羅までかをあらかじめ決めておく事。

※ユーティリティクラスは「状態」を持たないので比較的テストをしやすい。
ので初めのほうはユーティリティクラスのメソッドからユニットテストをしてみると、
ユニットテストに慣れやすいとのこと。
ユニットテストを習慣化すると不安要素が少なくなりはかどるとのこと。

○抽象化
ー共通的な処理をまとめて親クラスを作成する
ーデータベースへの接続情報を設定ファイルに外出しする
ー似たような振る舞いをインタフェースとして抽出する
　など

いくつかのレベルがあるみたい。
１、パラメータレベルの抽象化
２、型の抽象化
３、ポリモフィズム　など

※ペアで管理するべき変数が出てきたら注意してみる。
　もしかしたら１つのオブジェクトにまとめることが出来るかもしれないし、
　まとめて管理する出来ればわかりやすい。

チューニングはアート。アートをするには基礎が出来ないと出来ない。

→基礎すら出来てないです(；´Д｀)

○配列/コレクション化して抽象化
データと処理を分ける感じｃ⌒っﾟдﾟ)っφ

○抽象化の指針
どのタイミングがベストかを知る為に勘所が大事とのこと。
抽象化が後の開発にどれだけ貢献したか振り返っていくうちに、感じがつかめてくるとのこと。

→抽象化難しいです。。。

○メタプログラミング
メタプログラミング・・・ある特定の問題を解決するプログラムを生み出すプログラムを書くこと

例）プログラムを自動生成するプログラムとか
　　DSL（ドメイン特化言語）とか
　　　→外部DSL（JSPとかXML形式のものもある）設定ファイルのようなもの？
　　　→内部DSL（ホストとなる言語のみで表現するDSL）
○Excelを使った外部DSL
○ストラテジパターン


一応メモを元に残すとこのような形に。。。
ピンときたのが定数のところとArrayListとかくらいで、
ほかはさっぱり・・・・

全然だめですねorz
せめて読み終わった後すぐにここなりにまとめてアウトプットしておけば良かったです・・・