実装方針決め（雑談） - ビューティフルWebコード

※他にもあるかもしれないので、思い出したら追記します。

サイトを構築する際には、クライアントと打ち合わせを重ねていくことと思います。

サイトマップ、画面遷移図が出来上がり、ワイヤーフレームが出来上がり、

ヘッダーフッターなどの共通レイアウトが出来上がります。

デザインやHTMLコーディングはデザイナやそれを得意とする会社が担当することが多いとおもいます。

さて、そのデザインや画面遷移図を確認し、DB定義を起こし、実際にサーバーサイド（またはフロントサイド）の実装に入ることが多いのではないでしょうか。

本格的な実装に入る際に、決めておくべき事柄があります。

これを決めずにただ開発者を集めて、基本設計を渡して実装させると、

確かにコードの量は増え、たくさんコミットされ、順調に進んでいくように思います。

完成率80%まではあっというまでしょう。

ただし、その後が悲惨です。

ルールも何もない実装は、無駄なコードを生み、バグだらけになります。

終盤にはバグチケットが増え続け、直しても直しても新しいバグが出てきます。

原因がわからないバグに悩まされ、なぜこんなコードになってるんだ、と気が狂いそうになります。

修正しようにもどこから手をつけていいかわからず、影響範囲もわからず、

「作り直したほうが早いんじゃないのか」

という状態になります。

誰しも経験があるのではないでしょうか。

正直、経験の浅いエンジニアが10人集まるより、質のいいエンジニア2人の方が、開発効率が良かったりします。

それは、なぜなのか。

質のいいエンジニアはタイピング速度がめちゃくちゃ速いからです。

冗談です。

無駄なコードがないのです。

きちんとルールを決めるのです。

ルールを決めるとコーディングルールを真っ先に連想される方々が多いですが、

コーディングルール（たとえばメンバ変数はアンダーバーで始める）を決めても綺麗な実装になるとは限りません。

もちろんコーディングルールを決めることも大事です（ないよりはいいです）

でも、クラスやメソッドをきちんと設計し、役割を明確化することの方が大事です。

I/Fさえ合っていればなんとでもなります。要するに役割に閉じていて欲しい。

たとえば、DataAccess層なのに、入力値判定をしてエラー画面にリダイレクトさせたり、Cookieから値を読み込んだり、中途半端に共通化しようとして引数にフラグを渡したり、実装した本人も処理を追わないと何をしてるのかわからないコードは害悪です。

経験値が低いエンジニアでも、実装方針が決まっていて、それに従ったコーディングをしていただけると、バグがあってもその画面、そのクラス、そのメソッドに閉じるのでプロジェクトへの被害は少なく、きちんと経験値を積んでいただけるようになります。

次回からは、共通ルールについて詳細を書いていこうと思います。