runaround’s diary

なんとなく、つれづれ

「現場で役立つシステム設計の原則」を読んでみたよ

平日は仕事前の30分、仕事後は時々晩御飯待ちの間に読書するようにしています。

 

今日まで読んでいたのはこちら。

books.rakuten.co.jp

厚さは結構あるのにとっても軽く、最近の製紙や製本技術の向上には驚かされます。

そして本を開いてみるとびっくり。案外字が大きいw

なのに読んでみたら内容が濃い!

 

読み終わって晩御飯までちょっと時間があったのでインスタで呟いたりしてました。

 

https://www.instagram.com/p/BXFeKScj96S/

現場で役立つシステム設計の原則、ようやく読み終わった。大事だと思う所に付箋。

インスタは大体ツイッター連携してるので、ツイッターにも流れまして・・・。

 

そしたら・・・

 

なんと!著者さまが反応してくださって、心臓飛び出るかとw

食べてたチキンのフライ吹きそうになった・・・

どこに付箋を貼ったのか興味を持ってくださってたみたいです。

 

今度こちらの読書会に行く予定でして。

devlove-kansai.doorkeeper.jp

その際は他の参加者さんの見解などを見聞きするのが大変楽しみなんですが、とりあえず現時点でちょっと感想をまとめておこうかと。

第1章

光の速さで付箋をつけたのはこちら。

1つの変数を使いまわして代入を繰り返す書き方を破壊的代入と呼びます。

 破壊的。ほんとですね・・・。私、金融系のシステム開発が一番長いこともあって計算ロジックのとこでこれやっちゃうとヒドイ目に合うの、すごくわかります。

あと、やっぱり値クラス。

「数量」は単なるintではありません。「電話番号」は単なるStringではないのです。

 正直言って後頭部殴られた感覚・・・。今までDB設計したあと、実装はホント慣習でテキトーにIntegerやStringで扱ってた・・・( ;∀;)

Telephone型の例はとてもわかりやすくて、現場のシステムだったらどんな感じで当てはめたらいいかなぁ〜ってぐるぐる考えてました。

最近ほぼ全部のソースを読む機会に恵まれてまして、何気に気づいた・・・

えっ?Telephoneクラスあるやん・・・_:(´ཀ`」 ∠):

3年近く開発してるのにこんなクラスあるの気づかなかった・・・(爆)

あ、でもクラスは存在しているんだけれど、ホント一部の機能でしか使われてなくて存在感がとっても薄かった・・・。

これはちゃんと整頓して実現させたいですね。もちろんチームの同意を得るためにサンプルコードとか書いて提案してみないとですが。

第2章

Enumを使用した状態遷移の表現、つい最近もステータスの表し方でチームメンバーが頭を悩ませていたこともあってすごく身近に感じましたw

そうかー、こういうやり方があったか!と。

第3章

業務データと業務ロジックを一緒にしたドメインオブジェクトを設計するときに、どのパッケージに置くべきか、そしてどのパッケージの内容を知っていてもよいか/知っていてはいけないかを整頓し、改善を続けることで、業務ロジックの全体的な関係が明確になってきます。

 今のチームのソースはかなり綺麗な方だと自負しているのですがw、それでもこのロジックやサービスクラスってこのパッケージでいいのかなぁ・・・わかりにくくないかなぁ・・・と悩んだりすることもあります。

改修のチャンスがあれば、ちゃんと検討して改善するのはいいことなんだなぁとちょっと自身が湧いてきました。

第4章

ドメインモデルの考え方についてとても詳しく説明されていて、今後もいろんな本を読んで勉強する予定です。

一番激しく同意したのはこちら。

分析・・・人間のやりたいことを正しく理解する

設計・・・人間のやりたいことを動くソフトウェアとして実現する方法を考える

頭では理解できていても、人に説明するときにわかりやすく良い表現ってなかなか出来ないものですよね。それがとても簡潔に表現されていて感激しました。

あと、業務への理解というのはシステム開発者としては永遠の勉強のテーマだと、私は思っているのですが、こちらも激しく同意しました。

文書で体系化した情報、現場で実際に使われている場面や帳票や資料、そして業務の経験者との会話。これらを常に組み合わせながら対象業務の知識を広げて行きます。

第5章

サービスクラスについては、今のチームのソースはほとんど実現が出来ていてかなりほっとしましたw

きっと最初にルールを決めて書いて、展開してくださった方のおかげです。

あと、ちょっとデカいなぁと思った既存のサービスクラスはぶっ潰して解体、小さくリファクタリングしたりしてますwww

第6章

値クラス使ってない!の次にやっちまったーーー😅  と思ったのがこの章w

テーブル設計なんですけど・・・NULL値が入ったテーブルある・・・

そのせいでプログラムも超ダサいことに・・・API・・・

ちゃんとテーブル分けたらよかったんですね・・・そっか・・・

 

そして一番笑った部分はここ。

もっとひどい設計が「自由項目」や「予備項目」と呼ばれるカラムです。

 出たーーーーーーー!!!予備項目!!!

その昔とあるシステムでカラムが150個ぐらいある汎用的なテーブルがあって、あるお店のデータならカラム13には住所が入ってるけど、他のお店のデータならカラム13には顧客の性別が入ってる、みたいなのに遭遇しましたね。

ソース側は何が何だかですよ。読んでもさっぱりテンション上がらない。

予備項目職人だったら「ああ、カラム13か。あの店だったら住所だよね。」とか即答しそうですけどね(こら

第7章

うちのチームのシステムでは画面側(テンプレートエンジン)はThymeleafを使ってまして、画面側で色々出来てしまう(そして読みやすい)ということもあり、実装者によって法則がまちまちになりがちです。

ソースレビューで読んでてちょっと辛いなと思ったら「出来ればJava側で編集しておいてから画面側は表示だけにしない?」と提案することにしています。

そういう意味ではこちらはとってもぴったりで納得できるな、と。

画面まわりのロジックから業務のロジックを分離する

第8章

WEB APIの仕組みについてわかっているつもりでしたが・・・ちゃんと整頓立ててもう一度勉強させていただいた、という気分です。

いかに私はノリで開発してるかってことですね😜

最近チームでAPIを根本的に見直そうと話し合ったこともあって、この章はかなり参考になること間違いなしです。

第9章

うちのチームでは設計と開発、テストまでを原則同じ人間でペアプロすることにしています。「原則」と書いたのは途中で1人を残してペアの組み替えをすることがあるので。

それと、ドキュメントに関しては開発する前のイメトレや課題調査のアウトプットとしています。処理の大まかな流れだけ書いて、詳細はソースを読めば良いし。

しかし、最近特に考えていることがあります。古参メンバーがいなくなってしまい、既存処理がなぜそうなっているかの理由(歴史?)がわからなくなってどハマりするという苦い経験をしました。であれば、理由や歴史はドキュメントに書いておいた方がよいのではないかと。

・・・と、この章読んだら答えが書いてあったw

やっぱ分析時の資料は残しておいた方が良いのですね。

ホワイトボードなどでラフスケッチなど書いて写真を撮ってアップしておいたり・・・

第10章

オブジェクト指向の学び方・・・結局、なんとなくずっとJavaを書いてきたけれど実際自信を持ってオブジェクト指向!身についてますよ!と断言できるのかどうか・・・。 

ただ、私が恵まれているなぁと思うのは・・・

  • 新規開発の現場も行ったけれど、保守開発の経験が長かった
  • 今のチームで設計改善も含む開発の機会を得ている

ということでしょうか。

面白そうな本もたくさん紹介していただいているので、読んでみようっと。

これとか。

books.rakuten.co.jp

「心理的安全性」のことに思いを馳せてみる の勉強会に行ってきたよ

今日はこちらの勉強会に参加してきました。

 

devlove-kansai.doorkeeper.jp

 

スピーカーのお二人にとても興味を持ったのと、チームビルディングなどにも興味があったので光の速さで参加申し込みしました。

 

およべさんのスライド

speakerdeck.com

どちらのお話を聞いていても、チームで色々工夫して色々考えて、苦労もありながら、でもうちのチーム最高ーーー!ってことがとてもよくわかりました(雑)。

 

んでもって・・・

私がいるチームもほんとサイコーでーーーーーーーーーっす(ほんとに)。

手前味噌?いやいや、多分本当に毎日きゃっきゃ言いながら開発してますよ。

 

面白そうな本もたくさん出てきたんですが、これはお気に入りに入れておきました。

次のお買い物マラソンで買おうっと。

books.rakuten.co.jp

 

ドラゴンボールを揃えてチームを変えられるとしたら何を願う(願いは1つ)?

うーん・・・変えて欲しいことがないんですよね。冗談抜きで(^_^;)

なぜなら、こうしたいな、と思ったら「ねぇねぇ」ってみんなに相談してやってみて、うまく行ったら継続、うまく行かなければ諦めるかやり方を変える、みたいなことを日常やってるから。

まぁ、願いといえば・・・これ以上うちのチームのリソースを剥ぎ取らないで( ;∀;)って感じですかねw

今が一番バランスがいいかなぁと思っていたり。

困ったなぁと思ってた人たちが他へ移ったってこともあるけど(爆)。

 

何か困ったらすぐにメンバーへ相談できる。

ちょっとパニクってたらとりあえずメンバーに話して考えを整頓できる。

なんならホワイトボードに書きながら頭の中にあることをメンバーと整頓できる。

チームメンバーの作業に興味を持てる。

ペアで前向きに開発できる。

品質を上げることを常に目標に掲げられる。

メンバーからの指摘を素直に受け止められる。

チームメンバーのことを思いやれる。

毎日「やったー!(バンザイ)」が言える。

 

以上が私が心がけてる&今日の勉強会で見聞きして、ぜひ継続したい&やりたいと思ったことです。

 

ビジネスマンを「めんどくさい」から解放する【RODEM】の開発の現場 の勉強会に行ってきたよ

昨日はこちらの勉強会に参加してきました。

devlove-kansai.doorkeeper.jp

ヴァル研究所さんってあの駅すぱあとの会社ですよね。

roote.ekispert.net

そうか、今はWebとかアプリなんですね。私は最初に自分で買ったPCがWin95で、日立の一体型だったんですけど、駅すぱあとのソフトがインストールされていて。

なんて便利なんだろう!って感動したこと、今でも覚えています。

当時は離婚して働いてなくて求職中で、出張とは無縁だったんですけど(爆)。

 

で、今回のサービス、名前の由来はやっぱアレだったみたいです。

youtu.be

バビル二世の声は初代小五郎のおっちゃん・・・(コラ

 

容姿を変えながらご主人様に仕えるしもべということらしいです。

他にも執事っぽいもので候補は沢山挙げておられたとのことですが。

おっちゃんおばちゃん世代にはすぐわかりますが、若い世代はバビル二世ってわかるんだろうか・・・w

 

プロジェクトに携わっておられるPM、PO、開発、デザイナーさん揃い踏みという豪華なセッション。

決して順風満帆ではなく、半年作ってきたアプリのリリースストップという衝撃もありながらのストーリーにとても感銘を受けました。

(うちも色々ありましたしね・・・)

PMさんの反省をふまえたお話を聞いていると、やっぱり小さく作ってユーザーの反応を見るって大事だなぁと。

セッション後は発表者さんを個々に囲んでの座談会。

POさんの貴重なお話が聞けて大変よかったです。

私自身は開発側の立場なので開発担当の方のお話も興味があったのですが・・・。

POさんの立場への理解や興味は、開発側も持った方がいいものを作れるのではないかと思っています。

うちのチームはPOが大変仕事のできる方で、開発はとても楽で楽しく開発ができているのですがそれにあぐらをかいているのは良くないなぁと。

開発だってちゃんといいサービスとは何かを考えて正しく作るのを意識した方が絶対いい。

「言われたものを作っただけなんで、あとは知らない」って平気で言う開発者は結構います。特に派遣技術者は。

こんなこと言う人には絶対なりたくないです。

 

あとスライドでスターウォーズのネタもあってテンション上がりましたw

惑星ダゴバでのヨーダがルークをジェダイとして修行させてるシーンの下りが。

 

エピ8の公開が楽しみだなぁ・・・年末が(関係ない

KANJAVA PARTY 2017 !!!でLTしてきたよ!

あ、ありのままに昨日体験したことを書きますぜ((((;゚Д゚)))))))

kanjava.connpass.com

 

とりあえずは発表したスライドはこちらです。

speakerdeck.com

 

当日はちょっと迷いながら会場へ到着。綺麗すぎてマイクロソフト関西支店さんのオフィスがあるビルがわかりづらかった・・・。危うく阪神ホテル入るとこでした。

案内に立ってくださってるスタッフさんが笑顔で迎えてくださって感謝。

受付を済ませてセッション開始ー。体が2つあったらどっちも聞きたい内容ばかりで苦渋の選択を迫られる一日でした_:(´ཀ`」 ∠):

以下は私が聞いたセッションリスト

  • 「関ジャバとJava」関ジャバ会長
  • 「You can change the world !!AI & Bot でより良い社会を作ろう!!」てらだよしおさん #KanJavaPartyA1
  • 「JUnit5の味見」山根英次さん #KanJavaPartyB2
  • 「Introduction to JShell: Official REPL Tool for Java Platform」吉田真也(@bitter_fox, @shinyafox)さん #KanJavaPartyA3
  • 「Kafkaを使ってイベントを中心にしたアプリケーションを作ってみる。Spring Cloudにのせて。」  椎葉 光行(@bufferings)さん #KanJavaPartyA4
  • 「関西Java女子部ショートセッション大会」 関西Java女子部(Abe Asami (きの子) 他3名) #KanJavaPartyB5
  • はてなブックマークAndroidアプリへのKotlinの導入について』 西林 拓志 (takuji31)さん #KanJavaPartyB6
  • ビアバッシュ / LT

自分の専門外のセッションや今後うちのチームでも取り入れたいなーってことはついったで呟いたりしてました。

非常に有名でいつもついったやFBやブログ等でお世話になっている面々が登壇、参加されていることもあって本当に豪華でした。

こんな場所で自分がLTするだなんてっ・・・

いやいや、ガクブルしてるとよくないので考えないことにして、お昼休憩は職場の同僚2人とラーメンずるずる。んみゃかった。

今回同じ職場の方々も沢山参加されていて何だか嬉し恥ずかしでした。

ビアバッシュではかなり楽しいLT大会もあり、初めて(関西ではない)Java女子部のまーやさんとも色々お話させていただきました。

せろさんはポケモンGOのレイドバトルについて色々教えていただいたし・・・。

あとLT見たよ!って色々お声がけいただいたりしてほんと恐縮して体が 🦐  になりそうでした。

ほんと、ほんとに、参加された皆さま、運営の皆さま、ありがとうございました。

 

んで、ここからは今回このLTをやることになったことをちょっとメモっておこうかと。

 

もともとこのイベントには参加申し込みしていました。補欠じゃなくて。

だってめっちゃ豪華で面白そうですし。DevLove関西さんの勉強会にも参加しているので中村洋さんのお話も聞きたかったし。

 

LTやりませんか?とお声がけいただいたのは関西Java女子部のきの子さんでした。

何度か関西Java女子部のもくもく勉強会に参加させていただいてまして。(今年は参加できてないかもw)

そういや、この女子部の勉強会、職場のリーダーさん(男性)から「面白そうなのあるよ」ってチャットでリンク送ってもらったのがきっかけでした。

リーダーさんが「なんなら俺が行きたい」って言うので女装おすすめしましたっけ・・・w

 

このお話をいただく前、ほんと偶然なんですがこの本を読んでました。

books.rakuten.co.jp

最近全然本を読んで勉強してないなぁと反省して、毎朝30分早めに会社の近くまで来て本を読んでから出勤することにしているんです。本のジャンルはJavaに限らず。

あと、これもまたまた偶然なんですけど、読みたい本をお気に入りに入れとこうと思ってさまよっていて見つけた本。

いつも勉強会に参加していて思うのは皆さんプレゼン上手すぎる!なんか虎の巻あるんじゃないの!?ってこと。

books.rakuten.co.jp

この本、イラストめっちゃ可愛いし内容もいいのでおすすめ!

プレパタを使ってワークショップ開催したことあるしーばさんにチュッパチャップスと引換にどんな風にすれば良いかなど教えていただいたりしました。

んで、急にやって来たLTのチャンス。こーれーは、やるしかないっ!

・・・んぁっ?!タイムテーブル見たら中村さんの裏番組じゃないですか・・・orz

でも・・・でも・・・このチャンスは逃しちゃだめだ・・・と決心。

 

言いたいことを付箋に書きまくって順番を決めて、冗長な部分は落として・・・

リファクタリングについて話すので、通常であれば資料にサンプルコードを載せるのでしょうが、10分のLTでソースを色々流すというのもなぁ・・・

このプレゼンはリファクタリングしたいけど、どうしていいやらと困っている人に向けて話すと決めたので、こういうのを見つけて直したらいいよ、を書こうかと思いつきました。

直す対象も具体的なソースじゃなくてイメージ的なキーワードがあると便利だよねーと。んで、🍤  とかマトリョーシカとか家系図にしてみました。

「ふむふむ」ぐらいの反応がかえってきたらいいなぁと思ってたんですけど・・・

めっちゃ反応いただいて本人戸惑ってます(いや本当に)。

ついったのトレンドに入ってたりしたみたいで。

 

ビアバッシュでも「よかったよー」とあたたかいお言葉いただいたり、「東京遊びにおいでよ」とか言っていただいたり。゚(゚´Д`゚)゚。

実は密かに東京の勉強会も行ってみたいなーって思ってたので・・・

(先立つものと相談になるなぁと思いながら)

 

いやー、人生のリファクタリングしといて良かった。

GIS

今週、DevLove関西さんの勉強会に参加してきました。

devlove-kansai.doorkeeper.jp

 

私は位置情報や地理情報って利用させてもらってありがたやーって立場なんですが。

地図にどんな有益な情報をどんな表現で載せるか、とか。

位置情報を使ってどんな楽しいサービスを作ってきたか、とか。

何もかもが私にとって新鮮な知識ですごく楽しかった。

 

位置情報を使ったゲームの話でやっぱり出てくるポケモンGO

ジョン・ハンケさんの話も紹介されてたんでちょこっとググってたら、

へーって動画を見つけました。

ってか、これ当時そういう動画あるのは知ってた気がするけど、観たことなかった。

youtu.be

2014年エイプリルフールかぁ。

それから2年でリリースされたのね。

新しいポケモンはあらかたゲットしちゃった(アンノウンがまだ・・・)

新しいポケモン追加や機能リリースをワクワクして待ってます。

 

勉強会のお話の中で「位置情報はお金にならない」課題のお話をされてまして。

位置情報を使ったサービスを考える、ではちょっと限界があるのかなぁ。

まずサービスを考えて、じゃ、位置情報も使おうかって方がいいのかなぁ。

 

色々と考えがめぐる勉強会でした。

ベタで何が悪い

こないだ悩んでたDBアクセスまわりのクラスのjar化はうまくいきました。

jar化するプロジェクトの方にJerseyのライブラリ入れてしまっていて、

Tomcat立ち上げの時にJerseyが暴走しちゃってた・・・

 

jar化する方のプロジェクトを見直したらJersey使ってるとこあったけど、

そのメソッド自体使われてないやーんっorz

このクソメソッドめ(こら

いや、読んだらホントにクソメソッドやった・・・

 

メソッド消してライブラリも消してビルド、画面側に取り込んで

デプロイしたら\(^o^)/

Jenkins側にもjar取り込みの手続き書いたから自動化でけたー

いやー、色々環境設定頑張ってくれてる相棒のおかげでサクサク。

ホントありがたい。

 

最近は次にリリース予定サービスの結合テストが始まったわけですが。

久々にイケてない実装が混入しちゃって読んでヘコんだ。

ログ出力ロジックぐらいベタで書こうよー

何でメソッド化してパラメータ文字を連結するんだよー。

後でエラー発生時にソースgrepする時にヒットしにくいじゃんかよー。

何年前のコーディングなんだよ・・・

なんでもメソッド化すりゃええってもんではない。

 

今読んでる本に、

コンパイラにわかりやすいコードは誰にでも書けるが、人間にわかりやすいコードを書くのは大変」

みたいなことが書いてあった。

クソコードは簡単に混ぜ込めるんだよな。(もちろん自分にも言っている) 

 

案外ベタでもわかりやすいコードは存在すると確信している今日この頃。

どったんばったん

毎日ぼやーっと仕事している感じですが、これでも色々考えてます。

あれこれ考えることが盛り沢山なのと、タチの悪い喉風邪引いちゃって体調がぼろぼろ。

今日のTOEICも散々だったなぁ・・・。

来月はちゃんと頑張らねば。

 

今、TOEIC対策として週一でNOVAレッスンで専用テキストで頑張っているのだけど、もっと問題を解かないとねぇ。

本はもう問題覚えちゃうぐらいになってしまったので新しいのを買うか・・・

でも場所とっちゃうしなぁ・・・。

 

うちのシステムのDBアクセスまわりはDomaを使っているのだけど、

共通化(ライブラリ化ってやつ?)したくてプロジェクト分けたのはいいけれど、

jarにしてから他プロジェクトに取り込んでデプロイしたら・・・

画面がうまく起動してくんない・・・

ちっきしょーーー!!!

明日local環境でグリグリして何とかしてやるぅ!(出来るかはわからないw)

 

やりたいことは沢山あるけれど、時間は有限だし他にもやるべきことはあるし。

取りあえず広く浅くアンテナは張り巡らせておいて、気に入ったことは深堀りすべし。

 

来週は勉強会が続くのでちょっとハードですな。