Putting an Eyeball on It

By Russ Finney

細心の注意を払う

William Gladstone once mused that "the heated mind resents the chill touch and relentless scrutiny of logic". This observation seems to apply remarkably well to the situations frequently faced by technical code reviewers. Why make this chore painful, when it can actually be fun, and beneficial to the team! Using formal code "walk-thrus", especially when multiple team members are encouraged to participate, can have an incredibly positive effect on the system construction process. Some of the advantages of performing these peer level code walk-thrus are:
William Gladstoneは、「熱くなった心は、冷たい態度とロジックの徹底した検査に怒り出す。」と考察している。この言葉は、プログラムコードのレビュー担当が度々直面する状況を非常に良く表している様だ。実際には面白く、チームにとって有益なのに、この仕事が辛いものになるのは何故だろうか？正式のコード「ウォークスルー」を行ない、特に複数のチームメンバーの参加を奨励すると、システム構築作業に非常に大きな好影響を与える事が出来る。この同僚によるコード「ウォークスルー」の利点を以下に挙げる。：

• Helps to identify "hidden" logic problems before testing even begins.
• Verifies that all of the business requirements have been successfully built into the program.
• Creates a learning atmosphere for entry level programmers to discuss "best practices" with more experienced coders and reviewers.
• Promotes consistent programming approaches throughout the system.
• Increases the level of program completeness and quality which put into program, simply because the programmer's peers will be involved in the review.
• Allows less experienced programmers to share fresh new ideas and approaches with the more senior team members (upward learning!).
• Creates another opportunity to spot module and class sharing opportunities.


• 「隠れた」プログラムロジックの問題を発見するのに役立ち、テスト前に見つかる事もある。
• 業務要件の全てが、きちんとプログラムに盛り込まれている事を確認する。
• 初級のプログラマが、経験豊かなコーダーやレビュー担当者と「ベストプラクティス」について話し合える学習環境を作る。
• システム横断的な一貫したプログラミング手法を推進する。
• 単に同僚プログラマーがレビューに参加するだけで、プログラムの完成度とプログラムの品質が高まる。
• 経験の浅いプログラマーが、チームの先輩メンバーと実地に新しい考えや手法を共有する機会を持てる。(向上指向の学習)
• モジュールやクラス共有の可能性を見つける新たな機会が出来る。

One of the critical activities which should be undertaken before the first walk-thru is conducted is to determine the high-level objectives of the entire process. Answers should be formulated to the following question: Why are we doing this and what do we expect to get out of this process? The team must establish the quality checkpoints that will be at the heart of the code walk-thru reviews. Listed below are a representative sample of some of these quality objectives:
初回の「ウォークスルー」の前にやらなければならない重要な作業の1つは、作業全体の高次の目的を決めておく事である。次の質問には答えを準備しておくべきだ。:「我々は、何故これをやっているのか？、どんな成果を期待されているか? 」チームは、コード「ウォークスルー」レビューの中心となる品質のチェックポイントを作成しなければならない．以下は、品質に関する目的の代表例である:

• Each program follows all established company coding standards.
• Each program follows all unique project coding standards.
• Each program follows any common system "coding patterns" which may not be a part of the formal company or project standards.
• Each program accomplishes its intended business purpose in as straight forward and comprehensible a fashion as possible.
• All module or class sharing opportunities are utilized to the maximum advantage.
• No logic errors exist within any of the reviewed programs.
• All program branches are tied to business requirements.
• Each program is structured and modularized appropriately.


• 全てのプログラムは、会社の既存のコーディング規準全てに従う。
• 全てのプログラムは、プロジェクトに固有のコーディング規準全てに従う。
• 全てのプログラムは、会社やプロジェクトの正式の規準でなくても、一般的な「コーディングパターン」には従う。
• 全てのプログラムは、その意図された業務の目的を出来るだけ単純かつ判り易い遣り方で実現する。
• モジュールやクラスの共有の可能性は、最大限に活用する。
• レビューされたプログラムには、どんなプログラムロジックの誤りも残さない。
• プログラム内の全ての分岐は、業務要件と結びついている。
• 全てのプログラムは、適切に構造化やモジュール化がなされている。

Once the walk-thru objectives have been put into place, and freshly compiled programs produced, the fun part begins! Pulling a group together to review the code! But who should be involved in the program "walk-thru"? And how many reviewers is the optimum number to be involved in the session? These questions have been the subjects of books, papers, and studies for years. Three to four people seems to be the optimum number and the following roles should be filled:
「ウォークスルー」の目的をはっきりとさせ、新しいプログラムがコンパイルされると、楽しみが始まる！コードを検証する為、グループを召集するのだ!しかし、誰をプログラム「ウォークスルー」に参加させれば良いのか？それには、どの位の人数が最適か？この問題は、長年に渡って、本、論文、研究の対象になっている。3〜4人が最適な数だろう。次の様な構成が望ましい。:

Programmer
プログラマ

Since the programmer actually wrote the code (or action diagrams), clearly he or she should be involved in the walk-thru. During this review, the programmer is responsible for stepping the group through the logic within the program, stopping every now and then to highlight a particularly complex or unclear set of statements. He or she should be seeking feedback from the other participants which verifies that all established quality checkpoints are being met and that any improvement opportunities are not overlooked.
実際にコード(または、動作遷移図)を書いたのはプログラマだから、彼(彼女)は、間違いなく「ウォークスルー」に参加すべきである。このレビューで、プログラマは、率先してグループのメンバーと共にプログラムのロジックを一つ一つ追いかけ、特に複雑だったり難解な部分では、時々立ち止り詳細に説明しなければならない。他の関係者が、先に決めた全ての品質のチェックポイントが満たされているか、改良の余地が他にないか等、検証した結果をフィードバックして貰わなければならない。

Specification Analyst
仕様作成アナリスト

If the programmer was not involved into the creation of the specifications he or she is coding from, the responsible specification analyst should also participate in the review session. His or her role should be to ensure that all of the specifications have been successfully transformed into code which is both efficient and structured, as well as being an accurate translation.
もし、プログラマ自身がプログラム仕様の作成に関与していなければ、仕様を作成したアナリストもレビュー会議に参加すべきである。彼(彼女)は、プログラムが仕様の全てをカバーしていて、効率的且つ構造化され、解釈も正しい事を確認する役割を負っている。

Technical Specialist
技術担当者

Depending on the overall experience of the programmer and the amount of time he or she has spent on the development application at hand, it may be helpful to have someone sit in the walk-thru who is very familiar with the languages, as well as the coding approaches, being utilized by the team. His or her role is to act as a technical consultant, answering any questions or advising based on experience, as various programming solutions are discussed. In addition, if specialized technical coding is required, the technical specialist is present to assist in this effort and to ensure the correct approach is being taken.
プログラマの全体的な経験や当該のアプリケーション開発に費やした時間によっては、使用言語やコーディング手法に非常に詳しい人間を「ウォークスルー」に参加させる事は、有益である。彼(彼女)は、様々なプログラミングの解法が議論される際、技術のコンサルタントの立場で、質問に答えたり、経験に基づいて助言したりする。さらに、専門的な技術を要するコーディングが必要な場合、技術担当者は、これを助け、正しい手法が使われる様にする。

Programming Team Leader
プログラミング チームリーダ

The role of the team leader in this walk-thru is about the same as it was in the design walk-thrus. Making decisions, ensuring consistency, pointing out module or class sharing opportunities, and keeping the session focused are all familiar responsibilities. Again, the team leader should keep the spirit of the review a quest for quality rather than a critique of the programmer's thinking. If the programmer is somewhat inexperienced, the team leader should strive to keep the review non-threatening and educational. This is a chance for the new programmer to benefit from the experiences of others.
この「ウォークスルー」におけるチームリーダーの役割は、設計「ウォークスルー」におけるものと大体同じである。決定を下し、一貫性を確保し、モジュールやクラスの共有の可能性を指摘し、常に会議の目的をはっきりとしておく事などが、主なものであろう。ここでも、チームリーダーは、レビューの精神がプログラマの考えを批評する事でなく、品質向上にある事を押さえておかなければならない。プログラマの経験が浅い場合、レビューが脅威ではなく教育的である様に努力するべきである。これは新人プログラマが他人の経験から利益を得る機会なのだ。

Copyright © 1999, Russ Finney, All Rights Reserved