トーク

オープンロジでは約10年もののPHPアプリケーション(Laravel)が日夜動き続けています。
コードの行数は数十万行あり、データベースのレコード数も数十億程度あります。

弊社ではアプリケーションエンジニアの採用を積極的に進めています。
巨大なコードベースかつ物流のドメイン知識は複雑怪奇なので、少しでも認知コストやレビューコストを下げ、安心して開発を進めていけるようにCI整備が肝要です。

今回は具体的に取り組んでいることについて幾つか紹介します。

開発環境構築整備 / CI整備 / Linter整備 / 静的解析整備 / UnitTest整備

リリースはサービスの価値をお客様に届けるための重要なステップです。しかし、特に長期間開発されてきたプロダクトでは、そのリリースのプロセスに課題を抱えていることが少なくありません。
サイボウズのグループウェアGaroonも、ビッグバンリリースが常態化している、機能がリリースされるまで時間がかかる、リリース後の障害の改修にも時間がかかる、複数チームが利害関係者になっているリリースプロセスが複雑で制約が多い、といった課題を抱えていました。
しかし、ここ1年でGaroon開発チームが行ったリリース改善は一定の成果を得ることができました。例えばリリース回数だけをとっても、ここ数年のリリース数が月1～2回であったのに対して、最近では月14回のリリースができています。
本セッションでは、私たちがリリース改善への共感をどのように得て、どのような改善を行い、どのような成果を得ることができたのかを紹介します。

■ スライド
https://speakerdeck.com/tamayama0111/typescriptdatutarafetobedotutimoshu-kerusi-le-ziyanai-typescripter-vs-phpernozhan-i

■ あらすじ
「TypeScriptだったらFEとBEどっちも書けるし、楽じゃない？」そんな一言からこの戦いは勃発した。
今PHPer vs TypeScripterの戦いが始まる!

本トークではPHPのメリット・デメリットとTSのメリット・デメリットを話します

■ 内容

• PHPでAPIを作る上での優位性
• TSでAPIを作る上での優位性
• 性能面での比較
• バグの産みやすさの比較
• ユニットテストの比較

■ 対象者

• フロントエンドもバックエンドも書いている人
• TSに興味があるPHPer

あなたのアプリケーションでは、複数のコンテキストでロジックを共有することはありますか？

例えば、ECサイトの商品ページでは、管理者が商品の内容を変更して事前にプレビューしたいケースがあります。
ここには一般ユーザーが商品ページを閲覧するコンテキストと、管理者がプレビューするコンテキストが存在します。

プレビューのロジックはどこにあるべきでしょうか。
管理者コンテキストでは、一般ユーザーのロジックを再利用すべきでしょう。完全に分離してしまうとプレビュー機能が一般ユーザー向けのロジックに追従し続けるコストが発生します。
一方で、一般ユーザーコンテキストではプレビューのロジックは不要です。プレビュー機能を改修するたびに一般ユーザー側までテストしたくありません。

複数のコンテキストでロジックを共有する場合、コンテキスト間の依存関係を適切に制御するにはどう実装すべきかを考えます。