Skip to content

Instantly share code, notes, and snippets.

@daijinload

daijinload/create-system.md

Last active December 30, 2015 07:18
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save daijinload/fed50b63f6e6b53c76e2 to your computer and use it in GitHub Desktop.
Save daijinload/fed50b63f6e6b53c76e2 to your computer and use it in GitHub Desktop.
Download ZIP
システムを作るときに考えること
Raw
create-system.md

システムを作るときに考えること

概要

システムを作るときに、こんなことを考えてるよ的なことを書いておきます。（追記があれば追記します。） 設計は正解が無いので、自分はそうは思わないとかあると思いますが、 一個人の考えと、参考程度に見て欲しいです。

考える要素

  • コーディング規約について
  • 開発言語の静的チェック（Linter）について
  • フレームワークを採用する場合、シンプルで有名なものを
  • テスト環境について
  • 設計について
  • プログラミングについて

コーディング規約について

だいたいケンカになるので、コードフォーマッターを用意したほうが良いかと。 で、それをすり抜ける書き方は、許容すること。 あんまり細かいこと指摘されても、覚えてらんないですし、書いていて窮屈ですからね。。。 個人的には、誰が書いたかわかるコードというのも、プログラミングの一興かと思うのですが、どうでしょうか？

開発言語の静的チェック（Linter）について

Javaだと、findbugsとかcheckstyleとか、javascriptだと、eslintですかね。 ちょっと、言語を触ってみるときも、使うのが吉。

フレームワークを採用する場合、シンプルで有名なものを

学習コストが高いフレームワークを使ってしまうと、言語の習得プラス、フレームワークの習得となり、キツイ。 実際にフレームワークを使わなくても、httpとか書けるんだから、シンプルなの使っておくべし。そうすれば、 バージョンアップ時のスッタモンダを軽減できる。 （言語は後方互換万全なのに、フレームワークが足を引っ張るとか笑えない。。。）

テスト環境について

  • テスト駆動開発が出来るようにする。テスト駆動開発のやりかたは下記を参考

    夏の技術職インターンシップ講義資料公開

  • カバレッジとかの話

    右手に感情、左手に数値

  • 環境のセットアップについて

    • 最初にテストフレームワークの選定や書き方を決めておく
    • テストのフレームワークは、シンプルなものにしたほうが、バージョンアップ時に修正が無くて良い。
    • パターン別にテストデータを用意するのはありだが、ステージングのマスタとかで動くようにしたい。

  • テストを書くときの基本方針

    • ローカルでできることは全部やる（DBとかにも保存するし、ファイルにも書き出す）
    • 保存時にテストが走るようなものがあると良い
    • 起動が遅くて時間の掛かるものでも、なんとか速くなるように頑張る
    • テストを書くときは、粒度が小さくなり過ぎないようにController（API）単位で書く
    • 品質保証用のテストと、テスト駆動開発用のテストを分けて考える
    • 自身のテストに関心のあるデータは用意して、自分に関心事のないデータは、汎用のものを使う。

  • テストを書くときの個人方針

    • 実装する時間を短縮するために、テスト駆動開発の手法を使う
      • 正常系のみ記述
      • プロダクトコードを用いてデータを作成する（直接データを保存しない）
      • 出来るだけ本番に近い実行となるように、事前準備がんばる。
      • テストは割りと自由に書いても良いんじゃないかな？

コードレビューについて

  • 生存期間の長いものを先にレビューする（データ設計とAPI仕様）
  • 担当者が王様で、レビュー者が召使い的なロールでやると、割りと担当が傷だらけにならないで済む？

設計について

正解とか無いと思いますが、あえてスローガンを掲げるなら、 目指せシンプル！！Simple is Powerful!!

  • 一読してほしい
    シンプルさの必要性
    単一責任原則

  • ドメイン駆動設計（DDD）も考えてみる

    • DDDの本質は、システム化したい業務対象をコードで再現すること。もし再現できていれば、業務対象の仕様変更のインパクトとコード変更のインパクトが同じくらいになる。（例えばカレンダー休日の色を赤から朱色に変えるとか。業務的にぱっと見て簡単な修正が、コード上も簡単であることなど。）決してオブジェクト指向がどうのとか、小手先の話ではない。なので、下手に導入すると帰って複雑化して、MVCなどのレガシーコードのほうが良かったとかになるので注意。

  • OSI参照モデルのように、階層構造を作る(層をまるごと作り変えても他の層には影響がないこと！！)

    • クライアントの層
    • Controller層
    • logic層
      • Controllerのためのlogic
      • logicのためのlogic
    • データアクセス層（DBやAPIでの取得も含む）
    • インフラストラクチャ層（ドライバやORMなど）

  • 小さいシステムの場合

    • シンプルにMVC構成で良いかと
    • でも、表示とロジックとデータアクセスをしっかりと分けること

  • 大きいシステムの場合

    • コンテキストマップを作成する
    • 分割出来ないか？検討する。
    • 静的片付け言語の採用など

  • t_wadaさんの話が参考になるかも

プログラミングについて

たのしんで行きましょう（＾ω＾）
プログラマー人生を楽しむために知るべき97のこと

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment