実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット） 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
freee 会計に残る 400ファイルの CoffeeScript を decaffeinate を使って書き換えた話 - freee Developers Hub
こんにちは、freee会計でエンジニアをしている jaxx です。 freee 会計におけるメイン業務とあわせて、会計フロントエンド委員会というフロントエンドに思い入れのある有志で集まった委員会にも所属しており、フロントエンドの技術的負債と向き合ったり、新しい技術導入に向けて意見を交換し合ったりしています。 今回はその改善の一環として freee 会計に残る 400ファイルの CoffeeScript を decaffeinate を使って書き換えた話をします。 freee 会計と CoffeeScript 参考:「10分でわかるfreee エンジニア向け会社説明資料」 freee 会計の開発が始まった 2012 年ごろ Ruby on Rails3 では CoffeeScript が標準サポートされており、freee もそれにならってフロントエンドでは CoffeeScript がメイン
Kyash iOS アプリの履歴画面を SwiftUI でリファクタリングした話 - Kyash Product Blog
こんにちは。Kyash の Mobile チームで iOS アプリを開発している id:muijp です。 Mobile チームでは、日々の機能開発の合間に生産性向上のための取り組みを行っています。この記事では、その一環として行ったリファクタリングの事例を紹介します。 Kyash の履歴詳細画面 Kyash のアプリでは、決済などによるお金の動きが以下のように履歴として一覧できるようになっています。履歴の項目をタップすると、その取引についてより詳しい情報を見られる履歴詳細画面に遷移します。 履歴詳細画面の課題 Kyash では決済以外にも送金・入金・出金など様々な操作ができるので、それによって作られる履歴の種類も多く、2021年5月にリリースした v8.0.0 の時点で22種類の履歴が存在していました。Kyash では MVVM アーキテクチャを採用しており、以下の図のようにそれぞれの履歴
Ruby の oneshot coverage で本番稼働中の Rails アプリの使用状況を収集して不要なコードを発見するための仕組みを導入した話 - DIGGLE開発者ブログ
前置き プロダクト開発は人の手によって行われるものですから、開発サイクルの中で不要なコードを削除し忘れる人的なミスはどうしても発生します。 後から不要なコードに気づき削除する際には、慎重にチェックして本当にコードが使用されていないことを確認する必要があります。ただし、削除に自信が持てない場合、本番稼働中の Rails アプリに障害が発生する可能性も考慮しなければならず、何も影響しない場合はそのままにしておくことも多く、削除が難しい状況も少なくないと思います。 上記状況を打破するために DIGGLE では本番稼働中の Rails アプリのコードの使用状況を収集して不要なコードを発見するための仕組みを導入したので共有したいと思います。 前置き 不要なコードをどのように発見するか Ruby で コードカバレッジを計測する 仕組み導入にあたって悩んだポイント YJIT を有効化した状態で動作するの
https://standfm.connpass.com/event/256786/ GMOペパボではGitHub Enterprise Server を利用しています。 また、CI/CD基盤としてGitHub Actionsを活用してしています。 本発表ではGitHub上に構築したコードメトリクス計測基盤と、それを実現するために使用したGitHubやGitHub Actionsの機能について紹介します。 Links: https://github.com/k1LoW/octocov https://tech.pepabo.com/2022/01/06/four-keys-dashboard/ https://tech.pepabo.com/2022/04/25/code-metrics-dashboard/ https://recruit.pepabo.com/
クラスが増えても大丈夫！成長するソフトウェアを支えるリファクタリングの技術 - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 基盤本部ではさまざまな勉強会を開催しています。先日も、BIGLOBE Styleでその様子をご紹介しました。 style.biglobe.co.jp 「クラスを増やすの、怖くないですか？」 オブジェクト指向プログラミング（OOP）を学んでいた時に聞かれたことです。業務ではJavaやドメイン駆動設計を活用しているので、クラスベースのOOPが題材になることが多いのです。OOPに慣れていない人からすると、クラスの数が増えることで全体を把握しづらくなったり、適切なクラスを見つけるのが大変になりそう、と感じるそうです。 「大丈夫！クラスを増やしたほうが楽になることがあるよ！」 と伝えたくて、この記事を書かせていただきました。何が楽になるのでしょう？それは、ソースコードを読むこと、です。「クラスを増やすと、ソースコードを読むのが楽になる？
手元にある LINE ボット環境のソースファイルが 1 ファイルにも関わらず 350 行超えたので、最近勉強したドメイン駆動設計を実践も兼ねてリファクタリングしてみました。 こんにちは、高崎＠アノテーションです。 はじめに 過去の拙記事にも何度か登場している自身の LINE ボットの環境ですが、cdk のスタック定義が約 100 行、Lambda のソースが約 370 行と注ぎ足し注ぎ足しでだんだんと大きくなってきました。 一方、業務で使用している環境はドメイン駆動モデルを元に設計・構築を行っているものが多いため、これらの環境やドメイン駆動設計を学んだことを実践すべく、この LINE ボット環境をリファクタリングしてみました。 この記事の対象 筆者と同じく「ドメイン駆動設計を始めたばかりの方」向けと考えております。 今回の内容は筆者個人が参考文献を元に記載した記事で、ドメイン駆動設計の正確
Massive ~2.3k Patch Series Would Improve Linux Build Times 50~80% & Fix "Dependency Hell" - Phoronix
Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 19+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phor
koherさんが公開された、このFat View Controller、あなたはリファクタリングできますか？チャレンジに参加しました。 本チャレンジは、 Fat View Controller として実装されたリバーシアプリをリファクタリングし、どれだけクリーンな設計とコードを実現できるかというコンペティションです（ジャッジが優劣を判定するわけではなく、設計の技を競い合うのが目的です）。 GitHubのソースコード Qiitaの解説記事 Swift Zoomin' チャレンジ #1 チャレンジ Swift Zoomin' チャレンジ #2 報告会 すばらしいチャレンジを用意くださったkoherさんを始め、運営のお手伝いをされているtakasekさん、Ogawaさんの皆様に感謝です。 リファクタリング結果 以下のGitHubリポジトリにリファクタリングした結果を公開しています。masterブ
最もプリミティブなPG-Stromの処理は、ユーザが入力したSQLを元にCUDA CのGPUプログラムを自動生成し、これを実行時コンパイル。ここで生成されたGPUバイナリを用いて、ストレージから読み出したデータをGPUで並列処理するという一連の流れである。 後にJOIN/GROUP BYの対応や、データ型の追加、SSD-to-GPU Direct SQLなど様々な機能を付加したものの、このコード生成と実行時ビルドの仕組みは2012年に最初のプロトタイプを公開した時から大きく変わってはいない。 コードの自動生成を担当するのはcodegen.cで、この人が吐いたCUDA Cプログラムをcuda_program.cがNVRTC (NVIDIA Run-Time Compiler) を使ってコンパイルし、GPUバイナリを生成する。 ただ、当初の『全件スキャンWHERE句・固定長データ型のみ』という
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
レガシーシステムを近代化する7つの選択肢
ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 デジタルトランスフォーメーションの進展に伴い、レガシーシステムを近代化する効果的な方法を見いだすことが、アプリケーションリーダーにとって必須の課題となっている。その最大の難関は、行動を起こす前にリスクと効果を見極めることだ。 「多くの企業でレガシーシステムは、それらに依存するビジネス施策やそのプロセスの展開のネックになっていると思われている」と、Gartnerのアナリストでバイスプレジデントのシュテファン・ファン・デル・ザイデン（Stefan Van D
GitHub - sourcegraph/awesome-code-ai: A list of AI coding tools (assistants, completions, refactoring, etc.)
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
大阪Ruby会議02での発表スライドです
HOT PEPPER Beautyのアプリ開発チームでTechLeadをしている中里です。 こちらのブログで告知させていただいた通り、3/20にリクルートリファクタリングコンテストを開催しました。今回は当日の様子を紹介したいと思います。 リクルートリファクタリングコンテストとは リクルートリファクタリングコンテストは、HOT PERPPER BeautyのAndroidアプリを題材としたソースコードを、チームでリファクタリングしていき制限時間内でなるべくキレイなコードに書き換えていくコンテストです。 今回用意したソースコードは、HOT PEPPER Beautyのアプリを題材としつつも、その全てのコードをリファクタリングしようとすると仕様理解だけで時間が終わってしまうため、「サロン検索」「サロン詳細の閲覧」「サロンのブックマーク」という3つの機能に絞ったものにしました。 また、HOT PE
こんちはー、リファクタリング大好きなミノ駆動です。 私は初級〜中級向けのソフトウェア設計入門書『良いコード／悪いコードで学ぶ設計入門』（通称「ミノ駆動本」）を2022年4月に出版しました。 拙著はありがたいことに、さまざまな勉強会グループや企業さんでの輪読会で用いられていると聞きます。 この記事は、株式会社コドモン のエンジニアさんからお呼びを受けて輪読会に参加したレポートです。 召喚の儀（ことのはじまり） 「輪読会に召喚したい」的な雰囲気をTwitterで感知したので、私は次のようなツイートをしました。 僕は常にエゴサしているので、 #ミノ駆動本 の輪読会などで僕を召喚したい場合は、僕の名でツイートしていただけると、予定等にもよりますが召喚に応じます。 （※DMは相互フォロワー以外解放していないため） https://t.co/ljv8KnxcI6— ミノ駆動 (@MinoDriven)
カスタムCopでリファクタリング
RuboCopのカスタムCopを書いてリファクタリングを行う話として、丁度良い事例があったので紹介します。 改善したいコード 仕事先のRailsアプリを眺めてみると、昔から慣習的に次のようなコードが書かれていることが分かりました。 module A extend ::ActiveSupport::Concern included do def foo end def bar end end end 本来は、特別な理由が無い限り次のように書かれるべきコードです。 module A def foo end def bar end end これは後から分かったことですが、このようなコードはファイル数で言うと数百件、メソッド定義数で言うと千件弱あるようでした。 用意したカスタムCop そこで、RuboCopのカスタムCopを書いて、このコードを自動修正することにしました。詳しい書き方についてはここ
pmconf2020 登壇レポート「製造業PFの立ち上げ期にPMが向き合った課題と突破口の話」 - CADDi Tech Blog
こんにちは、キャディ株式会社の朱です！ 今回は10月27日に弊社のPdM笹口（@sasaguchisan）が登壇したpmconf2020のイベントレポートをお届けします。 発表内容は「製造業PFの立ち上げ期にPMが向き合った課題と突破口の話」と題しまして、弊社の原価計算システム立ち上げ時にぶつかった課題とそれを解決するためにとった突破口についてお話しさせていただきました。 本レポートでは実際に発表で使われたスライドを抜粋しつつ、内容を簡単にサマリーする形でまとめようと思います。 また、大変有り難いことに発表後の ask the speaker セッションでたくさんの質問をいただけたので、そちらの回答についてもまとめさせていただいています。 詳細が気になった方は以下にスライドの全文が共有されているので参照いただくか、後述のリンクからぜひカジュアル面談を申し込みいただければ幸いです！（発表では
【BASE えふしん】長期Webサービスのリファクタリングと、渋谷駅の切り替え工事の類似性とは？ そこで高まるエンジニアの市場価値
TOPインタビュー採用担当者の本音【BASE えふしん】長期Webサービスのリファクタリングと、渋谷駅の切り替え工事の類似性とは？ そこで高まるエンジニアの市場価値 【BASE えふしん】長期Webサービスのリファクタリングと、渋谷駅の切り替え工事の類似性とは？ そこで高まるエンジニアの市場価値 2023年4月26日 BASE株式会社 上級執行役員 / SVPoD 藤川 真一 Web制作のベンチャーを経て、2006年にGMOペパボ株式会社に入社。2007年から携帯向けTwitterクライアント「モバツイ」の開発・運営を個人で開始。「モバツイ」譲渡後、2012年に想創社設立。その後、モイ株式会社にてツイキャスのチーフアーキテクトを勤めた後に、BASE株式会社 取締役CTOに就任。2019年7月から同社取締役EVP of DevelopmentおよびPAY株式会社取締役に就任。2021年4月か
Tidy First? - Qiita
Kent Beckの最新作Tidy First?は、リファクタリングよりも小さな単位でコードを整理するやり方を記した本です。これをTidying（本記事では「片づけ」と呼びます）と呼んでいて、リファクタリングのサブセットと定義付けています。なので片づけはコードの振る舞いは変えないことはリファクタリングから継承します。 Tidy First?はこんまりメソッドの影響も少なからず受けてそうです。 Tidy First?を書いた背景には、リファクタリングが機能開発を止めて行うようになったり、振る舞いを変えてしまうようになったことがある、とKent Beck自身が本書の中で述べています。 最近のKent Beckの講演は、Tidy First？に関連するものになっています。最新は、DDDEUのイベントの講演で第３部の内容が中心に語られています。なおKent Beckのプレゼンは、スライドは用意せず
リファクタリングとデザインパターン
ハロー、 ワールド！ Refactoring.Guru を使えば、 リファクタリング、 デザインパターン、 SOLID 原則、 その他の賢明なプログラミング技法について、 知っておくべきことを簡単に見つけ出せます。 このサイトでは、 大局的観点、 お互いの関連、 なぜ重要かなどを説明します。 筆者は勿論これらの概念を発明したわけではありません。 ほとんどは、 今や過去となってしまった 20 世紀に発明されています。 しかし、 多くのプログラマーにとって、 リファクタリングとパターンと一般的プログラミング原則のつながりは、 謎の部分が多いと思います。 私はこの問題を解決したいと思います。 追伸 リファクタリングとデザインパターンに関する大量の情報を、 このサイトで見つけることができます。 当プロジェクトは常時改善していますが、 進捗状況を知るには、 メーリングリストに登録するか、 Faceb
Kaigi on Rails 2022 「実践 Rails アソシエーションリファクタリング」で伝えきれなかったこと - ANDPAD Tech Blog
この記事は ANDPAD Advent Calendar 2022 の 8日目の記事です。 リアーキテクティングチームの白土 (@kei_s) です。 最近は、ボーアとアインシュタインに量子を読む - 量子物理学の原理をめぐってという本がとても面白く、ちまちま読んでいます*1。 去る2022年10月21,22日に開催された Kaigi on Rails 2022 で、実践 Rails アソシエーションリファクタリングというタイトルで発表しました。今回の記事では、この発表の補足をしようと思います。 Kaigi on Rails に参加して 本題の前に Kaigi on Rails に参加した感想を書かせてください。 私個人として、対外的に技術コミュニティで発表を行うのがとても久しぶりでした。 オンラインのカンファレンスで発表するのも初めてで緊張しましたが、リハーサル含めて運営チームのサポート
Google Engineering Practices Documentation (日本語訳) Google には、全言語および全プロジェクトをカバーする広範なエンジニアリングの慣行があります。 ここにあるドキュメントは私達が長年の経験からさまざまなベストプラクティスを蓄積してきたことを表しています。 この知識がオープンソースプロジェクトや他の組織の利益になることを願って、私達は可能ならそれを誰にでも利用できるように公開します。 現在、以下のドキュメントがあります。 Google コードレビューガイドライン。これは 2 つのドキュメントからなります。 コードレビュアーのガイド 変更作成者のガイド 用語 ここにあるドキュメントには、Google 内部で使われる用語があります。外部の読者のために意味を掲載しておきます。 CL: 「changelist」の略。一つの独立した変更を意味していて
コードレビューにずっと苦手意識を持っていた。レビューは時間がかかるし、あまり気が乗らない。 がんばってやっても、うまくできたのかどうか自信が持てない。 もちろん、世にあるコードレビューに関する書籍や記事などはいくつも読んだ。 そこには、コードレビューをするときの観点や、コードレビューで望ましい言葉づかいなど、ためになることがたくさん書かれていた。 それでも、やはりコードレビューが苦手なことに変わりはなかった。 だけど最近ようやく、こうすればレビューをうまくこなせるのではないかという出口が、なんとなく見えはじめてきた。 この記事では、ぼくなりにたどり着いた、プルリクエストのレビューを上手に行うための心構え、つまりいかにしてレビューのつらみを減らすかについて書く。 目次 なぜコードレビューはつまらないのか われわれは、なんのためにコードレビューをするのか レビューのコスト レビューの観点 文化
介護事業者向け経営支援サービス「カイポケ」の開発をしている伊藤です。2019年4月に入社し、一貫してプロダクト開発部の介護レセチームでエンジニアとして活動しています。 本稿では私の所属する介護レセチームで実施している、システムの改善活動について気をつけていることや気がついたことをまとめます。 介護レセチームとは 介護レセチームは、介護事業者向け経営支援サービス「カイポケ」の介護領域の開発を担当するチームです。「カイポケを使った介護業務をノンストレスで行えるようにすることで利用者に向きあうゆとりを増やすこと」をチームのミッションに掲げ、日々カイポケの機能開発などを実施しています。 カイポケでは介護事業所の経営を支援するための様々な機能を提供していますが、コア機能の1つとして、介護事業所が収入を得るために必要となる請求業務の支援機能があります (請求業務はレセプト業務とも呼ばれ、介護レセチーム
「スパゲティコード化・ブラックボックス化したレガシーなアプリケーションを、どう改修するか」こうした課題に悩んだことのあるエンジニアは少なくないだろう。既存ロジックを壊さず、かつ最小限の工数でレガシーコードを修正することは、エンジニアにとって難易度の高いタスクの1つだ。この課題に解を示す開発手法が、ルール駆動開発である。複雑にソースコードが絡み合った既存システムを、うまく解きほぐすための手法とは？ レッドハット株式会社で培われたノウハウとベストプラクティスを、松田絵里奈氏が紹介する。 講演資料： 全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、“ルール駆動開発” レッドハット株式会社 Senior Specialist Solution Architect 松田絵里奈氏 既存コードの解析ではなく、業務要件の把握からスタートする ルール駆動開発とは、以下の特徴を持った開
ソフトウェアの品質 ソフトウェアの品質といえば, 大まかに外的品質と内的品質に分けられます. 外的品質: ユーザーから見た品質 例: 安全かつ確実に動作すること, 操作しやすいこと 内的品質: 開発者から見た品質 例: 変更しやすいこと, 型・linter・テストなどに守られていること, 読みやすいこと 当然ですが, ソフトウェア開発者としては外的・内的どちらの品質も高い, という状態を目指すべきでしょう. 場合によって優先度こそあれ, どちらかを一方的に切り捨てるべきではありません. どちらの品質から高めるか ある程度の複雑さを持ったソフトウェア (のコンポーネント) を作る場合, 大抵はどちらの品質も高い状態に向かって一直線に進めることはなくて, まずはどちらか一方の品質が高い状態を目指すのが普通かなと思います. こういった開発の進め方については様々な流派があると思いますが, ここでは
ソフトウェアを作っていて、ここの開発体験が悪いのでちょっとリファクタリングしたい、と思ったときにどうするか。 とにかく直してしまう 今後のリファクタリング予定、みたいなロードマップと見比べて、ロードマップに合致してたら直す すぐには手を付けず、今後のリファクタリング予定、みたいなロードマップを粛々と進める とにかく見かけたら完膚なきまでに直す、という人もいると思って、カッとなって直してきました…みたいな言説はよく見る。 一方で、目についた順に手を付けていてもできることには限界があって、全員の意識を統一して、こういう順序でやればうまくいくに違いない、みたいにロードマップを作ったりして段取りをして、同じ方向に向かっていけると、より大きいことができたり、より良い状態になれたりする、ということもあるだろうと思う。 というときに、どれくらいのバランスで、ちょっと直すのか、直さないのか、段取りを定めて
この記事は「連載：技術基盤強化プロジェクト「RFS」の現在と未来」として書かれたものです。 メルカリ JP の CS Tool チームの @AHA_oretama です。 私たちのチームでは、CS Tool (Custmer Service Tool)の開発を長年の間行ってきました。その中で積み重なった負債を解消するために、フロントエンドのリプレイスプロジェクトを立ち上げ、PoC（Proof of Concept）として3か月ほどの期間で1画面のリプレイスを行ってきました。今回の記事は、CS Toolのフロントエンドのリプレイスプロジェクトの成り立ち、リプレイスの開発とその成果を紹介していきたいと思います。 CS Tool チームの他の取り組みは、 @hukurou さんによる「メルカリCSツールにおけるDBの疎結合化への取り組み」 @monkukui さんによる「GKE 移行を進める上で
There’s a certain simple animation thing that I’ve been using almost since I’ve ever started doing anything related to graphics. I use it for rotating & moving the camera, for moving figures in a turn-based game, for moving UI elements, for smoothing volume changes in my audio lib, everywhere! So I decided I’ll write about it. The trick itself is nothing new, - in fact, you’ve probably already hea
はじめに リクルートテクノロジーズの 辻 健人です． GitHub では maxmellon で活動しています． 今回は，『Airシフト』における パフォーマンス改善とリファクタリングの事例を一つずつ紹介したいと思います． 『Airシフト』とは 『Airシフト』は，やりとりも作成も楽になるシフト管理サービスです． 直感的に操作できるシンプルな画面で，カンタンにシフト作成が行えます． 技術スタックとしては， React/Redux ，チャット機能に WebSocket， SSR やユーザ認証，ファイルダウンロードにBFFアーキテクチャを採用しています． 『Airシフト』はシフト表の作成や管理ができるだけでなく，大きな機能の一つとして 『シフトボード』を活用したチャットを行うことも可能です． 例えば，急用で別のスタッフにシフトを変わってもらうときや，シフトの希望を提出する締め切り前にチャットを
GitHub - dsherret/ts-morph: TypeScript Compiler API wrapper for static analysis and programmatic code changes.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
こんにちは、リファクタリング大好きなミノ駆動です。 2021年4月にREADYFOR株式会社にジョインしました。 概要 本記事は、なぜ私がREADYFORへのジョインを決断したのか、背景理由を記したエントリ記事です。 READYFORはサービス開始から約10年が経過。システムに相当な技術的負債が蓄積しているため、今後スピーディーにサービス拡大するためには負債解消が目下取り組むべき重要課題となっております。その課題解決のために私は誘われたわけですが、リファクタリングが十分に効果を発揮するには、設計技術面以外の様々なハードルを乗り越えなければなりません。 READYFORの組織ビジョン「乳化」が、ハードルを解消し、リファクタリング効果の大きな促進に貢献すると考えたため、ジョインを決断しました。 本記事では、技術的負債やリファクタリングにまつわる一般的な問題構造を解説した上で、READYFORが
※循環的複雑度を改善する以外にも、テストカバレッジを向上させるためにコードを整理したり、テストコードを増やしたり、アーキテクチャを刷新するためにリファクタリングを進めたり、さまざまな活動をしていますが本記事では割愛します。 実際、Yahoo!カーナビのAndroid版/iOS版共に、複雑度が75以上のメソッドが存在しました。 循環的複雑度の可視化 指標が決まったので、次に着手するべきは指標の可視化です。可視化については以下の2点が重要だと考えました。 自動で計測・集計できる（もしくは単純な手動作業で計測できる） 誰でもすぐに見られる 複雑度を計測する モバイルアプリにおいて、循環的複雑度を計測する方法はいくつかあります。私たちは同じZホールディングスグループのZOZOのTECH BLOG「ZOZOTOWN Androidチームにおけるコードメトリクスとビルド時間計測の取り組み」を参考にしま
GitHub - checkly/puppeteer-to-playwright: Puppeteer to Playwright conversion script
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Automate RuboCop ToDo fix
Let me introduce rubocop-todo-corrector in this article. ToDo list based linting These days, many projects are using Lint tools to self-diagnose their code. e.g. ESLint for JavaScript rustfmt for Rust RuboCop for Ruby etc. RuboCop has the ability to detect existing offenses and automatically generate a file named .rubocop_todo.yml. This file acts as a to-do list, so we can gradually fix the offens
はいさい！オースティンやいびーん！ 概要 今日の記事は、リファクタリングについてお話しします。 特に、エンジニアがなぜリファクタリングをしないのかについて触れたいです。なぜできないか、というべきでしょうか。 そして最後に、リファクタリングの文化を根付かせるためにどのような対策を取ればいいかの話題でまとめます。 背景 筆者が複数の日系企業で働いてきましたが、健全なリファクタリング文化を育んでいる会社は一社も出会っておりません。 リファクタリングをしないせいで身の回りの動きがどんどん取れなくなっていく、つまり開発の効率が悪化する一方で徐々にコードベースがわからなくなってくるという悪循環をいくつかのプロジェクトで見てきました。 なぜリファクタリングを敬遠するのか、どんな課題があるのか、ずっと疑問に思っています。 リファクタリングとは リファクタリングは、ソースコードを見直して再編することです。つ
この記事は Enigmo Advent Calendar 2022 の13日目の記事となります。 お疲れさまです。インフラチームの山口です。 弊社では一部インフラリソースのモニタリングにDatadogを利用しています。 その中で、今回はDatadogの利用開始当初にGUIで作成されたモニターをTerraformerとTerraformを使用して構成管理した際の事例について報告します。 同様の技術スタックを使用したインポートや構成管理における具体的なテンプレート等の事例には事欠かないと思いますので、作業計画を中心に説明します。 要は、TerraformerやTerraformの使い方は様々良い資料があると思うため、今回固有の対応をした点を注力して説明します。 本稿の構成を以下に記載します。まず、対象とするモニターの状態などの前提を説明します。次に、作業の流れを概説し、Terraformのディ
「技術書」の読書術という書籍を読んでみて、実際に自分でもやってみました！技術書に限らず、特定のテーマについて効率的に勉強する良い方法だと思います！ こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 突然ですが技術書を読む際に以下のような悩みが頭をよぎりませんか？ この本に書いてあることは世間一般的に見ても正しいのだろうか？ この書籍で語られているどの部分が特に重要なのだろうか？ この本にはこう書いてあるけど本当かなぁ？私は違う気がするけど根拠がないなぁ 私はよく思います。 そこで「技術書の読み方」自体も勉強したいなぁと考えていたところ、書店でこちらの本を発見しました。 この本を読んだ時に「3の発想」という素敵な考え方を知ることができたので、今回実際に実践してみました！ ITエンジニアの方に限らず、いろいろな分野の読書にも応用が効きそうだと思い
今がPython 2からPython 3へ移行するのにベストなタイミング：トークセッションレポート：Pythonイベント Python 2のサポートが終了したら、今あるPython 2のコードはどうすればいいだろうか。悩ましい問題にさまざまな選択肢を与えてくれるセッションをレポート。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
GitHub上で構築するコードメトリクス計測基盤 / TECH STAND #9 GitHub
ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた | DevelopersIO
iOSリバーシリファクタリングチャレンジ w/ Redux - Qiita
技術負債を返した話（Pre-built GPU Binary対応） - KaiGaiの俺メモ
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
Concerns about Concerns
リクルートリファクタリングコンテストを開催しました
コドモンさんのミノ駆動本輪読会に呼ばれました - READYFOR Tech Blog
Google Engineering Practices Documentation (日本語訳)
コードレビューはつまらないから丁寧なプルリクエストでチームの生産性向上を目指す
改善の小さい歩みをチームで続けるために - エス・エム・エス エンジニア テックブログ
レガシーコードから脱却するために有効な方法とは？ ルール駆動開発が解決する課題【デブサミ2020】
内的品質を無視せざるを得ない状況に陥るな - Object.create(null)
目についたところをやるか、ロードマップに沿ってやるか - hitode909の日記
CS Toolのフロントエンドのリプレイスプロジェクトについて
My favourite animation trick: exponential smoothing
Airシフトにおけるパフォーマンス改善とリファクタリング事例 | Recruit Tech Blog
リファクタリング効果を促進する組織ビジョン「乳化」 - READYFOR Tech Blog
循環的複雑度に着目し10年モノのコードを改善する（Yahoo!カーナビのコード品質可視化と改善の歩み）
リファクタリング文化が根付かない企業：あなたはどうする？ - Qiita
DatadogのモニターをTerraformerでインポートして感じたことなど - エニグモ開発者ブログ
【技術書の読書術 実践してみた】3の発想で3冊の本を読んでみた | DevelopersIO
今がPython 2からPython 3へ移行するのにベストなタイミング：トークセッションレポート