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

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

新規登録して質問してみよう
ただいま回答率
85.48%
コードレビュー

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

Q&A

解決済

7回答

1812閲覧

コードを自分が書いたかどうか思い出せない状態を予防するには?

manman

総合スコア233

コードレビュー

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

0グッド

2クリップ

投稿2015/09/19 10:49

編集2015/09/19 12:55

ずっとコードを書いていると、
自分が書いたコードですら思い出せないときがあります。
例えば、一ヶ月ほど前に書いた自分のコードを見ても、
そこに書かれているロジックは分かっても、
自分が書いたかどうかわからない感じです。

このような状態が続くとどういった場面で
不都合なことが起こるのでしょうか?
また、どのような予防を行えばよいでしょうか?

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答7

0

ベストアンサー

結論を先に書くと、下記の通りです。

  • 不都合なことが起こるのでしょうか? → だれが書いたかはあまり重要ではなく、特に不都合はない
  • どのような予防を行えばよいでしょうか? → バージョン管理システムを正しく使うだけ

以下は、補足説明です。

複数人で開発するならば、バージョン管理システム(GitやSubversionなど)を利用することは必須なので、それらを正しく使っている限り、特にコメント等をつけなくても、いつ、だれが、どの箇所をどのように修正したかを正確に追跡できます

バージョン管理システムを使う場合は、必要以上にコメントをつけない方が良いです。
というのは、本来バージョン管理システム側で管理すべきバージョン情報(修正者の氏名や修正した日付など)をコメントにも記載してしまうと、無駄に差分が増えるだけでなく、コメントに表記の揺らぎがあると結局は機械的に検索することは難しくなるので、労力の割には効果が薄いです。

むしろ、たとえ修正した箇所が1行であったとしても、最後にコミットした人がそのモジュール全体に関して責任を持つべきなので、だれが、いつ、どこを、どのように修正したか、ということ自体は、品質担保に関する限りあまり重要ではありません。

そうした情報は、いつどのようにバグが混入したかや、それを検出できなかったのはなぜかなど、いわゆるプロセス改善のためにこそ必要な情報であり、もはや「だれが」という情報は重要ではありません。だれがやっても同じ品質を担保できることが重要なのであり、強いて言えばだれに対してどのような教育が必要かを分析する際に役立つ程度です。

次にコメントについてですが、ポイントは以下の2点だと思っています。

  • 必要最小限の記載に止める
  • 式の意味や、そのような実装に至った理由や経緯など、コードからは読み取れない情報を記載する

過剰なコメントは、以下のデメリットをもたらします。

  • 修正のコストが掛かる
  • 修正漏れが発生すると実際のコードと乖離してしまう
  • バージョン管理上の妨げ(余計な差分が発生)

一方、コメントをいくら詳細に記載したとしても品質担保に直接寄与することはありません。
ですから、コードを読めば分かること、バージョン管理システムの履歴から分かることは、わざわざ記載するまでもありません。

一方、なぜそのような実装になっているのか、という意味経緯が分かるコメントであれば、時間が経過してから、あるいは別の開発者がコードを読む際に大きな助けとなり、影響調査の精度を高めデグレードを防ぐのに直接役立ちます。

投稿2015/09/21 09:19

pi-chan

総合スコア5936

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

pi-chanさんに1票です。おっしゃる通りだと思います。

source内のコメントは控え目に要点だけが良いです。PGのメンテナンスコストがかさみます。そして書かれている通りメンテナスもれで騙されてバグにつながります。コメントがあるだけに、ハマるとなかなか抜け出られません。

プログラムの流れは、それを見れば思い出せる程度の大きな枠のドキュメント(仕様:考え方や意味を含む)を(SEが)別に作成しているかと思いますので、そちらを充実させる方が良いと思います。(どうせ納品ドキュメントを兼ねることになりますし)

javadocのようなもので、クラス単位での用途と入出力が分かるようにしておく。source内にもバージョン埋めするので、documentとの差異が明白。メンテ漏れを防ぐ。ずれてたら怪しい。外だしすることで、リファクタリングできる。
後はみなさまのおっしゃる通りバージョン管理・更新の履歴管理でカバーです!

と、書きましたが、javaは苦手です ;-p

投稿2015/09/21 11:23

Ken.sakanakana

総合スコア1768

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

予防策としては既に書かれている様にソース管理ソフト(SubversionやVSS)等を使用し、
こまめにコミットする事です(コミットするときに面倒でもコメントを残します)

チームで開発している場合でも自分用にプロジェクトを分離して、
こまめにコミットする事をおすすめします。

仕事始める前に全体のソースと差分チェックと最新版の反映を習慣化すれば
大分少なくなると思います。

あとは健康管理と十分な睡眠を取る事が重要です。

投稿2015/09/19 13:12

pura90

総合スコア32

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

バージョン管理のコメントをしつこいくらい細く書くようにしてます。

投稿2015/09/19 12:18

yona

総合スコア18155

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

コメントと時には署名も入れるようにしています。
不思議と自分が書いたコメントなのかは判別できるものです。

投稿2015/09/19 11:52

rik

総合スコア1151

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

私は自分の書いたロジックが“なんで?”って言う状態になります・・・manmanさんより重症^^;
自分特有の言い回し(というかコーディング)なのに何かおかしい・・・
いいように解釈すれば、それだけ成長した。んだろうけど・・・
で、人に説明するときに詰まっちゃいますね。
なので、コードではなく機能(何をしているのか)で覚えるようにしています。Cなどで、関数いっぱいファイルもいっぱいw になると機能ごとに覚えないとパニックになります。
・・・“昨日の私は赤の他人”・・・あまり気に病まなくてもいいんじゃないでしょうか?

投稿2015/09/19 11:18

cateye

総合スコア6851

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

毎日、自身のHDDにコピペ。
これで、自分で書いたどうかわかると思う。

予防策は帰る前にコミットする。

改善策は、「誰のためにものづくりをしているのか」という意識。

投稿2015/09/19 11:10

TetsujiMiwa

総合スコア1124

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問