ravelll の日記

よしなに

Quipper に転職して3ヶ月+が経った

3ヶ月経った時点で書こうと思っていたのだけど、どうにも筆が進まずに追加で2ヶ月以上経ってしまった。

入社してからやっていたこと

  • (6月 ~ 10月) 新規事業のチームでバックエンドの開発
    • Ruby + Go の Microservices
    • 新入社員のオンボーディング
  • (11月) スタディサプリ（toC）の Web アプリの開発（フロントエンドもバックエンドも）
    • 新たに Go で（Microservices 文脈での）サービス作ってる

良かったこと

  • 転職活動時に転職先へ求めていたことが満たされていた
    • 優秀で組織を横断して協力的な同僚
    • 自身と近いインターネット感（言語化サボタージュ）
    • ユーザーファーストな開発組織
  • 知識量、学習意欲・実績、思考の速さ・的確さについて、自分より優れている人がゴロゴロいる
    • 同時に、オーバーワークを良しとする空気も感じない
    • 加えて裁量労働なので自身への負荷が調整しやすい
  • 目黒（オフィス最寄り駅）が比較的穏やかで良い食事にも事欠かない
    • 渋谷・新宿は人が多すぎて歩くのが嫌だった…
  • 予想以上に英語を使う環境だった
    • 「Pull Request は基本的に英語で書くが喋る機会は殆どない」と聞いていたが配属先チームは公用語が英語だった
      • ミーティングは基本的に英語で進み、詰まるときや間違いを許容できないときは英日両方で共有される感じ
    • 業務と英語習得が兼ねられて大変便利だった
    • …のだけど残念ながら今は所属が変わり英語を使う機会は大幅に減ってしまった
  • 貯金できるようになった
    • 年収が約1.5倍になり入社〜現在に安い中古のグランドピアノ分くらい預金が増えた
    • お金で行動の選択肢を増やしたい（休日増やすとか）ので今後も贅沢はほどほどにしたい

予想外だったこと・不満なこと

人間関係の悩みは無く大きな問題はナシ、ありがたや。

  • 自席以外の個人作業ができる静かめな空間がない
    • ふらっと移動して1人で仕事できる椅子・ソファの類が無い
    • オフィスを見学したときにはまあ大丈夫かなと思っていたが、しばらく働いてみて予想以上に自分がそういう空間を欲することに気がついた
    • そういう空間を求めるときは大抵不調なときなので予兆を掴めれば在宅勤務でカバーできるかもしれない
  • 通勤で山手線に片道20分以上乗る必要がある
    • 一刻も早くやめたいのでそのうち引っ越す

今後

  • 自己効力感を高めていきたい
    • 自己効力感 ≒ 幸福感 = 成果 * 成果理解力 = 能力 * 行動力 * 運 * 成果理解力、みたいな考え方をしてる
      • 成果理解力 = 自身の成果に納得し、自己効力として自然に受け入れられること
      • "成果は全てを癒す" は納得している考え方だけど "成果の実感は全てを癒す" が正確
    • 能力・行動力は一旦置いておくとして、成果理解力に乏しいと感じている
      • 大きな成果を上げたとき以外に自己効力感をほとんど感じなく、精神衛生的に不健康
    • 成果を出せるように能力向上を図り然るべき行動を起こしていくというのは前提
  • 週休3日化する？
    • 土日は妻や友人と過ごす時間を優先し、平日の1日をやりたい学習に充てられると幸せなのでは
  • 転職意欲が全く起きていないので上り調子にやっていきたい

落ち込むこともありつつ、概ね健康です。大健康大幸福を目指すぞ。　

2019-11-18 Mon. 17:30 追記

不満なことを思い出したので公平のため追記。
オフィスの無線 LAN 環境がしばしば厳しいです…（過度に遅かったりしばしば切れることがある）

2020-01-16 Thu. 10:12 追記

今では無線 LAN 環境は困らなくなりました、ありがたい！

エリック・エヴァンスのドメイン駆動設計 4章メモ

3章の週は時間が取れなかったので一旦飛ばしました。
4章はドメインを表現する箇所と技術的な要求を実現する箇所を分離すべき理由とその方法としてのレイヤ化アーキテクチャについて。

4章 ドメインを隔離する

  • (ravelll)ドメインから生じる問題とは？
    • あるドメインにおいてソフトウェアが解決したい問題？
  • 問題解決の流れを表現する部分と技術的な流れを実現している部分が混ざらないようにする必要がある
    • そうしないと何がモデルなのかをソフトウェアから理解することが難しくなる

レイヤ化アーキテクチャ（LAYERED ARCHITECTURE）

  • (ravelll)"ビジネスロジックとは何？"という問いに対する答えを1つ言語化できるようになる章っぽい
  • MVC の例
    • UI の変更がビジネスロジックの変更を巻き込んでしまう
    • "凝集度の高いモデル駆動のオブジェクトを実装することが現実的ではなくなる"
      • ビジネスモデルを純度高く反映したオブジェクトを実装するのが難しくなるということ？
    • 技術的なフローを実現するコードとビジネスモデルを表すコードが混ざるとテストもぎこちなくなる
  • Layered Architecture で関心事を分離しつつ相互作用も継続してできるようにする
    • "本質的な原則は、レイヤ内のどの要素も、同じレイヤの他の要素か、その「下にある」レイヤの要素にしか依存しない、ということである。"
    • "レイヤの価値は、それぞれがコンピュータプログラムにおける特定の側面を専門的に扱うことにある。"
    • "もちろん、決定的に重要なのは、設計における最も重要で凝集度の高い側面を隔離するレイヤを選び出すことだ。"
      • Layered Architecture は具体的な層の設計までを提供するものではなさそう
      • とは言えうまく行っているところはだいたいこういうパターンになるよね、という傾向はある
        • UI(Presentation) 層
          • ユーザーは人間に限らない
        • Application 層
          • ビジネスルールや知識についてのロジック・状態を持たず薄く保たれる
          • 技術的な操作や処理の状態は持てる
          • 調整役
          • UI 層と厳密に区別されない場合もある
        • Domain(Model) 層
          • ビジネスの状況や概念を表す責務を追う
          • これを分離して始めてモデル駆動開発が可能になる
        • Infrastracture 層
          • 上位レイヤーを支える一般的な技術機能提供を行う（これはしばしばサービスという形で提供される）
    • それぞれのレイヤはそれぞれ異なる速度で進化する
    • 各レイヤーは分散して配置されうる
  • 表示、格納、アプリケーションタスク管理などのロジックはドメインモデルの表現には不要
    • "アプリケーションタスク管理" とは？
  • (ravelll)依存が単方向になるべき理由を言語化できる？
    • 双方向になる => 互いに互いを知ることになる => 関心事を一方に留めておけなくなる ということ？

オンラインバンキングの機能をレイヤに分割する

  • ドメイン層でやるのは (1) 指定された口座Aを振込元して口座Bに対して指定された金額を追加すること (2) 指定された口座Aから指定された金額を引くこと
  • トランザクションを開始・コミットする、振り込みを DB に記録する、等はスコープ外
  • "おそらくそこには、元帳オブジェクトや、振り込みおよび引き落としオブジェクト、金銭取引オブジェクトなどが含まれていただろう。"
    • 振る舞いもオブジェクトなんだ。オブジェクトとは…？

レイヤを関係づける

  • 依存方向を逆転したいときはコールバックやオブザーバーを使う
  • (ravelll)アプリケーションコーディネータとは？

アーキテクチャフレームワーク

  • "多くのインフラストラクチャの要求を統合するフレームワークを使うと、他のレイヤをきわめて特殊な仕方で実装しなければならなくなることも多い。"
    • Rails の話か？？？
  • "最もよくできたアーキテクチャフレームワークは、複雑な技術的問題を解決する一方で、ドメイン開発者がモデルを表現することに集中できるようにする。しかし、フレームワークは、ドメインについての設計の選択肢を制限する前提を多く設けすぎたり、開発の速度を低下させるほど実装を重苦しくしてしまったりすることで、容易に開発の妨げとなり得るのだ。"
  • (ravelll)ドメインオブジェクトってつまるところ何？
    • ドメインモデルのいずれかの登場人物に対応するクラス？
  • フレームワークを選ぶときはちゃんとソフトウェアがモデル駆動となるものを選びましょう

ドメイン層はモデルが息づく場所

  • ドメイン駆動設計におけるレイヤ化アーキテクチャ => ドメイン層があること
  • "利口なUI(Smart UI)"
    • ビジネスルールのあまり無い小さく短命なシステムにおいてはアプリケーションを小さな単位に分割し、そのユーザーインタフェースに全てのビジネスロジックを詰めるという戦略がある
      • Layered Architecture を水平分割と呼ぶなら利口な UI は垂直分割っぽい
    • (ravelll)4GL ツールとは？
      • 4th generation language
      • R, SQL, MATLAB とか
      • 特定の分野において高次に抽象化された操作を可能とする言語のこと
        • ので特定のシステムと対になっているものも多い
    • やるなら不要な複雑さを高機能な言語やフレームワークから持ってこない用にする持ち込まないようにする
      • 4GL っぽい何かでよい
  • "同じ理由から、モデル駆動設計に取り組むチームは、最初からそれにふさわしいやり方で設計する必要がある。(snip)しかし、最初の一歩を試しに踏み出す先が、ドメインレイヤを隔離したモデル駆動でなければ、プロジェクトは利口なUIに行き詰まることになるだろう。"
  • この章ではドメインを隔離して実装する方法として Layered Architecture を紹介しているが、ドメイン層をどのようにやっていくかについては後続の章が担当するっぽい

エリック・エヴァンスのドメイン駆動設計 2章メモ

ユビキタス言語とそれを作る・使う上でのよくある勘違いの章と理解した。

第2章 コミュニケーションと言語の使い方

  • 言語はドメインに関する意思決定と実装を結ぶもの
    • 言語の乖離は実装の乖離に繋がりそう
  • ドメインエキスパートと開発者のそれぞれがドメインを記述する言語を独自に作り出してしまう
    • 翻訳が必要になるが、翻訳はモデルの概念を混乱させることに繋がり、混乱は破壊的なリファクタリングに繋がる
    • 通訳は知識の噛み砕きを鈍化させる
  • ちゃんとモデルに基づいた言語で会話をするように頑張らないと知識の噛み砕きのプロセスが良いモデルを作ることに繋がらなくなっていく
  • 実装に紐づく言語でみんながしゃべると不意に矛盾が見つかることが多くなって便利で、その一方で開発者の言葉をそのまま共通言語として採用するにはドメインエキスパート側の負担が大きいので双方から歩み寄った現実的な解としてのユビキタス言語という概念、という感じ？
  • 何でもかんでもユビキタス言語化するのではなく、あくまでもモデルが対象とする範囲においてユビキタス言語を作る、というのはなるほどという感じ
  • ユビキタス言語は開発者・ドメインエキスパートが理解するものの最大公約数となるような定義ではなく、厳密に限定された定義としなくてはならない
    • 両者が同じものを想像する程度に理解できる名前だからオッケーというものではない
  • UML はそれを書き出して議論に中心に置くことで統一した相互関係・モデル名を全員が持ち議論できるようにする = Unified Modeling Laungage
  • UML はそんなに完璧に詳細を書き出すものではない
  • UML はオブジェクトの属性と関係は容易に書き出せる一方でオブジェクトの振る舞いや制約は書き出しづらいツール
    • その限界をユビキタス言語を用いた会話によって補える
  • "モデルは図ではない"
    • 図は単にモデルについて議論する際にコミュニケーションや理解を円滑にするための表現の1つというだけ
    • 前職で開発の進行をやったときにすべてのモデルを言葉で表現しようとしたけど、もっと図を使ったり、複数の方向からモデル作成を試行してみればよかったな…
      • そもそもコミュニケーションが足りてなさすぎたのも問題だった

書かれた設計ドキュメント

  • ドキュメントが事実と乖離していく問題
    • XP => 極力書かずにコードに語らせる。コメントはこれに含まれないので重視しない
      • 厳密で活きたモデルを保てるが、理解しづらい。また背景を伝えられない
  • "すでにコードがうまくやっていることを、ドキュメントでもやろうとするべきではない"
    • ドキュメントはコードを補足する
  • ドキュメントはそれが必要なら乖離が問題として浮上する
  • 問題にならず乖離しているドキュメントは更新するのも時間の無駄
  • ユビキタス言語でモデルの背景となるビジネス知識などを共有することに成功するとモデルのドキュメンテーションを小さくすることができる
    • ドキュメントでコードと会話を補足する
  • "正しいことをするだけでなく、正しいことを言うコードを書くためには、潔癖でなければならない"
    • 前者だけではモデルとの繋がりが曖昧になる（名前が曖昧とか）
  • コードから何らかモデルを説明するもの（図とかテキストとか）を出力する方法は研究されていないのかな
    • コードを直接ドメインエキスパートが読むのは現実的には難しいけどそれを抽象化したものを使って会話ができると良さそうな気がする

説明のためのモデル

  • 実装、設計、コミュニケーションの根底にあるモデルはチームで1つにしよう
  • モデルのコアとなるものではなく一般知識を説明するためには別のモデルを利用できる
    • そのときにはコアとなるモデルと混同しないように UML は使わないほうが良い