レガシー コード から の 脱却。 O'Reilly Japan

【ボードゲームレビュー】 レガシーコード(LEGACY CODE)

レガシー コード から の 脱却

最初のレガシーコード危機(P35まで)については、開発者よりもディレクターやクライアント(予算管理者)に読んで欲しい内容だった。 これで事前知識の共有ができれば、保守性を高めるために時間をかけることに躊躇がなくなるし、クライアントとのコミュニケーションで齟齬が生じても、この本を引用すれば、分かってくれる範囲が大きくなりそう(よっぽどバカじゃなければ)。 以下ソフトウェア業界のプロジェクト分析データで面白かった数字。 この本は「 アジャイルソフトウェア開発宣言」の2つの弱点を補うことができるようだ。 その弱点は「 具体的なアドバイスが無いこと」と「 本番稼働に適用されない」ことらしい。 そして著者は、これを引き継ぐように、「はじめに」のセクションでこう書いている。 私は本書で 9つのプラクティスを提案する。 それらのプラクティスは、アジャイル開発手法のXP、スクラム、リーンから来た物だ。 プラクティスをただ適用するのではなく 理解した上で適用できれば、書いたコードが将来レガシーコードになるのを防げるだろう。 続く目次を見ると、この本はまず 「A. レガシーコード危機」について説明し、その後に前書きに記された通り 「B. 9つのプラクティス」を用意している。 レガシーコード危機 ソフトウェアは生き物 ソフトウェアにも ライフサイクルがある。 生まれ、パッチを当てられ、使われなくなり、死ぬ。 優秀な医師(エンジニア)によって延命治療はできるが、いつかは必ず死ぬ。 面白い表現だったのが、死んだソフトウェアに触れることによって生まれた 「ソフトウェア考古学」。 昔に生まれ、 ドキュメントもなく変数名も適当なソフトウェアを解読することは、 まるで考古学であるという話だった。 テストがない=レガシーコード コードを実行し、意図した通りに 使われていることを検証する優れた自動ユニットテストに高い価値をおいている。 これは私も同じである。 ウォーターフォール ウォーターフォール型マネジメントは元々 製造業や 建設業から来ており、橋の建設や部品の製造では理にかなっているが、 ソフトウェアではうまく行かない。 これがソフトウェア開発で機能しないだろうと言うことは、 提唱者のウィンストンロイスが最初から言及しているそうだ。 レシピと公式 レシピと 公式の違いについて述べているのも面白かった。 例えばパスタを作る時に使うのは 「レシピ」だ。 トマトやコンソメの分量を変えても問題ないし、いれる順番を変えてもまずくはならない。 一方、パンを作る時のイーストと小麦粉、スキムミルクの分量は 「公式」であり、少しでも変えるとパンが膨らまない(経験済み)。 さらに、 エンジニアの業務は「レシピ」に沿って料理するような物であり、公式が用意されている物ではない、と言っている。 とても納得。 さらにそのあとの部分でも、科学や工学と異なり、 ソフトウェア業界には完全な標準や慣行がない、という表現もしている。 CHAOSレポート CHAOSレポートは、スタンディッシュグループ(アメリカの調査機関らしい)がソフトウェア業界におけるプロジェクトの成功比率などについてまとめたレポートである。 そもそも成功・失敗の客観的な基準を設けるのが難しく、 このレポート自体の問題点についても言及しているが、それでもなお、大きな資金があるプロジェクトでさえも、 失敗が多い業界であることを最後に断言している。 レガシーコード危機での英知 レガシーコード危機のなかでも触れられていた細かい英知をまとめる ・無駄なコメント(何をしているのかをまんま書く等)は不要 ・メソッド名に全てを込める ・ 今回のまとめ 最初のレガシーコードの危機に関する著述に関しては、エンジニアのみならず、予算管理者に読んで欲しい内容だった。 次回からは具体的なプラクティスに入りそうなので、さらに楽しみ。

次の

デブサミ2020「レガシーコードからの脱却」講演メモ #devsumi

レガシー コード から の 脱却

常に連続的な成長を求められるのがスタートアップ。 だからこそ、発生する「技術的負債」の解消は後回しにされ続けることが少なくありません。 会社が成長期に入っていくと、その後回しのツケが働くエンジニア達に回ってきます。 もっと早く良いサービスを出したい。 その気持ちとは裏腹にレガシーコードはエンジニア達の毎日を圧迫していきます。 リファクタリング等を通じて、その解消を行いたい。 でも会社の成長を止めるわけにはいかない。 スタートアップで働くエンジニア共通の悩みではないでしょうか。 日本有数のネット印刷サービスを提供するラクスル株式会社では、そのレガシーコードに関する悩みに、「独自の方法」で立ち向かっています。 生放送に参加し、一緒に「技術的負債への立ち向かい方」を考えていきましょう。 制作会社を辞め、システム開発で起業。 しばらくアパレルのECや航空券予約販売などのシステム受託開発業を行う。 その後、モルガン・スタンレー証券会社に入社。 約7年間、主に債券の取引(現物・デリバティブ・仕組債)のシステム開発を行う。 その後、DeNAに入社し、ゲームプラットフォーム事業やバイオテクノロジー(遺伝子検査)のサービス開発のリード経て、2015. 10よりラクスル株式会社にてシステム部部長に就任。 2016. 3より同社CTOに就任。 現在システム部のマネージメント、及びアーキテクトを務める。

次の

楽天ブックス: レガシーコードからの脱却

レガシー コード から の 脱却

レガシーコードとは• レガシーコードとは?• 綺麗なコードは有用だが、テストがなければレガシーだ• 保守または拡張が困難なコード• 定義は様々• 議論の時はまず共通認識をとるのが大事• 理由は問わず、修正・拡張が難しいコード• 使われるソフトウェアには変更が必要になる• 原因は急ぎすぎている、たくさん作ろうとしている、読みやすさより書きやすさを優先している• つまり品質を犠牲にしている• 品質は検査ではよくならない、最後にテストしても仕方ない• やるべきことは問題を作り込まないこと、つまりレガシーコードを作らない• ソフトウェアを生み出す成果を決める要素• 問題設定力• 開発力• チーム力(組織力)• コードだけ綺麗に書いたり、開発プロセスだけちゃんとやっていればよいわけではない• レガシーコードを最初から作らないようにするには、具体的にはどうすれば?• レガシーコードを作らない9つのプラクティス• やり方より先に目的・理由・誰のためかを伝える• 小さなバッチ(単位)で作る• 継続的に統合する• お互い協力し合う• CLEANコードを作る• まずテストを書く• テストでふるまいを例示する• 設計は最後に行う• レガシーコードをリファクタリングする ScrumとXPからプラクティスが抽出されている。 やり方より先に目的・理由・誰のためかを伝える• 役割の違い• プロダクトオーナーの責任• 開発チームの責任• WhatとHowを分断する• 何を欲しいか、なぜ欲しいか(What)は顧客やPOの領域• やり方(How)は開発チームの役割• 物事のやり方は1つではなく、やり方ごとにトレードオフがある• やり方を命じされると代替案が出せなくなる• 結果として手続き的なコードになりがち(結果的にオブジェクト指向にならない)• 双方が創造的に協調することで無駄が減る• 作る上で重要なのはコンテキストを共有すること• ユーザーストーリー• 何が・何のために・誰のために存在するかを1文で示したもの• 機能について会話できるくらいの辛うじて十分なドキュメント(仕様書じゃない• 知識はドキィメントではなく、コード(テストも含)にまとめるべき• ストーリーが限定的でテスト可能になる(受け入れ基準と自動化)• シンプルにまとめて追加はあとで行う• ちょっとずつ進めることで良い設計が浮かび上がってくる 小さなバッチで作る• 鉄の三角形(Quality, Cost, Deliverly, Scope)• 同時に守れるのは2つまでと言われる• Qは落とすべきではない• QCDSの何を調整するか• Q(品質)を下げると、あとで何倍もの時間を使うことがある• C(コスト)を調整するとは、すなわち人を増やすことにつながる• ただし人を増やしても、オーバーヘッドがあるのでリニアにスケールしない• D(時間)を調整してもよいが、多くのビジネスは時間が重要• つまり一番調整すべきなのは「スコープ」• およそ半分の機能はほとんど使われていない• スコープを調整して価値(大事)のあるものが順に進める• タイムボックスによるアプローチ• 固定の期間の中でタスクに取り組む• 1 week• タスクの分割になれるまでは機能しやすい• ScrumやXPのやり方• 長い期間で大きなウソをつくのではなく、短いイテレーションで小さなウソをつく• 同じリズムを刻むことで負担を少なくして、異常に気づく• 日々の仕事も同じ• リソース効率とプロセス効率• 1サイクルのリズムが長くなると、リソース効率化を目指しやすい• 並行タスク・役割分担・フェーズが増える• 1サイクルのリズムを短くすると、プロセス効率が上がる• モブプロ=究極の1個流し• いくら人を働かせても、完成しているものが0なら、ビジネス価値はない• 難しそうなバックログはモブで、など結構モブを使っている現場は増えている• ソフトウェアの評価• ソフトウェアの評価は顧客にとっての価値• 価値は完成してはじめて価値になる• 部分最適化を避ける• 効率より効果を重視• フィードバックサイクル• 小さなバッチの方がフィードバックの回数は増える• スプリントレビュー、レトロスペクティブ... 顧客やPOと同席することでフィードバックの回数を増やす• そのためにビルドの高速化も大事• フィードバックへの対応をサポートする文化が必要• 価値やリスクに応じて取捨選択する フィードバックによって価値を高めていく CLEANコードを作る• 品質は検査では上がらない• よくないコードの特徴• 重複コード、長すぎるコード、巨大なクラス、長すぎるパラメーターリスト... よくない例をあげるとキリがないので、模範になるパターンを覚える• CLEANコードとは?• Cohesive 凝集性• それぞれの部品は1つのことだけ扱い、1つに集中する• 理解もバグも見つけるのが簡単• Loosely Coupled 疎結合• オブジェクト間の関係を明確な意図を持った状態に保つ• テストや再利用、拡張が簡単• Encapsulated カプセル化• 何をやっているかに名前をつけて、どう動くかは隠す• あとから変更するのが簡単• Assertive 断定的• 好奇心旺盛を避ける• Non redundant 非冗長• 同じことを繰り返さない(DRY原則)• バグ修正・変更は1箇所で1回だけすればよい• よいソフトウェアの土台となる5つのこと• これらを意識するとテストしやすくなる• CLEANとテストでバグ発見の時期をシフトレフトする• 設計の段階でバグを見つければ5分で修正できる• テストの段階だと修正に1日、、、本番リリース後だと数日、、、• そうならないようになるべく早期からテスト可能な状態にする• 明日のベロシティのために、今日品質を上げる• 速度は日々の積み重ねでしか早くならない• CLEANコードは理解しやすく取り組みやすい• 結果として総所有コストが下がる、逆の状態が技術的負債• すばやく働くということは「きれいに働く」ということ• これって"5S"だった• 整理、整頓、清掃、清潔、躾 レガシーコードからの脱却まとめ• 使われるソフトウェアは変更が必要になるので、コードは変更可能になるように書くべき• プロダクトオーナーは、目的、必要な理由、誰のためのものかが伝わるようにする• 要求は意味のある小さな単位にして重要なものから作る• 開発チームは小さなバッチで作っていく、作るときはPOと協力する• コードはTDDで書く、テストはふるまいを例示、テストも含めてCLEANを満たすように作る• できあがったものは1つずつ統合していき、常にデプロイ可能な状態にする• 1度作ったら終わりではなく、必要に応じて設計やコードを見直す、良い設計は創発する、子のときテストがあることが重要.

次の