昨年の 2015年に新たに読んだ書籍群を振り返って に続き、読んでBlogに書いたものをピックアップ。 昨年と比較すると、読んだ書籍の本数は減った。これは翻訳だったり発表、OSSメンテといったことに手を出していることもあり、時間の傾け方が変わった感じ。あと、有名どころは読み終えて大体は新しい書籍中心になったからというのもありそう。ただ、Webの記事やプログラミング言語でも書籍を元にしないものをトライする量も増えてきたので、入力の量は案外どっこいどっこいなのかもしれない。 よかったものは★をつける。 programming language Erlang [Erlang]Dive into Designing for Scalability with Erlang/OTP★ Development 「レガシーソフトウェアー改善ガイド」を読んだ★ 『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ Keep Agility with Rapid Deployment★ 『チームが機能するとはどういうことか』を読んだ read “オブジェクト指向入門 第2版 原則・コンセプト”★ Software Test / Organization 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだ★ 『Mobile Testing Interview Questions & Answers』を読んだけれど、これは入り口向け 『ヒューマンエラー 完訳版』を読んだ ~ これが否応のない人生の現実である ~★ Reading “Mobile Application Penetration Testing” and dive into it…More
Category Archives: books
「レガシーソフトウェアー改善ガイド」を読んだ
レガシーソフトウェア改善ガイドを読みました。英語では “Re-Enginnering Legacy Software” なので、”改善ガイド”とするには少し内容とタイトルに乖離があるかもしれないですね。 この書籍は、最近のアーキテクチャ(モノリシック/SOA/Microservices)や言語特性の変化、CI/CD環境など含め最近の流れを踏襲した上でレガシーソフトウェアを継続してより改善できる形にするためのtipsが書かれています。そのため、開発環境/スタイル/設計などを含んだ全体的な改善の話が書かれていました。レガシーコード改善ガイドをベースとすると、テストできない、継続して機能を壊さず改善することが困難なソフトウェアがレガシーなものになります。 ソフトウェア開発においてしばしば言われるように、コードがレガシーとなる原因の多くは人に関係します。それは例えばサービス開発におけるサービスの成長フェーズに対するビジネスの要求に応えるためのものだったりとします。そのため、レガシーに見えるものも実はサービス開発を試行錯誤しながら行い、成長した結果と言える面もあるかと思います。(ここは組織の力に依存しそうですが) この書籍の中で、コード品質の指標として欠陥密度に対する言及があります。それがCoverityによる2012年のLinuxカーネルの静的解析において、コード1000行あたりの欠陥密度(defect density)が0.66/klocであるというところでした。これは純粋に興味深い内容でした。OSSとして多くの意見が入る可能性の高い成果物が、高品質なコードであると示される珍しいものではないでしょうか。そしてそれを支える為に重視しているものがコードレビュー。これにより、低品質なコードの混入を防ぐ、知識の共有とそれらのサポートといった保守も含めた知見を共有しているとあります。 開発の中では心理的な障壁は最善の仕事を効率よく行うことを妨げます。この中に”恐れ”があります。この恐れは未知なものに対峙するときに顕著になため、未知な領域(コード)に足を踏み入れながら、未知を克服していくことが必要となってきます。このような未知を克服しながら進むことを”調査的リファクタリング”(exploratory refactoring)と呼んでいました。 Exploratory Testingが探索的テストと呼ばれる一方、こちらは調査的と表現しているのですが英語をベースとするとどちらも似たようなことをしながら”中身を理解し明らかにしていく”ことを達成しようとしているのですね。 ちなみに、これらを補助するためのツールなども書かれています。 理想のシステムは、コードの品質を開発者の努力なしに自動的に監視し、その情報をチームメンバ全員が利用できるようにするもの。意識しない、努力しないというのは大事で、それが系として組み込まれている状態を指します。やはり意識によって改善するには人は確率的に誤りをおかしすぎてしまいますからね。 そういえばミカドメソッドの話が出てました。これは修正したい対象の周辺をグラフに落としていって、見通しをよくした上で優先順位を定めて取り組むというものです。言及されるとは思いませんでした。 あとはmutableなものをimmutableにしていくところも言及されていました。これは最近の関数型言語に対する風潮もありますね。これは複雑奇怪なビジネスロジックをテスト可能にし、確認可能な状態で単純化することに貢献する説明の箇所で出てきています。 当然、テストの自動化にも言及していました。単体テストを自動化することに対しては誰もが納得することだろうという前提のもと。私もここ数年でモバイルアプリの領域でやってきたことなのですが、 とくに自動化を必要とするのがUIテストの領域 と書かれています。ここがちゃんとできているところはおそらくできていないところに比べて多くの利益を享受しています。不具合の見つからないごく一部の自動化されたUIテストではなく、不具合をちゃんと見つけてくれる多数の自動化されたUIテスト。個人的に、それは特にGUIが差別的な要素になる可能性の大きな特にモバイルアプリの領域では差が出てくるところだと考えています。(ここら辺は今度機会があるのでそこで話すかもしれません) 英語ではこれらのように書かれています。 – Unit tests are not a silver bullet. – One area that cries out for automation is UI testing. (4.3.2. Regression testing without unit tests) 他に面白かったところは、Webアプリのアーキテクチャの話でモノリス/SOA/Microservicesなどを比較しているところでした。特に、組織面での利点まで言及していたところが個人的には好印象でした。アーキテクチャはやはり組織に影響を及ぼしあうので。その中で、やはり情報伝達はモノリスがオーバーヘッドが小さく、個々の独立性が高まると従来の情報伝達はオーバーヘッドが大きくなるところが印象的。(いっていること自体は至極真っ当) まとめ 主な対象はWebサーバアプリでしたが、これはモバイルアプリにも多く転用できるものでした。実際、私がモバイルの領域でやっていたものはこの書籍における改善案の方針として言及されているものが多かったです。 refactoring/rewriteしながら継続して価値を出しているサービスをより継続して開発し続けることができるように取り組んでいきたいですね。More
Read “言語変化という問題――共時態、通時態、歴史”
言語変化という問題――共時態、通時態、歴史を読んだ。 これは教授がおすすめしていいて、言語変化をソフトウェア開発の変化に置き換えた時に良い示唆を与えてくれると仰っていたためです。なので、読んでみようかなと。 言語はなぜ変化するのかという問い自体、言語には本来そなわった安定性があるのに、生成発展がそれを乱し、破壊すらしてしまうのだと言いたげである。 > p19 言語が変化することをおかしい、というのであれば、言語は変化しない絶対的なものである必要がある。という仮定を幾つかの視点から紐解いていくことから始まります。例えば、機能的に言語を理解するのであれば、言語は体系であるから機能する、ではなく、機能を遂行するためにある目的に応じるために体系をなしているとみなすことができる、というような紐解きです。 言語の比較により、ある言語がそれとは別の言語に対して云々と言えるようなことも、自身がほかの言語に対して知ることにより産まれる疑惑です。そのため、例えばフランス人はロシア語を知っててもない限り、自分が別の仕方で考えることができるとは思いもかけない、という状態になります。 ソフトウェア開発においても、おかなくても大体同じだと思うのですが、自分の外側を知らないと井戸の中の蛙のような状態になりますし、それより良い/悪いと比較することもできない、ということですね。言語学でもそういう分析がされていたとは。 その中で、言語に対して通時態と共時態に関して分析した内容がありました。これはソシュールが使った考え方で、時間という概念を元に言語を分析した区分になります。 通時態(diachrony, diachronic: 通時的)とは、時間の流れに沿って変化していく言語の側面を言います。共時態(synchrony, synchronic: 共時的)とは、常に変化している時間の流れの一時点を抜き出してみた側面を言います。つまり、微分が共時態、積分が通時態のようなものですね。言語学には、これらを元に時の変化に伴う言語の変化を研究する通時態の学問、時間を軸に特定の言語の構造や体型を研究する共時態の学問が存在する、と。 また、記述されたものも同じ。記述された内容は、そのある時点での内容なので、連続した事象のある時点でのことでる、ということを忘れてはいけないですね。書籍に書かれたものや、資料に書かれたものは今でも有効なのか、変化しているのか、とかとか。そういうところはとても注意が必要な概念。 言語学は法則科学になる必要はない。それは対象の本性がそうなることを禁じているから法則科学になることができない。人間諸科学は物理的諸科学に比べてある種の厳密さ以上の厳密さに憧れてない。 > P、343より こう考えると、ソフトウェア開発のWFやAgileの話と似通っているところがありますね。また、それらをまとめた書籍もしかり。そして、品質というものを考えた時、従来のものは共時的品質(synchronic quality)、時間経過による変化を前提とした品質を通時的品質(diachronic quality)と呼ぶ、のも面白そうです。 詳しく内容を理解するには言語学に対する専門性が足りなくて難しい(覚えないことが多い)ので流し読みに徹したところもありますが、全体的に言語の流れは様々な変化に対する話にとって参考になる面が多そうです。 頭を使った…More
read “子どものUXデザイン”
子供のUXデザインを読みました。 これは人の認知の発達をもとに、子供を2~4歳、4~6歳、6~8歳、8~10歳、10~12歳と2歳ごとに区切りそれぞれの間で何を目指す必要があるのか、というものをモバイルアプリを使いながらまとめたものでした。年齢によって、どういう感覚が形成されていくのか、というところからどういうアプリにしたら良いのか、すべきなのかを例を交えながら書いています。 例えば、ユーザをどうコントロールしていくか、選択肢をあたえるべきかどうか、単純さをどこまで落とし込むか、コンテンツの階層はどこまで深くできるか、デザインパターンが使えるのはどこからか、ということです。 この書籍では入りとしてジャン・ピアジェによる認知能力の発達段階に言及しています。彼の理論では、シェマ、同化、調節、均衡化の4つが中核概念となるそうです。 それが、 感覚で運動する段階である誕生~2歳 前操作段階になる2~6歳 具体的操作段階になる7~11歳 形式的操作段階になる12歳~成人 と段階を経て、認知の段階が分けられていきます。 子供の認知の発達に注目してまとめられたUXに対する話はなかなか見ないので、とても興味深く読むことができました。 サービスを開発するという点だけでなく、子供と接する上でもどういうことが発達段階なのかを知っていると、より面白く接することができそうですね。More
read “オブジェクト指向入門 第2版 原則・コンセプト”
積読になってた オブジェクト指向入門 第2版 原則・コンセプト を、少しきっかけがあって主に11章付近の契約による設計付近を読みました。 行っていただいてます :bow: https://t.co/747YvMJo4a — KazuCocoa (@Kazu_cocoa) September 1, 2016 内容自体は、ある社内勉強会で得たこと中心でしたが、幾つか自分のためにメモ。 ホアトリプル(Hoare triple)による正しさの公式 {P} A {Q} P: 事前状態、A: 処理、Q: 事後状態 防御的プログラミングと、契約によるプログラミングの違い 前者は、他を信頼しないことを前提に入力値などを検査していく 後者は、契約により表明されたことを信頼し、過剰な防御は行わない。 冗長な検査は、ハードウェアは経年劣化などがあって時間によって変動があったり、例えば電気的な干渉などがある。そのため、電気的なシグナルの送り手と受け手の両方で整合性の検査を行うことはよくある方法。ソフトウェアは、何も経年劣化するようなことはないし、電気的な関与を受けるといったこともない。例えば sqrt(a) というメソッドを一度ちゃんと実装すると、それが1年後に挙動が突如変わる、ということはない。(実行環境の変化やシステムが更新されるとか、そういう外的な変化はないものとする) こう見ると、ハードウェアは過剰な防御をしているようで、実は冗長検査と言いつつも、特別・補足的な確認として利用されていることになる。 require/ensureによる事前/事後の表明 これは表明のサンプル 表明するモチベーション 正しいソフトウェアを書くのを助けるため 文書支援のため テスト、デバッグ、品質保証をサポートするため ソフトウェアの耐障害性(fault tolerance)をサポートする 最後に ここら辺を学んでいると、Elixir/Erlangをやっていると、関数に対するマターンマッチや when によるguard clauseを思い浮かべました。Swiftでは where みたいなやつですね。 でも、この青い辞書はとても厚い…More
read “The Way of the Web Tester”
The Way of the Web Tester を読んでみました。 私が読んだ時は、まだBeta3でした。最近、Beta4が出て、JSによるテストコードの話が追加されている状態でした。 この書籍は、自動化されたテストを書くための、テストエンジニア向けの入門書という感じです。内容はいかが大まかなところです。 Unit/Integration/UIのテストピラミッドの話 Unit/Integration/UIのテストコードの書き方(Rubyを例に) コラムとして、例えばrecord/playbackの使えないところ、など 全般的にWebだけの言及なので、モバイルに関しては対象外でした。Selenium系の書籍のようにツールに特筆してはいないので、そういう意味では確かに全般的な入門書という感じです。 ただ、コードの書き方などの話になるとリーダブルコードの内容や実装に近いところの話が含まれてきていたので、そこらへんの実装よりを詳しく学びたいとなったら何かWebフレームワークを使った実装とそのテストコードを書く、というところを開発者向けのなんらかの書籍など見て行う方が良いかもしれないです。 ある程度、書籍などで学んでいたり実装を経験した人からすると確かに入門的なものなのでザーッと読み飛ばしながらコラム中心に読んで終わり、となりそうです。More
reading “Advanced Software Testing – Vol. 3”
ISTQBのTTA(Technical Test Analyst)がどのようなことを学んでいるのか、を知るために読んでみました。 Advanced Software Testing – Vol. 3, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst ざっというと、様々なソフトウェアに関するメトリスクやその計測方法、カバレッジの話、さらにはテスト自動化に関する話までありました。 内容として、これはゆるSoftware Engineer in Testと呼ばれるような位置の人は頭に入れておくべき事柄、という感じでしょうか。 data driven や keyword driven なテストコードの話とか、静的/動的テストの分け方やその詳細への落とし込み、様々なコードカバレッジの定義やその役割など。 中でも、コードカバレッジをはじめとした様々なカバレッジ(それこそ、変更量とか含む)の厚みはすごくページを割いていて、その計算(アルゴリズム)の理解までこの書籍でできる感じです。 ただ、これだけできても十分ではなく、ここと実際の経験(開発など)が合わさって相乗効果を発揮する、という感じでしょうか。 効率性のテストの中で、以下のように数多くの xx testingという呼び名があったことは今回初めて気付きました… Load Testing Stress Testing Scalability Testing Resource utilization Testing Endurance or soak Testing Spike Testing Reliability…More
read 「料理のアイデアと考え方」
料理のアイデアと考え方 -9人の日本料理人、12の野菜の使い方を議論する- を読んだ。 日本料理を専門とする料理人が、どのような考えで、何を狙って、技術/表現を使ってデザインして料理を造るという一連の流れを知ることができました。やっぱり、ソフトウェア開発など含め、達成したい意図を落とし込む、というところは同じものがありますね。 面白かったのは、この中で各々の対談の記録を形態素解析などの分析にかけてどういうものが日本料理として大事にされているのか、という思考パターンの分析などもしていたところです。世界の地域ごとの料理で何が大事にされているのかなとが分析、可視化されて面白かった。 書籍では幾つかの食材をピックアップしていたのですが、ナス、トマトのところで取り上げられていた料理たちが個人的には美味しそうだった。ので今度作ってみよう。More
ビジョナリーカンパニー(1)を読んだ
ビジョナリー・カンパニー ― 時代を超える生存の原則を読みました。 セールで半額だったので。 心構えが書かれていた感じですね。 いろいろと、開発の時にも大事なことが書かれていたり、身近な人と重なる考え方が多くありました。 なるほど。 第2巻も読む予定。More
Reading “Software Testing: Essential Skills for First Time Testers: Software Quality Assurance:From scratch to end”
Software Testing: Essential Skills for First Time Testers: Software Quality Assurance:From scratch to end (English Edition) を読みました。 job descriptionとか、その必要とされるスキルセットに関して情報を集めたかったので。 この書籍は、まだSoftware Qualityに関して知見の少ない人を対象に、全体像を提供したり、より詳しく調べるならここ見てねという簡易ポインタを提供するものでした。”品質の高いソフトウェア = バグゼロ”だけではないことや、バグを作るこむことを防いでいくことが必要、というようなことが入りです。そこから、最後にはインタビュー形式でのキャリアを歩んでいる人の事例紹介まで乗ってました。 続けてよくある不具合のつくり込みとして以下が挙げられていましたが、その通りですね。よく言われ続けていること。 要件/要求定義 不十分な設計文書 プログラミング知見の不足 コミュニケーション不足 時間のプレシャー この他に、ソフトウェアテストのライフサイクルなど。全体的な話もまとめてされています。 テストだけではなく、品質を上げるために必要な開発体制に関しても言及されていました。反例としてビッグバンモデルの開発体制から、アジャイルな体制などの開発体制に関する内容まで。 私が求めていたようなjob descriptionレベルの新たな発見はなかったです。が、頭の中を軽く整理したりしたい人には良いものな感じです、短いのでさらっと読めますし。More