【勉強４】リーダブルコード　前半

勉強で「リーダブルコード」を読んだので、個人的に要点をまとめています。表現が正確でない点もあるかと思いますが、あくまで個人的な整理ですのでその点ご理解いただければ幸いです。

第１部　表面上の改善

  • ２章　名前に情報を詰めこむ
  • ３章　誤解されない名前
  • ４章　美しさ
  • ５章　コメントすべきことを知る
  • ６章　コメントは正確で簡潔に

2章　名前に情報を詰め込む

命名の情報の上手な詰め込み方のコツは以下。

  • 明確な単語を使う
    • GetPage→FetchPage（ローカルキャッシュやDBでなくインターネットからとるニュアンスが出る。）
    • sendの場合以下のシソーラスがある
      • deliver, dispatch, announce, distribute, route
  • tmpやretvalを避ける。
    • 生存期間がわずかで役割が全くない時はOK
    • ループイテレータ（i, j, k）もmembers_iとかにすると分かりやすい
  •  抽象的より具体的な名前を使う
    • ServerCanStart()→CanListenOnPort()　（TCP/IPポートをサーバがリッスンできることを明示） 
    • --run-locally→--extra_logging(実際はログ出力をするという意味を与える。)
  •  名前に情報を追加する
    • start→start_ms（単位の追加）
    • Url→untrustedUrl（安全かどうかの追加）
  •  名前の長さ
    • 前提として長すぎるのはNG
    • スコープが小さい時は「m」とかでもすぐ分かるからOK、グローバル変数とかは長い名前にする。
    • 省略形は一般的（evaluation→eval）なもの以外はNG
  • 名前のフォーマットで情報を伝える：見やすくする
    • Google
      • クラス名はキャメルケース、変数名は小文字のアンダースコア、などフォーマットを変える。 
    • JavaScript
      • コンストラクタは大文字スタート（DataPicker()）、関数は小文字スタート（pageHeight()）にする
      • jQueryオブジェクトの頭に＄をつける
    • HTML・CSS
      • idはアンダースコアで区切り(middel_column)、classはハイフンで区切る(main-content)

 

3章　誤解されない名前

追記中...

【勉強３】現場で役立つシステム設計の原則

勉強で「現場で役立つシステム設計の原則」を読んだので、個人的に要点をまとめています。表現が正確でない点もあるかと思いますが、あくまで個人的な整理ですのでその点ご理解いただければ幸いです。

前半

Chapter1　小さくまとめてわかりやすくする

キーワード
  • 変更が大変なプログラムの特徴
  • 説明用変数の導入、破壊的代入
  • メソッドの抽出
  • ドメインオブジェクト
  • 業務ロジック
  • 値オブジェクト
  • 完全コンストラクタ
  • コレクションオブジェクト（ファーストクラスコレクション
メモ
  • 変更が大変なプログラムは以下の特徴がある
    •  メソッドが長い
      • if-else分が入り混じるとバグが混入しやすい。
    • クラスが大きい
      • 変更が必要な箇所がクラスのどの部分かが分かりにくくなる。
    • 引数が多い
      • 変更時のどの引数が関係し、どの引数が関係しないかの見極めが難しい。
      • 引数が多いと必然的にめそっどが長くなりif文も増える。
  • 説明用変数の導入：計算の目的ごとに新しい意味のある名前を付けて変数を作る。逆に1つの変数を使いまわすのを破壊的代入と呼ぶ。
    • 説明用変数を積極的に導入することで破壊的代入が減り、プログラム変更時のバグが減る。
  •  メソッドの抽出
    • ある目的（送料計算）の計算をメソッド・関数で切り出すことで、メソッド内の変更を中に閉じ込めやすくなる。 
    • 異なるクラスにロジックが重複している場合は、別のクラスを新規作成し共通のロジックの置き場所とする（例では送料クラスを新たにつくり、送料クラスのインスタンスを立ち上げamountメソッドを呼び出す。）
  • ドメインオブジェクト：業務で使われる用語（ex 送料）に対応するクラスのこと。業務の構造とプログラムの構造が一致すると良い。
    • 送料計算のたった2行のメソッドすらも切り出すのが、変更を容易にする。
  • 業務ロジック：計算（合計、端数の丸め込み）、判定（期限切れ名の判定）、加工（フォーマット）
  • 値オブジェクト（Value Object）
    • 金額をただintで宣言したり、電話番号をstringでただ宣言するのは危険。
    • 専用のクラス（Quantity、Telphone）をつくり、そこに制約を課す。
    • 全ての関数の引数は値オブジェクトを受け付けるようにすると安全
  • 完全コンストラクタ
    • 値オブジェクトは内部の変数を変更不可にし、新しい値（ある商品の値から1000円割引など）は別のオブジェクトを返すようにする。
  • コレクションオブジェクト（ファーストクラスコレクション）
    • リストなどの要素の追加・削除・書き換えは、そのコレクションオブジェクトの中に閉じ込める。
    • コレクションオブジェクトを返すときは、必ず別のオブジェクトを返し、かつ買い替え不可能にする
まとめ

「業務の関心ごと」と「クラス」を一致させること。業務の関心ごとに業務ロジック（計算・判断・加工）と制約・約束事を詰め込む

Chapter2　場合分けのロジックを整理する

追記中...

【勉強２】達人に学ぶDB設計徹底指南書　前半

勉強で「達人に学ぶDB設計徹底指南書」を読んだので、個人的に要点をまとめています。表現が正確でない点もあるかと思いますが、あくまで個人的な整理ですのでその点ご理解いただければ幸いです。

前半　DB概要

第１章　データベースを制する者はシステムを制する

キーワード

メモ

  • DBMS（Database Management System）とはデータベースを活用するあらゆるシステム（Amazonの購入履歴データ、Facebookの投稿データなど）で、DBをいつでも簡単に利用可能にできるようにするためにある。
    • 代表的なDBMSはPostgreSQL, MySQLなどがある。 
    • データとは一定の形式（フォーマット）に揃えられた事実のことであり、一番イメージしやすいのは二次元の表形式。
  • データベースの代表的モデル
    • RDB（リレーショナルデータベース）では二次元表の形式で管理する
    • OODB（オブジェクト指向データベース）では、オブジェクト（データと操作をまとめたもの）をそのままDBに保存する。オブジェクト指向言語（Java, C++）で使用される
    • その他にはXMLデータベース、キーバリュー型ストア、階層型データベースなどがある。
  • ITのシステムの設計、またはシステム開発では以下の工程が必要である。
    • １．要件定義：システムが満たすべき機能やサービスの水準を決める。
    • ２．設計：要件を満たすために必要なシステムの設計・デザインを行う。より詳細には以下の設計が必要である。
      • アプリケーション（AP）設計：ソフトウェアの提供する機能を決める。
      • ユーザーインターフェース設計：ユーザーが使用する画面の設計
      • データ設計
    • ３．開発（実装）：プログラマによるコーディング以外にも、サーバーやネットワーク機器のハードウェアの環境構築も含む
    • ４．テスト：システムが要件を満たす品質があるかと試験する。大きく分けると、機能的な品質のテストと非機能品質（性能や信頼性）のテストに大別される
    • 本書は設計に焦点を当てる。
  • データ設計、特にデータベースに保持するデータの設計（データベース設計）はITの設計の中で最も重要である。
    • 理由は、ソフトウェアは「データの流通機構」であり、どんなプログラムが必要になるかが、どのようなデータをどういう形式で設計するかに左右されるため。
    • このようにプログラムより前にデータ設計をする方法論をDOA（Data Oriented Approach, データ中心アプローチ)という
      • 一方プログラムから設計するのをPOAというが、業務のプロセスは変わりやすいので非効率的で非推奨。
  • 3層スキーマはDB設計の段階を示す
    • 外部スキーマ：テーブルやビューの画面など、ユーザーに何を見せるかの構図。
    • 概念スキーマ：テーブル定義、データの要素やデータ同士の関係。開発者の視点。
      • 正規化（3章）、ER図（4章）に関連。
    • 内部スキーマ：データのテーブルやインデックスなど物理的な配置。DBMSの視点。
      • 物理設計(2章)やパフォーマンス(６章)に関連。
    • 概念スキーマは見え方（外部スキーマ）とデータ格納方式（内部スキーマ）の結合を租にし、データ独立性を高めるために必要。
      • 概念スキーマがないと、例えばユーザーへの見え方を変えたい時に外部スキーマだけでなく内部スキーマまで変えないといけなくなる。
    •  

第２章　論理設計と物理設計

追記中...

 

 

【勉強１】Webを支える技術　前半

勉強で「Webを支える技術」を読んだので、個人的に要点をまとめています。表現が正確でないものもありますが、あくまで個人的な要約ですのでその点ご理解いただければ幸いです。

目次

  • 第１部　Web概論
  • 第２部　URI
  • 第３部　HTTP
  • 第４部　ハイパーメディアフォーマット
  • 第５部　Webサービスの設計

第1部　Web概論

第１章、第２章

キーワード

  • ハイパーメディア
  • 分散システム
  • HTTP,URI,HTML
  • SOAPvsREST

メモ

  • Webとは分散システムのハイパーメディアであり、HTTP、URI、HTMLの3技術で構成される。
  • Webはインターネットを用いたハイパーメディア
    • Web以前のハイパーメディアはMemex,Xanadu,HyperCard,などがある
    • Webはハイパーメディアとしては欠点がある（単方向、リンク切れなど）が、それでもそのシンプルさから世界で最も普及したハイパーメディアとなった。
  • Webは分散システム
    • Web以前の分散システムはRPCやCORBRA,DCOMがある。
    • これらは均一なクライアントを前提としており、世界規模にスケールアップしにくい
  • SOAB vs REST
    • 2000~2003年頃にWebのアーキテクチャスタイルでSOAPとRESTのどちらが優れているかの議論があった。
    • RESTに対してSOAPはHTTPをアプリケーションプロトコルではなくトランスポートプロトコルとして使用する点が特徴
    • 最終的には2004年から始まったWeb2.0の流れで、GoogleやAmazonがREST形式のWebAPIを使用したことにより、RESTに軍配が上がる。

第３章

追記中...