「リファクタリング 既存のコードを安全に改善する」を読んだ

リファクタリングについては Java言語で学ぶリファクタリング入門 を必要な時に必要なとこだけパラパラと読んだだけ、という感じだったのだけど、ふと、ちゃんと一冊何か読みたいなと思っていたので読んだ。選んだ理由は特になくて、前から知っていたというのと、借りられる状態だったのでちょうど良さそう、みたいな結構軽い気持ちで読み始めた。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

第1章~第4章

この本には、まず「リファクタリングとは何か」とか「いつ、なぜリファクタリングをするのか」みたいなことが書かれている。特に第三章の「コードの不吉な臭い」という章は導入部としては一番重要な章で、「どういうコードを見たらリファクタリングしないといけないか」ということを「不吉な臭い」という表現で表していて、具体的にどういう臭いがあるかがパターンに分けられてそれぞれ名前が付けられている。名前が付いてるのはとても良くて、「ああこういう時はマズイんだな」というのが雰囲気で伝わってくる。 わかりにくいやつもあって、例えば「特性の横恋慕」みたいなのはそのワードを見ただけでは正直よくわからない。そういうのにも「どういうコードか」ということと「こうやって直していくとよい」という方針がその後のページのリファクタリングカタログへのポインタと共に書かれているのできちんと理解できるようになっている。

第5章~第12章

第5章からはしばらく「リファクタリング・カタログ」が続く。リファクタリング・カタログというだけあって、リファクタリングの内容にそれぞれ名前がついている。各項目は決まったフォーマットで書かれていて、そこだけ開いて読んでもわかるようになっている。サンプルコードはJavaではあるのだけど、作業手順が丁寧に書かれていてわかりやすい。サンプルコードはJavaだけど、他の言語にもそんなに難しくなく応用できると思う（もちろん個々の事情の違いはあるとは思うけど）。

第13章~第15章

残りの章は著者であるMartin Fowler以外の寄稿となっている。実際にリファクタリングを伝えて行こうとした話や、リファクタリングをする時に考える必要があることとかが書かれている。この部分は実例に沿って書かれている部分が多いため、自分で実際にリファクタリングを進めようとする時に参考になると思う。とはいえこれを書いている時点でこの実例に沿うような事態になっていないので推測だけど。 第15章の「部品から全体へ」にはリファクタリングを進めることだけではなく、リファクタリングを進めずに戻ることについても触れられている。リファクタリングをやめることについても書かれている。ちょっと感情寄りな話が多いような気もするけど、書かれていることについては意識しておいたほうがよさそうだな、と思う。

全体を通して

「はじめに」にこの本をどうやって読んだらいいか、というのが書かれていたけど、僕は一旦全体をざっと読んだ。「コードの臭い」や「リファクタリング・カタログ」の部分についても、まず読まないと後で参照できなくなると考えたのでまず通して読むようにした。 コードの臭いに書かれた部分やリファクタリング・カタログについては、例えば「長すぎるパラメータリスト」は結構意識しているし、「メソッドの抽出」とか「条件記述の単純化」についても意識している。なので実際にリファクタリングする時だけじゃなくて、最初からコードを書くような場合についても役立つ考え方だと思う。

簡単な修正に関してはそんなに難しくないのだろうけど、少し大きめのリファクタリングをする時にはある程度設計の知識も必要になると思う。例えば「巨大なクラス」みたいに、「これはちょっと大きくなりすぎているな」という時に後のことを考えつつ分解していくのは、当然ではあるけどリファクタリングの知識だけだと難しい。何の知識もないまま分解すると結局よくわからないものが出来上がりそう。

リファクタリングに慣れるためには、既存のコードを少しづつ修正していくというやり方しか無いと思う。最初に書いたコードが最高な状態になっていることはほとんど無くて、少しづつの修正を繰り返して洗練していく必要がある。仮に最初から最高の状態だったとしても、コード外の環境の変化（仕様変更とか最初の想定からのズレとか）によって最高の状態でなくなることがあるので、 リファクタリングに関する勉強をしておくのは良いことだと思う。 リファクタリング作業を進める時に、カタログを何度も参照することになりそう。何度も読んだほうがよさそうな本だと思うし、合わせて設計の勉強もしないと、この本に書かれている内容を完全に実践することはできないと思う。設計の勉強も進めていきたい。

京都に引っ越して3ヶ月が過ぎた

東京から京都に引っ越してきて3ヶ月が経った。

引っ越した当初は「1ヶ月くらいしたら街にも慣れてくるはずだしブログでも書くか」とか思ってたんだけど、 2月とか3月とかとにかくいろんなことがあって、最近ようやく落ち着いてきたというか慣れてきたというかそういう感覚になっている。

そんな感じなので、京都に引っ越してどこに行ったの？とか美味しいお店見つけた？みたいなこと聞かれると結構困る。 どこ行ったかという話であれば金閣寺とか清水寺みたいなTHE観光地とか、あと家が近いというのもあって妙心寺の退蔵院に桜を観に行ったくらいだったりする。

www.myoshinji.or.jp

とはいえ金閣寺とか清水寺とか、それこそ20年ぶりくらいに行ったけどすごく良かった。特に清水寺は夜の特別拝観というのに行ったのだけど、 とにかく雰囲気が良くて、こういうのに気軽に来れるのは良いなあという気持ちになったりした。

美味しいお店についても、現時点では特に見つけられてない。まあ美味しいと思う店はあるけどラーメン屋だったりするので「美味しいお店見つけた?」という質問をしてくれる人の期待には応えられてないと思う。 京都のラーメンだいたい美味しいと思えるのでよい。まだ行ってないんだけど一乗寺周辺に美味しいラーメン屋が結構あるらしいので是非行きたい。 自分で見つけたわけではないのだけど、二条にある大鵬という中華料理屋がすごく美味しかった。

tabelog.com

義父が京都に来た時に「雑誌で見つけた」という理由で行ったけど、高級中華とかじゃなくて「安くて美味い」みたいな感じの店でよかった。一度しか行ってないけど、ここは結構記憶に残っている。

街自体はすごくコンパクトというか、小さくまとまっている、という感覚がある。自宅から会社までは自転車で30分ぐらいだし、デパートとかがあるエリアまで行ったとしてもだいたいそれくらいの時間で行けるので良い。 東京みたいに公共交通機関がすごく充実しているとかではないけど、移動には困ってない。春になって観光客が増えてて、それでバスが遅れたりするとかはちょっと大変ではある。

引っ越してきた部屋は実は一度も内見してないのだけど、奇跡的に大成功だった。インターネットで部屋を見つけて、不動産屋さんにお願いして写真を撮ってもらって、それを見て決めた。写真が思ってたより綺麗だったこととか、築年数もそこそこ浅いとか、南向きだとか、なにより今までよりも広いしもうここでいいよね！みたいに勢いで決めたのだけど、最寄り駅から徒歩2分とかスーパーが徒歩5分くらいの場所にあるとか周りが静かとか、わりと「まあこれは別にいいか」みたいな条件についてもクリアされててとにかく満足度が高い。運が良かっただけという気がするので次回以降はもうやらないと思う。

そんなこんなで3ヶ月経ったけど、まだ慣れてない部分もあるし、まだ行ってないとことか食べてないものとかたくさんあるので周りたい。鴨川とかまだ行ってない。特に妻が図書館で借りてきた、京都の和菓子の店がたくさん紹介されている本がとても良かったので、和菓子店は順に巡って行きたい。

なんかまとまりのない文章になったけど、要は京都に引っ越してきたけど最高、みたいな話。

東京の終電は本当に最悪

金曜日に久々に終電に乗ったのだけど、とにかく乗車率が高いというか潰されそうだったし本当に最悪だった。

長時間終電に乗らないと帰れないのは辛い。

危機感の話

普通に一日を過ごしていて、仕事でもそうじゃなくても「あ、これこのままだとヤバイなー」みたいなことを感じることあると思うのだけど、そういう危機感みたいなの結構重要だよな、と。

ちょっとでも危機感を感じたら、それが結局どういう危なさなのかを冷静に分析する必要がある。 たとえば「エンジニアとしてこのままで大丈夫なのかな」みたいな漠然とした悩みを持った時に、どの方面に不安があるかを考える。コードを書いてないから不安になるのか、新しい知識を得られてないから不安になるのか、それ以外の何かなのか。いい感じに分析することができれば、その後自分がどうしないといけないかも（ぼんやりとかもだけど）見えてくる。 そういうのを繰り返せばちょっとずつかもだけどいい感じに何かが改善されていくはず。

一方で、危機感を感じない、というか「今は最高にうまくいってる！」みたいなときは気をつけた方がいいと思う。そういう時は足元見えてないとか周りが見えてないとかの可能性がある。正直何もかもが順調に進むことってほとんどないと思う（短期的にはそういうことあるかもしれないけど）ので、順調に進んでいる時ほどいろいろ見なおさないとダメだと思う。

ヤバさクラスもそれぞれあるけど、ちょっとでも「これやばいのでは」と思ったら立ち止まって考えたほうがよいし、自分の感覚は信じたほうがよい。 「まあたぶん今は大丈夫だろ」みたいなのが蓄積されていくと、気がついたら膨れ上がっていてもうどうしようもなくなっていたりする。 そうなると解決は難しいし、やってても楽しくなくなっていくと思う。

■

至極当然のことだと思うのだけど、やっぱりコミュニケーション大事だよな、と。

あとチームでというか他者と仕事する上で必要なのって「自分の意見をとにかく押し通す」とかじゃなくて「あーだこーだ言いながら着地点を見つけて着地する」とかだと思ってるのだけどこれってそんなに一般的な考え方じゃないのかな。一般的じゃないような気もしてきたな。でも余程の自信がないと押し通すとか無理だと思うんよな。それくらいの自信を持ってる人、素直に羨ましいな。

あとまあリスペクトだよなー。仕事はだいたい尊いのだ。たぶん。 「まだhogehoge書いてるんですか？」みたいな煽り、うっかりやりがちではあるのだけど良くないと思うのよな。もちろんその後フォローするなら別だけど、わりと投げっぱなしな人のほうが多いというかなんというか。ぼくの観測範囲的な何かが狭いだけで実際はきちんとフォローされてる事のほうが多いのかな。

なんとなくTwitterあたりに投げちゃえばいいのかなって思ったけど、Twitterだとあとで発言探すの面倒な感じだしたまにこーいうところにこーいうこと書いていくかな。

ダスキンのモップを使う

ねとけん Advent Calendar 2014 - Adventar

この記事はねとけんAdventカレンダーの最終日の記事です。

一週間前からダスキンの「おそうじベーシック3」というのを試しています。

おそうじベーシック3｜ダスキンスペシャルサイト

実は我が家には掃除機というものがなく、いつもはほうきとクイッ◯ルワイパーで掃除をしている。 が、会社の同僚と話しているときに「ダスキン」という言葉が出てきて、そういえば昔ダスキン使ってたなということで、 一ヶ月お試しを申し込んでみた。一ヶ月600円だし試すにはちょうどいいなーと思う。

インターネットで申し込んだ後は担当者から電話がかかってきて、実際にモップ類を受け取る日時を決めて、 実際に担当の人が家にやってきてお金を払ってお試しスタート、となる。 人にもよるんだけど、この辺は煩わしいと思う人もいるかもしれない。宅配ボックスとかに入れといてくれよ、みたいな。 ぼくも最初「ちょっとめんどくさいな」と思ったけど、そもそも我が家には宅配ボックス的なものはないので結局直接受け取るしか無いのでまあ仕方がない。 日時に関しては、「枠」みたいなのがあって、その日に実際に訪問できる数が決まっているような印象をうけた。

使ってみてそろそろ一週間なんだけど、モップそのものの性能はかなり良いっぽくて、ホコリがガンガンとれて楽しい。 実際奥さんはクイック◯ワイパーで掃除してるときより楽しそうでよいし、僕もちょいちょい掃除するようになった。 実家で借りてた時はモップに集めたホコリどうやって取ってたか覚えてないんだけど、今はモップを掃除するための掃除機もついててよい。置く場所については適当な場所に立てておけるので場所もとらないのでこれもよい。

一応継続しようとは思っているんだけど、毎月一回のモップ交換がどれくらいめんどくさいか（時間指定しないとダメ的な意味で）、みたいなのはまだよくわからないけど、かなり好感触だし、これからの大掃除で大活躍だと思う。

てことで今年の汚れは今年のうちに。

【2015/1/20 追記】 一回目の交換の時期がきて、気に入ったので継続することにしたのだけど、 東京都在住者限定で「おそうじ定期便」というのがあって、モップとかを郵送で交換できるらしい。

東京おそうじスタイル | ダスキンからの新提案| 東京限定

支払いはクレカ限定とのことだけど、今回来てくれる日時を調整しながら「毎回これやるのめんどくさいなー」と思っていたので助かる。