ボクがプログラミング学習したいた時と実際の業務で感じたギャップの一つを今日も書こうと思う。
タイトルでもある通り、コードは「書く」以外に「読む」力が大切だ。
学習しているときは一から書こう、とボクも意気込んでいたが、実際の現場になると「書く」よりコードを読む時間の方が長くなる時すらある。
今日はどうしてそんなにコードを「読む」ことが大切なのか、書いていきたいと思う。
■理由１：実業務では新規開発より、すでに存在しているプログラムの改修や解析が圧倒的に多いから。
これは会社を立ち上げるか・就職するかの違いに例えたらわかりやすいかな、と思う。
会社を一から立ち上げるのは、プログラムでいうと新規開発にあたる。
もちろん起業自体は世の中にたくさんやっている人はいる。
ただ大抵の人は、すでにある会社に就職すると思う。これがすでに存在しているプログラムの改修・解析にあたる。
すでにある会社に就職するとなるとまずいきなり、社内で新しい部を立ち上げよう、新しく制度を提案しようとする人は少ないのではないだろうか。
まずはその会社の風土を理解したり、同僚・先輩や上司と仲良くなるために行動すると思う。
プログラムの場合も同じで、まずは存在するプログラムの理解に努めた方がよい。
プログラム（会社のこと）を理解して、初めてプログラムの改修・解析（会社をよくするための行動）ができるようになると思う。
■理由２：自分がコーティングするにあたって、他の機能に影響しないか調べる必要があるから。
現場で扱うプログラムは、1つ・2つのソースコードでなく、数十・数百となるプログラムを扱うときが多い。こういった場合、自分が実装した部分が思わぬところに影響が出ることがある。
例えば、このように改造したとしよう。
関数A (
処理（１）
処理（２）
処理（３） → ここを改造
)
この関数Aを呼び出しているところが仮に3か所あったとしよう。
すると、3か所の中で自分が関わっていない機能が存在しているかもしれない。
となった時、自分に関係ないから。。と放置するわけにはいけない。
3か所の部分で問題ないことを確認する（読み解く）必要がある。
■理由３：仕様書が使い物にならず、実際のプログラムからシステムの仕様を読むとる必要が出てくるケースがあるため。
現場によっては、仕様書（システムの説明資料）、プログラムがあったとしても、
プログラムにだけ機能追加や改修をやって仕様書を更新し忘れていたり、下手すると仕様書自体存在しないケースもある。
こういった場合、プログラムを実際に読んでシステムがどういう動作をしているか、読んでいく必要がある。
実業務で扱うシステムは練習と違って、1ファイルや2ファイルでなく数十・数百ファイルで構成されているため、自力では理解できないところもたくさんある。
こういう時に重要なのは、以前別記事でも紹介した、人に聞く力だ。
（※) 参考記事
https://qiita.com/894kun/items/f818faed1057dc41100d
参考までに。