「ソースコードブランチ管理のパターン」のダイアグラム - 日々常々
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja) お世話になっている人も多い Martin Fowler's Blikiの日本語翻訳サイト 、いつも運営＆翻訳ありがとうございます。 パターン言語は関連が重要な役割を担っています。そして関連はダイアグラムにすると捗ります。ダイアグラムがついている書籍もよくみます。 なので、ダイアグラムがないときや書籍と違う雰囲気のダイアグラムが欲しくなった場合、自分で描きながら読んでたりします。こんな感じで。 紙に手書きすることも多いのですが、インターネットで公開されているものはURLが付けやすいのでSVGで作るのが最近のマイブーム。SVGはサイズが大きくなっても拡大すれば読めるのでいいです。 上の画像はPNGをアップロードしたものなのでGistに上げました。 GistのSVGへのリンクを置いておきます。Gistの
finalを付けるのをやめてみた - 日々常々
Javaの話ね。バージョンは8以降の実質的final（effectively final）があるものとします。7以前は匿名クラス（この呼び方は 匿名クラスとかローカルクラスとか参照）でローカル変数を使うにはfinalが必要なので文脈変わります。 前提の整理 final は色々なところにつけられます。 例えばこんな感じ。 final class FooClass { final Object barField = new Object(); final void bazMethod(final Object quxParameter) { final Object corgeLocalVariable; } } このエントリで対象にするのは変数。フィールド barField 、パラメータ quxParameter、ローカル変数 corgeLocalVariable です。 以下を前提にします
Javaであまりしないコーディング - 日々常々
Java Advent Calendar 2014 - Qiita の9日目です。9日ったら9日です。 なんか難しいエントリが多い中ですが、空気を読まずに軽めでいきます。 Javaでは色々なコードの書き方ができるけど、実際あまりやらないよなーって思うコーディングについて、やらない理由を無理矢理書いてみた。 決して「やってはいけないコーディング」と言う意味ではないです。単に「私はあまりしない」程度で、一般的な（？）業務開発でもあまり見ない、くらいの位置付け。理解した上でやる分には全く問題無いですし、そう言うもんだと思って使っても良いとは思います。 複数変数を同時に宣言する int i, j = 2, k; 同じ型の変数（フィールドでもローカル変数でも）は同じ文で宣言できます。 けど、あまり使ってるのは見ません。 同じ型でしか使えないし、フィールドだとJavaDocコメント書き辛いし、初期化式
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
