Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
@nagise 裏勉強会LT「タスク管理関連」メモ - @katzchang.contexts
5/1に「@nagise 裏勉強会」が行われました。参加者は11名くらい、内容は自己紹介を兼ねたLT大会でした。id:Nagise,ご結婚おめでとうございます。 自分のネタは課題管理関連。社内向けに資料を考えていたメモをEvernoteに残していたので、説明しつつツッコミを頂くスタイルで発表させて頂きました。ありがたい。 以下、メモを加筆修正したものでございます。 タスク管理の重要性 言うまでもありません。 Excelによる課題管理は破綻する 不吉な匂い メンバーの増加 5名程度が限界 小さいがクリティカルなタスク（不具合など）が管理しにくい 優先順位付けとか 元のフォームが悪いんじゃない？ 異なる拠点（自社、元請け、客先、別の客先… 増える資料（課題票、課題一覧表、線表、問題処理票＆一覧表、…） これらの条件でも管理稼働を最小にしたい タスク管理サービスの導入 Redmine（うちのチー
TDD Boot Campの感想 - @katzchang.contexts
「一番大事なことは最初に言う」とのことなので、大事なことから順に書きます。 反芻してるうちに思い出したら、追記するかもしれません。 ペアプロの前半のパートナーである@kozy4324とともにミルズ賞を受賞しました。 「前半のペアでコードが綺麗だった。私はJavaはわからないが、何が書いてあるのか、どう動くのかがわかった。後半にペアを変えても、それぞれのペアで綺麗なコードを書いていた。」とのこと。最大級の栄誉です。 個人的な理由の一つは、「いわゆるJava」っぽくないJavaが好きなので、Javaに慣れていない人向けなコードを書いていたこと。もう一つは、TDD読書会で存分に予習できていたことです。 @kozy4324はもちろん、TDD読書会のメンバーにも感謝です。 TDD Boot Camp Hokurikuを企画中です。3月予定。コーチ役としてid:t-wadaは欠かせないでしょう。Mic
privateメソッドは不要 - @katzchang.contexts
そのままの構造で全部publicにしろってわけじゃなく、大抵のprivateメソッドは別クラスに切り出して委譲できるか、もしくはstaticメソッドに切り出せるからそうしようって理屈です。とりあえずprivateな内部クラスとして定義するとか。結果、publicメソッドしか残らなければ上出来。 大抵のprivateメソッドは別の複数のpublicメソッドから呼ばれて、かつインスタンス変数の内容を更新する（つまりインスタンスの状態を変える）ことになるはず。そのprivateメソッドが更新する変数（の一部）を別のメソッドが更新できるようになると、あるインスタンス変数の状態を管理するのは誰なんだろうというのがとっても混乱する。privateメソッドに切り出したということは、そのprivateメソッドが更新するインスタンス変数はそのメソッドで共通的に管理したいという意図があるはずで、対象となるイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
