プロの方には当たり前ですが、コード理解はエンジニアリングのスキル向上に不可欠です。しかし、
コード理解がどのくらい時間がかるのか？
何がコード理解を妨げるのか？
ということには意外と無頓着ではないでしょうか？私もです。
そんなわけで今回は
コード理解は開発現場でどれくらい大切なのか？
どうすればコード理解が早まるのか？
についての研究を紹介します。
プログラム理解は実労働の〇〇％！
当研究の対象者は中国のITベンダーの労働者2000人以上が対象。（つまり、学生ではなく実際のプロ）被験者には2週間の労働時間で開発者のアクティビティを
ナビゲーション（＝開発しているプロダクトの操作）
編集（コードを新規で書いたりリファクタしたり）
理解
その他
の4つに分類した上でそれぞれでどのくらいの時間を費やすことになるかを調査したんですね。またできるだけ研究を調整するために
新規と完了プロジェクトは除く（要件定義や納品などはコード自体いじらなくなるので）
被験者を5年以上の専門職、3〜5年、3年未満とレベル分けしている
ついでに開発規模も調整している
コードははCかJAVA
というような配慮もされています。
で、結果ですが開発者は
理解活動に時間の 57.62%
次いでナビゲーション (23.96%)、
その他 (13.40%)、
編集 (5.02%)
という順で労働時間を費やしていることが分かりました。また、これは当然ですが
専門歴の長い人ほど理解活動に費やす時間は少ない
ということもわかりました。それはまぁよしとして、コードの理解に労働の6割近くを費やしているというのは驚きです。
コード理解を邪魔する9つの要因とは？
研究はそれだけにとどまらず、どこに時間がかかったのかも調査してくれております。以下時間がかかる9つの要因を紹介しましょう。
1. コメントがないか、不十分
「特にソースコードが少し複雑な場合、コメントが不十分だとソースコードを理解できません」
実際には、コメントがなければ開発者はコードを見てボトムアップで理解する必要があるため、プログラムの理解が困難になります。 以前の研究では、特に保守の段階でその重要性が強調されており離職率も高まってしまうんだとか。
2. 意味のないクラス/メソッド/変数名
意味のないクラス/メソッド/変数名が多数ある場合もコードを理解するのにより多くの時間を費やす必要があるかもしれません。 たとえば、分析した「readHistory」という 1 つのメソッドで 5 つのファイルを開く必要があったけれど実際にはその後2つしか使われていなかったりとか。
3. クラス/メソッド内の行数が多い
サブメソッドを使っていないせいでクラス/メソッドは非常に長くなるやつ (行数が 500 を超えるなど)。
4. 一貫性のないコーディング スタイル。
「user name」、「UserName」、「userName」、「username」などソースコードが複数の命名規則に従っていると、ソースコードは理解しにくくなります 。
5. 継承階層の移動
抽象化は、オブジェクト指向プログラミング言語にとって最も重要な機能の 1 つです。 開発者が関連するソース コードを見つけるために何度もナビゲートする可能性があるため、抽象化によりプログラムの理解に余分な時間がかかる場合があります。 「抽象化はソース コード内の API を再利用するのに役立ちますが、ソース コードの動作を理解するのが難しくなります。 たとえば、クラス A と B が両方とも抽象クラス C から継承されている場合、同様に C から継承された新しいクラス D を作成するように求められた場合、A、B、および C のソース コードを読んで取得する必要があります。
6. クエリの絞り込み、および多数の検索結果/リンクの参照。
開発者が例外/エラー/バグまたは API を理解するためにクエリを実行する場合、必要な結果を見つけるためにクエリを複数回調整する必要がある場合があります。この時に時間がかかりがち。
7. ドキュメントの不足、内容が曖昧または不完全。
一部のドキュメントの内容があいまいまたは不完全であるため、開発者がこれらのドキュメントを理解するのにかなりの時間を費やしていることもわかりました。 たとえば、ある要件文書では資金の送金方法を規定するルールの説明が短すぎて明確では無かった。そのため 開発者は、この要件を理解するのに 2 時間以上を費やしました。時にプログラムの理解に時間の90% 以上を費やす必要もあったのだとか。
8. 関連資料の散在
アジャイル開発あるプロジェクトでは、要件ドキュメント、設計ドキュメント、API 使用ドキュメント、テストケースドキュメントなど、さまざまな種類のドキュメントがありました。 そして、各種類のドキュメントには複数のバージョンがあったとのこと。合掌。。
9. ビジネスロジックに慣れていない
インタビュー対象者10人中5人は、ビジネスロジックに不慣れであることもプログラムを理解する作業の妨げになっていると述べています。ビジネス ロジックの不慣れによるプログラムの理解の難しさは新人が直面する一般的な問題の 1 つですが、新人がプロジェクト チームに長く在籍したり、ソフトウェア開発の経験を積んだりするとこの問題は軽減されるそうです。
まとめ
というわけで今回はプログラマーのプログラム理解についてでしたー。個人的にはいつも「コード理解とかデータ理解遅いなぁ」なんて思ったりもしましたが、まぁー皆様苦労されているようです。デバッグ技術やレームワーク名、ライブラリ名においても参考になればと思います。コード理解力を上げる方法についても引き続きウォッチしていくので続報をお待ちください。
参考
https://ieeexplore.ieee.org/abstract/document/7997917/metrics#metrics
