コーディングの掟、読了!

ペース上がってきました。やっぱり連休があると、一気に読めますね。

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)

コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)


キャッチコピーの「現場でよく見る不可解なJavaコードを一掃せよ!」にある通り、Javaの話がメインです。業務システムでJavaを触ったことがないので深いところは分かっていないのですが、Javaに限った話ではないところはためになりました。

無意味な定数定義
誇れるところではないけど、自プロジェクトでよく見ます。みんな「リテラルは定数定義する」というルールの本質的な意味を考えなさ過ぎ。定数を「CNS_1 = 1」と定義して何のメリットがあるの…?と、作った人に小一時間ほど問い詰めたいw
巨大な共通定数クラス
概ね同意。そのクラス・メソッドでしか使用しないならばそこで定義しようと。共通で使いそうならば、極力最小の範囲で切り出そうね。定数に限らず変数も。
リターンコードはもうやめよう
オブジェクト指向的な例外処理機構を使いましょうと。例外の伝播を容易に記述できて本質的なロジックが見やすくなるってことはメリットとして意識していましたけど、チェック例外による例外処理の強制もメリットの一つだということを改めて実感。
フレームワークやユーティリティのサンプル
「サンプルコードはたいていそのままコピーされる」は名言w。ライブラリ提供者はこの辺も考慮に入れて、サンプルプログラムを記載しろということですね。
日頃からあまりデバッグに頼らないようにする
これは頭にありませんでした。自分も、何かバグっぽい振る舞いがあったらまずデバッグしてました…。けど、確かにログだけで現象を追えないようならば、ログがまだ足りてないということの証拠ですよね。そこから、ログ出力を洗練する必要があることが判明するかもしれないと。今度から意識してみましょう。

StrategyやTemplate Methodパターンなどをうまく使って、ちょっとしたフレームワークを提供するのが最近楽しいんですよね。けど、フレームワークとかライブラリには一般の機能以上に高品質が求められます。そのために、↑のようなことを常に頭に入れておかないと。


次は、TracとSAPの連携 - @ikikko のはてなダイアリーを実現するためにPythonのおべんきょをしようかな・・・

みんなのPython

みんなのPython