【雑談？】他人のコードを読み解くコツとは？

[jay]

そういえばもうＣ言語(Ｃ＋＋)を学び始めて３年と９ヶ月、長かったような短かったような
とあまり意味の無いことを考えてた今日この頃、ちょっとした悩み(？)があるのです

(以下本文)僕は情報系の専門学校に通っている２年生なのですが
高校生の頃からプログラミングを勉強していただけあって大半のクラスメイトより経験も知識もそれなりに多いです(間違いなくクラス内で上位１０％に入る程度には)
それ故に他のクラスメイトから教えを求められることも多いです。

学校の作品制作(ゲーム制作)の時間では自分のチームメイトにレクチャーするだけでなく、他のチームの人からＳＯＳを求められることも時折あったりします。
コンパイルエラーの修正とかならともかく、デバッグエラーやエラーは起きずとも想定通りの動きをしないといった類の話だとまず他人のコードを読み解くところから始めなければなりません(これが非常に厄介)
しかもそういう人に限ってコード内のコメントがやたら少なかったりします(チームメイトにはコメント書けって口うるさく言ってるんですけどね)

「そもそも先生に頼めよ」と思うでしょうが、先生が教室にいないことも多いですし(チーム毎にいくつかの教室に分かれて作業を行っているため)
教室内にいたとしても他の誰かに捕まっていることも多いです。
結果自分で教える方がはるかに手っ取り早いということも多いのです(自分のチームメイトに教えるときは尚更)
でもあんまりそれに時間を取られると今度は自分の仕事をする時間が無くなっちゃうんですよね・・・。

そんな訳でこの様な状況の時に決まって最も手こずる「他人の書いたコードを読み解く事」について
このサイトで常日頃から多くの人に助言をしている方々ならば何かコツを知っているのではないか？　と思い質問させてもらいました。
僕も時々誰かの質問に答えたりしてますが、見当違いなこと書いたりコードを読んでも肝心なところを見落としていたりするんですよね・・・。
他人のコードを読み解く時のコツや意識するといいことなど、何かあれば教えてください。

[beatle]

僕もあまり他の人のコードを読むのは得意ではありません。でもやはり人のコードを読む必要に迫られたことはあります。そのときは「ひらメソッド」を実行して対象のソフトウェアを理解しました。

プログラムの理解は、それだけで国際会議(IEEE International Conference on Program Comprehension)が成り立つほど難しい問題です。

[poppin']

10年以上システムエンジニアとして経験した上での発言になります。

まず本文では主にコメントについて述べていましたので、コメントについて言いますと、
はっきり言って、コード内にコメントがあるのは苦手です。
それはコメントが無くても困らないですし、逆にコメントが邪魔になるからです。

コメントが無くてもフローが追える理由は、
プロジェクトで開発をすると、コーディング前に必ずプログラム設計書（詳細設計書）というものを製作するのですが、
アルゴリズムのフローはそれを見ればわかります。
他人が製作したソース、もしくは自分が過去に製作したソースを見るときは、ほぼバグ修正か改修作業ですが、
それも設計書でフローを理解します。（設計書とソースはイコールなのが前提なので）
個人的には、学生だから設計書なんて製作しない、小規模な開発だからいらないというのは言い訳にもなりません。
「コメント書いてる暇あったら設計書書けよ」と思ってしまいます。
私は学生の時から勉学の範疇ということで設計書を作ってましたし、
現在、個人の趣味でゲームを開発してますが、設計書を書いてます。

次に、コメントが邪魔な理由は、
上記を踏まえた上で、フローを理解してからソースを見るので、コメントの存在理由が無いのでいらないという事、
さらにCUIのOSで動いているマシン（汎用機やサーバに多い）内にあるソースや、
ソースを印刷してみる場合、すなわち白黒だと一目でコメントなのかコメントではないのかが分かり難いからです。
それとプロジェクトでの開発だと、完成したソースの行数や容量の報告をする場合があるのですが、
コメントがあると正確にわかりません。

ただしコード外にはコメントを書きます。
それは、ソースのヘッダと関数のヘッダに開発者の名前、更新日時などを書くときのみです。

コード全体の書き方に関して言いますと、
プロとしてプロジェクト内で仕事をすると、社内かチーム毎に必ずコーディング規約というものがあります。
コメントやインデントなどは全部そのコーディング規約に則らないといけません。
なので勉強中にある一定のルールを叩き込む事はあまり必要にはなりません。
例えば、コーディング規約に「コメントは一切書いてはいけない」とあるにもかかわらず、
新人一年目の人がコード内にコメントを書いていて、その理由を聞くと「今までの癖」といったのが良くあります。


以上を踏まえ「コードを読み解くコツ」としての私の答えは、
設計書を読む、設計書が無ければコーディングした人に設計書を書いてもらう、
それが出来ないのであればソースを見ながら、自分で逆設計をして設計書を書く
（書いているうちにフローが分かってくる）ということになります。

つまりは、システムエンジニアは設計書至上主義といことです。

[softya（ソフト屋)]

poppin'さんの意見とまるっきり相反しますが、プロのゲームプログラマは設計書を作らないのでコード自体とコメントだけが解読の手がかりです。汎用機の業務プログラムと両方を経験してますが、すごく文化が違いますね。ただ、できの悪いコメントは有るだけ邪魔です。コードを見れば分かることはコメントに書くな！って事ですね。

で、他人のプログラムを読むコツですが初心者のコードはポリシーも何も無いのでとにかく読みづらいことは間違い無いです。なので、ここで質問される多くのコードもちゃんと追わずに直感に頼ってバグを発見していたります。
やって見てると良いかも知れないのはソースコードのレビュー手法ですね。当人とjayさんでソースコードを見ながら当人にソースコードを解説してもらいます。解説していると矛盾が出てきたり抜けが当人にも分かったりして意外に速く解決するのでは？と思います。

[ISLe]

学生さんが授業中に読み解くということだと参考にならないかもしれませんが。

わたしは長いこと移植中心の仕事をしてきたのでいろんな方が書いたコードを読みました。
見積りを出すために数時間で内容を理解して移植に必要な工数を計算する必要があります。

そんなときにどうするかというと、プラットフォームに依存した命令を検索してそこから関数やメソッドの関連を追いかけます。
あとはざっくり。
ゲーム移植では描画やサウンド、通信周りなど入出力がネックなので最初にしっかり抑えておきます。

長く続けているとプログラムの構造にもプログラマの癖が出ることが分かってきます。
数個の関数を見てそのプログラムを書いたひとがどのように関数を分けて書くかが予想できるようになります。

バグに関しては経験も必要ですね。
症状からどういったコードで再現できるかを考えます。
その再現コードがどのような処理に当てはまるかを考えます。
そしてどこに書かれているかを予想します。

いまでは一度見たコードならバグの症状を聞けばすぐにどこのコードが原因か分かるようになりました。
覚えてなくても自分ならこういう関数名を付けるはずだと予想しながら、電話で修正箇所を指示したこともあります。

いろんなプラットフォームに同じゲームを作る場合においては、実装に関して設計書を作っても無駄です。
プラットフォームによって実装を変えざるを得ないことが少なくないですから。
ゲームの仕様書もユーザー目線の内容ですし。

ゲームプログラムはコーディングルールに縛られてないことが多いですし、非力なマシン用に高度に抽象化されたコードは目の前にしてもすぐには理解できないことがあります。
設計書を用意する場合は上から下にデータが流れるつもりで、コードも分かりやすく書くと思いますが、縦と横と斜めからの入力を一度に処理してしまうようなコードがあったりするんですよね。

けっきょくたくさんコードを読んて経験を積むことが大事ですね。

[jay]

なんだか凄く興味深いお話もありますね！
みなさんありがとうございます～

＞beatleさん
「ひらメソッド」ですか～
最初はwikiでページ作るとか聞いた時点で「面倒くさそう」とか思ったものです。
でも実際改めて読んでみたら凄く理に適ってるんですよね。　ようはプロジェクトのリファレンスを作るようなものですしね。
(自分が直接関わる)大きなプロジェクトになるとこれもいい方法なのですね、選択肢として大いにアリ！
他のチームの人からちょっと助けを求められた場合には必要な手間と時間的を考えるとアレですけど(苦笑)
でも今回「ひらメソッド」についてちょっと見直しましたｗ

＞poppin'さん
お話を読んで凄くビックリしました！
その後のsoftyaさんのお話でもあるようにプロの業界でもＳＥとゲームプログラマーでもそんなに違うものなのですね(もちろん企業による違いもあるでしょうけど)
作品制作の時も設計書があれば見せてもらんですけどね(苦笑)
ＳＥはホントに設計書ありきって感じなのですね。　なければ書かせる、ダメなら自分で書くとまで言い切るとは。　僕には到底できない発想でしたｗ

僕が個人でゲームを作る時には企画書的なモノ(アイデアや仕様等を書き綴ったもの)を書いたりはしますが（それでも詳細なコードを書くことはあんまりしないですけど）
学校の作品制作の時は誰一人そんなことを言わなかったですね(時間が少ないのでとにかく作るという考え)
先生にも授業でそういった話を言われたことも殆どないですし、この辺りもその辺りの違いがあるのかも知れませんね(こじつけ？)

＞softyaさん
毎度毎度ありがとうございますｗ

ゲームプログラミングの現場と汎用機の業務プログラム制作の現場ではそんなに文花が違うのですね。
凄く驚きました～、就職活動の時はその辺りも考えて試験を受ける企業を選ばないと・・・

とまぁ、それはさておき
元プロというのは初めて効きましたが、やはりsoftyaさん程の腕になっても場合によっては直感に頼って、ということもあるのですね。
それでいて(僕と違って)的確に指摘できるというのはやはり経験によるところが大きいのでしょうね。
その経験豊富さに憧れますｗ　ついでにゲーム業界を目指す身としてsoftyaさんがかつてどんな企業に勤めていたのかお話を聞いてみたかったり・・・ｗ

レビュー手法ですか、これは良さそうですね！
なんで今まで気付かなかったんだろう、とつい思ってしまう程画期的に思えてしまいました。
早速明日から試してみます！　と思ったんですが明日は座学ばかりでしたｗ
早速次から試してみます！　これでよし

・・・。　誰かに教えるときはとりあえずこういう無駄な発言をなくすことも意識すべきかも知れませんねぇ(遠い目)


まだまだ他のお方のお話も聞いてみたいと思っています。
参考になるお話など待っています。

[beatle]

softyaさんがいうレビューは、ピアレビューというやつですね。
コードレビューにもいろいろあって、事前に告知したり発表の準備をしたりして行うフォーマルなレビューもあったりします。
ピアレビューはレビューの中でもかなりお手軽なやつですね。

[jay]

＞ISLeさん
これまた何度もどうもです。

そうですね、授業中に読み解くと一言に言っても
授業の課題(既にある程度できているものを設問で指示された通りに完成させるのが主)のコードと作品制作(各々のチームが自由に作る)
では勝手が全く違いますしね(苦笑)

とは言いつつもなんだかんだで参考になるところは多いです、そしてまた考え方が凄いですね。
「症状からどういったコードで再現できるかを考えます」「その再現コードがどのような処理に当てはまるかを考えます」
という部分も。　僕ならまず今までの経験から考えて「何でそのバグが起こるのか」という考え方になりますが、そうではなく端的に言うと「どうやったらその現象を起こせるのか」を考える訳ですね。
そして可能性が高い所から順に見ていく訳ですか、思わず「なるほど～」と口にしてしまいましたｗ

またISLeさんも凄いスキルをお持ちですね。
経験を積むことが大事と言われると、やはりこういう高いスキルを持っているお方に言われると説得力がありますね。

お話ありがとうございました。


＞beatleさん
ピアレビュー、授業で聞いた覚えがあります。

他にもインスぺクションとかウォークスルーとか色々方式があるとか言ってました。
まぁ、学校の作品でインスぺクションすることなんてないんですけど(苦笑)　最後に発表会という名目でプレゼンするだけですしね～
まぁ優秀な作品はそのご作品展に出したりとかするんですけどね。


っと。
まだまだみなさんのお話をお待ちしています

[Poco]

私がコードを読み解く場合は、まず
　1.書いた人間がいるなら、その人に聞く。
　2.コメントがある場合は話半分で読む。
　3.データ構造を追う。
　　3-1.どの構造体がどのソースで使われているか
　　3-2.グローバル変数はどれか
　4.main()から浅く呼び出し関係を見る
と、します。

この辺を簡単に押さえて、どういうプログラムか自分なりの仮説を立てます。
で、3でモジュール構成の仮説が立てられるので、重要そうなところに一気に深く読む。
ここでは必要に応じてデバッガを利用し、データの変遷を追ったりもします。

あとは仮説を修正→読み直し、動作確認を繰り返します。
最初は全然理解が進みませんが、ある時から加速度的に理解が深まっていきます。
なお、コンパイルが通らないコードは論外です。

[jay]

＞ぽこさん
コンパイルが通らないコードは論外。　お気持ちは凄く分かりますけど
２年生の最初の頃まではコンパイルエラーの修正もよく頼まれていたなぁ・・・、とつい思ってしまいました(苦笑)
まぁ、流石にプロになればそんなことはないのでしょうけどねｗ　この辺りも学生ならではでしょうねｗ

読み方に関しては、僕が先生に教わったやり方とほぼ同じですね。
やはりこういうのが一番オーソドックスなのでしょうか。
とはいえ学校で配布されているプロジェクトのテンプレがアレなのでmain()から～と
いうのはできないんですけどねｗ

お話ありがとうございました～。
もう少しお話を聞いてみたいと思ってます、皆さんお話まだまだお待ちしています。