nekoTheShadow’s diary

IT業界の片隅でひっそり生きるシステムエンジニアです(´・ω・`)

結城浩『Java言語で学ぶリファクタリング入門』(ソフトバンク クリエイティブ)

Java言語で学ぶリファクタリング入門

Java言語で学ぶリファクタリング入門

免許更新の待ち時間に読みました。待ち時間が長すぎる(´・ω・`)

SIerシステムエンジニアが跳梁跋扈するような現場、要するロートルシステム開発現場だと、その重要性が受け入れられているとはまだまだ言い難いリファクタリング。現実に動いているコードに対して手を入れるということに対して強い抵抗感があるーーという比較的ポジティブな理由ならまだしも、「もとになるコードが古すぎてユニットテストが残っていない、実施していない」というようなネガティブなものだと、(´・ω・`)な気持ちが抑えきれなくなります。

リファクタリングという単語、そしてリファクタリングとは何をすることなのかということぐらいは知っていたのですが、その技法、すなわち「リファクタリングでは具体的にどのようなことをするのか」ということについては不勉強だったため、この1冊を手に取りました。本書の筆者は結城浩氏。日本のプログラマでその名を知らないものはいない、いないとしたらもぐりーーとわたしが勝手に思っている筆者の本だけに内容は期待通りでした。

どのようなコードがリファクタリングの対象であるか、そのコードがどのような問題を抱えているのか、そしてそのコードをどのようにしてリファクタリングしていくのか。そうしたリファクタリングのいろはが事細かに解説されています。またおまけとして、リファクタリングの手法一覧が掲載されており、これも役立ちそうです。問題のあるコードに出くわした時、それをリファクタリングすることが許される時に読み返したい。そんな1冊だと思います。

渡辺修司『JUnit実践入門 ~体系的に学ぶユニットテストの技法 』(技術評論社)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JavaのテスティングツールのデファクトスタンダードといえばJUniteclipseNetBeansなど、主要なIDEにはビルトインで入っているほど、影響力の強いライブラリですが、ふと自分自身を振り返ってみると、かなり漫然と使っていたことに気づき、これはいけないと慌てて購入した次第になります。

本書ではJUnitやその周辺ツールの機能が一通り解説されており、assertEqualsばかりを書いているような脳死プログラマにとってはそれだけで勉強になるのですがーーそれだけではないのが本書の良いところ。本書を読むと、JUnitというツールに関する知識はもちろんのこと、JUnitを利用するユニットテストそれ自体に関する知識を得ることができます。ユニットテストをどのように遂行すべきか、その方法論はどのようなものか、あるいはどのようにしてシステム開発ユニットテストを導入するのか、ユニットテストを用いる場合はシステム開発全体をどのようにデザインすべきかーーなどなど、ツールをうまく使うという以上のことを学ぶことができると言っては過言ではありません。

内容としてはJUnitの機能解説が多くを占めますし、ユニットテスト自体に関する知識もJavaプロジェクトの特性が暗黙の了解としてあるように感じられます。つまりユニットテストについて学びたいからといってJava以外を主言語とするプログラマが本書を取るのはちょっと違うような気がしますが、しかしJavaプログラマであれば問答無用で読むべし。そんな1冊だと思います。

青木峰郎『10年戦えるデータ分析入門: SQLを武器にデータ活用時代を生き抜く』(SBクリエイティブ)

本書のスタンスは「分析のためのSQL」。つまり主なターゲットはマーケターやアナリストであり、アプリケーション構築という観点で書かれているわけではありません。そのためプログラマやエンジニアの観点から読むと、やや退屈というか初心者向けの内容に思えるかもしれません(とりわけ前半部分)。しかしselect文すらもわからないような人たちがいるという、当たり前だが傲慢なプログラマが忘れがちなことに気づかせてくれました。

前半部分は基本的なSQLやOLAP関数の解説ですが、後半部分はデータ分析のためのシステム、つまりBIシステムに関する話に移っていきます。こちらはプログラマにも読む価値がある内容であり、とりわけデータマートをめぐる思想やSQLのみを利用したバッチ処理を解説した部分などは大変勉強になりました。

最近はデータ分析の重要性が経営層などにも浸透しつつあり、専業の分析屋さんでなくとも、データ分析に関わることがあります。プログラマであれば、BIに関わるシステムの構築が多いと思いますが、その際にデータ分析の視点を持っているか持っていないかで大きく違いが出ることはいうまでもありません。一歩先を走るプログラマになるためのとっかかりにはちょうどよい1冊だったと思います。

増田亨『現場で役立つシステム設計の原則: 変更を楽で安全にするオブジェクト指向の実践技法』(技術評論社)

勉強不足で申し訳ないのだが、本書の筆者はDDD、すなわちドメイン駆動開発の日本における第一人者であり、その観点から好意的な書評をWeb上で見かけることが多く、ついつい手に取ってしまったという次第になります。

業務のシステム化に当たって、システムエンジニアがもっとも苦労するのは、現実の業務の複雑さであり、その複雑さをシステムに落とし込む部分だとわたしは考えています。「システムに合わせて業務をデザインすべき」という意見もたまに耳にしますが、現実の業務には法律や業界慣習など、複雑さを増大させる要素が多く、業務を単純化するのは現実的に不可能であることもしばしば。

本書はその業務の複雑さをシステムに反映させるという場面において「関心」という観点を重視しています。詳しくは読んで欲しいのですが、「システム利用者の「関心」がどこにあるかを考え、それをソースコードへ写し取っていくと、そのシステムは自ずと変更可能で使いやすいものになっていく」という哲学はぜひ実践していきたいと思います。現実の業務の複雑性と日々戦っているシステムエンジニアにはおすすめ。またプログラミングレベルのTIPSも多数提示されているので、その点でも大変勉強になる1冊でした。

安岡孝一・安岡素子『キーボード配列QWERTYの謎』(NTT出版)

キーボード配列QWERTYの謎

キーボード配列QWERTYの謎

たいへん興味深く、通勤途中の電車で読み切ってしまいました。巻を措く能わずとはこのことである。

タイプライターはあまり早く打鍵すると壊れてしまうので、それを防ぐために開発されたのがQWERTY配列。つまりQWERTY配列は本来効率が悪いはずなのだが、何の因果か世界中に広まってしまった――という説はよく耳にする。わたしがこの説を知ったのは大学生だったころ、経済学入門のような講義だった。講師曰く「QWERTY配列のように効率が悪いものでも、一度広まってしまうと、歴史的な経緯などもあって簡単にやめることができない。これは近代経済学が想定する人間像、つまり人間はいつでもどこでも最も合理的な選択肢を選び続けるという像に対するクリティカルな批判になっている」。その当時は「そういうものなのか」と講義を聞いていたのだが……。

本書はタイプライターの歴史を丁寧になぞるにより、QWERTY配列非効率説が神話に過ぎないということ、そしてその説がどのように広まっていったのかを追いかけた本である。QWERTY配列がなぜ効率的ではないと考えられるようになったのか、さまざまな要因や歴史的経緯があり、その詳細を知りたい場合は本書を手に取ってほしいのだが、個人的に最も関心をもったのが「dvorak配列の創始者によるネガティブキャンペーン」。プログラマなら一度は耳にしたことがあるであろうdvorak配列。非効率なQWERTY配列に代わって、より効率的なタイピングを実現した配列といううたい文句を聞くことも多いのだが、本書によると実は因果が逆。つまりdvorak配列の創始者が自ら開発した配列を宣伝するために、かなりあやしげな根拠のもと、qwerty配列への批判を繰り返しており、それが巡り巡ってqwerty非効率説の都市伝説化に一役買ったというのが実態のようです。

IBMAT&Tのような通信業界やコンピュータ業界の雄の名前が出てきたり、テレタイプの普及機において文字コードの標準化戦争があったりと、本題以外のところ(といいつつ実は本題に大いに関係するのだが)でも面白く読める本でした。しいて難点を上げるとすれば、出版社がややマイナーなため手に入りづらいということ、そして本屋ではコンピュータ書や理工書のコーナーに置かれやすいために、本書を読むべき人に届きずらいということぐらいでしょうか(´・ω・`)

本書が中公新書あたりで売り出されていたら爆発的に売れていたような気もする(適当)。分量的にも新書ぐらいですし。

「仕事が忙しくてつらい」からはじまる、とりとめもない雑談

最近は仕事が忙しくてつらい(´・ω・`) 仕事自体もつらいが、仕事が忙しいと、仕事の外で勉強ができなくなってしまう。それがつらい。「プログラマは業務外で勉強せねばならない」という面もあるのだが、それよりも趣味=プログラミングの時間が削られてしまうのが精神的な負担である。睡眠時間を削ってプログラミングの時間にあててはいるものの、やはりそれにも限界があるし、「では転職だ」と意気込んでみても転職活動する時間がない。とりあえずこの忙しい期間はもうすぐ過ぎ去る予定だから、それまではじっと我慢である。

仕事が忙しいのは仕方がない――と百歩譲るとして、許せないのはマネージャたちがプログラマたちを尻目にさっさと退勤していくことである。そもそもプロジェクトが炎上した原因は上流側、すなわち元請のマネージャたちに責任があるにもかかわらず。もちろん残業をするしないは労働者の権利なのだが、やはり腑に落ちない。「忙しくさせてごめんな。でも俺たちはコードが書けないから、あとはまかせたで!」と一言言ってくれたなら「おたがいさまやからええんやで」と気持ちよく仕事をするのに、どうしてそういう最低限のコミュニケーションすら取ろうとしないのか。


今上陛下の退位問題が世間の話題になっているころ、Twitterを眺めていると、ソフトウェア業界のフォロワーの多くが元号廃止論をつぶやいていた。元号はかなり政治的な問題であり、元号を使う使わないはその人間の政治的立ち位置を示す。少なくとも元号の否定はすなわち左翼、それも比較的急進的な左翼であり、発言者の所属企業に右翼の街宣車が取り巻いてもおかしくないようなテーマなのだが、それをプログラマたちが簡単につぶやいているのを見て、隔世を感じたというかなんというか。とりあえずはとんでもない世界にいることは間違いないのである。

「今上」あるいは「天皇」という単語単体がすでに敬称のため、実際はどちらか一方でよいのだが、やはり「今上天皇」と書かねば落ち着かない。この辺りは左翼大学に5年間通った影響というかアレルギーというか。教授たちが左翼らしく「天皇家」と呼んでいるのを聞いて、なんとなく「皇室」と使いだしたことがきっかけだと思われる。

敬称はやはり難しい。ローマ法王は聖下、ダライラマだと猊下――とここまで大げさでなくとも、単なるビジネスメールの宛名でも悩むところではある。ビジネスメールでは宛名に企業名や部署名をを添えることが一般的だが、いつも悩ましいのは「企業名」「部署名」。まず「企業名」だが、何が正解なのかわからないということが多々ある。後株なのか前株なのか、旧字体にすべきか新字体すべきか。あるいは「通称はアルファベットだが、正式名称はアルファベットをカタカナ呼びしたもの」という場合、アルファベットにするかカタカナにすべきか――考え出すと本当にきりがない。「部署名」についてもどれだけ詳細に書くべきものなのか。「XX部XX課XXグループ」とまで書くとすこしくどいように感じられるし、とはいえ「XXグループ」だけだとそっけないような気もする。そういうどうでもいいこと、メールの本質ではないところに頭を使いたくないので、「会社名+個人名」でいいというルールを作ってほしい(´・ω・`)


最近はPython3に凝っている。「言語仕様に難がある、というより厳密さや一貫性に欠ける」と昔は思っていたのだが、書いているうちにそれが気にならなくなったというのが実際のところかもしれない。あばたもえくぼとはこのことである。

食べ物でいうとストレートの紅茶をよく飲むようになった。かくいう今も熱い紅茶をぐびぐび飲んでいる。といっても本格的に凝っているわけではなく、コンビニで売っているようなペットボトルの紅茶を飲んだり、安物のティーパックで熱い紅茶を飲んだりする程度なのだが。

山田祥寛『改訂新版JavaScript本格入門: モダンスタイルによる基礎から現場での応用まで』(技術評論社)

最近はJavaScriptを書く機会が多い――というより書かされる機会が多いのですが、はたと自分自身のスキルセットを振り返ると「JavaScriptについてきちんと学んだ機会がない」。いわゆるWeb系のプログラマならともかく、SIerだとクライアント系は軽視されがちで、Javaプログラマが本業のついでに書くこともしばしば。わたしもその風潮に甘えて、いい加減なJavaScriptプログラミングを続けて来ました……。

本書はわたしのようなプログラマにはうってつけでした。つまり「多少のプログラミング経験はあるが、JavaScriptについては初心者で、これを機にJavaScriptの正しいお作法を学びたい」。逆にいえば「そもそもプログラミング経験自体がない」というタイプの初心者には少し厳しいように思われます。そもそもプログラミング初心者にとって処女言語にJavaScriptを選択することが最適なのかどうかは議論を呼びそうなところではあるのですが……。

ともあれ体系的なJavaScriptプログラミングを学べたのはプログラマとして大きな糧になったように思います。本書を読んだだけでお金が取れる程度のJavaScriptプログラマになれるわけではありませんが、少なくともでたらめなJavaScriptプログラミングは脱却できますし、SIerの現場であればこの程度でも十分のように感じます。これでスキルセットにJavaScriptと書けるぜ(´・ω・`)