この記事は、株式会社ACCESS Advent Calendar 2017の2日目の記事です。
あらまし
9月から11月にかけて携わったプロジェクトでは、やたらとスペルミスが多かった。
そういうプロジェクトはどういう状態なのか、なんとなく思ったので書き下す。
スペルミスによる害
スペルミスは害がある。
普通にバグの原因になるし、バグはなくともコードを読むときに脳に負荷を書ける。
そして一部の言語（Ruby, JavaScriptあたり）は、正確に治すのは難しく、スペルミスを直したつもりが直しきれずにバグになってしまうこともある（以前にAndroid StudioでJavaのリファクタリングしたときはかなり正確に、しかもコメント内まで修正が入っていた。言語によっては安全に直せるケースもある）。
そういう要素はプログラマのやる気を削ぎ、プロジェクト離脱や退職に繋がる。
成果物にスペルミスが混入する状況について
ある程度コードを書いていれば、スペルミスは多かれ少なかれしてしまう。
混入したものがリリース物に残ってしまう状況がどういうことか、考えてみよう。
セルフレビューの欠如
学校のテストなら、時間があれば提出前に見直す。
それと同じようにPRをレビューに回す前に差分に対して見直すのがセルフレビュー。
セルフレビューは自分の中でスペルミスを完結させる最後のタイミングだ。
そこをスペルミスが通り抜けるということは、
セルフレビューが行われない、または行っているが十分ではない、ということになる。
なぜそういうことになるのか。以下が考えられる。
- （セルフではない）レビューに頼っている
- 締め切りギリギリ、もしくはオーバーでそれをする余裕がない
- スペルミスへの意識が低い、英語が苦手
いずれにせよ問題がある。
1番目は、他人にコードの妥当性の判断を丸投げするような人間が良いコードを書けるわけもなく
結果他人の作業時間を奪ってレビューNGでまた戻ってきて修正して、というようなループに落ちいて貴重な時間を無駄にする。
仕事人として失格。
2番めは、プロジェクトの問題で、作業見積もりが甘い、仕事の割り込みが多い、など技術的ではなくプロジェクト運営に関連する問題が疑われる。コードを書く当人だけでなく、マネジメントにも問題があるケース。
3番めは、スペルが間違っていても正しく動けばいい、という意識。
メンテナンスする必要のない、書捨てのプログラムならそれも許されるが、
プロダクトでそれをすると、プロジェクト後期やメンテナンスフェーズでひどい目に合う（主に書いた当人以外が）ので、
仲間を大事にしない人間だと思われてしまう。
レビューの不具合
セルフレビューをすり抜けてやっぱりスペルミスが入っているコードがレビューに上がってしまうこともある。
レビューは品質保証活動の一環であり、プロジェクトの中で問題を完結させ、市場不具合などでプロダクトの価値を下げるのを防ぐ最後の砦だ。
結局こちらもほとんど同じで、以下が考えられる。
- テストに頼っている
- 締め切りギリギリ、もしくはオーバーでそれをする必要がない
- スペルミスへの意識が低い、英語が苦手
1番めについては、プロダクトの外から見た品質は守られるが、メンテナンス性への意識に問題がある。
3番目も同じである。
プロダクトの開発速度は徐々に鈍り、価値は低下していく。それを予測していないプロジェクトはろくなものではない。
2番めもセルフレビューと変わらないが、プロジェクト全体の遅延は致命的なので、より問題は深刻になる。
まとめ
スペルミスが多いコードを持つプロジェクトは、メンテナンス性や見積もり、意識に問題がある。
ジョインしたプロジェクトのコードベースにスペルミスが多かったら危険信号、
改善するなり逃げる算段を立てるなり対処しよう。
明日も @katoken-0215 です。お楽しみに！