にわかPHPerのコード解析〜修正手順

なのでWEBのシステムです。

去年まで新規での開発が多かったのに対して、

今現在は既に運用されているサービスの機能追加や

バグ対応のタスクがメインとなっている。

以下はあくまで仕事で使うコードに対するスタンス

新規で作る場合は、小さなものから出来上がっていくのを眺められるので全体像を把握しやすいのだけど、

既存で動いているサービスへ途中から参入する場合

既にコードは膨れ上がっているので違ったスタンスで挑まないといけない。

 ■解析のフェーズ

１、まずはどんなシステムなのか概要を知る

仕様書があってもなくても、触ったほうが最初のとっかかりの全体像を知るのは早い。

２、ホーム画面まで持っていった後、それに対応するコントローラとビューを探す

大体URLから推測できる（もしくはルーティングの処理）。

ホームの画面をベースにすると、枝分かれにして各機能を調査しやすくなる。

３、各機能をざっくり調べる

適当に機能を触りながらコードを読む。

その過程で、そのシステムの設計やどこに何が置かれているかなどをざっくり知る。

４,ざっくり調べている最中に気づいたことなどをメモする

とにかく新しいコード読むと、それだけに注力してしまって他のことをすぐ忘れる。

これは私の脳のメモリが足りないことにも起因するのだけど。

多分コレが最初のステップ。

実際の機能修正のステップに入らないと気づけないことも多々ある上に、

解析だけというのはキリがないのでどこかで区切らないといけない。

また解析するにおいて、

使ってるエディタで効率よく短時間でファイルを解析できるようにしておく。

Grepやファイル名指定してジャンプやコードの奥までたどる方法（また戻ってくる方法）

修正しているファイルをすぐさま行き来する方法など。

これは自分の中ではかなり重要で、

ファイルを探すのに手間取ってしまうと脳にノイズが走って

直近考えているメインの内容がぼやけてしまうため。

これもおそらく脳のメモリが足りないことに起因するのだけれど。

■機能修正のフェーズ

１、修正場所を特定する

コントローラなら先程のようにURLから（バックエンド側の処理はそこから辿る）、

画面はHTMLのid属性やユニークっぽいキーワード探してGrep

（画面は分割されていることも多いので、丁寧にたどるよりコレのほうが早いことが多いのだけど、正攻法なのか謎い）

２、車輪の再発明を避けることを意識する

（最初に解析する時点でざっくりどのような機能があるのか、

また欲しい機能がありそうな画面のあたりつけられるようにする）

→あればそれを流用、ないことを確認してから実装

３、他の機能に影響を与えないようなコードを書く

コードが膨れていることが多いので。

各処理の責任部分を意識したら自然とそうなる（スコープが小さく、切り離しされたコード）

４、修正するときは常にログを見る

画面に出ないエラーに気づけないので。

またデバッグログを出力するためのメソッドをスニペットにしておくと捗る。

修正作業を実施しているときは、

不必要に時間がかかっていないかを意識、改善のサイクルを作る。

おそらく、

そもそも難しいシステムにあまり携わったことがないせいもあるのだろうけど、

上記のステップで基本的な流れは大体はなんとかなっている。

あくまで機能追加、および修正のステップで、

不具合の解析などはステップが全然変わってくる（そしてそれは一律ではない）。

修正のステップは更に細分化できそう。

膨れ上がったコードを読むのは骨が折れるけど、

逆に言うと既に必要な機能は揃っているから楽をできる部分も多々ある。

新規の場合はゴリゴリ書いていく姿勢だったけど、

今は解析やリーディングの方を主軸にしているくらいの意識。

こういう記事を書くのは非常に恐縮なのだけれど、

あまり言語化することがなかったので整理してみたいと思っていた。

また、１つでも他の人の参考になる部分があれば幸いかなと。

少なくとも私が実施している時点で秀才にしか適用できない手法などではないと思うので。