1．コーディング規約作成

プログラム製造時のルールを決めておき、その内容をチーム内で（製造担当者は必ず）情報共有し、徹底する。

プログラマーによる書き方のばらつきを防ぐ。

書き方にばらつきがあると、名前の認識違いなどが発生することも多く、各ソースを結合した時の不具合の可能性が高くなる。
統一することで、結合時の手間の軽減をはかる。
書き方にばらつきがあると、別のプログラマーが見てもよく分からないので、その担当者でないと修正が難しくなる。特定の担当者でないと対応できない部分が多いと、チーム効率が悪くなったり、別担当者が対応してかえって品質を悪くすることもある。 誰が見ても修正しやすい状態（メンテナンス性が高い状態）を目指す。

製造が本格的に始まってからルールの統一を図ったのでは、間に合わない。
製造作業が本格的になる前にルールを決めておき、チーム内での徹底をはかる。

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業	事前情報、他
・設計全般・製造全般	・システムの内容詳細・技術知識（マシン、ソフト、プログラム言語）

コーディング規約として決めておく項目には、主に以下のものがある。

ファイル名の付け方

プログラム開発中には、何人もの人が多くのファイルを作成することになる。ファイル名がバラバラで脈絡がなかったり、重複したりすると、プログラム全体を合わせるのが大きな手間となる。
あらかじめ、発生するファイルの種類を想定し、だいたいのファイル名の付け方を決めておく。
プログラム数とその内容が分かっている場合は、最初に全部決めてしまってもいい。

（プログラムの）関数・変数名、（DBの）テーブル・フィールド名

コメントの付け方

コメントが全くないプログラムは、他人はまず読めない。作った本人でも、時間が経つとほぼ分からなくなる。
プログラムに修正・変更が入った場合に解析に手間取り、ミスも発生しやすくなる。
コメントを入れる箇所、どんなことについてコメントを入れるか、などを標準化しておく。
- 関数ヘッダー・ファイルヘッダー
- 変数の用途
- まとまった制御ブロック（if、forなど）の説明
- その他

関数ヘッダー・ファイルヘッダー

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他	この後の作業
・コーディング規約（ドキュメント化したもの、またはメモ）	・製造全般

「どうしよう？」とみんなで議論することというより、誰かが決めてしまえば済むこと。
うまく分担して、効率よく作業全体を進める。

同じ言語で使ったものであれば、他のプロジェクトのものでもけっこう使える。それをもらってもいい。

決めただけではなく、チーム内で徹底しないと意味がない。

客先に提出するものではないので、形式ばったドキュメントにする必要はないが、何かしらの形で明文化されていたほうがいい（紙またはファイル）。
それを、製造にかかわるメンバー全員で共有する。

results matching ""