質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.32%

  • PHP

    21359questions

    PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

  • Java

    14434questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • コードレビュー

    42questions

    コードレビューは、ソフトウェア開発の一工程で、 ソースコードの検査を行い、開発工程で見過ごされた誤りを検出する事で、 ソフトウェア品質を高めるためのものです。

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

解決済

回答 6

投稿

  • 評価
  • クリップ 5
  • VIEW 1,344

tmizuma

score 45

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

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

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

よろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

+5

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/10 01:26

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

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

    キャンセル

  • 2017/02/10 10:15

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

    キャンセル

+2

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/14 12:28

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

    キャンセル

+2

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

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

重要なのは

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/14 12:30

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

    キャンセル

+2

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

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

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

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

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/14 12:33

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

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

    キャンセル

checkベストアンサー

+1

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

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

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

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/14 12:36

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.32%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

  • PHP

    21359questions

    PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

  • Java

    14434questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • コードレビュー

    42questions

    コードレビューは、ソフトウェア開発の一工程で、 ソースコードの検査を行い、開発工程で見過ごされた誤りを検出する事で、 ソフトウェア品質を高めるためのものです。