Programming: Standardization & Uniformity

By Russ Finney

プログラミング：標準化と統一性

Ralph Waldo Emerson one said "a foolish consistency is the hobgoblin of little minds", and this advice still holds true for project team leaders. The benefits of standardization should not be so rigorously enforced that potential time saving and innovative fresh approaches are suppressed. Once again the key word here is: balance.
Ralph Waldo Emersonは、かつて、「愚かな一貫性というのは、小心者に取り憑いたおばけである」と言った。この言葉は、プロジェクトチーム・リーダーにも当てはまる。標準化の恩恵は、時間節約の可能性や革新的で新鮮な手法を排除してまで無理やり押し付けてはならない。ここでもキーワードは、バランスである。

Two extremes seem to exist within projects at companies with system building experience. One approach is to do everything in a new way, making everything up as the system is built, never looking back to previous successes. Another is to religiously follow established patterns of uniformity, never allowing new ideas to be introduced, always doing everything the same way. Most companies fall somewhere in between. The optimal approach is to begin with the existing standards as a baseline, and then to review, discuss, revise, and implement each throughout the system building process.
システム構築の経験のある会社のプロジェクトには、2つの両極端が見られる。一方は、全てに新しい方法を採り、全てを新しく作り込んでシステムを築くもので、決して過去の成功に目を向け様としない。他方は、盲目的に既存の方法を踏襲し、新しい考え方を一切受け入れない。殆どの企業は、この間に位置しているだろう。一番良いのは、現在の規準をベースに、システム構築期間を通して、一つ一つ見直し、話合い、修正し、実施して行く事である。

Another unreasonable focus can be on program efficiency and processing speed, rather than on program modularity and maintainability. This is a mistake. With the availability of today's highly advanced technical platforms, no one really cares anymore if it runs in 20 instead of 80 nano-seconds. This is especially true for business programmers. The emphasis should be on structure, reusability, and ease of understanding. The business system builder's philosophy should be rooted deeply in these quality and excellence ideas:
もう一つ拙いのが、プログラムのモジュール化や保守性より、プログラム効率や処理速度に精力を注ぐ点にある。これは誤りである。今日の最新のプラットホームでは、それが80ナノ秒で処理されようが20ナノ秒だろうが、誰も気にかけない。これは業務処理系プログラマに、殊更当てはまる。構造、再利用性、可読性に注目すべきである。業務処理系システム構築者の哲学は、次の様な品質や卓越性の考えに深く根ざしたものでなければならない。:

• The system should be coded as if no one on the team will be around in two years to help with the maintenance.
• The system should be coded as if everyone on the team will be on call at three o'clock in the morning to solve any processing problems.
• The system should be coded so that anyone who will be unfortunate enough to really get a call at three o'clock in the morning will be able to quickly and efficiently understand the programming approach and logic.
• The system should be coded so that once a programmer becomes familiar with just a few of the programs, all the others begin to look the same. A maintenance programmer should be able to depend on this consistency.
• The system should be coded as if it were becoming a business asset, not someone's personal creative outlet.


• システムは、保守を助けてくれるチームのメンバーも2年後には全員がいなくなる事を前提に、プログラミングされていなければならない。
• システムは、チームの誰が午前3時に呼び出されたとしても、処理上の問題を解決出来る様に、プログラミングされていなければならない。
• システムは、不幸にして午前3時に呼び出されたチームの誰もが、素早く効率的にプログラミング手法やロジックを理解出来る様、プログラミングされていなければならない。
• システムは、プログラマが２−３プログラムを見るだけで書き方に慣れ、他のプログラムも同じ作法に見える様に書かれていなければならない。保守担当プログラマが、この一貫性に依存出来る様でなければならない。
• システムは、一個人の創造性の発露ではなく、経営資産にもなれる様、プログラミングされていなければならない。

Copyright © 1999, Russ Finney, All Rights Reserved