はじめに
この記事は、2020/02/10に開催されたPHPerKaigiの1日目のセッション中にまとめたメモをつなげたものです。
些細ですがアウトプットのつもりで書いています。
もっと気軽にOSSにプルリクを出そう
by DQNEO(ドキュネオ)さん DQNEO
コントリビューションのイメージは？
- まずしっかり使いこなしたりする ←ハードルが高い
4つの着眼点
-
作者の関心ゾーンの外側を見る
Guzzleのエンドポイントミスのプルリクを例に
- プルリクエストのコメントは、否定から入らないようにする。
- 深い知識が必要なプルリクエストでもない。ちょっとした着眼点で修正ができる
PDOのDocコメントの修正を例に
- エラーケースの書き忘れ
- Nulになるケースが漏れている
- Unionの書き忘れ
- 単純に英語の間違い
→躊躇しないですっとPR出すのが大事
→そうすることで、次のモチベーションにつながる
-
業務で得たノウハウを横展開
→業務で培ったバージョンアップ周りの知識を他のライブラリに適用
→バージョンアップに関するプルリクエストを投げまくってみる
-
使ってなくてもコントリビュート
- 使われていない変数
- 子クラスでのreturn使忘れ
-
ダメ元でやってみる
- ドキュメントの英単語が難しいから別の単語にしてみる
→ネイティブの人にとっては普通だし却下されると思っていた
→ただ、向こうの人は英語を第二言語としている人に対しても考慮をして修正を受け入れてくれた
感じたこと
僕も一時期、Gatsbyのテンプレートに対してビルドコマンドに強制的にnpmが使われてyarnを常用している人はうまくビルドが出来ないというバグ(?)を発見したときにPRを出そうとしたが、結局怖くてできなかった。。。
でも、やっぱり俺OSSにプルリクなげたぜ！！！！っていう実績は欲しいという気持ちは強い。
どんな些細なことでも、自分のスキルを前面に出そうとはせず、まず出してみること、怖がらないことという気持ちを持って出してみようかなぁ。
あと、やっぱりプルリクって全部英語で書かなきゃいけないっていうちょっとハードルが高いですよね。
僕は幸い英語に対して煙たい気持ちはないのでこの辺はクリアできそうだが、ここもなかなかプルリクを出すことの壁になっているのだろうか。。。。。
AWS Lambda にCustom RuntimeでPHPを導入したシステムに改修を加えてUT導入まで行った話
by しろぐちゆうま さん yu_mashirou
設計は我々に根付いていない？
- ディレクトリを分けてみたけど、AWSUseCase.phpとか謎なファイルが生まれる
- Lambdaの実装が最上位のファイルに詰め込んである、細かい処理はUseCaseにある
本当にやりたいこと
- 関心ごとの分離
- アーキテクチャ層の展開
- index.phpの役割を最低限にする→そうすることで、機能回収が簡単になる
- そして追加修正
- bootstrapをテストできるようにする
そもそもテストがなかった
- リリース直前まで改修をしていたのでテストを書く暇がなかった
- デプロイしてLambdaのイベントを発火させて実行をしていた
- そこでUnitTestを導入
UnitTestの実行環境をどう作る？
- DockerでLambdaもどきを立てる
残り作業として
- 追加改修とUnitTestの導入をメインになったから課題が山積み
- UMLの精査
感じたこと
１つのクラスに子クラスから多くの参照があり、パンパンに膨れ上がってしまう、しかもテストがない。
こういう状況は自分も仕事やプライベートで開発をしていてもすごくよくぶち当たる問題であり、なんでかって考えたときに、プロダクトを作って早くユーザに提供したいという思いが強すぎるのかなぁと感じました。
新規プロダクトって自分も熱があるうちに作らないとモチベが下がってスピード感がかなり落ちちゃうことが多いので、テストとか関心の分離とかまでは手が届かないんですよね。
でも、将来的に自分も含めてそのプロダクトに関わる人が全員幸せになれるようなコードを書いて、その場しのぎのif文は絶対にダメで、常に設計レベルの話をしなければならないと感じました。
知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか？
by 小山健一郎 さん k1LoW
GOAL
- 途中JOINについて改めて考える
- ノウハウを共有する
開発レイヤー
- サービス理解レイヤー
- アーキテクチャ理解レイヤー
- データストア理解レイヤー
- 環境レイヤー
- コードレイヤー
なぜ開発にスッと取りかかれないか？
- 言語に対する抵抗もない
- ソースもGitで管理されている
- いけそう
- いけない、なぜ？
- ゼロから作るよりも楽なはずなのに…
- ゼロから開発するとき、サービス→アーキテクチャ→データ設計→開発環境→DDD?TDD?コーディング手法→開発
- ↑めちゃ道のりが長い。（開発レイヤー）
- これを踏まえて、途中JOINを考えると…？
- これらのレイヤーは、途中JOINするにしても全て必要。
- どこから切り込むか？→答えはそのサービスを知ることから
サービスを知ることがなぜ必要か？
- 開発の気づきを多くするため
- １つの機能を作るときも、他のサービスや機能との関係、サービスの根幹の考えや関係性がないといけない
データ設計を知る必要性
- だいたいRDBMSとか
- サービスの機能のコアはデータベースのテーブル設計にあると考えている
どのようなコードかを知る必要性
- ソースコードを読むためのエントリポイントが欲しいから→１からコード読むのってつらい
- メジャーなフレームワークを利用している場合に暗黙的に伝えていることが多い
- 経験値や力技で解決しがち
これを踏まえて。。。
技術スタックの知識があったとしても開発開始までには手間と時間がかかる
↓
開発開始までのオーバーヘッドと呼んでいた→これはメンバーの入れ替わりが有る限りは永遠の課題となる
どう解決するか？
オーバーヘッドを小さくするメリット
- 属人化が少なくなるなど
どう削減するか？
-
スコープを絞る
- 例えばログイン機能を作る場合、ログインに関わる部分をサービスの根幹からスコープを絞って知る
- ユーザテーブルを知る、フレームワークを知る、ログインページのURLを知るetc
-
専用のSlackチャンネルを絞る
- 次の人への布石にもなる
-
閉じた開発環境を手に入れる
- 例えばDocker + PHP + SendMailなど
技術の積み重ねによって、汎用的に再現してオーバーヘッドを限りなく小さくできるようになると
オーバーヘッドが少ないことが前提の組織となる
具体的な取り組み
-
STNS
- tomlファイルを修正してマージをするだけで全てのサーバ群へのSSHアクセス権を得られる
- 権限がgit管理されている
- 環境レイヤーのオーバーヘッドを削減できる
-
tblsというツール
- ドキュメント生成ツール
- CIに組み込んでドキュメントの更新忘れを検知する
- ドキュメントとコードをリンクすることができる
- データストア理解レイヤーのオーバーヘッドを削減できる
- brewでinstallできるらしい
まとめ
-
途中JOINでもゼロから開発するときと同じ
- 違うのはサービスの開発フェーズだけ
- 途中JOINのノウハウ=開発開始までのオーバーヘッドをエンジニアリングで解決する
- オーバーヘッドを削減するということは、組織にも影響を与えることができる
- レイヤーが進めば進むほど、自力で解決できる
感じたこと
僕も新卒で入社してからバージョンアップと新機能開発の２つのプロジェクトに途中からJOINをしたので、開発までのオーバーヘッドについてはとても痛感していました。
もともと僕自身の理解速度は残念ながら遅いので、既存のコードとか要件提議書、UMLを読んでクラス構造を理解するのに時間がかかり、焦ってしまうことがほとんどでした。
トータルして見ると、ゼロから全てをゆっくり眺めるよりも時間がかかる上に理解も中途半端になってるなぁと今思うと感じます。
そう考えると、開発開始までのオーバーヘッドを縮めるために途中JOINした人だけでなく、チームのメンバー全員でなるべくノウハウを残し、エンジニアリングで誰でも理解できる環境を整えてあげることがサービスの寿命にも関わるのかなと感じました。
マネジメントで解決することも出来そうだが、エンジニアなのでなるべく自力でエンジニアリングで解決した方が共通認識も得られやすいし、リーダーの負担も減るのかなと感じました。
色々と自分の中で考えさせられるセッションでした。どこかのタイミングでみんながわかる形でアウトプットをしたいです。
