<aside> ◻️ L I F E

<aside> 📝 2022/12/25 知識系はツェッテルカステンベースで再整理中（✅  再整理完了 ‣ ）

</aside>

• 自身について
• 学び（一般）
• 学び（IT / プログラミング）
• 学び（デザイン / マーケティング）
• ライフログ </aside>

<aside> 💡 目次

</aside>

<aside> 📆 2021/01/26 書いた

</aside>

原則

• 基本的に、コードは書かない方が良い
• 機能を追加するたびにソフトウェアのエントロピーは高まる。高まりを抑えるのが設計の役割。

心構え

• いきなり機能を追加しない
  • 全体を眺めて、先にリファクタリング・テストの追加をする
• リファクタリングのタイミング
  • 二重化を発見した場合
  • 直交性の低いデザインを発見した場合
  • テストに合格したとき
• 直交性のあるデザインが良い（一方が他方に影響を与えない）
• 割れ窓を放置しない
  • 機能追加が要件だったら、機能追加をササっと終わらせて、非機能要件や、リファクタリングに注力する
  • デザインデータも同じ
• 早めのクラッシュ
  • クラッシュさせずに放っておくのは、壊れたデータが重要なデータベースに格納されるのを指を加えて見ているのと同じ

エンジニアリングとは？

• 「実現」すること
  • 抽象的なもの（たとえば要求とか）を具体化（要件定義）して、システムに落とし込むこと
  • コードを書くだけがエンジニアリングではない

関連

• ‣
• ‣