これから開発チームのリーダーになるあなたへ～最低限の標準化について～

##はじめに
私がこれまでに教えていただいた内容や学んだ内容を元に、
チームの標準化でやってよかった(やればよかった)内容をまとめてみました。

チームをまとめるためにどんなルールが必要なのか、ある程度汎用的に書きました。
これからリーダーをやる方やメンバーの方も、「これは使えそう」と思っていただければ幸いです。
また、「こんなことをやってました」などございましたら、是非コメントいただければと思います。

※あくまで、私の個人的見解です。
プロジェクトによってはマッチしない場合があると思いますが、参考程度に見ていただければと思います。

##詳細設計
設計書は外部の目に触れる可能性が高いため、見栄えの面でのブレをなくすのに力を入れましょう。
また、テンプレを作成し、それをベースに作成するようにしたとして、
テンプレがプロジェクトとマッチしていないと感じたならば、定期的な見直しも必要です。

細かい内容は以下です。
###記載内容の統一
設計書間で記載内容が統一取れていない場合、読みづらさに直結してきます。

しかし、がちがちにルールで固めてしまうと現状の設計書では表現できない処理が出てくるため、
ある程度の汎用性が求められます。

その解決策として、繰り返し出てくる処理をフォーマット化してしまうのが有効です。
大体、以下のようなインターフェイスに関わる箇所や処理をフォーマット化しましょう。
・DBアクセス
・ファイル読み込み・書き込み
・API呼び出し
・ループ
・分岐

また、忘れがちな統一をとった方が良い内容の一覧は以下です。
細かいですけど、チーム内の争いの種はこうゆうところから来てると感じます。。。

内容	例
同じ意味の記載	・DBに登録する ・テーブルに〇〇をInsertする ・テーブルに〇〇を登録する ⇒できる限り具体的に、かつ設計書寄りに書くという意味では一番下がいいと思います。
汎用的に使える言葉	DAOやUtilクラスのメソッドを"API"と一律で呼ぶ ⇒認識齟齬が生まれる可能性があるため、問題があれば統一しましょう。
クラス名・メソッド名	和名と英名の混在 ex) 和名:会員情報登録 英名:registerCustomerInfo ⇒ここが統一取れていないとリファクタができなくなる。。。

###コンポ分割方針
使用する言語の特性を考えてコンポ分割(どの単位でクラスを作成するか)を考えましょう。
例えば、Javaならオブジェクト指向がベースになります。

オブジェクト指向の基本的な考え方は、カプセル化・継承・多態性です。
現実世界のモノ(クラス)に例え、それがどのような情報を持ち(プロパティ)、どのような振る舞い(メソッド)をするのかをイメージし、分割を行っていきます。

しかし、実際に作成するプログラムは、現実世界のモノに例えられないようなものばかりです。
例えば、もらったデータを加工しDBに登録する処理が大半で、あとは外部連携などのバリエーションが加わるだけの場合、
「そんなもん現実になくね？」と絶望すると思います。

そこで一旦、データに着目します。
データはテーブルに蓄えられ、必要な時に取得されます。
そのテーブルは正規化され、論理と物理に分かれた設計がなされています。

この論理的に分割されたテーブルを軸にクラスを作成していくのがベストです。

要は、そのデータを専門に扱う窓口(モノ)として考えるのです。
すべてのケースにはこの例はあてはまりませんが、
適切な機能配置は、能動的なメソッド配置が可能になると思います。

###インデント
インデントは、仕様書の骨格になりますが、ある程度は好みでいいと思います。

ただし、以下のインデント例より深くなる場合は、可読性の問題(またはそれ以外の問題)のため、処理の見直しをおすすめします。
また、分岐やループなどは字下げするように定めておくことで、
プログラムとの整合性が取れるようになります。

インデント例

1.
___1).
______(1).
_________➀.
____________a.
_______________a).
__________________(a).

(トピック)
新規着任者がきたら、大項番から処理を書くように指示しましょう、
項番ごとにレビューをしてあげることで手戻りと同一項番におけるタイトルの統一性が図れます。

###TODO
TODOをどこに残すかは決めておきましょう、
これを先に決めないとメンバーがTODOを残し忘れる可能性があります。
また、TODOの内容もまとめることが可能ならば、TODOに対してコード採番・管理するのも手です。
これにより、同一起因のTODOに対してのアプローチが機械的にできるメリットがあります。

##実装
自分が書いたコードを何十年もあとに解読する、、、

こんなの絶対覚えてないですよねw
覚えられないなら、覚えなくていい仕組みを作りましょう！

リーダブルコードやデザインパターンを読んで、
各言語に合わせたスマート(可読性の高く・変更に強い・各関数の振る舞いが推測可能な)な実装を強制するルールを作ります。

以下はその代表例です。

###命名規則
「名前は大事」と耳にタコができるまで指摘された記憶があります。。。
基本的な内容はルール化しましょう！

決めないでバラバラになるより、統一しとけばリファクタで何とかなる！

####1.動詞と名詞
メソッド名、クラス名、変数名を付けるにあたり、おそらく使うであろう内容は規約として定義します。

ex)
登録：register
更新：update
登録：insert

####2.文字のつながり
ハイフンがあったり、なかったり、、、なんてことは無いようにしましょう。

ex)
定数：スネークケース(かつ、すべて大文字)
⇒ MAX_RANGE
変数名・メソッド名・クラス名：キャメルケース
⇒ getUserInfo
URL・ファイル名：スパイナルケース
⇒ user-info

####3.ヘボン式が英語か
日本人が故、誤字や誤用を回避するためにヘボン式を採用することもあるかと思います。
どちらでもいいと思いますが、ヘボン式の誤字は人に見つかると恥ずかしいです。

WEBツールなどあるので有効活用しましょう。

###DRY原則(OAOO原則)
一度書いたら、もう書くな(関数化しろ！)
多分こんな内容です。

eclipseなどの開発エディタには、関数化(リファクタリング)の機能が備わっています。
使用しているツールの機能をある程度調べておくといいかもしれません。

###関数化・定数化
その処理が、メソッド固有かクラス固有か(はたまた、アプリケーション共通の処理か)を考えてもらいましょう。
先にUtilクラスや定数クラスを作ることで、さぼりに対してアプローチできると思います。

また、その処理固有の機能であっても、詳細設計のインデント大・中項番レベルで関数化するよう指示してもいいと思います。(スパゲッティコードのレビューはとても大変です。)

###コメント
詳細設計のインデント大・中項番レベルを丸々張り付けていいと思います。

ただし、大事なのは詳細設計との関連性です。
意味のないコメントはレビュー時に指摘しましょう。

##テスト
テストファーストという言葉もあるぐらい、大事なフェーズ。
また、観点が揺らぐと網羅性についてレビューしづらくなります。

基本的に、
自分が書いたコード部分についてはホワイトボックス
呼び出すコンポーネントについてはブラックボックス
をUTやITなどフェーズに合わせて考えていくのがベースになるでしょう。

余力があれば、全データバリエーションを網羅したテストデータをテーブルごとに作成する、
業務有識者にデータを作ってもらうなども有効な手段になります。

##レビュー
###セルフチェック

セルフチェックシートを作りましょう。
今回ルール化したものをチェックシートに記載するだけで、かなりの数の手戻りが減ります。

###クロスチェック
レビュー指摘の内容は大体、同じ内容になります。
また、誰かがやったミスは、ほかの誰かもするでしょう。
必ず全体共有をし、何かしらの方法(ツールなど)で対策するようにしましょう。

特定処理にのみ存在する指摘でも、手戻りが大きければ、セルフチェックシートに記載することを検討してもいいかもしれません。

##その他
実際作業に入る前に、忘れてたり、ついつい後回しにしてしまうタスクを片付けておきましょう。

###必要資料をまとめる
どこにあるのか探している間に、なんでその資料が欲しかったのかわからなくなった。。。

そんなことありませんでした？(私はありましたw)
フレームワークやライブラリーのドキュメントについて、リンク集を作りましょう。

また、新規参画者用に最低限読むべき内容を色分けしておくといいです。
(あとできっと役に立ちます。)

###フォルダを作成する
MECEや時系列で洗い出しを行い、将来使用するであろうフォルダを前もって作りましょう。
(後から作るのは大変です。)

.
├─00_共通
│  ├─
│  │
│  └─
├─01_詳細設計
├─02_実装
├─03_UT
└─04_IT

###情報共有の環境を作る
今まで紹介した中で一番大事だと思います。

素敵なツールがあるのであれば、課金してでも使いましょう！
注意として、情報の共有ツールを複数作らないでください。
情報の発信元がメールであれ、一元管理できる仕組みを考えてください。

また、共有内容にはわかりやすいタイトルを付けるのをお勧めします。
※エラー内容など、一言タイトルをつけると会話の面でも楽になります。

##まとめ
メンバーが最大限の力を発揮するためには、明確な目標とどこまでの裁量でタスクを行えばいいかを示す必要があります。
そのため、タスクの裁量を決めるためのルール作りはとても大事な工程になります。

また、メンバーの犯したミスは、そもそもの仕組みのせいです。
そのようなルールを作らなかったリーダーに責任があります。

そのため、ルールはめちゃくちゃ大事です。

策定するのはとても難しそうに感じますが、考え方はシンプルです。
ルールによって以下が得られるように作りましょう。
・シンプルになること
・定量的になること

これを突き詰めて守っていけば、大道から大きく外れることはありません！