タグ

リファクタリングに関するmather314のブックマーク (9)

  • 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

    このの概要 「ITエンジニア大賞2023技術書部門で大賞受賞! 書は,より成長させやすいコードの書き方と設計を学ぶ入門書です。 システム開発では,ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる,コードの影響範囲が不明で変更すると動かなくなる,新機能を追加したいがどこに実装すればいいかわからない……。 変更しづらいコードは,成長できないコードです。ビジネスの進化への追随や,機能の改善が難しくなります。 成長できないコードの問題を,設計で解決します。 こんな方におすすめ コードの設計スキルに興味がある人 日々,悪いコードと向き合っていて改善したい人 より良いコードを書きたい人 1 悪しき構造の弊害を知覚する 1.1 意味不明な命名 1.2 理解を困難にする条件分岐のネスト 1.3 さまざまな悪魔を招きやすいデータクラス 1.4 悪魔退治の基 2

    良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
    mather314
    mather314 2022/04/28
    電子書籍で購入して読んでる。やはり「悪い例」「失敗するケース」から学ぶのは大事ですね。
  • モジュールの構造化 · An Introduction to Elm

    Webアプリケーションの構造化 前のページで述べたように、すべてのモジュールはその中核となる型のまわりに組み立てられるべきです。ブログ投稿のWebアプリケーションを作っているとすると、私なら次のようなモジュール構成で作り始めると思います。 Main Page.Home Page.Search Page.Author Model型を中心にして、それぞれのページに対応するモジュールがあります。これらのモジュールはElmアーキテクチャに従っており、Modelとinit、update、view、それから必要に応じて作られた補助関数からなります。ここで、モジュールがどんどん長くなり続けるのに任せていますが、そのまま必要な型と関数を追加し続けます。もし自分がたくさんの補助関数を持つカスタム型を作ったことに気付いたら、そのとき初めてそれを別のモジュールへと切り出しても構わないといえるでしょう。 いくつか

  • 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ

    システム開発の世界において「技術的負債Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

    【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
    mather314
    mather314 2020/06/23
    なるほど / “Ward の言う負債の悪影響とは開発と共に得られていく知識、理解と目の前のシステムとの乖離が引き起こす生産性低下のこと”
  • 技術的負債への後悔と返済|Seiji Takahashi@ベースマキナ

    反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの1つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負

    技術的負債への後悔と返済|Seiji Takahashi@ベースマキナ
  • Kyash iOSアプリの大規模リファクタリングの話 - Kyash Product Blog

    こんにちは、クライアントエンジニアの@kobakeiです。元々KyashAndroidアプリを立ち上げから担当しており、昨年末よりiOSアプリを開発しています。 Kyashは3/5 (月)に初のメジャーバージョンアップとなる2.0.0をリリースし、大幅にデザインをリニューアルしました。実はiOSチームはそれよりも前、昨年末から大幅なアーキテクチャの見直しとリファクタリングを並行して行っていました。今日は皆様にその裏側をご紹介したいと思います。 当時のiOSアプリが抱えていた課題 KyashのiOSアプリは2017年の4月にリリースされましたが、開発期間は意外に長く2016年2月に最初のコミットがGitHubに入りました。そこから様々なスクラップ&ビルドやiOSチームのメンバーの増減を経てリリース、そして現在に至るのですが、その結果「品質が安定しない」、「普段の開発効率が上がらない」という

    Kyash iOSアプリの大規模リファクタリングの話 - Kyash Product Blog
    mather314
    mather314 2018/03/20
    これ / “CEOやプロダクトマネージャも技術的負債の返済にコストを割くことに理解があります”
  • データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳

    岡山にはオープンセミナー岡山と言う最高のイベントがあります。 okayama.open-seminar.org 昨日は id:t-wada さんや id:naoya さんの資料がホットエントリー入りしてました。 この登壇はそれと同じイベントになります。 その他の方も超豪華講師陣の中で、私が出来る精一杯の経験も踏まえたお話をさせていただきました。 speakerdeck.com この中で出て来る、データベースリファクタリングは当に素晴らしいです。 OracleベースなのですがMySQLだろうがPostgreSQLだろうが必ずためになるです。 ですが、このは既に廃刊になっており再販の予定もありません… 僕は後世に絶対必要なの一つだと思っているので再販のためにも皆さんの要望の声を上げていただけるとうれしいです。 そしたらもしかしたらが世に復活するかもしれません。 またSQLアンチパタ

    データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳
  • 技術的負債とどうやって戦うか - Qiita

    プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」というには下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう

    技術的負債とどうやって戦うか - Qiita
    mather314
    mather314 2016/09/27
    「起こるかもしれない」リスクに対して「起こらないように」対策をするのに、何故か偉い人は「ほら心配してたことは起こらなかったよ」と言う。
  • RubyのリファクタリングでNull Objectを使ってコードをスッキリさせる方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

    前回、Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法という記事を書いて、いい反響をいただいたので第2弾を書いた。 Ben Orenstein氏の講演で話されていた前回のとはまた別のリファクタリング方法。元ネタはこちら。 github.com 【リファクタリング前のコード】 class JobSite attr_reader :contact def initialize(location, contact) @location = location @contact = contact end def contact_name if contact contact.name else 'no name' end end def contact_phone if contact contact.phone else 'no phone'

    RubyのリファクタリングでNull Objectを使ってコードをスッキリさせる方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
  • メタプログラミングをして割に合うかの判断基準:処理を1箇所に局所化できるか - 2014-01-16 - ククログ

    毎日他の人のコミットをながめる文化で生活していると、理由は浮かばないけど「ん?このコミットはなんか気になる」と感じるようになります。それは、新しいことを知ることができたコミットだったり、真似したくなるようなコードが入っているコミットだったり、なんかまずそうな気がするコミットだったり、様々です。 「ん?」と感じてコミットを見直してみても、何が気になったか自分でもすぐにわからない場合があります。そんなとき、気になったことをコミットした人に伝えるために、コミットへのコメントをまとめ始めます。「コミットした人に伝えるため」というように、他の人に伝えようとすることがポイントです。他の人に伝えるためにまとめようとすると、思いの外なにが気になったかまとまるものです。 今回は、メタプログラミングを使ってコードを整理したコミットで「ん?」と感じたときのことについて紹介します。このおかげで「メタプログラミング

    メタプログラミングをして割に合うかの判断基準:処理を1箇所に局所化できるか - 2014-01-16 - ククログ
    mather314
    mather314 2014/01/17
    “メタプログラミングでやっていることの詳細を知らなくても使えるくらい抽象化しているか” なるほど。それは抽象化レイヤには必要な考え方だよな。
  • 1