ツールメモ Eclipse
Eclpse
まとめ
Java書くならやっぱりこういうちゃんとしたIDEが無いと辛いかなと思います。
ショートカットキー
- ctrl+alt+h 呼び出し階層を開く
- F4 実装クラスを開く
- ctrl+o クイックアウトラインを開く
- ctrl+alt+f フォーマット
その他
ステップカウンタプラグイン
StepCounter - Project Amateras
簡易的にステップ数知りたい時便利。
Vrapperプラグイン
Eclipseのキーバインドをvim風にできるVrapperが素晴らしすぎる件について - ( ꒪⌓꒪) ゆるよろ日記
キーバインドをvim風に変更するプラグイン。vimeerなら必須。（まあ、ゴリゴリのvimmerならjavaでもeclipse使わなそうだが。。）
はまりポイント！ 設定ファイルを.vrapperrcに記述しユーザのホームディレクトリに配置するが、何故か適用されず。環境はWindows7。 ➡︎原因は不明だが、dドライブのユーザディレクトリに配置したら適用された！
quick junitプラグイン
- ctrl+9 テスティングペアを開く
- ctrl+0 現在カーソル位置のテスト実行
- ctrl+shift+0 現在カーソル位置のテストデバッグ実行
➡︎自分の環境だとなぜか動かない。ググって同様の事象があるみたいだが、なぜか対策しても直らない。。。
リモートデバッグが便利
読書メモ 実践Vim
- 作者: ＤｒｅｗＮｅｉｌ,新丈径
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/01/28
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
Vimについての実践的な内容。(タイトルのまんま)
だいじなこと
- とりあえず.(ドットコマンド)で繰り返す！繰り返せるよう操作を積み重ねてく。
- オペレーションとモーションを習得。
第1章 Vimのやり方
TIP1:ドットコマンドとは
- ドットコマンドは直前の変更を繰り返す
TIP2:DRY
複合コマンド
C 現在カーソルから行末まで文字変更。c$と同じ。
S 現在行を文字変更、
s 1文字変更。変更後も挿入モードのまま。 clと同じ。
Ｉ 行頭に挿入
A 行末に挿入
o カーソル位置の下に改行
O カーソル位置の上に改行
TIP6 ドットの公式
理想形は、移動にキー入力1回、何かするのにキー入力1回。
第１部 モード
第2章 ノーマルモード
TIP8 アンドゥはひとまとめに
挿入モードに入った瞬間からノーマルモードに戻るまでの入力が、アンドゥの単位となる。 （ドットコマンドの繰り返しも同様の単位となる）
TIP11 繰り返しで済むなら、回数を指定しない
2dwとかしないでdw.とした方が良い。 繰り返し、アンドゥの単位がひとつの方が扱いやすい。
TIP12 統合して統治せよ
オペレータ+モーション=アクション
よく使うオペレータコマンド
g~ 大文字小文字の入れ換え
gu 小文字化
gU 大文字化
オペレータコマンドを連続入力して呼び出すと、現在行に適用される
第3章 挿入モード
TIP13 挿入モードで簡単修正
C-h 直前の1文字削除
C-w 直前の1単語を削除
C-u 行頭までを削除
メモ
CapsLockキーはあんま意味ないので、ctrlとかescキーに再マッピングすると良い。 （日本語配列だったら無変換キーも再マッピングして良いと思う！）
TIP15 挿入モードでレジスタから貼り付け
C-r{register}
TIP16 簡単な計算をその場で実行
- C-r= Expressionレジスタからの戻り値を入力
第4章 ビジュアルモード
TIP21 ビジュアルな選択範囲の定義
- o 選択範囲の始点と終点を入れ替える
TIP23 可能ならばビジュアルコマンドではなくオペレータを優先しよう
その方がドットコマンドとの連携がしやすい
第5章 コマンドラインモード
TIP30 選択範囲に対してノーマルモードのコマンドを実行する
ビジュアルモードで選択し、:normal . 選択範囲にドットコマンド実行
:normal I// 行頭に//挿入
TIP31 直前のExコマンドを繰り返す
@:
TIP33 カーソル位置にある単語をコマンドプロンプトに挿入
- C-rC-w
例︎ testをカーソル位置の単語に置換 :%s/test/C-rC-w/g
TIP34 履歴からコマンドを呼び出す
q:で呼び出す
:qで閉じる
CRで実行
TIP35 シェルでコマンドを実行
:!でシェルコマンドを実行
引数もわたせる :!cmd % （編集中のファイル名をわたしている）
:read !cmd コマンドの標準出力を、バッファに送り込める
:read !ls ➡︎ls結果を編集中のバッファに挿入
:write !cmd コマンドの標準入力にバッファの内容を使用する
第6章 複数ファイルの管理
TIP36 バッファリストを使ってオープン中のファイルを管理する
- :ls
バッファリストを表示する
- %記号 ウィンドウに現在表示されてるバッファ
- ＃記号 代替ファイル（ひとつ前に表示していたファイル）
➡︎C-^で切り替えられる - +記号 保存されてない変更あり
- :bp 前のバッファ
- :bn 次のバッファ
TIP37 引数リストを使ってバッファをコレクションにまとめる
- :prev 前のファイル
- :next 次のファイル
バッファリストは机みたいなものだ。つまり、いつもゴチャゴチャしている。引数リストは独立した作業場所で、広々と作業をしたいときのために、いつでもきれいになっている。
第7章 ファイルのオープンとディスクへの保存
:e .
現在の作業ディレクトリでファイルエクスプローラをオープン
:E
アクティブなバッファのディレクトリでファイルエクスプローラをオープン
第3部 スピードアップ
ここから更に重要。
テキストオブジェクトとか。
第8章
読書メモ CleanCode
- 作者: Robert C. Martin,花井志生
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2009/05/28
- メディア: 大型本
- 購入: 27人 クリック: 914回
- この商品を含むブログ (80件) を見る
ついにこの本を読むときが来た。電車で読もう。(でかいんで邪魔だが)
第3章 関数
関数では1つのことを行うようにせよ。その1つのことをきちんと行い、それ以外のことを行ってはならない。
まあそこはなんとなくわかるけど、問題は何を持って1つのこととするのか。
関数が1つ以上のことをしていないか調べる、もう1つの方法は、その関数の実装の中から単なる言い換えではなく別の関数を抽出できるかを調べることです。
関数内の処理の抽象レベルが合ってるかということ？。それならなんとなくわかりそう。
フラグ引数
フラグ引数は汚い方法です。〜 これは、ただちにメソッドのシグネチャをわかりにくくします。
これは良くやってしまっている。。確かに保守性下がっちゃうかもしれないのでなるべく避けよう。
第４章 書式化
縦方向の書式化
インスタンス変数は、これに対しクラスの頭で宣言するべきです。これは、垂直距離を広げることにはなりません。 垂直距離を広げるとは、密接に関連した概念を、垂直方向に離して配置することの、アンチパターン。
上記引用は、インスタンス変数はそれでいいよと言ってる。使用するメソッドなりの直前で宣言しなくて良い理由は、ちゃんとクラス設計していれば、全てではないにしても、非常に多くのメソッドから使用されるはずだから。
第６章 オブジェクトとデータ構造
データ抽象化
単に変数との間に関数の層を入れるということは、実装の隠蔽ではありません。実装の隠蔽とは抽象化なのです！
単純にゲッターとか用意すりゃいいわけじゃないぞと言っている。何を外に伝えたいかを考えるのが、データの抽象化だということ？
データ／オブジェクトの非対称性
データとオブジェクトは相反する概念。 データ型の追加より、関数の追加が多いシステム(そんなない)では手続き型とデータ構造の方が適している。
混血児
オブジェクトとデータ構造との混血児は作ってはいけない。関数の追加もデータ構造の追加も困難にする。
第７章 エラー処理
(例外処理における)tryブロックはあたかもトランザクションに見えます。
まさに！ （例外機構は本当に良く出来たアーキテクチャだと思う。はじめはC#なのか？）
非チェック例外を使用する
チェック例外を完全にdisっている。
チェック例外の代償は解放閉鎖原則に違反する点です。
下位のメソッドのシグネチャ変更が上位に影響すると。 ただこれは若干疑問。例外シグネチャも通常のメソッド間のIFだとすれば、普通では？ハンドリングを強制できるメリットはでかい気がする。。
nullを渡さない
nullを許容しないメソッドの挙動として、アサーションを推奨。
assert arg != null : "arg should not be null" 通常のnullチェックだと、実行時エラーになるので、問題は解決してるとはいえない。
第９章
テストをきれいに保つ
汚いテストを持つということはテストを持たないことと同値だということ
たしかに。(前のプロジェクトが正にそうで、リファクタリングの補助になっておらず、むしろ阻害していた。。)
クリーンテスト
テストをきれいに保つには、読みやすさが最も大事。テストコードもちゃんと設計しよう！
1つのテストに1つのアサート
いろいろあるけど、
確実にいえることはアサート文の数をなるべく少なくするべきということです。
厳しすぎる規範は微妙だけど、やれるならやりたいよね。という感じ。 ここは、テスト書いてていつも悩む部分。1テスト1アサートにしようとすると、コードの重複しがちになる。。。
1つのテストでは1つの概念を扱う
これは激しく同意。 例えば、日付の加減算関数のテストで、いろんな条件を一回でしちゃってるとかはダメ。分ける！
F.I.R.S.T.
- 高速である
- 独立している
- 再現性がある
- 自己検証可能
長いファイルを読まないとテスト結果がわからないようなテストは避けるべき。
- 適時性がある
テストは製品コード直前にあるべき。
第9章 クラス
こっからひとつ段階があがるかんじ。重要そう！
カプセル化
変数、ユーティリティ関数を private とするのを好みますが、それに固執するわけではありません。テストからアクセス可能とするため、〜 protected にする必要がある場合もあります。筆者らはテストを優先します
クラスは小さくしなければならない！
理由はいわずもなが。問題はどうやって小さくするか？
- クラスの大きさ≒責務の数
クラス名は、そのクラスの責務を表すべきです。〜 あいまいな名前は、責務が不適当に集められているサインです。
やっぱり、名前付け≒設計ってこと。
単一責務の原則
SRP (Single Responsibility Principle)
クラス、モジュールは変更の原因となるものが1つでなければなりません。 〜 責務(変更の原因となるもの)を探すことは、コードの抽象化を高めることに役立ちます。 〜 システムは、少数の大きなクラスではなく、多数の小さなクラスで構成する必要があります。
凝集性
初耳なのでメモ。
あるメソッドが操作する(インスタンス)変数が多いほと、そのクラスのメソッドの凝集性は高いといえます。
高い方が、全体としてひとつのロジックを表してるので適切ということらしい。
変更のために最適化する
洗練されたシステムは、変更に対するリスクが最小限となるよう構成される。
変更から切り離す
具象クラスに依存していると、詳細が変更されたときに影響を受けるリスクがあります。
インタフェースと抽象クラスを導入しましょう。
箸休め
ちょっとメモ
- SRP 単一責務の原則
- OCP 開放/閉鎖の原則
- DIP 依存関係逆転の原則
今まで出てきたものですごく気になる、大事そう。。書籍「アジャイルソフトウェア開発の奥義[PPP]」に詳しくあるらしい。
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者: ロバート・C・マーチン,瀬谷啓介
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/07/01
- メディア: 大型本
- 購入: 18人 クリック: 586回
- この商品を含むブログ (70件) を見る
本書はその続編とも言えるらしいので、先に読みたくなってきてしまった。ポチろうかな。。。
第11章 システム
システムを使うことと、構築することを分離する
例えば、オブジェクトの生成を利用する際に行っているなど。あらゆる場面でそのオブジェクトが正しいと言える？テストのときは？
依存性注入
オブジェクトの利用と生成を分離するための強力な仕組み！！
