SpringBoot2.0がリリースされたのでバージョンアップしてみた

spring.io

待望のSpringBoot2.0がリリースされました。 ので早速バージョンアップだー。

やったことといえば、 build.gradle のビルドスクリプトプラグインのバージョンアップだけ。 Spring Boot Gradle Plugin Reference Guide に書いてる通りですね。

- id 'org.springframework.boot' version '1.5.10.RELEASE'
+ id 'org.springframework.boot' version '2.0.0.RELEASE'

そしたら java と io.spring.dependency-management が外れるので、追加。

+ apply plugin: 'java'
+ apply plugin: 'io.spring.dependency-management'

対象のプロジェクトは spring-boot-starter を使ってるだけのやつで、超シンプルなやつなのでこれだけで完了しました。 application.properties にSpringBootのことは書いてなかったんで、そっちがどう変わったかはみてないです。とりあえず軒並みキーは変えなきゃいけないはず。

SpringFrameworkも4から5に上がるわけだけど、コンパイルエラーとかにもなんない。流石にこう言うところは安定してるなー。

変わってたとこ

なんかあったらメモがてら実装してこーかと思って。

github.com

application.properties の空白文字の扱いが変わってた。

プロパティファイルの空白ってどう言う扱いなんだっけなと軽く探してみてみたけど、 Properties (Java Platform SE 8) くらいしか見つけられず。 そもそも Properties#load で読むのと SpringBoot1.5で application.properties を読むのとでも違うので、まあ、うん。

とりあえず application.properties で値に空白文字（スペースやタブ）を使用してたら、 String#trim されるんで消えちゃいます。 これは新しいプロパティを読むクラスで実装されてるので、 PropertyPlaceholderConfigurer. setTrimValues(false) とかしてみても意味ないです。

ちなみにapplication.properties ではなく、コマンドライン引数とか application.yml とか、他の手段で設定すれば特に関係ない話です。 どうしても application.properties でないとダメなんだーとかでもなければそちらで対応できるやつです。

もともとが正しいとも言いづらい（IDEが警告だすような記述なわけだし）ものなんで、仕様外の話かなーと。

ベタープログラマの第一部を読んだ

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマを読もう - 日々常々で5,6,8,11,13章を読むと書きました。 実際2,4,5,6,8,11,13章を読みました。2つほど増えてますね。

雑感

部タイトル

you.write(code) って code を you に書かせてる？ you は渡された code をそのまま書くのだろうか。仮にそうだとしたら you の型って何なんだ・・・プログラマではなさそう。もし渡した code がそのまま書かれないとしたら write メソッドって名前はどうなのってなっちゃうし。ところで code は誰が生成するんだろう。 you かしら？だとしたら code 生成と code の write で分かれてる？ 流石に code って変数名で型がコード的な何かじゃないってことはないと思うし・・・

2章

vimが最善です。それがすべてです。

のっけからこれ。こう言うことを書いてる本ってのがわかりやすくていいと思います。客観的な正しいっぽいことが書いているのではなく、著者が好きに書いている感じがします。

グッドリフの法則

「コードのレイアウトに関するすべての議論は、白熱すればするほど、ほぼ実りのない議論になる」

そのとおりでございます。

さて2章は「見かけのよい状態」ってのがどう言うものかを書いてます。 前に書いた 見やすいコードのために出来るたった一つのこと - 日々常々 とか、 "ふつうのJavaコーディング"を話しました - 日々常々 で話したことのいくつかとか、普段話してることと被っているものも多くありました。「そーそー、そう。これが前提、このあたりは議論の対象じゃなく、話したいのはこの先なんだー。」と言う感じ。

4章

まだやりすぎてるところ多いなーと思ったり。「結論を出さなくてもいいように、どうとでもなるように実装しておく」ってのは確かにYAGNIではあるなーと。小さいものでも不要な作り込みは不要なわけだし。

実装する前に話すのがいいってのはわかるのだけど、でも机上の空論するなら実装しちゃったもので話したほうがいいよなってのもよくみるので、この辺は意図しての使い分けかなー。

5章

自分の古いコードを読んで、そこから学ぼう、といった趣旨。

思い返してみると、自分の過去書いたコードをみる機会って案外少なかったです。長期プロジェクトは多かったけれど、プロジェクトの間にコードが変わることは少なかったかもしれない。プロジェクトが変わるタイミングでコードも変わってた感じがする。なので以前携わってたプロジェクトのコードを見たときに、ここで書いているような経験になってたかな。git以降は普段のコードを見返す機会も増えた気がする。ここ最近はプロジェクトの切れ目とかは関係なく自分のコードがころころ変わるので、昔よりも実践できてるかもしれない。

そいや昔から言ってるよなーとログ漁ってみたら

過去の自分は良い教材。

— irof::ねむい (@irof) 2010年12月17日

それっぽいのがツイッターはじめた年にあったので、もっと前から言ってそう。

あと「過去の自分は遠慮なく叩ける」とかもしょっちゅう言ってる。コードに限らず過去のブログもいい教材になります。

6章

章タイトルが謎だから読もうと思った章ですね。プロジェクトに途中参画するときにどのようにしてコードにたどり着くかって話を「航路の航行」と名付けている。なるほど。

私は途中参画もそうだけど、新規プロジェクトでも地図を描くことが多いです。地図と呼んでいる何か、ではなくて結構それっぽい地図でプロジェクトをあらわしてみる。システムの境界を海岸線であらわしたり、港や崖を描いたり、わかんないところは雲や霧で隠してみたり。傍目は遊んでるように見えたかもしれない。最近はコンテキストマップを描こうとしてる。他の人との会話に使えそうだから。

ソフトウェア考古学

たまに耳にする、具体的にはどういうものか知らない言葉が出てきた。 Wikipediaだと Software archaeology - Wikipedia とかある。まあ考古学って言うのだから、事実から文化とか状況を読み取るって感じなのだろう。メンテナンスの時によくやってるアレのことだと思う。

8章

「エラーへの言い訳」に反論するの、表面的にはできるだろうけど、反論しきろうとすると難しいなと。章タイトルの「そのエラーを無視するな！」から想像していた内容よりも具体的で強い論調だと感じました。この章は読んでみてほしい。

11章

章はじめはテスト駆動開発から入りますが、話は一応テスト全般をスコープにしてる感じです。考える機会になることがいっぱい詰め込まれてます。やはり話題としては自動テストの比重がほとんどですが。

よくある誤りは、五つのメソッドを持つクラスを見て、（略）個別のテストを五つ必要だと考えること

これを明確に「誤り」と言ってるのは初めて見たので印象深かった。理由も添えられていますが、SUTがオブジェクトとしてあまり役に立たないスメルなのかなーというのが感想。

そういえばIDEでテストクラスを生成すると、メソッドに対するテストメソッドが生成されたりしますね。あれでメソッド作ったことないですけど、ああ言う選択肢がでるのがこの辺を助長してるのかもしれない。

てことで

次は二部。そのうち。。

「現場で役立つシステム設計の原則」の感想

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

目次流しは以前書きましたが、読み終わってるので改めて。

一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。

読書会をしてみて

4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。

平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いなく実践で役立たない 、そんな感じです。現場での実践をシミュレーションするだけでも多くの問題にぶち当たるでしょう。そういうのがあっさりした言葉でさっくり片付けられています。このようなことを通じて「ただの理想論」と片付けるのは簡単ですが、残念ながら本書の内容は殆どが実践されているものです。特殊な一つのプロジェクトではなく、複数の会社の複数のプロジェクトで。

実践しないとわからないことが膨大にあり、それを乗り越えてようやくさらっと書かれている1文に届く感じです。読み流せば「ふんふん、まあそうだよなー」で片付いてしまい、簡単に誤解できるし、ややもすれば実践不可な理想論にしか映らないのでタチが悪い。これを危険と言わずなんと言うか。。。

読む際に外すと誤解するポイント

この本は徹頭徹尾「変更を楽で安全にする」ことを書いています。

変更しないものには興味がなく、「どう作るか」ではなく「変更のためにどう作るか」が書かれています。書いていること全てが変更ありきなので、変更しないものや変更できないものに適用しようとしても無理があり、解釈が歪みます。（しかも歪んだまま解釈できてしまう。）

どんな本もそうなんですが、書かれていることはたいていそのまま適用できません。現場のコンテキストに応じて調整する必要があり、実践で学べば方針も変える必要が出てきます。その際に変更できるかは重要で、少なくとも変更できるように作っていなければ変更はできません。得た学びを反映するためにも「変更を楽で安全にする」必要があるわけです。

読み終えて

実は書かれている内容をあーだこーだと議論してもあまり意味がない本なのではないかと思いました。議論すべきは、書かれていることを実践した結果の経験に対してです。なのでコンテキストの共有できない状態で会話すると全く実になりません。話すのならば実践経験を語れる場で、できるならば同じ経験を共有した人たちがいいでしょう。そう言う場で実際のコードと本を突き合わせて話すと、短い言葉の随所に詰め込まれた情報がようやく読み取れます。

噛んでたら味が変わる系の本ですね。

おまけ（半年前のLTスライド）

ddd-alliance.connpass.com

このイベントでのスライドです。新幹線の終電に乗ろうとしたら、山手線を逆方向に乗ってしまって帰れませんでした。ドンマイ。