技術記事ノック #265~#275

SQLを高速化するために

パフォーマンス・チューニング --> ボトルネック(一番遅いところ)の改善

十分速い箇所を速くした所でシステム全体のパフォーマンスの向上は見込めない。

どこが遅いのか　を調査し、改善することが重要

• ボトルネックになりやすい箇所
  • ディスク I/O (input, output)
    • ストレージに対するデータの読み書き操作のこと

SQLは未学習なので、頭に片隅に入れておく

デザインパターン

Web制作のデザインの雛形かと思いきや

プログラミングにおいて、何度も何度も様々な難局を耐え忍んで乗り越えた達人がいる。そのような達人たちが同じ問題に取り組んだ場合、典型的にはみな同じパターンの解決策に辿り着く。

これがデザインパターンと呼ばれる物である。

すごい種類がある

わからん！

lambda式とは

lambda式記法を使って書いた物が、無名関数と呼ばれる

無名関数とlambda式は関係がある

要件定義

プログラミングは実装の部分に該当し、それ以前に4つの壁が存在する

[ 企画 ] -> [ 業務設計 ] -> [ 要件定義 ] -> [ 設計 ] ->

[ 実装 ] -> [ テスト ] -> [ リリース ] -> [ 保守 ]

エンジニアが理解しておくべきは　要件定義, 設計

• 要件定義
  • 発注者の頭の中にあるイメージを明確化しなくてはいけない
  • 納品時に「これでいいですか？」と具体的に確認できる事前約束
• 要件定義を決めるプロセス
  • 要望: こんなシステムあったら良いな　といったアイディア
  • 要求: システムに実装して欲しい大まかな機能一覧
  • 要件: 双方が合意した具体的な機能一覧と実装方法
    • 要望 -> 要求 -> 要件 に落とし込んでいく

Componentの凝縮度を高くするために

• UNIX哲学

Do one thing well = 1つのことを上手くやれ

複雑な処理を行う際には | で連結して実現する

• KISS原則

keep it simple, stupid = シンプルにしておけ、バカ　もしくは

keep it short and simple = 簡潔かつシンプルにしておけ

リーダブルなコードが重要

こういった類語(考え)に共通することは、モジュールの責任を減らす　という考え方

上記の類語を現実世界のコードに反映させる具体的な指標が凝縮度である。

何となく、言わんとしてる事は理解出来ているとは思う

プログラミング的指向　【抽象化】

抽象化とは目的に応じて適切な側面・性質だけを取り出し、他の部分を捨てること

※以下個人的解釈

要件定義の段階

要望を受け取った段階でざっくりした要望で計算する機能と言われたとする

四則演算はだけがあれば良い

桁数は100桁まで欲しい

経理処理は対応してなくて良い(この部分を捨てる)

こういった、ある目的を叶えるために必要な必要はこれとこれがあれば良いと絞り込むころでゴールイメージが明確になる。

チラシの裏

• 関数型プログラミング　難しい
• CORSという概念がある…