「“読む側”になって初めて分かったこと」
新人エンジニアの頃、私はこう思っていました。
コードを書くことが仕事
なので当時はどう実装するかばかり考えていました。
しかし実務に入ってしばらくすると、
あることに気づきます。
実務は「書く」より「読む」が圧倒的に多い
しかも読むコードは
・他人のコード
・数年前のコード
・仕様不明のコード
です。
そしてさらに恐ろしいのは昔の自分のコードすら読めないことでした。
今回は**“読む側”になって初めて分かったこと**を書いてみます。
新人の頃は「書くこと」が全てだった
新人の頃は実装することばかり考えていました。
例えば
if(user != null){
if(user.getEmail() != null){
sendMail(user.getEmail());
}
}
動く。だからOK。
当時は自分が理解できれば十分と思っていました。
でも実務では違いました。
コードは
・他人が読む
・未来の自分が読む
ものだったのです。
実務で最初に衝撃を受けたこと
実務に入って最初に驚いたのは
コードを書く時間より
調査している時間の方が長い
ことでした。
例えば障害対応。
なぜエラーになったのか
を調べます。
すると
Controller
↓
Service
↓
Repository
↓
SQL
を追いかけることになります。
新人の頃は実装メインだと思っていました。
しかし実際は既存コードを読む
時間の方が圧倒的に長かったです。
読みにくいコードは本当に辛い
実務で特につらかったのがこれです。
String data;
String tmp;
int a;
変数名が意味不明。
さらに
if(a == 1){
// 何かの処理
}
aって何？
状態になります。
新人の頃の私は
変数名なんて適当でいい
と思っていました。
でも読む側になると分かります。
命名は説明そのものでした。
「短いコード = 良いコード」ではなかった
新人の頃はコードは短い方がカッコいいと思っていました。
例えばこういうコード。
return list != null && !list.isEmpty();
当時はスマート！と思っていました。
でも実務で大量のコードを読むようになると一瞬で理解できるかの方が重要でした。
つまり書きやすさではなく読みやすさが重要だったのです。
コメントを書かなかった理由
新人の頃はコードを見れば分かると思っていました。
でも実務では
if(status == 9){
process();
}
みたいなコードが出てきます。
9って何？
となる。
業務コードでは業務知識が必要なことが多いです。
つまりコードだけでは意味が分からない。
読む側になって初めて
コメントは未来の読者への補足
だと分かりました。
一番読みにくかったのは「昔の自分のコード」
これが一番衝撃でした。
数ヶ月前に書いたコード。
if(checkFlg(data)){
update(data);
}
でも後から見ると
checkFlgって何…？
となる。
書いた本人なのに分からない。
ここで初めて気づきました。
コードは記憶に頼ってはいけない
ということです。
つまりコードは
未来の自分でも読める必要がある
のです。
「読む」を意識するとコードが変わる
読む側を経験すると
コードの書き方がかなり変わります。
例えば変数名。
昔
String data;
今
String customerEmailAddress;
長い。
でも圧倒的に分かりやすい。
他にも
メソッドを分割する
責務を分ける
コメントを書く
などを意識するようになりました。
理由はシンプルです。
読む人を助けたい
からです。
個人的な考察
実務をやっていて思うのは
コードは「書くもの」ではなく
「読まれるもの」
だということです。
新人の頃は
自分が実装できればOK
でした。
しかし実務では他人が理解できるかの方が重要でした。
特に業務システムは「5年後」「10年後」も使われます。
つまりコードは未来へのドキュメントでもあるのです。
まとめ
“読む側”になって初めて分かったのは
実務は読む時間の方が長い
ということでした。
そして良いコードとは書きやすいコードではなく読みやすいコードでした。
もし新人の頃の自分に
一言アドバイスするならこう言います。
未来の誰かが読むことを前提に書け
その「誰か」は
未来の自分かもしれません。