仕様化テストについて
仕様化テストとは何か
コードから起こした仕様を検証するテストのこと。 大事なのは理想的な仕様を追い求めるのではなく、「現在のコードはこのように動いている」点を明らかにすること。
何のために行うか
機能追加の際に、理想的なテストを書いてしまうと、既存バグが発見され、そちらの対応に追われるかもしれない。 バグ修正よりも現在の変更作業を優先するために、一旦既存バグを含めた現在の挙動を保護するテストを作成する。*1
トレードオフ
機能追加 vs 品質
既存バグを直さずにシステムに機能追加が出来るというメリットがあるが、システム自体の品質は良くなっていないし、 作成した仕様化テストも最終的には理想的な仕様をブラックボックステストで網羅できるようなテストコードで置き換えられる必要がある。
ほぼ全てのレガシーシステムでは、「システムがどのようにうごくべきか」よりも、「実際にどのように動いているか」のほうが重要です。*2
仕様化テストはレガシーコードに対処し始めた初期段階のプロセスといえるかもしれない。
SSIDのANY接続拒否(ステルスモード)はセキュリティ強度を下げる？
長らく、自宅のWifiをステルスモードにして使っていたが、2〜3年前からiPhoneが自動接続しなくなった。手動で接続すればつながるのだが、毎度ルーターのSSIDとパスワードを入れるのは面倒だ。だがなぜか、パスワード無しで接続→失敗→数秒後接続される、という方法で繋げていたので、パスワード無し接続でしのいでいた。
流石に毎度手動設定は面倒で、たまにwifiにつなぎ忘れて通信料の多いアクセス等をしてしまうので、なんとかならないのか？と調べてみたら、どうやらAppleはアクセスポイントのステルスモードを推奨していないようだ。
https://discussionsjapan.apple.com/thread/10177615?start=0&tstart=0
また詳しそうなサイトの解説を見る限り
以下のような理由から推奨していないと勝手に推測してみる
自動接続設定時の電力消費
any接続許可(非ステルスモード)の場合、ビーコン信号はアクセスポイント側が発信する。 any接続非許可(ステルスモード)の場合はクライアント側が定期的にアクセスポイントを探すパケットを周囲にブロードキャストする。非接続状態の場合、クライアント側が無駄にアクセスポイントを探し続けてしまい、無駄な電力消費となってしまう。
自動接続設定時のセキュリティ
ステルスモードのアクセスポイントに対して自動接続を設定している場合、非接続状態のクライントは周囲にアクセスポイントを探すパケットを投げ続ける。偽のアクセスポイントを立てて、クライアント側の接続要求のパケットを受信すれば、WEPでなくても容易にパスワードが解析できる
他情報
手元にある2016年情報セキュリティスペシャリストの対策本に関連する記載がある。
端末側にSSIDを設定していなくても(ANYと設定していると)接続が出来てしまいます。こちらもセキュリティ確保の観点から考えればANY接続を拒否する設定(ANYプローブ応答の禁止設定)にすべきでしょう。なお、こうした隠蔽を実施したとしてもSSIDは平文でやり取りされます。したがって、その通信を傍受されると、すぐに判明してしまうので、セキュリティ対策にはなりません。
推奨しているのかしていないのか、イマイチわからない。
接続が出来てしまいます。
この一文の意味がわからない
strategic choice閉鎖か？
http://d.hatena.ne.jp/asakichy/
昔からよく見ていたサイトですが、非公開設定になってしまっている。書籍化した影響なのかどうかは分からないが、readable codeもeffective javaもこのサイトがきっかけで読んだので閉鎖だと寂しい。
野菜が何故か辛いことがある
昔はキャベツをよく食べていたが、たまにメチャクチャ辛いキャベツ、というのがある。 唐辛子ほどではないけど、普通に苦しいくらいに辛い。
最近辛い小松菜に当たってしまった。
何かの残留農薬なのか、それとも害虫などが毒を植え付けたのか。 はたまた放射能の影響か、私の命を狙う秘密組織の陰謀か。
妄想はさらなる妄想を掻き立てた。 怖くなったので調べてみた。
イソチアシアネートという辛味成分が生産時期によっては含まれるらしい。
なんとこのイソチアシアネート(変換できねーぞコラ) 強力な強酸化作用があるので、がん予防に効果的なんだとか。
とりあえず水溶性らしいので、水につけて様子を見てみたところ、辛味はほとんどなくなった。*1
からい野菜に遭遇したらお試しあれ。
*1:がん予防とはなんだったのか。
誰もズルしないことの重要性
「君の名は」のインタビューの記事です*1
ズルという言葉の意味ですが、一般的な意味よりとても厳しいです。 盗作を納品するとかそういう意味ではなく、真剣に作品と向かってない、くらいの意味で語られています。
今までのルーチンでやって、そこそこのパフォーマンスを発揮して仕事を終えるということを一人もしなかったんです。
ここに「ズルをしない」という言葉の意味が集約されています。
レガシーと関わると自分のせいじゃないからとどうしても考えがちですが ただ個々の責任範囲に忠実に作業してるだけじゃダメですね
もっとドメインやユーザーと向き合って 本当にあるべき姿を探る姿勢を持たないといけません
真剣にモノづくりに取り組んで「君の名は」みたいなシステムを作りたいですね。*2
時間がないときの機能追加(スプラウト/ラップ)
時間がないときは既存のソースにリファクタリングを行わずに機能追加をする。
その時に以下の二点を気をつける
- 既存ソースにテストを書けなくても新しいコードにはテストを書く
- 既存のソースの変更は最小限にとどめる
後述の方法で実現する
スプラウトメソッド
変更箇所を丸々メソッドとして作成し、既存箇所からはメソッド呼び出しのみにし、 既存箇所に入れる変更を最小にする。
テストコードのない既存箇所にロジックを入れてしまうと、変更箇所のテストが難しい。 ひとまず新しく作る箇所だけはテストで保護する。
これ以上レガシーコード(=テストのないコード)を増やさない工夫ともいえる。
ラップメソッド
変更箇所の前後に処理を入れないといけない場合、 新規のメソッドで既存処理をラップし、新規のメソッド内、かつ既存のメソッド外に処理を書く。 既存の処理の中身は極力触らない。
臭いものには蓋、という工夫ともいえる。
スプラウトクラス/ラップクラス
メソッドでやったことを同じようにクラスでも行う。
- スプラウトクラス:変更箇所を新規クラスとして用意し、既存クラスからは呼び出し箇所だけを変更することにより、変更箇所を最小にする。
- ラップクラス:既存のクラスを拡張したサブクラス上スーパークラスのインスタンスをもたせた上で新規処理を書く
ちなみにラップクラスはデザインパターンのDecoreterと同一である。
デメリット
両者とも自体を悪化させることはなくても 既存コードの質は一切よくならない。 今は時間がないから仕方ないのだろうが、 既存コードのリファクタリングはどこかで時間を用意して計画的にやるべきだ。
所感
これ以上悪くしない。少しでも前進する
〜メソッドの方は普通にプログラミングをやっていれば思いつくと思う。(同じようなソースを何度か実装したことがある) クラスの方は微妙。私にオブジェクト指向のセンスがないのかもしれない。 デザインパターンだけではなく、リファクタリングパターン的なものを極める世界もありそうだ。
接合部と許容点
接合部
接合部(seam)とは、その場所を直接編集しなくても、プログラムの振る舞いを買えることのできる場所である。
許容点
どの接合部も許容点(enabling point)を持つ。許容店では、どの振る舞いを使うかを決定できる
プリプロセッサ接合部
プロプロセッサ指令をサポートしている言語では コンパイル時にプログラムの振舞を買えることが出来る。
例:includeしたファイルの先のプリプロセッサ指令の中で、プログラム中の処理を再定義する
この場合、接合部はincludeしたファイルの中身になる。
リンク接合部
コンパイラが出力した中間表現の参照関係を変える。 Javaの場合、CLASSPATH環境変数を使ってリンカがクラスを探す場所をスタブ関数を持つライブラリ等に変える
オブジェクト接合部
オブジェクト指向を駆使して振る舞いを変える。
例:インスタンスメソッドの振る舞いを買えたい。 →インスタンスの型を抽象化し(interfaceを利用)引数等で外部から具象クラスを与えるようにする。
この場合、接合部は具象クラスを受け取る引数になる。
※他にもサブクラスで振る舞いを変える方法などもある。
注意事項
プロプロセッサ接合部とリンク接合部は強力だが保守が困難。 できるだけオブジェクト接合部を使う前提で考えたい。
参考:例レガシーコード改善ガイド第4章
