ヌッ

適当

「現場で役立つシステム設計の原則」を読んでます(8-10章)

8章 アプリケーション間の連携

アプリ間の連携の方法について、特にREST APIの話が中心に解説している。
URIはリソースと一致させる、ステータスコードやHTTPメソッドが正しく対応しているかなど、
規約に沿うことで分かりやすく利用しやすいAPIとなる。

Web API: The Good Parts

Web API: The Good Parts

またJSONよりもXMLのほうがメタデータを使えるし複雑なデータを再現するならXMLのほうが良いと主張している。
これに関してはあんまり賛同していなくて、そんなメタデータ渡す必要あるのだろうか、
JSONで簡潔に済ませたほうがいいんじゃないかと思った。
これこそアプリによる課題かもしれないが。

またメッセンジャーを利用することで、疎結合な非同期通信を行えるので良しとしている。
具体的なサービス名について明記してなかったが、GCPのPub/Subがこれに相当すると思う。
たしかにアプリ間で直接やりとりするのではなく、Pub/Sub経由を前提とすることで、
疎結合になりアプリ単体のテストがしやすくなる。

複数の小さなサービス間の連携を行う設計、マイクロサービスについても触れている。
このようにサービスを分割して検証しやすくするのはオブジェクト指向の考え方にも沿っている。
ただマイクロサービスだと一部分割したサービスを統合したり移譲したりするのが難しい。
そのため深いドメイン知識が必要とされる。
以下の書籍でも初めは単一のアプリ(=モノリス)から実装し、ドメインについて詳しくなってから徐々に分解していくことを是としている。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

9章 オブジェクト指向開発プロセス

今までメジャーだったウォーターフォールは、設計、実装、テストを別々の人で分業して行っていた。
一方最近流行りのアジャイルは、このサイクルを1,2週間のスプリントとすることでより速いサービスの改善を試みているが、
実装に寄りがちで設計、テストがないがしろになりがちである。
結局、ドメインに詳しい人間が設計、実装、テストのすべてを担当することでブレ無いドメインモデルが出来る。
また無駄にドキュメントを作ることはせず、コードこそが全ての仕様書となるようにする。

この辺の主張はまぁ分かるのだが超優秀な人間を前提としているような気がした。
実際自分もこれに似たようなことはしているのだが、コードから全てを把握するのはまだまだ出来ないし、
設計も実装もテストもまだまだスキル不足を感じる。
分かりやすいようにドキュメントがほしいと感じるのだが、書いてもすぐに陳腐化するし、そもそも誰も読んでくれないし、
結局頑張ってコード読むしか道は無いような気はしている。
コードを理解するスピードがあれば済むということであればOSSのコードを読み漁るとかすべきなのだろうか。

10章 オブジェクト指向設計の学び方と教え方

「どうすればオブジェクト指向設計を理解出来るのか?」「体で覚えよ!」
以上、という感じの章である。
こう書くと脳筋感があるが、いくつかのルールに乗っとってコードを書くトレーニングをすることで身につく、という話である。
たしかに動物をクラスとして鳴き声がメソッドで〜みたいな例を出されても結局何が嬉しいのか謎である。
ならば実際に実装してみてオブジェクト指向の良さを体験すれば良い。
紹介されているルールは基本的にlintでチェックされるようなものも多いが、例えば「全てのプリミティブ型、文字列型をラップする」というものがある。
手続き型の書き方だと難しいルールだが、このようにオブジェクトを多用することで結果としてオブジェクト指向の書き方になるという寸法である。
またいくつかオススメの書籍についても解説しているが、一番は「エリック・エヴァンスのドメイン駆動設計」のようだ。

ふりかえり

そうだよなー確かになー本当かなーとか色々思うところはあったが、全体的に平易で読みやすい書籍だった。
勝手に初級者向けのDDD本と思って読んでたが(まぁ実際そうだったが)
値オブジェクトとリポジトリ以外のパターンについてはほとんど記述がなかったように思う。
エンティティとか(極力使うなという話?)ファクトリとか(チラッと出てたけど)
そういうパターンとか考えないでひとまずオブジェクト指向に慣れろという話かもしれない。
とはいえ層とかパターンみたいなものをちゃんと理解しない開発についてけない感はあるので、
そろそろ原本を読んで勉強しようかなというところ。
あとは書籍じゃなくて開発するとかコードリーディングするとか実践経験を積むしかなさそうな感じはする。
以上です。


前々回
woody-kawagoe.hatenadiary.jp


前回
woody-kawagoe.hatenadiary.jp

「現場で役立つシステム設計の原則」を読んでます(4-7章)

4章 ドメインモデルの考え方で設計する

まずドメインモデルはデータモデルとは異なりロジックがあると述べている。
よくあるパターンとしてデータはクラスか変数として、ロジックは関数として別々に作ってしまう。
もしくはフレームワークに合わせて適当にクラスを作成するとか。
しかしオブジェクト指向ではデータとロジックはまとめ、オブジェクトとして扱うものである。
これにより業務データとそれに関連する処理を一元化することができ、シンプルな構成になる。

またトップダウンでなくボトムアップの設計を推奨している。
一個一個の部品=ドメインオブジェクトを作り込む。
とはいえどのような部品が必要になるかは知る必要があるので業務フロー図やパッケージ図を用いておおまかな地図を書くことから始まる。
(これだけ見ると結局トップダウンじゃんという感じはするが)
結局のところ全体と部分を行ったり来たりしていくことが大事ということである。

開発を進めることで徐々にドメイン知識が身につくはずである。
そのため徐々にドメインモデルを正確なものに改善していくことができる。
リファクタリング」でもクラスの分離や結合、移譲などの話をしているが、
これもオブジェクトの構成を改善するための手法の一つである。

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

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

またドメインに関する語彙とドメインモデル中の変数名や関数名を一致させることでより分かりやすくなる。
ドメイン知識が少ないうちはまずは専門用語を身に着けていくと設計がしやすくなる。

データとロジックを合わせて設計をするというのはまだなれないところだが、
これが出来るとシンプルな実装に出来るかと思うので実践してみようと思う。

5章 アプリケーション機能を組み立てる

アプリケーション層のクラス=サービスクラスは複雑になりがちであるが、業務ロジックはドメイン層に書くべきである。
MVCでもfat controllerを避けるべきみたいな話があるが同様のことだと思う。
(ググったら機関車トーマスに出てくる局長のキャラクターもfat controllerと呼ばれてるらしい)
業務ロジックは出来るだけ細かくし、サービスクラスはその組み合わせを構成する。
プレゼンテーション層では入力を受け、サービスを呼び出して適用し、出力を返すだけで、ここにロジックは置いてはいけない。

またサービスクラスからデータベースの都合を切り離すために記録と参照のみを行うクラスとしてリポジトリを利用する。
具体的なデータベース操作はリポジトリ内に記述することで、サービスクラス内では記録と参照を行っているということだけがわかるようにする。

6章 データベースの設計とドメインオブジェクト

データベース設計では制約を行うことでプログラムの記述を簡単にする。
具体的にはNOT NULL制約, 一意性制約、外部キー制約である。
この辺は「データベース実践入門」にも記載があった。
(この書籍だともっと厳しい正規形についても述べている。)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

特に一意性制約は重視したい。テーブル内のカラムでどれが一意になる組み合わせを考え、
それを複合キーとして設定することで参照が楽になる。
個人的に最近はNoSQL(datastore)を利用する機会が多い。
そのため外部キーを利用してJOINでつなげることが少なく、使用場面を考慮したテーブル設計になっていることが多い。
それでもNOT NULL制約、一意性制約に関してはNoSQLのテーブル設計にも役立つ。

またオブジェクトとテーブルの設計は異なる点に注意すべきである。
オブジェクトはロジックを含むがテーブルはデータのみを管理する。
フレームワークによってはテーブル設計とオブジェクトが一致するような命名規則を強いるものがあるが、
このようなフレームワークは避けるべきとしている。
MVCだとmodelがリポジトリドメイン層となってしまっている。
「現場で役立つシステム設計の原則」だとJavaのSpring bootがドメイン駆動を再現しやすいとして推奨している。
僕としては制約の少ないシンプルなフレームワークを利用して必要な部分だけ利用すべきかなと思っている。

7章 画面とドメインオブジェクトの設計を連動させる

UI中に業務ロジックをおくべきでない。DDD本でもこのようなUIは「利口なUI」としてアンチパターンとしている。
また複雑な画面になってしまう場合は分離すべきである。
たとえばユーザー登録画面でも1画面にすべての項目を入力するのではなく、
いくつかのフローに分離した画面のほうが開発しやすく、ユーザ側としても使いやすい。
またユーザーの関心事に注目して設計すれば画面の内容とドメインオブジェクトが連動してくるはず。
それから画面の設計には近接、整列、対比、反復を重視すべきとしている。
これはノンデザイナーズ・デザインブックに書いてある話である。

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

ふりかえり

今まで読んできた本とのつながりが見えてきたのが良かった。
特にDB設計に関して学んできたことは変わってないなと思う。
一方でデータと業務ロジックをオブジェクトとしてまとめるということはまだ出来てないなと感じる。
また今自分が開発に携わっているシステムが、どうして今のような構成なのか、
どうしてこのようにオブジェクトを分けて設計しているのかなど、設計の意図を把握しやすくなったような気がする。

前回
woody-kawagoe.hatenadiary.jp

「現場で役立つシステム設計の原則」を読んでます(1-3章)

DDDやっていきたいなーとか言ってたら同期にこの人の本良いっすよと言われて読んでみたのだが思った以上に良い感じだった

1章 小さくまとめてわかりやすくする

ソフトウェアの変更が大変なのはどこをどのように変えればいいのかが分かりにくいのが原因。
だから分かりやすい構成、設計にするべき。
始めの方は「変数の命名はxとかじゃなくて意味がわかるものにしようね」とか、
DRY原則を守る」とかリーダブルコードに書いてあるような基礎的ですぐに実践しやすいことが記載されている。

ここで数値だったらなんでもbuildinの型使っちゃダメよと言っている。
例えばお金を示す値だったら整数だからとりあえずint型かなとしがちである。
が、システム内ではintの最大値と同じ金額を使うパターンが無いとか、100円単位で使われる可能性がある。
そのため専用の型として「値オブジェクト」を使い仕様を厳しくするべきである。
これにより異常値が入ってエラーが発生するということを防ぎやすくなる。

エリック・エヴァンスのDDD本とか実践DDD本とかだと割と後の章で値オブジェクトの概念が解説されるので1章目でこの話をするのかーと思った。
でも確かに「〇〇という概念がある。それは〜」という説明よりは「こういう課題があるので対策としてこういう設計がある。これを〇〇という。」という方がストーリーだっていて分かりやすかった。
また、よくエンティティと値オブジェクトの違いは可変か不変かですよという説明は見ていたのだが、なんでそういう分け方にしてるのかとかはよくわかっていなかった。
この書籍だと値オブジェクトの利用例があり分かりやすい。(他の書籍や記事でもあったのかもしれないがたどり着けてなかった)

2章 場合分けのロジックを整理する

基本はif-else文だと入れ子構造が深くなっていて複雑になるから控えようね、という話。
対策として「ガード節を使う」、「カテゴリ用のEnum作っておく」、「多態性ポリモーフィズム)をもたせる」などがある。
これは書籍にはなかったが個人的には以下のような辞書型を使ったスクリプトで場合分けを行うことが多い。(上司に教えてもらった)

# 元コード
fruit = input()
if fruit == 'apple':
  return 100
else if fruit == 'orrange':
  return 200
else
  return 0
# 改良版
fruit = input()
prices = {'apple': 100, 'orrange': 200}
return prices.get(fruit, 0)

3章 業務ロジックを分かりやすく整理する

書籍ではデータクラスとロジックは分けないで書こうという話をしている。
正直言うと僕は役割が異なるから別で分けるものという認識だった。
しかしここを分けてしまうとデータクラス、ロジックの変更の影響範囲がどこなのかを調査するのが難しくなってしまうという問題がある。
データクラスとロジックをあわせて業務内容を再現したオブジェクトをドメインオブジェクトという。

また三層アーキテクチャについても触れている。ここでいう三層は以下の層を示す。

  1. プレゼンテーション層
  2. アプリケーション層
  3. データソース層

n層とかレイヤーアーキテクチャとかはよく聞くのだが、上記の層含めどういう層があるのかとかはいまいち分かってなかった。
MVCでいうとそれぞれV, C, Mが対応してるんだろうか。
同じような役割の層でも呼称とか変わる場合もあるし難しいものである。flaskとかだとMVTだし
書籍では業務領域を表すドメインオブジェクトの集合であるドメインモデル(ここが一番複雑な処理になるはず)を別の1つのレイヤとして持つことで他の三層の記述は簡潔になる。

ふりかえり

手元に以下のDDD関連の古典がある。まだ全部は読みきれてない。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計

実践ドメイン駆動設計

頑張って古典を読んで理解しようと思ってたのだが、その途中で「現場で役立つシステム設計の原則」に触れておもしれーってなったので一通り読み進めたいところ。
これ読み終えたら上記2冊も読んでより理解を深めたい。
割と実装してる最中でも(この実装この階層であってんのか……?)となって開発に手間取ったり手戻りすることがあったりするので、サッと判断して爆速で開発できるようになりたいものである。
引き続き4章以降も読み進めます。

路上プロレス生で見た

皆さんは路上プロレスをご存知でしょうか。
大体こういう感じのやつです。アマゾンプライムでも「ぶらり路上プロレス」とかやってて面白いので皆見ましょう。

youtu.be

それはともかくとして、たまたまDDTのサイト見てたらこれを見つけたので行ってきた。

東京・グランデュオ蒲田「路上プロレスinグランデュオ蒲田
DDT ProWrestling

試合開始が18:00からだったので会社の会議終わってからすぐ出発した。
Twitter見る限り屋上からスタートするらしかったので、会場付いてからエレベーターで屋上に移動した。
と思ったのだが途中階で降りた瞬間に怒声が聞こえ、眼の前に樋口和貞がいた。男色ディーノもいた。
こりゃ行くしか無いと思いすぐに降りて観戦を始めた。

各階を移動しながら普通の床に叩きつけたりいろんな技をやっていた。
それに合わせて観客はヤジを飛ばしたり写真撮ったりして追いかけた。
男色ナイトメアや地獄門などのコンプラ的に非常に問題のある男色殺法も見た。
19:00頃に決着がついた。ピッタシ1時間くらいだし、タイムキープが素晴らしい。
というか早めに出発しておいて本当に良かった。

すごい近くでよく知ってるレスラーがいるってだけでも貴重な体験だけども、
普通のデパートの中、大人数でレスラーを追いかけるのが体験としていい。
ヤジ飛ばしたり、ちびっこが参戦したり、試合中にレスラーと記念撮影したり、路上プロレスでしか見れないシーンが沢山ある。
もちろんブック(八百長)というか茶番が沢山あるんだけどそれがこの上なく面白い。
他の団体もこういうのやればいいのになーといつも思う。
どう考えても「路上プロレスやらせてください」と交渉するのは難しいし、
明らかに試合後怒られてるんだろうけど。
それに普通に買い物に来てた人からすればクッソ迷惑なわけで……。
ただこういうバカをするというのがこの上なく楽しい。

したい。どうすれば出来るんでしょうか。新潟プロレスに所属して交渉すればいいんでしょうか。

www.n-p-w.jp

レスラーデビューコースあったわ。マジかよ。というか大日本と提携とか色々やってるんすね……。
デパートでやるにしてもリングたてるだろうし、路上プロレスはしてなさそうだけど……。
あと選手プロフィール見たらレルヒ少佐とかアオーレ長井とかいて草。


普通に今はエンジニア職しながら総合のジムでやっていきます。

youtu.be

初めてライブハウスに行った

フェスとかはたまに誘われていってたんだけど小さい箱ってあんまいったことない。
行きてぇなぁ行きてぇなぁとずっと思ってたけどようやく行動に移した。
特別気になるバンドがあるわけでは無い。
ただ下北沢は近いしバンドの街というイメージがあったので、たまたまライブやってるところを探して行った。

結局このイベントに行った。
liveholic.jp

箱はこじんまりしてるんだけどそこそこ人はいた。
客層としては大学生くらいの男性女性がほとんど。
意外におばさんもいた。

雰囲気としては割と落ち着いていて、体揺らしながら音楽楽しむ程度。厄介はいない。
空気だけでいえば学祭のライブとかを思い出したけど、
やっぱちゃんとしてるというか流石にプロ(?)で演奏は上手い。

聞いた中だとまちぶせというバンドが一番良かった。
曲も良かったんだけどMCのマシンガントークが面白くて盛り上がった。
「照明で暑い!なんだこの照明、こんな照明初めて見たぞ!たこ焼き器みたいな形して!たこパ、皆さんたこパやったことありますか?いねえよなぁ陰キャしかいねえんだから!」
とか脊髄で話してた。良かった、ロックは陰キャのものなんだ。
他のバンドは結構MCが短くて「後2曲やったら終わりますー」程度で、曲をしっかりやっていく、硬派タイプが多かった。

あと全体の感想としてステージ上で演奏するの楽しそうだなぁというのもあった。学校とかで演奏してたのが楽しかったのを思い出した。
滋賀県から来ました、〇〇です」とMCしてたバンドがいて、声に出して読みたい日本語だった。(ナンバガリスペクト)
コピバンでもいいけど、このネガティブで憂鬱な感情を歌詞に出来たらなとも思った。
曲としては電子音、重低音、変拍子とかが好きなんだけどジャンル的にどうなるのか、どこでライブやっているのか、あんましよく分かってない。
結局面倒でトラックメイカーにはならないんだろうな。

それはともかくとして今回みたいにフィールドワークしていくと新たな発見あっていいし、
ただ突っ立って聞いてるのも退屈なわけではなく割と曲を楽しめた。
音圧を感じるのがいい。周りがノッているのが分かるのもいい。
もっとライブに参加していく、バンドTを買っていく活動やっていきたい、楽しいので。

www.youtube.com

Vim再履修

色々あったので一日vimrcいじるなど開発環境の見直しをした。
技術的な話なのでQiitaに書いても良かったけど個人的なvimrcをちょっと改良した、勉強した程度なのでこっちにした。

dotfile

github.com

これが今の最高状態や。(更新したらまた変わるわけだけども。)
昔「最強のvimrc晒す」みたいな奴適当にパクって使ってたんだけども、
今回はちゃんと中身理解しようと思って色々調べてから必要な奴だけにした。

公式ドキュメント

vim-jp.org

やっぱ公式が最強や。vimtutorだけやってたけどマクロとか知らない操作ちょくちょくあったので勉強になった。

dein パッケージ管理

github.com


neobundleは死んだ、もういない。(開発中止している。)
ということでパッケージ管理は全部deinで出来るようにした。
調べてる限りだとtomlファイルで別に管理している人が多いようだったけども、
そんなに多くのパッケージ使わないだろうし、管理するファイルを離散させたくなかったのでvimrcにベタ書きすることにした。

利用パッケージ

github.com

入力途中で単語のサジェストをする。

github.com

日本語ドキュメント。:helpで呼び出せる。

github.com

ファイル一覧とか呼べる奴。Ctrl + nで開いたり閉じたり出来るようにした。

map <C-n> :NERDTreeToggle<CR>
let g:NERDTreeShowHidden = 1
let g:NERDTreeNodeDelimiter = "😀="
let g:NERDTreeDirArrows = 1
let g:NERDTreeDirArrowExpandable = '▸'
let g:NERDTreeDirArrowCollapsible = '▾'
let g:NERDTreeGlyphReadOnly = "RO"

github.com

いろんな言語のカラースキーマとか勝手にやってくれる君

github.com

文法チェッカー君。
synatsticは死んだ。
そんなに細かく設定しなくてもコード書いてる途中に勝手にlinterが動いてくれる。
Ctrl + fでlintに沿うよう修正できるようにした。
flake8, autopep8とかは別でインストールする必要あり。

map <C-f> :ALEFix<CR>
let b:ale_linters = ['flake8']
let b:ale_fixers = ['autopep8', 'isort', 'yapf']

github.com

インデントの色つける君。
いつもHTMLのタグ間がわからなくなってたのでスペース2個のインデントでも色が変わるようにしてる。

let g:indent_guides_enable_on_vim_startup = 1
set ts=2 sw=2 et

所感

よくわからんまま使ってるところが分かってスッキリしたし面白かった。(小並感)
自称vimmerの割に有名どこのパッケージ使いこなせてなかったのは普通に恥ずかしい。
ただ設定できる範囲がデカすぎるし一日で知るのは到底無理だと思う。
また今度復習とかして見直したいところ。

最近の仕事

新卒二年目に突入した。
エンジニア業もなんやかんやクビにならずに済んでる。
最近疑問なのが近い職種の人とやってることが近いのか遠いのかである。
自分では割と幅広いような気がするのだが、本当に普通より範囲が広いのか狭いのかわからない。
もしかしたら今後ポートフォリオとかに書けるかもしれないのでまとめてみる。

本業

  • 設計
    • UI
      • google slide使う
      • 見た目もそうだけど機能の確認もする
    • 機能
      • google document使う
      • 機能の詳細を詰めたり調査結果まとめる
      • DBから変えるときは影響範囲もデカかったりするのでその辺も
    • テスト
      • google spread sheet使う
      • この辺まだ不慣れ
  • 実装
    • front end
      • Vue.jsでゴリゴリ作る
      • 微妙なズレとかでCSSと格闘しがち
    • server side
      • GAE+python
      • ここが一番やってて楽しい
      • リクエストの仕様はcerberusで書く
      • GAE ndbだとコードでDBスキーマかけるのでmigrationが不要で楽
  • テスト
    • UI - テスト設計に書いたやつをポチポチやる
    • API - postmanでポチポチ
    • その他 - ログ見たりとかdatastoreの中身見るとかしてチェック
  • 運用
    • リリース - 基本CIが全部やってくれるけど事故らないか見守る
    • サポート - 仕様どうなってるんすかというのに答える、正直これが一番辛い
    • 障害対応 - 事故ったときはGCP consoleとにらめっこして調査し修正対応、異常に不安になったりハイになったりする

副業

  • イベント系
    • 司会 - なんか喋る、たまに絶叫する
    • ケータリング手配 - 出前館 is GOD
    • ブースに立つ - お悩み相談する
    • 動画を作る - プロダクトの葬式用
    • 墓を作る - プロダクトの葬式用
  • 研修で面倒見る系
  • 求人お手伝い系
    • 面談 - 雑談
    • 求人イベント - 雑談
  • その他
    • ブログ - 書くかも
    • 発表 - 極稀、やっていきたい
    • 幹事 - 経費精算ももう慣れた
    • 電話応対 - たまにある、苦手

補遺

バイト時代は実装だけとかだったので大分やれることは増えた感。
出来るようにしたいことは色々あるけど、今は仕様の理解・提案をもっと早く精度高くやりたいなというお気持ち。
以上です。

youtu.be