アサインされたプロジェクトのソースを理解するときどこから読み始めますか？

Question

プロジェクトにアサインされた際(もしくは新しい会社に入社した際)プロジェクトのソースを読み込むのに何日か時間を与えられたとき、どこからソースを読み始めるものでしょうか？

自分の場合、どこから読み始めて良いか分からず途方にくれてしまい、とりあえず気になった機能をデバッグしてみるというようなあまり効率的でない時間の使い方をしてしまいます。

プロジェクトの性質によるとは思いますが、例えばサーバサイドの開発をPHPやJavaで行うプロジェクトの場合、どういったところから手をつけるのが良いでしょうか？

よろしくお願いします。

Answer 1

私の場合はまずは設計書を読んで、システムの概要を理解するところから始めます。

もし、設計書がなくてソースしかないのであれば「メニュー」などから取り掛かると良いと思いますよ。

「メニュー」にはそのプロジェクトで開発している機能がほとんどリストアップされているはずなので、
「メニュー」を確認することで、「どのくらいの画面や機能があるのか」を把握しやすくなると思います。

「メニュー」から以下のことも読み取ることができると思いますよ。

• 画面の大まかな数（最下層のメニュー項目の数から推測）
• サブシステムや各機能の構成（メニュー構成から推測）
• 権限による画面へのアクセス制御の有無（メニューの表示部分の実装から推測）

あとは「メニュー」にある画面名や機能名を見ながら、不明点を整理して、既存のメンバーなどに確認すれば、システムの全体像はつかみやすくなると思います。

Comments

[tmizuma]

ご回答ありがとうございます。
今まで関わってきたプロジェクトはほとんどドキュメントが存在しないプロジェクトばかりだったので皆さんどのようにコードリーディングしているのかなと疑問に思った次第です。

いきなりコードリーディングから入るより大まかな仕様から理解することから理解することが大事なのでしょうね。

[koichi-ezato]

やっぱりシステムの全体像であったり、概要が把握できていないと自分が書いたコードの影響範囲などがわからないと思うので、大まかな仕様を理解した上で詳細な仕様を確認していった方が良いと思いますよ。

Answer 2

僕はあまりソースは読みません。

ビジネスロジックはソースを追ってもあまり意味が無いと考えています。
そのあたりのコードは仕事を割り当てられてから読むので十分です。
事前にソースを読み込むことはしません。
最大で１機能分の処理の流れを確認しておく、って感じですね。

途中でプロジェクトに組み込まれた場合は動かすことを優先します。

■ドキュメントを確認する
ドキュメント類はより簡単なものを優先します。
一般向けの説明書＞概要書＞仕様書＞設計書の順で左優先です。

■プロジェクトの一覧を確認する
マイクロサービスとかに分割されてるとアレだし…

■コーディング規約を確認する
これはちらっと目を通しておけば十分です。

■使用されているフレームワーク、ライブラリを確認する
フレームワークとライブラリを知っていれば開発に参加した後でソースを追う助けになります。
有名どこが使われてれば名前見るだけで全体の構造がある程度分かることも多いです。
問題は情報が少ないプロジェクトほど著名なフレームワークやライブラリが使われてないことですが…

・リポジトリの構造を確認する
データの保存、取得はどうしているのかは重要な部分。
データ層は末端といえるので。

・UIの構造を確認する
同じく逆側の末端部分なので。

で、後はもう仕事振られるまで勉強が多いですね。
知らないフレームワークやライブラリがある場合は、それらの情報を集めます。
独自のものならソースから使い方の確認をします。
それが終わったら、プログラムがこなす作業の方を調べます。

Comments

[tmizuma]

＞そのあたりのコードは仕事を割り当てられてから読むので十分です。
まさにその通りですね。目的なくソースを読み漁るのは非常に非効率だと感じました。
「とりあえずソース読んどいて」みたいな感じで放置されることが多いのですが、何かしらのタスクを振られる方が効率が良いかもしれないですね。

＞一般向けの説明書＞概要書＞仕様書＞設計書の順で左優先です。
こちらもなるほどです。

Answer 3

仕様書がない場合、コード全体を網羅的に眺めて、全体的な流れを追います。
MVCっぽい構成であれば、

・テーブルとモデルを眺めてどのテーブルがメイン機能でいくつくらいあるか把握する
・他システムとの連携機能がないか探して、もしあれば連携機能の仕様を把握する
・アクション数が全体でどれくらいあるか把握して、似たアクションは頭の中でグループ化しておく
・各アクションの前後に実行される共通処理に目を通す（認証、権限機能など）
・画面も見ながら業務フローの流れを想像する
・時間がありそうなら全アクション順番に目を通していく

Comments

[tmizuma]

なるほど！仕様書がほとんどないプロジェクトのためまさにこのような回答を望んでいました。
＞テーブルとモデルを眺めてどのテーブルがメイン機能でいくつくらいあるか把握する
この辺りなるほどなと思いました。

Answer 4

そのプロジェクトの進捗度合いと、自身が求められるポジションによって変わりますね。

まだコーディング未満とか言うなら設計書から入るしかありませんし、コーディングはそれなりに進んでいてある部分の実装を任されたなら、まず設計書でその部分の設計を確認したうえで、他の部分のコーディングも参考にして（でないとソースコード全体の整合性がとれなくなるので）いきますし、デバッグ要員ならまずは当該部分のコードを追いかけるのと設計書とを並行ですし。
あと、たいていはデータベースが絡みますから、データベースの項目と、画面の項目との対比表があればそれも（なければまずそれを作るところから、かな）。

重要なのは

• 設計と実装が乖離していないか
• 実装した結果、設計に瑕疵が発生していないか

を把握することだと思います。ことに後者が発覚した場合、設計修正があるから影響も大きい為、早めにアラート上げないとなりませんから。

Answer 5

仕様を理解した上でデバッグするのであって、仕様を理解するためにデバッグをしてはダメだと思いますよ。

下記を見た方がいいですよ。
・各種仕様書
・動くGUI成果物があるならGUI成果物

Comments

[tmizuma]

確かに仕様を理解するためにデバッグというのは非効率ですよね。自分もやってて気付きました。
いきなりソースから入るのではなく全体像をつかむのが大切ですね。

Answer 6

私の場合は、最初に使い方を口頭で説明してもらいます。

一回一時間で二回ぐらい説明を受けます。それ以上になると私のキャパを超えます・・・
あとは機能ごとに順次説明を受けます。各作業の目的を確認しないと理解しづらいかもしれません。

相手の時間が取れるなら、すべてのユースケースを起こすのは有用で、あるべき姿だと思いますが、それが許可されるならすでにドキュメントが揃っていることでしょう。

ドキュメントが無いプロジェクトの場合、ソースコードを読んでもその部分しかわからないので、次に、データベースその次は、フォルダ構成と保管されているデータの種類を確認します。更に外部システムととインターフェイスがどのようなものあるかを確認できれば、システム内にどのようなデータがどのように保管されているか理解できます。

概要としての理解であればここまでで十分でしょう。ここまでは出来るならこの順番の方が無駄がなくてい良いです。

これより先が開発に関わる部分です。更に開発方式のドキュメントがない前提で。

ソースコードを一式を手に入れます。
使われているフレームワークなどで、分からない物が無いかを確認します。
わからないフレームワーク・技術の習得について上長と相談をします。

ここからさきは順不同です。
ソースコード管理方法を確認します。
リリースの手順を確認します。
手元でビルドが出来る状態かを確認します。（出来るようにします。）
テストの手順と求められる証跡を調べます。
コーディング基準を確認します。
テストDBへの切り替え方を確認します。

後は、いろいろな人とプロジェクトについて雑談をします。
プロジェクトの狙いや目的、人間関係、問題点などを大まかに把握することが出来ます。

Comments

[tmizuma]

仰る通りコード読む以外のアプローチも大切ですね。
「とりあえず２、３日コード読み漁ってみたけど大した収穫がなかった」みたいなことが多いのでこの辺りは今後改善していきたいと思います。