どうもお久しぶりです。ishida(@kojiisd)です。
ブログを書くのは実に半年ぶりくらいですね。
今回はAdvent Calendar25「新人/若手向け、これだけは知っとけTips25」
の22日目として書きます。
実は私、訳あって今ミャンマーで仕事しています。
そこで若い人たちのプログラムを見る機会が多くなってきたので、
そこから感じることを独断と偏見で書きますね。
前提
品質の高い成果物は設計・製造の中で作られる。
私はこう思っています。
たまにレビューや試験で品質を上げる、、、ということを聞いたりしますが、
あくまでレビューは仕様との突合せ確認、試験は作った品質を保証するものであって
品質を高めるものではありませんよね。
レビューや試験で70点の成果物を80点にすることはできても、
30点のものを70点にあげることはできません。
だからいかに高い品質のものを最初に作るのかが重要、そう私は考えています。
規約に従え
「規約って何?」という人は先輩やプロジェクトリーダに聞いてみてください。
必ずどのチームにも製造をするための規約があります。
※ちなみにAcroquestにも公開している「コーディング規約」があります。
もしないチームがあったら、そのプロジェクトからは逃げ出した方がいいですね(^^;
Javadocの書き方やクラス名、メソッド名、変数名の命名規則、
インデントなど、可読性と保守性を高めるためのルール集が規約になります。
他人のコードを最初に見てこの規約に沿っていないところを発見してしまうと、
その成果物に対して一気に信頼感が落ちるんですよね。
あぁ、この人ケアレスミス多いんだろうな、注意して色々と確認しなきゃ
となります。逆に規約にしっかり沿っているコードだとわかると
この人はしっかりしてるなぁ。安心してレビューできそう。
と思ってコードレビューできます。
たかが変数名やインデントですが、その簡単な一つ一つをしっかりと
作ってくれることで、あなたの成果物に対する安心感が格段に上がります。
左の実装と右の実装。機能的には一緒ですが、どっちのコードが安心して見れるか、一目瞭然ですよね。
ちなみにEclipseには、Javadoc自動生成や
オートフォーマット機能など、簡単に規約に沿えるようになる機能が
備わっています。ぜひ活用して効率的にプログラミングをしましょう。
静的チェックエラーは0を保て
CheckstyleやFindbugsを知ってますか?
Checkstyleは前述の規約通りにプログラミングされているかを自動でチェックしてくれるツール。
Findbugsは放っておくと不具合になる可能性のあるコードを事前に
発見してくれる優れたツールです。
あなたが書くコードはこのツールが出してくれた警告・エラーを常に
0にするように気を付けてください。
「後でまとめて直せば・・・」なんて考えは一片も持たないことです。
そうやって後回しにした、あるいは気にしなかった結果
Checkstyleのエラーが10万件を超え、Findbugsのエラーが1万件弱存在する、
という現場を聞いたことがありますが、そうなっては手遅れです。
手遅れになる前に、毎回エラーが発生したら対処することです。
このマークを見かけたら真っ先に退治にかかってください。(上がCheckstyle、下がFindbugsのマーク)
特にFindbugsのエラーは無視してはいけません。そのエラーを回避するために
ロジックを組みなおす、ということも必要になることがあるからです。
こちらもコードレビュー時に静的チェックエラー0を見ると、
その成果物に対して安心感を抱けますね。
設計通りか常に突合せろ
実装をするときには、その基になる設計が必ず存在します。
あなたの実装は常にその設計に沿っているでしょうか?
どんなに素晴らしいコードを書いたとしても、設計に沿っていなければ
その成果物はゴミコードになってしまいます。
とてもおいしいんだけど、注文と全く違う品を出すレストランがあったら、客は怒りますよね。それと同じです。
また設計通りの実装をしているコードを見ると、多少の実装誤りや
非効率なコーディングをしていても、安心して成果物を見てられます。
テクニックはその場で教えれば身に付きますからね。
まとめ
いかがでしたか?テクニック的なことが一つもないって?
ええ、いいんですそれで。
最初に独断と偏見で書くって言ったし。
テクニックは学べばいつでも高められます。しかし今回書いたことは
全て私たちの意識に根差しているものです。手を抜けば
あっという間にコードの品質は落ちますし、逆に実装開始時から
上述したような意識を保てれば、自然と品質の高いコードが
書けるようになると、私は信じています。
ちょっとしたこと、毎回の意識、ですが、その基本的な意識面こそが
テクニックよりも大切で、プログラマやSEが持たなければならない
マインドではないかと、私は思っています。
それでは。