WEBにおいて明確しておいた方がよい方針・指針

WEBにおいては方針や指針をちゃんと決めておけば、負の遺産の発生を防ぐことができます。

方針・指針が特に明確に決まっていない、または曖昧なまま事業を開始するといずれ負の遺産が膨大になったり、スピードが出ない開発になったり、開発プロセスが増えていってしまいます。

結果として作り直した方がよい状況が発生してしまいます。

設計等に関しては基本的に最初からきちんと分けて、疎にしておくことが重要です。

特に開発初期の中心メンバーが方針・指針を明確に決めるべきだと思います。

そこで、こうしておいた方がよい方針・指針をご紹介します。

開発標準

静的解析

明確にしない場合

様々な書き方が散乱
後の開発者の混乱の元となるコードが多数
XXX派論争による無駄な時間の発生
ソースの複雑度が高くなり、膨大な負の遺産が発生する
1コード1機能で明確にディレクトリを分けて、実装では使うだけにすることができなくなる
似たようなソースが散乱するようになる
ソースのコピペが多発する
ソースの量が膨大になる
パフォーマンス劣化
メモリを無駄に消費
DDOSに対して、脆弱になる

保存時に動かせるもの

行末のスペースを削除
余分なタブやスペースの削除
ファイルの最終行の改行

保存時に何も動かしていない場合

無駄な大量の空白(余分なタブやスペース)が散乱
行末の改行がないwarning
保存時に自動的にスクリプトを動かすと空白の大量のdiff
無駄にリソースを使う
リポジトリが大きくなればなるほど、余分なタブやスペースの総バイト数が増加

技術要素の選定・採用基準

先を見る

先を見ていない場合

流行っているからという理由だけで飛びつく
後にオワコンになり、学習コストが高く、デメリットしかなくなる
その技術要素を採用する理由があるかをゼロベースで考えることができる中心人物がいない

ツール・フレームワーク等をできるだけ自作しない

不要に自作する場合

オペレーションに問題がある
変えるべきはほとんどの場合、自社・自分自身であり、ツール側ではないことを認識していない
膨大で保守性が低い、自作デプロイスクリプト・ツール
各種バージョンアップをしにくくなる(自作フレームワークの場合)
バージョンアップができないことによる脆弱性・情報漏洩リスクの上昇
変にカスタマイズした結果作者の意図とは異なる使い方をしている
秘伝のXXXXシリーズで後の開発者のコストが高くなる
個人やコミュニティが開発したものでメンテされなくなる
プロビジョニング用サーバーの保守運用が発生する
CI用サーバーの保守運用が発生する

用語・名称マスター

英語にする

英語にしない場合

マルチバイト起因の脆弱性
日本語や英語での似たような表現が散乱する

省略語

明確にしていない場合

様々な省略語が散乱する

連続した数値に意味を持たせない

0012→A
0013→B

連続した数値に意味を持たせる場合

直感的なソースの理解を妨げてしまう

同じ対象の名称を統一する

同じ対象の名称を統一しない場合

同じものなのですが、異なった名称が散乱する

※散乱させた実装者ではなく、エンジニアの中心人物が明確に用語・名称の定義をしていないことが原因です


ディレクトリ分けの方針・各ディレクトリの役割の方針

実装時にどれを使うか

実装時にどれを使うかの方針が明確ではない場合

毎回機能の使用ではなく、実装が必要になる
工数が多くなる
人数が必要になる
バグが発生しやすくなる
テスト工数の増大
似たような処理が散乱するようになっていく
※リポジトリのサイズが大きくなる
レビュー時間が長くなる
出戻りが発生する

キャッシュの方針

明確ではない場合

キャッシュに接続できない場合にアプリケーションが機能しない
いろんな所でキャッシュされてしまう

リポジトリを分ける方針

明確ではない場合

リポジトリが巨大になる
デプロイ時間が長くなる
インフラがどんぶり勘定になる

各サーバーの役割

1サーバー1機能ではない場合(機能が共存している場合)

※フロント、管理画面、バッチ、API、BFF API

フロントの問題で他の機能に影響が出る
管理画面の問題で他の機能に影響が出る
バッチの問題で他の機能に影響が出る
APIの問題で他の機能に影響が出る
BFF APIの問題で他の機能に影響が出る

パラメーターの複数対応

複数対応していない場合

APIに必要以上にアクセスしてしまうリスクが高くなる
※複数必要になった段階で改修しない場合

RDB設計

カラム設計

アプリケーション側での処理を考慮できていない場合

SQLでできることをアプリケーション側で計算することになる

データの特性を考えていない場合





汎用的にするか目的に特化したものにするか

明確にしていない場合

似たような処理が散乱する
他の目的に他の目的が混ざってスパゲティコードになる

どこをDRYでどこを疎にするか

明確ではない場合

モノリシックでDRYなインフラができる

バリデーションの方針

明確ではない場合

同じ値を複数回バリデーションして無駄に処理をしてしまう

データの存在の担保の方針

明確ではない場合

キーの存在確認が散乱して、無駄に処理をしてしまう

DB(SQL等)/API/アプリケーションでやることの方針

明確ではない場合

アプリケーションでデータを取得して表示するだけにならない
アプリケーション側のコードが複雑になる