Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
ソースコード改造の発注時に気をつけること - @katzchang.contexts
メモメモ。他にあれば、ぜひおしえてください。 ソースコード中の改変コメント（"// add 2011.02.03 katzchang start"等）は不要です。 元のソースコードのコメントアウトは不要です。必要ないコードはそのまま削除してください。 ifなどのブロック（"{ ... }"）の追加や削除の場合、ブロック中のソースコードに改変がないとしても、インデントを適切に増減させてください。 Javadoc コメントを記述する場合、定義と矛盾がないようにしてください。メソッドコメントの @param が特に矛盾しやすいようです。setter/getterのように自明であれば、省略しても結構です。 Javadoc以外で、ブロックコメント("/* ... */")は使わないでください。 SCMで適切に管理されていることが前提です。 追記 あぁ、大事なことを忘れていた。 VSSで管理しないでく
Don't Tell, Ask - 求めよ、命じるな - @katzchang.contexts
えーと、どんな因果か、レビューされる側よりもする側になることが多くなってしまった。 対象となる生産物の欠点を指摘することは、レビューの大事な役割の一つであるとされている。だが、レビュアーとして一番怖いのは、間違った指摘や無意味な指摘をしてしまうことだったりする。そう、レビュアーもまた間違いを犯すんだよ。恐ろしいことに。 そこで有効なのが、"Don't Tell, Ask."「求めよ、命じるな」の原則。 レビュー対象物の「至らなさそうな点」に対して、なぜそこはそうなっているのかについて答えるよう求める。自分がより良いアイデアを持っていれば、それを伝え、どちらが優れているか判断を求める。「ここは、こうしてよ」のような命令（出す側は「アドバイス」と呼ぶ）は出さない。だって、レビュアーの意見の方が優れている保証なんて、何もないんだからね。 そもそもレビューをするのは、そのアドバイスに黙って従う初級
MyBatis Schema Migrationを使ってみる - @katzchang.contexts
この記事は Java Advent Calendar -ja 2010 の4日目のものです。 はじめに 継続的な開発では、データベーススキーマも段階的変化に耐えることが求められる。マイグレーション・システムが必要だ。 そこで、MyBatis Schema Migrationというのがあるらしいので試してみた。ほら、Java屋にはおなじみのMyBatisだ。 インストールする http://code.google.com/p/mybatis/downloads/list?can=3&q=migrations から、「MyBatis Schema Migrations 3.0.2 GA」をダウンロードし、適当な場所に展開し、PATHを通す。 migrate init - 初期設定 プロジェクトのホームがあれば、その下に空のディレクトリを作り、そこでスキーマの管理をするとしよう。空のディレクトリ
2.5時間で成果を出す、レガシーコードとの戦い方 - @katzchang.contexts
ポイントは 真っ先にコードをぶっこわせ！ いやその前にバージョン管理に突っ込め！ 安全にコードをぶっこわせ！ 仕様化テスト書こうぜ！ で、ようやく機能追加なりリファクタリングなり不具合の改修なりができる状態になります。 以下詳細。 …と、続けようとしたんですが、 短いサイクルで変更し続けるコードを示すには時間なり紙面なり根性なりが色々足りないので、gitのコミットを採って公開しつつ解説を入れようとも思ったんですが、コードをちょっと変更してJUnitの実行ボタンを押して git commit -a -m "いちいちコメント" などをしてたら5周目くらいに「うがー！」となったので、JUnitが実行されるたびにgit commitしてくれるようなEclipseプラグインが欲しくなりました。いまココです。 TDD Boot Camp名古屋のときも、結局最初のコミット以降ずっと忘れてたというなんとま
「あなたがTDDやユニットテストについて課題に感じていることがあれば、教えてください。」 - @katzchang.contexts
参加者アンケートより。 想定バグ検出件数とか、昔からなぜかある指標を打ち倒すこと やろうと思ってもなかなかできない・・・ モックのライブラリー等を使ったテストケースの書き方。すべてのテストケースの実行時間の短縮 知識のみで実際の経験がないこと。テストを書くのが難しいためテストケースを書けない場合がある。 テストを先に書く文化がなかなか根付かない→テストできないコーディングをしているorz 社内が従来のやり方に固執している為、新しい手法が試せない。 テストドリブンな手法を開発以外の分野にも適用してみたい。 マルチスレッド関連のテスト方法が分からない。 BDDなど、他のテスト技法（？）との使い分けが分からない。BDDはTDDの一部？ 他のクラスが必要で、テスト対象クラスのインスタンス化ができないやつとか、データベース使うやつのテストコードの書き方が分からないので、勉強が必要だと思う。 開発時点
TDDと品質保証 - @katzchang.contexts
今んとこはこんなイメージです。 *1 TDDで作るテストコードは、開発者が意図している仕様となっていることを保証している、と言う部分は言い切っちゃっていいような気はする。問題は、その仕様が要件を満たすとは限らないということ。最悪のシナリオは「仕様を保証するテストコードはきっちり出来たけど、ユーザが欲しいものは何も出来なかった」。よくある、古典的な課題の一つです。 要件を確認しながら「小さな一歩」を続けられるかってことなんだろうかなぁ。「目の前の問題に集中しろ！たまには周りを見渡せ！」っていう、相反した要素が求めらるわけですよ。これが、ペアプロとの相性がいい理由かな。 この辺りを夜な夜な語り明かしたい方々は、 TDDBootCamp北陸に是非お越し下さい（宣伝 *1:https://cacoo.com/diagrams/C1YxffZJT0r38ey6
TDD Boot Camp 北陸 事前アンケート中間発表 - @katzchang.contexts
自由回答欄がいい感じにいい感じなので、だーっとコピペします。 引き続き、このアンケートにご協力頂けるかたを募集しています。TDDBC北陸に参加してみたい方はもちろん、興味はあるけど参加はできなさそうな方なども、ぜひご協力ください。 アンケートは => http://bit.ly/6ToL7W イベントの参加募集は、1/12くらいから始める予定です。参加表明っぽい設問がありますが、改めて募集しますので、今しばらくお待ちください。顔。 あなたが自動テストを使って開発しているなかで、課題となっていることがあれば、教えてください。 TDDを既に実践している テストの資産価値。今後役に立たない/足枷となるテストをいかに捨てるか。 スローテスト。 テストしにくいもののテスト。JavaScript や GUI など。 「テスト」という用語がもたらす誤解。お客様には品質保証として捉えられがち。都度説明して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
