プログラミングの構造化とデザイン

N予備校のプロフェッショナルプログラミング講義の受講メモ

ジュニアクラスとプロの違い

ジュニア

どうやればプログラムが動くかを考えるので精一杯

プロ

動くプログラムを作るのはあたりまえ

書く時間より読む時間の方が長い

人が書いたプログラムを修正したり書き足したりが多い

なぜCiが必要か？

CI: Continuous Integration(継続的インテグレーション

エラーを小さい単位で発見できる

自動でテストしてくれる

例えば...

1. GitHubにPRを作成

2. CIによる自動テスト

×の場合デバッグ

○の場合マージ

開発者が余計なことを気にしないで開発に専念できる

ソフトウェア

ぱっと作ってリリースして終わりではない

一度作り上げてからの方が長い

Webサービスは進化していく

0→1開発時の開発者が抜けることは必然

一々質問できない

後の開発が複雑化しないためにデザインや設計が大事になってくる

保守しやすさを向上する考え方

他人が見たときに意図を理解できるプログラムを心がけること

時代の流れとともに変わっていく

「銀の弾丸はない」

プログラミングインターフェース（関数やオブジェクトのインターフェース）が、使う側から見て理解しやすいこと

呼んだときにどう動くかが、名前、引数、で理解できること

プレゼンテーションとドメインの分離

プレゼンテーション: 見た目

ブラウザ上でのUI

WebAPI

CLI

ドメイン: 見た目以外の、処理の中核

table: idiom,design_paterb,arcitecher

粒度

大 アーキテクチャパターン レイヤー化、MVC、パイプ&フィルター

中 デザインパターン GoFパターン(Iterator,Flyweight)

小 イディオム クラスより小粒度のコーディングパターン

インターフェース

オブジェクトやメソッドやAPIを使う側からの視点

製品一覧を取得できるよ

Tell, Don't Ask(求めるな、命じよ)

例: 消費税の計算

const tax = prodact.tax();

const tax = product.price * 1.08;

使う側からしたら上の方が親切

* 1.08 という処理を他の場所でも書く必要がなくなる

インターフェースから考える！

大事なものと大事じゃないものの間に境界を儲ける

大事: ドメイン

プレゼンテーションとドメインの間 / ドメインをデータアクセスの間

副作用があるもの / ないもの

境界間の依存関係をクリアにする

大事なもの(ドメイン)が大事でないもの(プレゼンテーション、データアクセス)に依存してはいけない

大事でないものの変化が大事なものに影響を与えてはいけない

壊れにくいもの・壊れてはいけないものが、壊れやすい / 変化し愛やすいものに依存してはいけない

データアクセス層

ドメインから依存してはいけない

CSVファイルからデータを受け取るかDBからデータを受け取るかなどあるが、そこの方法を変えてもドメイン層に影響がないように作る

データアクセスは冪等ではない(DBへのアクセス失敗などエラー)ので、ドメインから分離して作る