見出し画像
Photo by todaimori_pj111

「【リンケージxセレス】～失敗する開発とその対策～」に参加してきました。

小泉岳人

表記イベントに参加してきたので、感想を記載します。

開発の失敗、対策に対してのLT大会でした。前半は仕事の都合で出席できなかったので、後半からの記載になります。後半の発表が良かったので、前半も聞きたかったです。申し訳ありません。

「アンチパターンから学ぶ教訓と抽象化」

　kudoさんからの講演でした。上流設計でのビジネスアーキテクチャを構築する際に、抽象化の妥当性の検証に時間を取られすぎて、失敗した体験からの学びを報告いただきました。

アンチパターン①：前提条件の曖昧さ
コンテキスト図はMUST。境界が分からないと判断基準が生まれないので、
境界を共有できるようにする。（これは最終形をいきなり決めれないので、いったん前提を置いて詳細化して検証する）

アンチパターン②：検証の機会の少なさ
一発目から妥当なInterface抽象を出そうとしすぎた
⇒検証無くして抽象は語れない。SLAP原則だけでは十分に足りない。アンチパターン①で書いた境界についても、複雑系だと、境界は曖昧なので、それを意識して検証でカバーする。抽象の方向性については具体で検証しないとわからない。

逆に良かったこと
問題を聞いた中で、収束に向かっても微妙な事が多い。発散させることで本質的な価値が見つかる

また最後にDXの文脈の中で、『抽象化能力』の重要性についてお話ししていて、管理層は経験・スキルだけでなく、そういった能力もしっかり見つめるべき（新人でも強い人はいる）という話があり、ギクっとしました。

⇒非常に学びの深い内容でした。私は、こういった抽象概念で考える事（言語化すること）を苦手としていて、最近この能力を鍛えたいなぁといつも思っているので、普段から考えている人は、具体的な対応からの学ぶ力が強いなと感じました。徐々にアーキテクチャについても学んでいこう。

「そのリファクタリングで貴様は死ぬ」

　ミノ駆動さんからの講演でした。自分が何故苦しんでいるかわからないリファクタリングのパターンを話してくれました。超素晴らしい内容でした。

チームビルディングをおろそかにすると死ぬ
・ろくに合意を得ずに、リファクタリングを強行すると、機能開発チームから反発を喰らう。リファクタリングプロジェクトはハードルが数多あるので、丁寧な戦略策定と、遂行するためのチームビルディングがベース

書籍リファクタリングの知識だけでリファクタリングすると死ぬ
・技術的負債とは、変更容易性の高いあるべき構造とのギャップ。アプリケーションソフトにおける変更容易性の高い構造とはドメインレベルで高凝集疎結合。DDDや凝集度や結合度等、様々な設計知見が必要

DRY原則を正しく理解せず共通化すると死ぬ
・DRY原則は「意図、目的の重複を許さない原則」。「コード重複を許さない原則」と理解すると間違いなく死ぬ。
（静的解析ツールのコード重複を検出する機能を鵜呑みにすると死ぬ）

目的の違う者同士を抽象クラスやinterfaceで抽象化すると死ぬ
・具象クラスは同一目的のバリエーション。目的の等しい者同士のみ抽象化可能

再利用性を追いかけすぎると死ぬ
・たとえば、ゲームだとUnreal EngineといったFWを使って色々なゲームが作られている。FWは再利用性を追うべきだが、アプリケーションはドメイン特化なので、再利用性はほぼない。(ストⅡの要素をドラクエに再利用しようとしてもクソゲーになるみたいな理解）
再利用性を無理に追いかけると容易にDRY原則に違反して死ぬ。

設計しすぎると死ぬ
・設計は必要だが、実装して動作して気付くことも多い。良い構造はたった一度の設計では見いだせない。設計と実装のフィードバックを回すことが重要

⇒ １時間くらいで作ったと話ですが、超重要な内容でありつつも、シンプル/関係でウィットにも富んでいて、非常にわかりやすいLTでした。このLT。かなり神内容で、皆にも見てほしい。。説明後の話でミノ駆動さんはプロダクションコードを練習環境でリファクタリングしまくって、デザインパターンの理解を進めていたという話がありました。素晴らしい！！

「失敗から学ぶ技術的負債との正しい歩き方」

　そーだいさんからの講演でした。これ伝説的なLTでないか？と思えるくらい感動する内容でした。

廃墟とも呼ばれる技術的負債はエンジニアを滅ぼす。我々が技術的負債と共に歩むためにはどうすればよいかというテーマでのLTでした。


進捗の麻薬とHowの呪い
-「何のためにリリースするの？、何のために監視するの？」といった目的部分が一番大事
-リリース手順を作りました！となると、リリース方法を出来るだけ変更したくないという力学が働きやすくなる。こうやって作業が増え、仕事が増え、リソースがどんどん足りなくなる。作業はあるので、仕事をした気になり、たちが悪い


プロダクトと向き合え
・技術的負債の話をすると「創りなおすぞ！スクラムでやろう！DDDでやれば上手くいく。」といったHow特化の意見がでるが、そんなことはどうでもよくて、目の前のプロダクトの現実と向き合うことが重要。サービスの価値があるから仕事して給料がもらえる。自分で価値を提供する所にフォーカスする。
・問題はプロダクトの中にあるし問題の解き方はプロダクトに左右される。
自分たちのサービスが何なのかを考えることが大事

リファクタリングとリアーキテクチャとリプレース
リファクタリング：振る舞いを変えずにコードをかえる
リアーキテクチャ：サービスを変えず、アーキテクチャから変える
リプレース：サービスから変える

→リファクタリングは四の五の言わずやる。リアーキテクチャが、エンジニアとして腕の見せ所で重要。パフォーマンスやリリースサイクルの改善などがやりたい時はリアーキテクチャ。リプレースをやりたいと言っても実はリアーキテクチャで十分な場合が多い。リプレースはだいたい失敗するし、真に必要な場合はない。リアーキテクチャの後に行う方が安全。どうしてもやるのであっても自分たちのコアバリューの部分から小さくやる。結局サービス、ドメインが重要

リリースと品質について
「リリース優先なんで。。と負債が残ることがあるが、YAGNIを言い訳に使ってはいけない。リリースを優先することと設計品質を妥協しないことは共存する。この事は筋トレのように鍛えると成長していくが、妥協すると鍛えられない。妥協しないで頑張るとだんだん出来るようになる。問題にフォーカスしたうえで解決する。これを当たり前にやる。当たり前の積み重ねの先に共存がある
・ちゃんと投資は回収する。負債は作らないでなく、ちゃんと返済することが重要。自分で負債を作ったら必ず返す。自分で返せない場合は責任をもって次の人につなぐ。

最初からうまく作れるか
　Unixの哲学にも「システムは２度死ぬ」と書いてある。正しく小さく作ってすぐ捨てるが大事。３回目が成功なのでさっさと２回作って捨てる。
　セカンドシステム症候群にならない。皆すぐ創りなおしたくなる。肥大化する。そうならないよう、小さくリリースするを徹底する
・リリースされていないものは全部在庫。

技術の選び方
・どうでもいいことは流行に従い重大な事は標準に従い、ドメインの事は自らドメインフレームワークを設計し実装する。
・自分たちの解くべき問題を考える⇒世の中のHowが解いた問題を知る。(新しい技術が出てきたときにどういうWhyを解くためのHow何だろうと考える）

愚者は経験から学び、賢者は歴史から学ぶ。 byビスマルク
優れた芸術家は模倣し、偉大な芸術家は盗む　byピカソ

・10代でしかできない事もあるが勉強は今からだってできる。今からやるのが一番早い。手を動かした者だけが世界を変える


⇒本当に素晴らしい内容でただただ、驚きました。短い時間に本質的な内容が分かりやすく詰まっていて衝撃を受けたLT？でした。本当にありがとうございました。

感想

　後半しか聞けなかったのですが、ものすごくよい内容でした。私は設計・実装はやらないのですが、それでも超参考になりましたし、今日聞けて本当に良かったと思える会でした。。前半聞けなかったのがとても残念です。

ありがとうございました。


この記事が気に入ったらサポートをしてみませんか？