昨日のことと今日のこと

技術書の感想や勉強ノートみたいなノリです

わけわからんコードにはとりあえず影響スケッチ。

影響スケッチとは?

レガシーコード改善ガイドに掲載されている、影響を把握するための方法です。

影響はどのように伝搬するか

影響は

  1. 呼び出し側によって使われる戻り値
  2. パラメータとして渡されるオブジェクトの変更
  3. グローバルスコープのデータの変更

によって伝搬します。

影響スケッチの書き方

ただ影響の伝搬を線で結ぶだけです。変数だけでなく、メソッドも結びます。

例:直したメソッドがグローバル変数を書き換えていた→そのグローバル変数を参照している箇所には全て修正の影響が伝搬してしまっている(涙)*1*2

レガシーコード改善ガイドの例では変数もメソッドも同じように丸で囲っていてわかりにくかったので、メソッドは()をつけるなどの工夫が必要でしょう。*3

影響スケッチは何に役立つのか。

1.テスト箇所の把握

まだテストコードが十分に整備されていない時は、変更を入れたコード以外にどこまでテストコードを準備する必要があるのか、という把握のために使える。

2.リファクタリング

本書の中の例では、変数の取得方法をgetterメソッドに統一することで影響の重複を排除していた。*4

感想

なぜ影響スケッチが必要になるかというと、そもそも変数に必要以上に広いスコープや可変性を持たせているからであって、 きちんと構造を持っているコードなら影響スケッチはシンプルになるし、そもそも影響スケッチを書くまでもないかもしれない。

レガシーコード改善ガイドは自動テストが導入されていることを前提に話を進めているので、そういう現場で働いていないと役立たないかもしれない。 でも調査や分析のためのテクニック、精神論などはテストを自動化していなくても役に立つと思う

今回紹介した影響スケッチもそんな役立つ技術の一つだと思う。

参考:レガシーコード改善ガイド第11章 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか?

*1:図は書くのがめんどくさいのでなんとなくイメージしてください。。。

*2:スコープの広い変数に影響与えたあとにはきちんと調査してください

*3:別にこの本にケチを付けているわけじゃないよ。アメリカ人は変数は名詞、メソッドは動詞みたいなことをちゃんと徹底できるから別に俺が書いてる工夫なんてしなくて良いんだよ。ブツブツ…

*4:参考:11.6影響スケッチの単純化

テスターのジレンマ

コーダーとテスターを兼任するというやり方には問題があると思う。 見つけた人が直すルールになっていれば、 修正が面倒くさいから、わざわざ頑張って見つけようとは思わないし、 自分で直さないにしても、レポートを書いたり、 修正担当者にわかるようバグの詳細や再現方法をまとめないといけない。

コーダーにとってテスターは仕事やす厄介な存在だ。 そのテスターをコーダーが兼任すると何が起こるのか、火を見るよりも明らかだ。

バグを見逃しても、商用で再現されなければ問題ないし、 見逃したバグが見つかっても特段責められるわけでもない。 バグを見つけたらからと言っても特に何も褒められないし、評価もされない。

むしろ過剰なバグ探索はチーム全体の進捗を落とすし、 信頼度成長曲線を書いていれば、 顧客や上司に見せる可視化された品質は発見されたバグによって汚される。*1

バグを見つけると、色々時間がかかる作業が発生するし、 自分のノルマもあるから、バグっぽいものがあっても深い負いせずに 放置する。

こうしてバグだらけのソフトウェアが出荷される。

テスターとコーダーをうまく三権分立っぽく、利害関係を分離できればいいのだが。

知識ゼロから学ぶソフトウェアテスト

*1:まぁこんな考え方が本末転倒なんだけどね

Effective Java 3rd予約開始!

日本語版翻訳者の柴田さんのブログで知りました。

yshibata.blog.so-net.ne.jp

アマゾンの紹介を見る限り7~9も扱うらしい。*1 2ndはjava 6までの内容だったので少し古い感じがあった。

https://www.amazon.co.jp/Effective-Java-3rd-Joshua-Bloch/dp/0134685997

今から英語鍛えようかな

*1:なんでリリースしてない9が書けるんだろう?

仕様化テストについて

仕様化テストとは何か

コードから起こした仕様を検証するテストのこと。 大事なのは理想的な仕様を追い求めるのではなく、「現在のコードはこのように動いている」点を明らかにすること。

何のために行うか

機能追加の際に、理想的なテストを書いてしまうと、既存バグが発見され、そちらの対応に追われるかもしれない。 バグ修正よりも現在の変更作業を優先するために、一旦既存バグを含めた現在の挙動を保護するテストを作成する。*1

トレードオフ

機能追加 vs 品質

既存バグを直さずにシステムに機能追加が出来るというメリットがあるが、システム自体の品質は良くなっていないし、 作成した仕様化テストも最終的には理想的な仕様をブラックボックステストで網羅できるようなテストコードで置き換えられる必要がある。

ほぼ全てのレガシーシステムでは、「システムがどのようにうごくべきか」よりも、「実際にどのように動いているか」のほうが重要です。*2

仕様化テストはレガシーコードに対処し始めた初期段階のプロセスといえるかもしれない。

*1:もちろんこれはゴールではない。既存バグの修正よりも、機能追加を優先したというだけであり、既存バグは別に対処しなければならない。

*2:レガシーコード改善ガイド13.1仕様化テスト

SSIDのANY接続拒否(ステルスモード)はセキュリティ強度を下げる?

長らく、自宅のWifiをステルスモードにして使っていたが、2〜3年前からiPhoneが自動接続しなくなった。手動で接続すればつながるのだが、毎度ルーターSSIDとパスワードを入れるのは面倒だ。だがなぜか、パスワード無しで接続→失敗→数秒後接続される、という方法で繋げていたので、パスワード無し接続でしのいでいた。

流石に毎度手動設定は面倒で、たまにwifiにつなぎ忘れて通信料の多いアクセス等をしてしまうので、なんとかならないのか?と調べてみたら、どうやらAppleはアクセスポイントのステルスモードを推奨していないようだ。

https://discussionsjapan.apple.com/thread/10177615?start=0&tstart=0

また詳しそうなサイトの解説を見る限り

https://the01.jp/p000137/

以下のような理由から推奨していないと勝手に推測してみる

自動接続設定時の電力消費

any接続許可(非ステルスモード)の場合、ビーコン信号はアクセスポイント側が発信する。 any接続非許可(ステルスモード)の場合はクライアント側が定期的にアクセスポイントを探すパケットを周囲にブロードキャストする。非接続状態の場合、クライアント側が無駄にアクセスポイントを探し続けてしまい、無駄な電力消費となってしまう。

自動接続設定時のセキュリティ

ステルスモードのアクセスポイントに対して自動接続を設定している場合、非接続状態のクライントは周囲にアクセスポイントを探すパケットを投げ続ける。偽のアクセスポイントを立てて、クライアント側の接続要求のパケットを受信すれば、WEPでなくても容易にパスワードが解析できる

他情報

手元にある2016年情報セキュリティスペシャリストの対策本に関連する記載がある。

端末側にSSIDを設定していなくても(ANYと設定していると)接続が出来てしまいます。こちらもセキュリティ確保の観点から考えればANY接続を拒否する設定(ANYプローブ応答の禁止設定)にすべきでしょう。なお、こうした隠蔽を実施したとしてもSSIDは平文でやり取りされます。したがって、その通信を傍受されると、すぐに判明してしまうので、セキュリティ対策にはなりません。

推奨しているのかしていないのか、イマイチわからない。

接続が出来てしまいます。

この一文の意味がわからない

レガシーの意味とは?

レガシーという言葉の意味について、改めて確認しよう。

遺産のこと

いい意味でのレガシーはこれのみである。

東京2020レガシー 未来に何を残すのか byNHKスペシャル

オリンピックの勢いで出来たインフラや設備は、一般的にレガシーというらしい。

時代遅れのも

古いコンピューター、ガジェット等を指す。 あまりにも技術パラダイムが古いソフトウェア、ハードウェアもここに含まれる。

古い実装のこと

廃れてしまったが後方互換のために残しているAPI等のこと。 一般的に新規に何かを作る場合、代替するベターなAPIを使うべき。

Vector - 「レガシーメソッド」を持つ List インタフェースの、同期化され、サイズ変更可能な配列実装 by Collections Framework の概要の注釈

近い将来削除予定であり、非推奨のものも含まれる

テストのないコードのこと

テストがないコードはレガシーコードだ byレガシーコード改善ガイド 冒頭

広く知られた一文だが、実は煽り文句であり、本中で語られている意味とは少し違う。

正しく保守することが困難なシステムのこと

レガシーコード改善ガイドで語られているレガシーはこの意味になる。

  • 密結合な設計になっており、変更の影響が計り知れない
  • テストに非常に時間がかかり、コード修正のフィードバックが遅い

等。 前者はリファクタリングで、後者はテストの自動化で解決する。*1

*1:たとえリファクタリングが許されていなくても、どのように責務が混ざっているか、という視点でコードを読む必要はあるし、テストの自動化を実施していなくても、変更を高速に検証する方法を工夫することは大切だと思う。

strategic choice閉鎖か?

http://d.hatena.ne.jp/asakichy/

昔からよく見ていたサイトですが、非公開設定になってしまっている。書籍化した影響なのかどうかは分からないが、readable codeもeffective javaもこのサイトがきっかけで読んだので閉鎖だと寂しい。