リファクタリングの定義とその誤解について
既存のシステムのインターフェースが変更されるのは、リファクタリングではなく、リアーキテクチャである。という話を耳にして、むむ、リファクタリングってインターフェース変えたらダメなんだったっけと思って、リファクタリング 第2版を再訪。
まずは定義のおさらいから。
リファクタリング(名詞)外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること
少し定義を分解してみよう。この定義にはリファクタリングの目的、事後条件、その手段が含まれている。
リファクタリングの目的は「理解や修正が簡単になる」こと
目的を達成する手段として「ソフトウェアの内部構造を変化させる」
事後条件として「外部から見たときの振る舞いを保」たれていること
なるほど、「外部から見た振る舞いを保つ」と定義にある通り、ソフトウェアの内部構造が変更されても、ユーザーから見たソフトウェアの挙動が変わらなければ良いのか。
そんなのどっちだっていいじゃんって話かもですが、こういうのが気になるのがエンジニアの性でしょう。多分ね。
このブログ書いた動機と外れるけど、せっかくリファクタリング読み直したので
雑多な読書メモ。
リファクタリングの目的
-
ソフトウェア設計の改善
-
ソフトフェアを理解しやすくする
-
バグの発見を助ける
- プログラミングを速める
- 既存のコードを資産として使えるため、開発と共に機能追加が容易になる
まとめると、、、素早く苦労せず機能追加する(雑)
コード書いてる時に、コード読みにくいな。とかこの部分がこうなら、すっと機能追加できるのにな。とかそういうちょっとした不快感を取り除いていく作業なんだ。
間違っちゃいけないのは、リファクタリングは、僕の考えた最強の設計を披露するための言い訳ではないし、エンジニアの美的感覚をお披露目する場所でもない。
リファクタリングは、プログラミングを速くして、プロダクトを市場に出して、顧客からのフィードバックをもらい、機能をさらに修正して...というフィードバックのループを早く回すXPの実践の営みの中にあって、もっぱら経営的な理由から要請されるものというのは、エンジニアが肝に銘じておかないといけないんじゃないかな。
memo: DNSを始めよう
先日AWSのRoute53で使用されているサードパーティのDNS provider で名前解決ができなくなる障害が発生した。
同一ドメインにアクセスするユーザーの中でも当該障害の影響を受けるユーザーと受けないユーザーがいたが、この原因がわからなかったのでさらっとDNSの概要を掴み直したいと思って、この本を読んだのでそのメモ。画像はこの本から利用させてもらってます。
ドメインの入手方法
[evernote:9fb4a7f65c8a1c5d170b0653724a6e3f アップロード中]
サブドメイン
Who is...?
ドメイン名を所有している組織や担当者の氏名がわかる
DNSとは
フルリゾルバ
一定期間はその結果をキャッシュする
ページが表示されるまで
ポイントは移譲とゾーン
startdns.fun(というゾーン)のことについては、 dns.onamae.comに任せる(移譲)
リソースレコード
TTL
Time to Live キャッシュの保持時間のこと
dig aaa.example.com a +short
133.242.53.94
MXレコード...メールサーバ
dig medpeer.co.jp mx +short
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
1 aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
nits
ドメイン名の大文字小文字の区別はない
プライベートIPの範囲
CS事始め。SICPを読む。
最近『計算機プログラムの構造と解釈』を読んでいる(通称「SICP」「魔術師本」)。
2年ほど前に上京してきてソフトウェアエンジニアとして仕事をしている。ソフトウェアエンジニアを名乗っているのにも関わらず、文系の大学を出ているのでコンピュータサイエンスの訓練を受けていないのはどうにもマズい。
ただ、今からコンピューターサイエンスの学士号を取るのも様々な制約から厳しいし、大学院に行って研究したいテーマがあるわけでもない。そこでマサチューセッツ工科大学(MIT)のOpen Cource Software(OCW)を使って、Computer Science and Engineering (Course 6-3)というコースを進めて行っている。