タグ

あとで読むとRefactoringに関するmasa8aurumのブックマーク (7)

  • 技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(前編)

    技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(前編) ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90%以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命

    技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(前編)
  • たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita

    はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話: この記事の旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは?リファクタリング耐性低くない?みたいな話は度外視してます。

    たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
    masa8aurum
    masa8aurum 2024/03/19
    ・主にレガシーコードで単体テストを書く際のハードルになりがちな「依存関係の排除」について
  • リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog

    どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①~④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図:レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか?」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私

    リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
    masa8aurum
    masa8aurum 2023/11/29
    ・まず現行仕様を明確にしよう /「汚いソースコード」の例が書かれていて、それも参考になる
  • 非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに? ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ

    非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
    masa8aurum
    masa8aurum 2022/12/13
    技術的負債がある状態を「収納がぐちゃぐちゃになっており、スムーズに物を取り出せない」と喩える
  • 「無人化システム」を駆逐する組織マネジメントとエンジニアリング

    弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい

    「無人化システム」を駆逐する組織マネジメントとエンジニアリング
    masa8aurum
    masa8aurum 2021/01/21
    「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」を無人化と呼んでいる / >システムを維持するかどうかの決断はマネージャーや事業責任者には行わせません。
  • このFat View Controller、あなたはリファクタリングできますか? - Qiita

    iOS アプリ開発において、 Fat View Controller はよく知られたアンチパターンです。 iOS アプリ開発では View Controller が大元にあるので、 View Controller になんでもかんでも実装していると、どんどん View Controller が肥大化してしまいます。 Fat View Controller には、たとえば次のような問題があります。 UI とロジックが分離されておらずテストしづらい。 コードの見通しが悪く、可読性が悪い。 状態管理が複雑になり、修正時の影響範囲を見通しづらい。 みんなで同じファイルを触ることになり、コンフリクトが起こりやすい。 そんな Fat View Controller との戦い方の知見を共有し合うために、たくさんのiOSエンジニアで同じ Fat View Controller のリファクタリングに取り組んで

    このFat View Controller、あなたはリファクタリングできますか? - Qiita
  • DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える!

    DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか? 曽根壮大(soudai)さんによる寄稿です。 こんにちは。そーだい(@soudai1025)です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ

    DBの寿命はアプリより長い! 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える!
  • 1