以下の１つでも当てはまる場合は、作業者的プログラマーの可能性が高いです。
作業者的プログラマーとは、プログラミングを作業としか捉えず、
バグを出さないためのコツや可読性、処理速度といったことが考えられず、
設計書をそのままプログラムに変換することしか考えないといったプログラマーです。
可読性の観点
1つの関数は1画面内に収めること
1画面内（50行程度でしょうか）に収まるようにする。収まらない場合は別関数化の検討をする。
どんなに複雑な文章でも、句読点や段落の無い文章は無いように、分けれるはずです。
変数のスコープは可能な限り小さく
グローバル変数(C言語の言葉ですが)的な、どこからでもアクセスできる変数はやめましょう。
というのも、変数の値と値が入るタイミングを解析するとき、たくさんのところからアクセスしうるため、
解析が難しくなってきます。
ドキュメンテーションコメントを書く
優れたソースコードはドキュメンテーションコメントとクラス名、メソッド名だけ見れば
振る舞いが分かるようになっています。
ソースコードを読む人の負担が減ります。
見ればわかることをコメントに書かない
以下のようなプログラマーであればソースを見ればわかるようなことは行数が増えてかえって見づらいです。
//aにbを代入する
String a = b;
//リストを生成する
List<String> = new ArrayList<>();
こういったコメントばかり書いてドキュメンテーションコメントをろくに書かないのはいかにも作業者的に見えます。
全体を俯瞰して見て、それをドキュメンテーションコメントに書きましょう。
マジックナンバー禁止
論外です…。
同じマジックナンバーを使用している個所を全て洗いださないと解析ができなくなり、
コードを読む人改修する人の負担が増えます。
ツールを使うかコピペすること
DBのテーブル名や他のシステムと接続するようなものをコーディングする際は、
インターフェイスにかかわる箇所だけは、変数名などをコピペかツール化してtypoが起きないようにすること。
typoしてしまったソースのメンテナンスは、コピペ・ツールによる自動生成と一致しなくなるため、バグを生みやすくなってしまう。
再利用可能にするべきか検討すること
ソースコードを再利用するべき箇所をコピペして作っている場合、以下問題が発生してしまう。
- コピペしたところ全て修正が発生するため、修正漏れが発生する可能性が高くなる。
- 微妙に違う場合、どこが違うのかdiffをとらないといけなくなる。
処理速度の観点
- 1回の実行で十分な処理をループ内に書かない
- 同じ処理を複数回行わない
for( String line: lines ){
Pattern p = Pattern.compile("[a-z]+");//ここは結果が毎回同じ値のため、ループの外で良い。
if( p.matcher( line.trim() ).find() ){
System.out.println( line.trim() );//trim()を2回もしているためパフォーマンスが悪い
}
}