Subscribed unsubscribe Subscribe Subscribe

システムのアンチパターン

人に関するアンチパターン

・管理コスト、コミュニケーションコストが膨大になります
・少数精鋭でするより、品質が低くなります
・少数精鋭でする場合と比べて、リリース後の保守性が低くなります
↓
改善策:少数精鋭でフェーズを分けて開発するようにします

※品質や保守性はプロジェクト管理者が指針を示せば問題が発生しないこともあります

  • 脳内の整理整頓能力が低いエンジニアが設計や実装をする
・整理整頓されていないディレクトリ構成やソースが多く見受けられるようになります
・大枠の方針が明確ではないまま、プロジェクトが進んでいきます
・本番リリース後はデータ量の増加に伴うパフォーマンス問題、保守性の問題が発生します
↓
改善策:情報の整理整頓がうまい人のみを採用する
改善策:脳内の整理整頓能力の低い人に他の職業への転職を促す
改善策:世の中で成功しているサービスの設計とのdiffを認識してもらう

※システムは人による差がとても大きいです
※才能がない人は年数が経過しても才能がない状態のままが多いです

  • 現実世界の曖昧さを明確にすることがITエンジニアの役割だと認識していない人が多い
・仕様変更が多発して、手戻りが数多く発生します
・手戻り分の売上を補填するために1人月の単価が高くなります
・結果として、金額の割に質が低いものができあがります
・やっつけと言われる状態のソースが見受けられます
・保守性が低いものができあがります
↓
改善策:何をすればいいですかというエンジニアは解雇する
改善策:自身でサービスを作ってみて、仕様を考えてもらう
改善策:現実世界の事象をプログラムに落としこんで、現実世界の曖昧さを認識してもらう
  • エンジニアとしてベースとなる経験がない
サービスを一から作った経験がないエンジニアが多い
※企画、デザイン、AWS、アプリケーションの作成、デプロイ、改修等
↓
改善策:複数サービスを一から作った経験のあるエンジニアのみに開発させる

※収支が黒字になるくらい

設計に関するアンチパターン

  • 方針が明確になっておらず、共有されていない
・何をどこに置くかが明確になっていない
・汎用的な処理orビジネスロジックで格納する箇所が明確になっていない
↓
改善策:葉をみて、森を見ず状態であることを認識してもらう
改善策:基本となる方針とディレクトリやソースを対応させたものを作成してもらう

※ビジネスドメインに関する部分を削除した場合に他のアプリケーションでもすぐに使用できるフレームワークになっているべきです

  • URLが基本コード値
・文字列ではなく、コード値(101001、A3050009など)がURLに頻出する
↓
改善策:URLにはコード値ではなくより名前を使用する
  • パフォーマンス対策が後手後手
・パフォーマンスはアーキテクチャで担保する認識が低い
・ベンチマークテストをして、ボトルネックを見つけてから対応して後手になる
・アーキテクチャはトレードオフだという認識がない
↓
改善策:実際にサービスをローンチしてもらって、パフォーマンスについて考えてもらう
改善策:アーキテクチャにおいて何を捨てて、何を優先したのかをまとめて展開する
  • 依存先が不明確
・依存ファイル、依存モジュールを明確にしていない
↓
改善策:依存関係が明確なフレームワークを使用する
  • マルチデバイス対応に共通のAPIを使用していない
・各デバイスごとにライブラリが存在する
↓
改善策:どのデバイスからも共通のAPIを使う。
改善策:APIはキャッシュを使用する
改善策:APIはパフォーマンスを考慮して、Go言語等で作成する
改善策:APIサーバーのアーキテクチャ設計ではパフォーマンスを再優先する
・流行っているからという理由でフレームワークを理解せずに選定する
↓
改善策:公式ドキュメントでフレームワークの思想を理解してもらう
改善策:そのフレームワークでサービスを作ってもらう
改善策:そのフレームワークを採用に至った理由を競合フレームワークとの比較で説明してもらう
・社内フレームワークの思想が世の中で評価されているものから乖離している
・経験に応じた単純性よりも推測の汎用性が重視されている
・パターンの病理学に陥っている
・作り込みすぎて逆に複雑さを増しているだけ
・優れたソフトウェアは構築するのではなく、成長するという認識が低い
・システムの複雑さが組織のレベルの判断基準とされることを認識していない
・ロジックをモジュールごとに分けてしまっている
・ロジック、utilファイルが4000行を超える
・git clone後に設定ファイルを編集する必要がある
↓
改善策:デザインパターンの病理学に陥っていることを理解してもらう
改善策:ゼロベースで設計してもらう
改善策:世の中で評価されているものがなぜ、評価され使われているのかを考えてもらう
  • データの格納先がとりあえずRDB
・データの格納先の指針が明確ではない
↓
改善策:何をどこに置くかを理由と共に明確にしてもらう
※ファイルにするか、DBにするか、検索エンジンにするかを含む
  • データ取得の際にキャッシュを使用しない
改善策:キャッシュがあるかを見て、ないときのみ直接取得する
※RDBを使用していて、複数テーブルをjoinするSQL文を毎回発行しているのは最悪です
  • ログが巨大で問題解決に役立つものの割合が少ない
改善策:ログに何をなぜ出力するのかの方針を明確にする
  • 全画面のURLの洗い出しがコマンドでできない
改善策:パラメーターで画面を分けない(アクションで分ける)
ユーザーにとってどう利点があるかからを考えずにツールを選定する
流行りでツールを選定する
↓
改善策:過去に選ばれなかったツール、選ばれたツールとその理由を考えてもらう
  • セキュリティ
・セキュリティはインもアウトもという方針が明確になっていない
・セキュリティの方針を設計していない
・ソースを見て、脆弱性があるかどうかを判断できるエンジニアがいない
↓
改善策:ニュースになったセキュリティインシデントの原因と解決策を考える

ソースに関するアンチパターン

  • セキュリティ
・汚染リスクのある変数が明確になっていない
・自身のソースに攻撃しない
↓
改善策:コーディング規約に盛り込む
  • 例外処理があちこちに散在している
・例外は最上位でハンドリングする意識がない
・トップレベルの例外処理メカニズムに任せていない
↓
改善策:例外ハンドリングについての方針を明確にして展開する
・タイムアウト、データの上限を意識していない
・限界を意識していない
・データ量が膨大になったときにどうなるか考えていない
  • 情報取得元
・公式サイトを見ていない
・ソースを見ていない
・周りの人の言ったことをすべて聞き入れる
・ググって、ブログの内容を信用してしまう

コミュニケーションに関するアンチパターン

  • 情報共有
・一人一人のアクションがチャットで自動的に共有できていない
・リアルタイムの進捗の見える化ができていない
・チャットで流れては困る内容とそうでない内容のアクションが同じ

実装に関するアンチパターン

  • コメント
コメントにWhyが書いていない
コードを書いたときの考えが残されていない
呼び出し元に関数定義のドキュメントと同じ内容がある
オブジェクト指向と多くの可変なメンバ変数が必要が存在する
メソッドの挙動がメンバ変数に左右されてしまう
読みやすさよりメモリを優先している
  • フォーマット
「,」「=」が揃っていない
コード内段落がない
既存踏襲できていない
  • DRYに反する
アクションにビジネスロジックが多数存在する
viewがlayout化されていない
巨大なメソッドが存在する
リファクタ前提で作っている
  • 変数の命名
変数名で何が入っているかを表現できていない
メソッド名で何をするのかが表現できていない
明確な語彙を使っていない
  • 変数名(数値)
数値が格納されているのに単位が変数名に入っていない
  • 変数名(ファイル関連)
file名なのか、絶対パスなのか、相対パスなのかが変数名からは分からない
  • 変数の状態
データの状態が変数名で表現されていない(plain,urlencoded,raw,整形後)
クラス変数とローカル変数の区別がつきにくい
  • 変数のクラス
スカラ値なのか、配列なのか、ハッシュなのかが変数名に表現されていない
  • 変数名の長さ
略語が世間一般的ではない
スコープが短いので、変数名が1文字
  • 否定
否定のelseがある
  • ネストの深さ
早めreturn,continue,breakせずにネストが深くなっている
100%存在するものの存在確認で必要以上にネストが深くなっている(責務の区分けができていない)
  • 変数の数
役に立たない一時変数がある
不要なフラグが存在する
不要な制御変数が存在する
何度もハッシュ内の特定の値を取得している
説明変数がない
  • メモリへ対する考慮
巨大なデータを引数として何回も渡している
  • タスクの明確化
タスクの細分化と対応したメソッドの作成が行われていない
  • コードよりも仕様書を充実させる
仕様書が膨大(500行の仕様書より、1行のコード)

テストに関するアンチパターン

  • テストケースの内容
テストケースの内容よりもカバレッジを重要視する
テストケースが完璧であっても、アプリケーションに不具合が発生する
テストケースが過剰にありすぎる
E2Eテストコードが最優先されていない
  • プロダクトとの関連
テストがプロダクトの足かせになっている

引用元(一部引用させて頂いています)

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp