【ペチオブ】ぺチトーーク<T>#1

この記事はペチオブで2020/03/12(木)に開催された
ペチオブの議事録です。

ペチオブとは

株式会社ミライトデザイン主催による
エンジニア向け初学者向けオブジェクト指向ワーキンググループです。

詳しくはグループページをご覧ください

ぺチオブConnpassページ

もくもく会や、モブプロ会、セミナー、LT会、輪読会　なんかをやっていきたいなと思っとります

Miraito Design, inc. - YouTube

ペチトーーク<T>とは

ペチオブで開催している勉強会の形式の1つです。
YY形式の勉強会です。

このTってのは、プログラミングの仕組みのジェネリクスってのを使うときの記法で、<>の中のTは使う時に型を決める=話してによって話題を決める、みたいな意味が込められてます！

テーマは自由なのでみなさんが話題にしたい事をピックアップして話をしましょう！

@juriful さんにブログを書いていただきました！！

【ペチオブ】ペチトーークでリモートワークについて話せたのが結構よかった話【IOMO】 - juriful

議事録

リモートワークを普及させていくためにどうすればいいか(のむらや)

• リモートを普及するには

• そもそもリモートをする意味って何？

  • メリット

    • 物理的な制約がなくなる
    • 採用や通勤など
    • 子供がいる人は送り迎えとかができる
    • 独り言が言える
    • 選択肢があるのは意義があるよね。天気悪い中の移動とか、体調悪い時の移動とか、それだけで体力を消耗して仕事にならなくなったりするし。
    • 選択肢が広がる
    • 個人的な開発効率は上がる
    • リモート２週間やってますけど、生活に目に見えて余裕が生まれた

  • デメリット

    • コミュニケーションが不便
    • 直接話せた方がコミュニケーション取りやすい
    • 業務効率が落ちる（業務以外の時間などは多く取れるが）
    • 自己管理できないのでw、リモート苦手な方かなー。
    • 仕事と私生活の境目がなくなる。
    • 教育はリモートでは難しそう

• リモートが苦手な人は、無理せずリモートしない方が良さそうな気がする

• 「選択肢を増やす」がキーになりそう

• リモートを許さない、理解をしないという風潮は変える必要があります

• リモートできてなかった会社は、普段は使わないとしてもリモートできる準備はしておくべき。

  • いざというときに通勤を強要する非人道的な現場になるか、業務が破綻するかに陥るから。

• 結論：コロナの影響でこれから流行るかも

  • やるなら今

頑張った結果、昔からある設計原則に落ち着いた、みたいな話(hilomagi)

• 頑張って考えても、結局過去に考えられたパターンに行き着くことが多い

  • 昔から残ってる知識はすごいよね。

• 逆に本に書いてあるからみたいな、盲目的に使うのはよくないよね

• SOLID原則どれが一番重要？（推しはだれ？）

  S	O	L	I	D
  3	5	0	1	3

  • 設計判断の重要性はO、モデリング観点での重要性はS、破ったら論外なのがL。
  • DIPちゃんは目立たないけど、いざというときすごい気が効く娘なんですよ！！
  • 最近Oにお世話になってるので
  • Lは確かに場合によっても許されないと思ったけど、あんまり継承しないから選ばなかった
  • SとDは、むしろ一番スポットあたってるイメージw
  • Oを達成するために他の原則がある。
  • DIPでしょDIPなかったらインタフェースいらないくらい大事
  • クラス階層と型階層を同一視する場面ではL必須。それを一致させなくてよい特殊な場面に限って言えばLは任意。かな。Lが前提になると言う意味で重要には同意。

コミットメッセージをどんな感じで書いているか聞きたい(yuki)

• 英語でかけそうなら英語、わからなかったら日本語。

• なるべく英語では書いているけど、表現しにくかったりする時は日本語で書く

• ターミナルで書く時に日本語で書きにくいから

  • そもそも読めない環境もあるので

• 「add: XXXX機能を追加」しか書いてない

• 英語で書いてたけど、ちょっと前から日本語に統一しました

• github(公開ライブラリ) にあげる場合は海外の人にも使ってもらいたいので英語。仕事ならみんな日本人だから日本語でいいんじゃない？

• 結局見るのはプルリクだから、そこまでコミットメッセージになこだわらなくていいんじゃない？

• 最近は conventional commit + commitlint 推しです

  • Conventional Commits
  • commitlint

• 英語で読みづらくなるくらいなら日本語

• なるべく英語で。MBCS使えないコンソール作業とかを考えると、日本語よめなくてなく ;_;

• add header とか英語です

• 妥協案。1行目サマリは英語。 空行はさんで、3行目以降は日本語。というのはあり。英語読まない人も少なくないし、自分もめんどうなので。カテゴリプレフィックスは有能。

• gitのコミットのチーム方針にもよる

  • issueのタイトルと同じにしたい
  • ローカルのコッミットメッセージはなんでもいい
  • isuueがわかるように

• 絵文字prefixの人も

  • Gitのコミットコメントを絵文字Prefixにして楽しく開発する - Qiita
  • 絵文字は、意図が正しく伝わらなくなりやすいと感じるので、やだなー

• 自分の居るチームでコミットメッセージを読んでる人、そもそもそんなに居なさそう・・・

• Gitのコミットメッセージの書き方 - Qiita

• コミットメッセージって本でいう目次なんだなって思いました

• 1行目に要約、3行以降にに詳細。は有用。あと、チケット番号とかURIも入れておくとよい。

• チケット番号は、conventional commit とセットでくっつけてますね。後からの追跡可能性が段違い

• 規模の大きい開発ではコミットのルールが大切。

• ビルド通らなくてもコミットすることはあるよ

  • わかるように目印を付けて
  • ローカルでは作業メモのようにコミットしたりする

• feat: #1234 うんたらみたいな書き方してます

• 開発中のセーブポイントみたいな感覚でローカルではコッミットする

• ローカルではissueを細かく分けて達成すればコミット、最後にまとめてリモートにあげる

• コミットは最後の最後にする。めんど臭いから。

  • 私もテスト通るまでコミットしないから、コミット少なくなりがちですね。

• 新規作業はブランチ切って、broken commit する時はそこから更にブランチ切って分岐しまくる派。失敗と分かったブランチごと、ぽいしたりする。

• リスクヘッジのために毎日どんな粒度でもいいからpushする運用にすれば安全かも？

• リモートワークのときには作業の共有にもできるかも

• masterに混ぜるときにmergeかrebaseか

merge	rebase	push（featureブランチなしw）
3	5	2

• pushしようとして、競合した時pull(merge)なのかpull --rebaseなのかで判別できそう

DDDの導入的な話を聞きたい(しばてぃ)

• チームでDDDやってる？なってない？

  • YES: 4 NO:5
  • DDDはちゃんと出来てないけど、DDDに触れた事で少なからず自分のモデリング能力は上がった(と思いたい)ので、加えてDDD戦術だけ取り込んでても、DDDに触れる前の設計と実装よりはマシになった。はず。
  • ユビキタス言語を見つけてドメインモデルを得て、それをコードに落とし込むをやってるかと言うと、全く出来てないです。
  • チームでDDDやっているという合意はないが、パターンは勝手に持ち込んでる。一応のドメイン層を機能によっては持とうとしている。

• どうやってDDDが取り組める環境になったのか

  • 設計しないと後が辛いという話をメンバーにした。
    • まず自分が実際にコードで書いて、布教した。
  • DDDを実際やっている会社に入る。
  • 言って共感してもらえなければ、 チームポリシに反しない範囲で 草の根で実践して、価値を理解してもらうのが結果的には近道になるよに思う。価値を認めてもらえるところまで行くと、トップダウンに展開する道が開ける。よに思う。
  • 草の根で実践となると、やっぱりDDDの戦術部分を持ち込むことになりますよね？その場合、フレームワークのスタイルからの逸脱が必要になると思うので、最初の1歩がすごく難しそう。
  • DB構造が、利用者のメンタルモデルとほぼ一致しているなら、scaffold の自動生成で問題は少ないので、開発コストを考えるとあり。

ICONIX やDDD が知りたい(wata)

• DDDってそもそもなに？

  • モデル（ドメインモデル）をベースにして、コードに落とし込む
    • ドメイン（実際の業務）をコードに反映したい
    • モデルとのギャップがない実装にしたい

• 戦術的設計は、ドメインモデルの設計手法ではなく、構築したドメインモデルをドメインオブジェクトとして実装するための方法の一つに過ぎない感がある。ドメインモデルの設計手法については、ほとんど何も語っていない。ここは、オブジェクト指向方法論とか概念的モデリング手法とかの領域になっているのが現状であるように思える。

• 「ドメインから駆動しよう」「そのためにモデルと実装を一致しよう」「一致させるためにこういう実装テクニックが有効だよ」みたいな流れだと思ってます。

• 戦術的設計というか実践上のパターンはDDDの本質とは大きく距離があるよね。ドメインを隔離してドメインに集中しやすくするための手段としては有効ではあるけれど。

• ドメインを実現するためのモデル(＝ドメインモデル)と、その実装を対応させる + ドメインモデルによって、開発者に閉じない相互会話を実現するがDDDのコアだと思ってます

  • 開発者に閉じないって何？
    • 利害関係者一同で同じ目標を共有する、というのがDDDの肝。そのための、モデル・コード一致という手段があり、ユビキタス言語だと思ってる。モデル・コード一致は、手段でしかない
    • 技術者同士だけじゃなくて、コードが読めない人でもわかる。ドメインモデルによって。
    • ドメインモデルがあることによってコードが読めない人でもシステムがどうなっているのかがわかる。
    • そのための、モデル・コード一致という手段であり、ユビキタス言語だと思ってる。

• DBを共有する3つのシステムと2つのチームという状況なので、開発者の間の対話の為だけでもドメインモデル欲しいなぁと思ってます。

名言

「宵越しのブランチは持たない」
「高度にコードに落とす」
「論よりコード」