【アーキテクチャ ディスカッション Vol.1】に行ってきました。

アーキテクチャ ディスカッション Vol.1

https://istyle.connpass.com/event/97862/

に行ってきたので、そのときのレポート

 

ディスカッション形式のメモです。
発言に対する発言を1つインデントするようにして書いています。

※正直、うまくまとめられている自信がないので、会話を追って雰囲気が伝われば幸いです。

 

ビジネスロジック層のモデリング

  • active record を使ったときのモデリングが難しい。どうモデリングをするかで分離の仕方が変わる。
    • DB を一回忘れるのはどうか?
    • DB のことは一旦忘れるけど、どこまでを考えるのかが重要になりそう。
    • それって DB を最初が存在している前提では?ソフトウェアの内部構造って、オブジェクトの意味やライフサイクル単位で作っていくと良いのでは?あまり、テーブルに引っ張られて考えるのはよくないかもしれない。
      • その分析ってどうやって始めます?
        • 業務フローから考えます。業務をプログラムに落とし込むにはどうしたらいいのかを考える。
        • この言葉はどういうカテゴリなんだろうとか。
          あまりプログラミングというか、サービス仕様だったりデータのカテゴリわけをする

          • この場合のデータってなんですか?
            • 仕様に出てくる言葉のこと。
            • モデリングっていう言葉の意味が幅広いので、焦点はここだよっていうのを考えるようにする。
            • エンジニアが使うことばっていうのはいろいろな意味があるので、その意味を付箋で貼ってみたりとかもする。
              部分部分でやっていかないといけない。業務の一番重要なところはどこなのかを聞いて、そこに焦点をあてるようにしている。

              • ドメインというのは、答えが出た時に、どういうことをやったんですか?
                • 僕らが行ったこととしては、経済活動という古くから使われているものをドメインとおくことにした。
                  入荷なのかなのかの単位を人それぞれだったが、少しずつリファクタリングすることで擦り合わせていった。
                  図書館アプリを練習で作ってみようとなった時に、
                  会社は貸し借りが大事なのか?いや、在庫管理が大事だ。となって、在庫管理をドメインとして初めて行った。

Clean Architecrue を採用した話

  • 最初始めたときは、どうしてもこの形にならなかった
    presenters を使わない人もいて、translater を使う人もいた。
    スクラップ  &  ビルドを繰り返して、最終的にはこの形になった。
    大事なのは UML 図だった。

    • entity はきっとトランザクション管理でもよいのだと思った。
      ヘキサゴナルアーキテクチャがきて、そのあとこの形になったと思っている。
      オニオンアーキテクチャはただ単にドメイン駆動設計のことを行っているだけなので、use case の部分。
      僕はこれ、浸透させるために教育させるのは無理だと思った。
      なので、ツールを作った。
      WEB のときは、 presenter のときはいらないと思った。
      非同期処理は contorller が返してくれたほうが都合がいいときが多い。
      なので、WEB の場合は presenter はいらないが、GUI ツールのときはいると思っ

      • 教育は諦めた的なことを言っていて、ツールを作ったという話があったが、
        こういう手順でやってねということをやると、考えずにやってしまう人が出てきそうだが、どう思うか?

        • ツール使った方が早くできるよ、というメリットを提示して納得してもらった。
          保守フェーズをやったことがないエンジニアって、伝わらないからつらい。運用する辛さが伝われば話も伝わる。
          そういう意味では、モノリシックで1000行ぐらいあるメソッドの保守とかしてもらったほうがいいかもですね笑(会場でも笑いが起こる)
  • presenter について最近本を読んでて思ったことがあるが、
    本では、presenter はテストしにくい部分とテストしやすい部分を分けましょう、という話が23章であった。
    その中では、 view はテストしにくいが、viewmodel まではまだテストできるという内容だった。
    プログラミング言語中で、日付オブジェクトというものを view に渡したときに
    文字列に変換しなければいけない。
    日付オブジェクトを文字列に変換するのが presenter
    その文字を活用するのが view という感じにしていたので、
    presenter は必要なのでは?と思った。

    • dto を使っていて、テストするので、そこは問題ではないと思った。
  • clean architecture に乗っ取ってるかを管理する CI ツール気になる。
    • それは取り組みをやっている。構文を解析してチェックするようにしている。
      java で gladle を使ってやっているが、導入も簡単なので良い。
      ドメインの依存すべき方向とは逆方向になっているときなど、そういうのはすぐに検知できる。

DB に入れるときに レポジトリって入れると思うが、何を引数に渡している?

  • DB の方は基本的にイベントを保存するようにしている。
    失敗談で、entity を渡すっていうようにしていたら、
    レポジトリの中で新しい entity が渡されたときに、古いものとの差分をとって DB にインサートとかしていたので、その管理がつらくてやめた。

    • 僕もentityというか集約をインサートしている。
      • それってentityとテーブルに差がない状態になる?
        • いや、差がある。
        • DDD のいいところが、イベントをインサートするとDBは肥大化するが、ドメインは綺麗に保てることができるのでそこがいいと思っている。

レポジトリにおいて、参照系と更新系で分けている人はいますか?

  • 参照系だとオーバーヘッドが大きいと思うが、参照系でもユースケース層もあったほうが便利だよねという面もあって、みなさんの事例を聞きたい。
    参照系と更新系を同じレポジトリで管理するか否か?ということ。

    • Clean Architecure の場合は、ユースケースがインターフェイスになるので、レポジトリ使わないパターンで行った。
      • レポジトリはそのまま経由させて、書くのは RDS を使って読むのは Elastic Search とかを使ったりもしている。
        • たしかに書くのは多くなる。DB の先って何年か後に違うのにしようという話が出てくるので、そういう風にしている。
        • 両方とも同じように扱いたいので、レイヤを挟まないようにしている。
          • 逆に、レイヤを分けるようにしている人いますか?
            • 挑戦はしている。ドメインを守りたいみたいな方向でそういう風にしている。
            • 読む先と書く先が違うからという理由があるが、
              キャッシュが落ちた場合って、DBに取りにいくと思うが
              そういう場合はインターフェイスは同じだが、中身は違うようにしている。

キャッシュって、みなさん(Clean Architectureの)図でいうとどこに入れていますか?

  • DB のところに入れている。
    ただ、ドメインをまたぐときに困る。

Clean Architecture って、人と会話するのが苦手な人にとっては苦痛かもしれない

  • 人と会話して、こっちの人は商品って言ってるけど、こっちでは違うことを言っていて、
    そこの分析をやるのが楽しい。
    逆にそこを分析してからでないとコードに落とし込めないと思う。

    • お金をもらって、人に本当に必要なものを作るためには、人と会話ができないといけない。

ドメイン駆動をやっていると、自分の言語がプログラムになってくるのでプログラムを英語で書くのが辛くなる。

  • 逆に日本語のローマ字で書くと良いと、結構読みやすくて良い。

Clean Architecture の本を読んで思ったが、実践に使うには大きなサービスでないとやりずらい。ただ、実際に手を動かさないと習得しずらい、みなさんはどのようにしていますか?

  • 教育を2週間、題材を用意してやってみた。
    すると、完璧に理解するのは難しくても、コピペすればなんとかできるという状態には持っていけた。
  • 個人的には、小さいサービスを作ってみて練習している。
    自分の中で鉄板のお題(RSSリーダーを作るみたいな)を作ってみるというのをやっている。

    • その時って実際に業務でやるときとのレベル感というのが出てきてしまうと思うが、
      どうやってその差分を埋めてますか?

      • 埋まらないですね。ただ、どうしても抑えておきたい部分(例えば例外ハンドリングの仕方とか)はやるようにしている。
  • うちの会社ではレビューで学んでもらうようにしてますね。小さい単位で業務を任せて、レビューして教えたりする。

Flux アーキテクチャって Clean Architecture に似てるって思った人います?

GUIを組んでるときに思ったんだが、形的に似ているなと思った。
そのとき思ったのが、サーバーを介さなければ同じ形になるのかな?と思った。
特に思った人がいないので、この話はやめます笑

ゲームアプリのエンジニアも Clean Architecture に興味あるらしいですよ。

  • ゲーム全体をそうするのはしんどいかもしれないが、一部分だけ Clean Architecture にしてテスト可能にするのは良いと思う。

みなさんどういった経緯で設計とかアーキテクチャに興味を持たれましたか?

  • 僕の場合は 13 年続くでかいサービスを一人で保守していて、そこでアーキテクチャが必要だと思うようになった。
  • 自分でクソコードを生み出して保守しきれなくなって、あるべき姿ってどんなんだろうと思ったのがきっかけ。
  • コアなモデルのほうに興味があったのが一つと、学生のときに設計やアーキテクチャの情報がたくさん入ってきたので、そこがきっかけ。
  • オブジェクト指向から始まって、すごい人が言ってるからいいものに違いないと思って勉強から入った。
  • DBに興味がもともとあった。データモデルが出発点になって、それがきっかけ。
  • 入社したときに、Android が世に出たときくらいだった。一番最初の Activity に何千行もあるアプリを保守しなければいけなくなった。
    そこをどうにかしなきゃねって思って、アーキテクトの考え方になって言った。保守しやすいアプリケーションを突き詰めたら、今に至った。
  • 炎上しているPJがあって、どうにかしてくれというふわっとしたオーダーがあった。
    そういうもののセオリーってテストを書いて始めていくのだが、どうせだからドメイン駆動設計(というのがあるらしいレベルだった)を突っ込んでみたのがきっかけ。
    炎上PJってもしかしたらチャンス(新しいことに取り組める)なのかなと思った。
  • 他者が作ったが放り出したものと同じものを作ってくれと言われた。
    それが、ループが17段あったりもした。
    そういう過酷な状況の中で生き残るためには設計が必要だと思った。
  • 会社が、一人で作って一人で運用している人が多く、アーキテクチャを知っていないと自爆してしまうことがあるので、それがきっかけになった。

分析系の処理を書く(マイクロn秒)ときには、Clean Architecture は採用しないことが多い。

  • なぜかというと面倒臭いから。
    速く返さないといけないときとかは一つのファイルにたくさん書いたりする。

    • それはそれでいいと思う。
      そのソフトウェアが求められている関心事による気がする。
      人が運用する上での複雑性を解決するのが Clean Architecture だったりするし、
      速く返さないといけないとかだと技術的なアプローチが必要になるので、そのときどきにあったアプローチが必要
      Clean Arhitecture は万能薬ではないので、適材適所なアプローチが必要になってくる。

本の内容に関して

「本当の重複」と「偶然の重複」があって、

  • 重複を排除すれば無条件で良いと思っている人がいるが、そこについて書かれているのが嬉しかった。
    • このコードを重複させるべきかどうかという点を考えた時に、
      テストできるコードが設計ができるコードというわけではないと言われたりもした。

組織の形態がアプリケーションに反映されてしまうという法則がある。

  • 組織の形態はなかなか変わらないが、アーキテクチャはよりよいものにしたいと思うときがあるが、みなさんどうしていますか?
    • うちは microservice を採用していて、新しく入った人にはローテーションして多くを触ってもらうようにしている。
      そういう風に知識を蓄えてもらうようにしている。
  • 組織変えなきゃなと思いながらコードを書いたりもしている。
  • 何かサービスを作ろうとなったときに、新しく部署が生まれてそこで作るような文化になっている。
  • スクラッチで作られるサービスがたくさんあるので、横軸で共通で使えるようなライブラリとかプラットフォームがあったらいいと思うが、
    いまのところ組織と同じ形になってしまっている。
  • アーキテクチャ設計と組織設計って同じだと思っていて、組織設計やる気持ちがないとアーキテクチャ設計できないと思う。
    組織設計はマネージャーがやるというマインドだとできないと思う。
  • 結論、組織設計から逃げない。

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門に行ってきました

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門

https://supporterzcolab.com/event/533/

に行ってきたので、そのときのレポート

 

以下、講義を聴きながらのメモ

 

登壇者の方は、留学の経験があるが、

留学したからといって、すぐに英語ができるわけではない

それがきっかけになって勉強しようと思った。

 

その辺の本屋で、「2語で伝わる英会話!」とかいう本が多いが

そういう楽して学べる英語は本当の英語ではない。

 

この勉強会を通して、

みなさんが英語への一歩が踏み出せればよい。

エンジニアが英語できると何がよいか?

嬉しいことはすでに分かっている。

が、英語を勉強するのはとてもしんどい

なので、目標やモチベーションが大切。

嬉しいこと1: 入出力のスペック大幅アップ

入力

  • 最新のドキュメントが読めるようになる。
  • 疲れずに英語のドキュメントが読める。

出力

  • 例えば、技術ブログなどを英語で書くと、海外の人も見てくれる。
  •  OSS 活動がしやすくなる(PR  のコメントやコミットメッセージなど)

嬉しいこと2: 市場価値の高い人材になれる。

嬉しいこと3: もちろん、お給料が増える

いろいろなデータを見ていると、英語ができていると年収が上がる人が多い。

嬉しいこと4: 転職の際の選択肢が広がる

例えば、海外企業に勤めたいというのがまず浮かばない。

それは、英語ができないから。

それで選択肢が減っているのはとてももったいない。

嬉しいこと5:  かっこいい。

 

英語のジャンルを4象限に分けたとき

  • listening (リアルタイム・自分でコントロールできない)
  • speaking (リアルタイム・自分でコントロールできる)
  • writing (ノンリアルタイム・自分でコントロールできない)
  • reading (ノンリアルタイム・自分でコントロールできない)

どれが難しいか?

ノンリアルタイムの方が、翻訳ツールなど使えるので簡単

事前に準備できるspeaking, writingは、自分でコントロールできるので簡単

逆に準備できないのは、相手に依存しているので、むずかしい。

準備すれば誰だって英語でスピーチできる。

結論からいうと、

listening が一番難しい。

speaking ができれば、writing はそれを書くだけなので speaking のほうが難しい。

エンジニア向け、英語表現テンプレート

英語の人は、あいさつの始まりに「調子どう?」みたいなのをめちゃめちゃ言う。

ただ、how are you? はほとんど言わない。

what’s up の返答は i’m fineじゃだめ

最近なんかあった?とかそういうことを聞かれている。なので返答は難しい。

 

ずっとyesを使ってると、硬い人だと思われるので、いろんな表現を使えると良い。(yup など)

コミットメッセージとかは、日本語よりも英語のほうが簡単だったりもする。

主語とかいらないんで、動詞から始まっていい。

speaking 攻略

格好つけずに簡単に喋る

 

発音

日本人を知ってる海外の人は、日本人が英語の発音がひどいことは分かっているので

海外の人もそこは日本人に合わせて喋ってくれる。

逆に、自信なくして小さい声で喋ると、もっと伝わらないのでよくない。

 

喋りながら、発音が難しい単語は避けるようにする。

R と L の発音は本当に難しい。

が、R と L を入れ違えたときに存在しない単語だったら

相手が意味を汲み取ってくれるので、意外と大丈夫だったりもする。

Q & A

Q1.

英語をはじめたきっかけは?

A1.

学生の頃の先生が良かった。

 

Q2.

こういう勉強方で良かったというのはあるか?

A2.

実際に喋るのがよい。skypeとかで喋れるサービスもある。

DMM 英会話など。

 

Q3.

話をしていると、分からない単語があって、スペル自体も分からないから調べようがなさそうだがどうすればよいか?

A3.

スペルが分からなくても、それっぽい単語でぐぐったら、googleがもしかしてこの単語?とサジェストしてくれるので、それをつかっている。

 

Q4.

下手な英語を喋って相手を怒らせたときの対処方は?

A4.

そもそも怒らないと思う。そうとう変なこと言わなければ。

 

Q5.

日頃、ものを主語にしてしまうことがおおいが、人を主語にしたほうがよい?

A5.

いや、それでもよい。

 

Q6.

ゲームのチャットで英語を勉強するのはよいか?

A6.

何もしないよりは良いが、ゲーム特有のスラングとかもあるので、仕事で喋るほうがよい。

 

Q7.

どの程度英語ができたら市場価値として英語ができると言えるか?

A7.

どのくらいかはわからない。ただ、自分は英語できますと言える。

 

Q8.

実務として、エラーを検索するときは、どういう検索の仕方をしたほうがよいか?(効率の良いググり方は?)

A8.

普通に日本語で検索することもある。そのほうがわかりやすいので。

 

Q9.

英単語を覚えるためにどっかに保存している?

A9.

頭の中に保存している。話すときに何か見たりはできないので。

補足:

alcというサイトが良い。

辞書のようなサイトだが、辞書ではなくて、その単語を使った例文が表示される。

 

Q10.

日常で使うテンプレートとかある?

A10.

それが難しい。エンジニアに限定すると用途に特化して作れるが、日常会話は難しい。ので、テンプレートは持っていない。

 

Q11.

英語のpod cast など使っているか?

A11.

聞いていない。ただ、聞くとしたら自分の英語レベルにあったものを聞いたほうがいい。