リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEの京都開発室でフロントエンド開発を担当している柴坂浩行です。 みなさんは仕事中などにパソコンで音楽を聴くことはありますか？ LINE MUSIC にはスマホアプリだけではなくWeb版アプリがあります。 私たちが開発しているWeb版アプリでは、JSフレームワークとして Vue.js を使用しています。 https://music.line.me/webapp/ これまでこのWeb版アプリには Vue2 が使われてきましたが、 2022年6月、私たちは Vue3 にアップグレードしたバージョンをリリースしました。 私たちのチームではWeb版アプリの機能開発と平行して、パフォーマンスの改善にも取り組んでいます。パ
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
はじめに hey のネットショップ開設サービス「STORES」 の開発フロントエンド組織で EMをしています、 daitasu と申します。 2022年の上半期、私たちのフロントエンドチームで「除雪部」という技術負債解消ワーキンググループ(以下、WGとします)を立ち上げました。 この記事では、「除雪部」とは何なのか、なぜ設立したのか、何をしているのか、半年間の振り返りをご紹介します。 「除雪部」とは 除雪部は、フロントエンド内で、通常のプロジェクト(以下、PJTとします) と並行して、有志数名で集まり、技術負債の解消をハンドリングするWGです。 フロントエンド関連で負債に感じている課題を集約し、優先度付け、必要な各所への連携やタスクの分解をして、「負債を各メンバーが対応可能な状態まで落とし込むこと」、「負債の解消を一歩でも前に進めること」を役割として動いています。 なぜ設立したのか STO
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
レガシーコードのリファクタリングの書籍の多くは、テストコードの大切さを説いている一方で、肝心のテストコードはあまり記述されないことが多いです。 これにより、あたかも「最初の作業として、テストコードをたくさん作る必要がある」と思わせてしまい、リファクタリングをするためのテストコードの作成に挫折してしまう事態を生み出しているように感じています。 そこで本書籍では、テストコードを少しずつ注入していきながら、レガシーコードに立ち向かう方法を、実際のテストコードを記載しつつ説明していきます。 想定読者本書籍では、レガシーコードに対しての最初の一歩を踏み出したいと考えている人に向けて書いた本になります。その際、テストコードの記述にも重点をおきながら、レガシーコードをリファクタリングする過程を説明しています。 本書籍では下記のような人を想定読者としています。 ・テスト駆動開発(以下、TDD)を知っている
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
こんにちは。Backlog開発チームの砂川です。 現在BacklogではフロントエンドのReact/TypeScriptへのリプレイスを進めています。既に一部の画面（課題検索画面、課題詳細画面）がリプレイスされ、本番環境で稼働しています。 この記事では、Reactへのリプレイスによって素早い機能開発ができる状態を実現しようとしていること、リプレイスしたコードを安心して触れる様にするために導入したものをご紹介します。 本題の前に: 表示速度も大幅に高速化 本題の前に今回のリプレイスによる副産物を紹介しておきます。今回のリプレイスは機能開発を楽にすることが第一目的ですが、リプレイスの過程で一部SPA化もしているため、ユーザーの体験も向上させることができました。 リプレイス前(900ms程度) React版（50ms程度） 課題検索画面と課題詳細画面をSPA化したことによって、この二画面間では、
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
内容 ワークディレクトリーのセットアップ(10min) ワーク用リポジトリーの git clone 依存のインストール モブプログラミング準備(30min) VSCode Live Share を使い、参加者すべてが同じコードベースで作業できるようにする ドライバーの担当順の決定 仕様を確認する リファクタリング開始(6 * 15min) コードスメルを探す リファクタリングしてみる 発展課題 書籍リーダブルコードを読み、生じた疑問や質問について同期やエルダーと Slack 上で議論する 新卒メンバーからのフィードバック 良かった点 モブプログラミングでリファクタリングを体験できたことは良かった リファクタリングを意義を理解できた Next.js に触れられた リファクタリングの観点と方法を知ることができた やっていることを言語化しながら共有する練習になった 伸びしろ モブプログラミングは
ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて
ドメイン分析とモデル化ここで「モデル化」と呼ぶのは、実装者が理解しやすいように重要な側面に注目して、端的な形に抽象化する行為であると定義します。 また、実際に実務で行なっている自身のモデル化を行う時の書き振りを近しく再現(中身は変更)しているため、わかりづらいかもしれませんが、”実務ではこうやっている” というのを理解していただければ。 先の要件を整理すると、数という概念に金額とポイントという2つのドメインモデルが含まれる。 金額とポイントという異なる概念を計算して最終的に獲得ポイント数を導き出す必要がある。 存在する制約 金額が負の数になることはありえない。ポイントが負の数になることはありえない。金額は日本円のみを考慮し、外貨は存在しない。ポイントは文脈によって呼び名が変わるが、単位は変わらない。支払い金額合計以上にポイント利用数が設定されることはない。金額に小数点は存在しない。ポイント
ブレずに、爆速に、安全にプロダクトを作る！〜認知負荷を下げて共通認識を確実なものに〜 - ANDPAD Tech Blog
こんにちは、soe-j と申します。主に新規プロダクト開発に従事し、ここのところフロントエンドに傾倒しております。 アジャイルやスクラムという言葉が一般的になった昨今ですが、 「小さく作って顧客に見せ、フィードバックをもとに進行方向を調整しつつ次に進めていく」というプロセスが私はとても好きです。 これは、ANDPADが顧客からのフィードバックを沢山もらえる環境であるという前提の上成り立ってるので、本当に感謝しています。（これを書いている間にも「〇〇機能が出来たことで××できるようになりました！」という声が届いてとても嬉しいです！） いただくだけでは申し訳が立たぬ、それを元に ブレずに 爆速 かつ安全に 価値を提供していかなければなりません。そのためには「小さく作る」ということが肝になっていると感じています。 言うのは易し、じゃあやってみせてと思うところですが、そんなもん答えはありません。ほ
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏（以下、高橋）：じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏（以下、高木）：ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう（笑）。 高橋：まず、日本人がすごくリファクタリングが嫌いな
Well-organized Transaction Script - リファクタリングの妥協的手法 -
設計ナイト2022 Related Links: p.7 https://speakerdeck.com/qsona/developing-masterdata-management-tool-by-using-vscode-extension p.18 https://higayasuo.hatenablog.com/entry/20080519/1211183826 p.30 https://speakerdeck.com/qsona/architecture-decision-for-the-next-n-years-at-studysapuri
4/30発売の『良いコード/悪いコードで学ぶ設計入門』を紹介する「『良いコード/悪いコードで学ぶ設計入門』著者トーク」。ここで著者の仙塲大也氏が登壇。続いて、各章の概要について話します。前回はこちらから。 第1章：悪しきコードの弊害から痛みを知る 仙塲大也氏（以下、仙塲）：ここからは各章の紹介です。本書は1章から17章までの全400ページあります。第1章「悪しき構造の弊害を知覚する」。1章と2は、新卒さん向けの章です。「設計なんかぜんぜん知らないですよ」という方向けの章です。 そもそも設計って、「設計しなきゃ」という危機意識が必要なわけですね。その危機意識の醸成には、悪しきコードによる弊害を知覚する必要がありますよ。悪しきコードの弊害を数例用いてダイジェスト的に紹介して、痛みを知ってもらおうという章です。 第2章：「設計とは？」を学ぶ 第2章「設計の初歩」。本格的な設計は3章の「クラス設計
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。 ▼SRE NEXT 2022オフィシャルサイト https://sre-next.dev/2022/ ▼発表の概要 https://sre-next.dev/2022/schedule#jp20
こちらのトークイベントで用いたスライドです。 『良いコード/悪いコードで学ぶ設計入門』著者トーク https://modeling-how-to-learn.connpass.com/event/242976/
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
[Rust] モジュールのベストプラクティス
Rust のモジュールシステムは私の知る中でもトップクラスによくできた仕組みだと思います。特にリファクタリングによってモジュールを再構成するときのやりやすさは他の言語では経験できないものです。例えばそれなりの規模の Python プロジェクトを回帰バグを導入せずにモジュール構造のリファクタリングするのは不可能に近いですが、 Rust ではそのような不安を覚えたためしがありません。 Rust のモジュールシステムがどういうものかは、 The book にも書かれていますし、すでに大量のガイドが書かれていると思います。しかし、どのように使うべきかについては意外なほど情報が少なく感じます。 ベストプラクティスというのもおこがましいですが、数年使ってきて Rust のモジュールシステムを使う上でスムーズに感じる方法をまとめておきたいと思います。 Rust のモジュールシステム 本稿の主題はモジュー
![[Rust] モジュールのベストプラクティス](https://cdn-ak-scissors.b.st-hatena.com/image/square/891eeb61cb537942f816adc8c8b2ea1079e47749/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--9-GnInIk--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BRust%25255D%252520%2525E3%252583%2525A2%2525E3%252582%2525B8%2525E3%252583%2525A5%2525E3%252583%2525BC%2525E3%252583%2525AB%2525E3%252581%2525AE%2525E3%252583%252599%2525E3%252582%2525B9%2525E3%252583%252588%2525E3%252583%252597%2525E3%252583%2525A9%2525E3%252582%2525AF%2525E3%252583%252586%2525E3%252582%2525A3%2525E3%252582%2525B9%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Amsakuta%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EvQUFUWEFKeG5tZ0ZYQlJsZjJpZVh1QWlwOG9LaFdpT2FSczg2dXRzWlcwN3o9czk2LWM%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
kintone のテストを JUnit 5 に移行した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintone 開発チームの @hikoma です。kintone のテストを JUnit 4 から JUnit 5 に移行した話を公開したいと思います。 背景 2017 年に JUnit 5 がリリースされてから約 4 年半、みなさんは既に JUnit 5 を利用していることかと思います。 kintone では JUnit 5 への移行がなかなか進みませんでした。テストのボリュームがそれなりにあり（Java の単体テストが約 6500、REST API のテストが約 4000、Selenium のテストが約 3000）、E2E テストで並列実行やリトライのために JUnit 4 の仕組みを利用していたので、目に見える問題が起きていない状況では優先度も上がりませんでした。 しかし、このような状況ではテストの改善に着手しにくく、持続的な開発のリスクも感じていたため、何度目かの移行
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 がメイン
Last week, we deployed a refactoring patch to our Ruby codebase that was big for us 1 – 178 files changed: Changeset. If you’d asked me five years ago how to safely deploy a change of this size in Ruby, I’d have a very simple answer: you can’t. Ruby’s parser is no help in detecting regressions – it’ll notice invalid syntax, and that’s about it. A good test suite helps, but it’s never complete enou
Twig, jQuery, Bootstrap で構成されていたシステムをNext.jsでリプレイスしたときにやったことを書く。 前提 IE対応必須 ディレクトリ設計 github.com を参考にした。 ユニットテスト用の__test__は基本的に作らず、format.tsとformat.test.tsは同じ階層に配置するようにした。テストが存在するのかの確認コストと、書くときのハードルを極力下げるようにするため。 コンポーネント分割については、アトミックデザインを採用しようとも思ったが、結果やめて下記のような分割単位とした。 components ├── button ├── label │ ├── H1.tsx │ └── Title.tsx └── icon アトミックデザインでいうところのatoms(原子)とmolecules(分子)までを最大として、それ以降の大きな単位はfea
この本の概要 「ITエンジニア本大賞2023」技術書部門で大賞受賞！ 本書は，より成長させやすいコードの書き方と設計を学ぶ入門書です。 システム開発では，ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる，コードの影響範囲が不明で変更すると動かなくなる，新機能を追加したいがどこに実装すればいいかわからない……。 変更しづらいコードは，成長できないコードです。ビジネスの進化への追随や，機能の改善が難しくなります。 成長できないコードの問題を，設計で解決します。 こんな方におすすめ コードの設計スキルに興味がある人 日々，悪いコードと向き合っていて改善したい人 より良いコードを書きたい人 1 悪しき構造の弊害を知覚する 1.1 意味不明な命名 1.2 理解を困難にする条件分岐のネスト 1.3 さまざまな悪魔を招きやすいデータクラス 1.4 悪魔退治の基本 2
こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 本記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン（業務活動）にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
はじめに ドワンゴ教育事業 Web フロントエンドチームの berlysia です。 ドワンゴ教育事業が提供するオンライン学習サービス『N予備校』は、この 4 月でリリース 6 周年を迎えました。N 予備校の Web フロントエンドはリリース以来、全面的な書き換えを行い、今も続けています。 この記事では書き換えに伴う N 予備校の Web フロントエンド実装の変遷を説明し、これら書き換えの経験やWebフロントエンドという領域の性質を踏まえて、すべてを書き換え続ける選択をしていることを述べます。 この記事は berlysia が他社様イベント*1にて発表させていただいた話題を元に再構成しています。 speakerdeck.com ※JSConf JP 2021 で発表させていただいた事例とは異なるコードを対象にしています。 はじめに 実装の 5 つの世代 v1 v2 v3 v3(TypeSc
ボーイスカウトルール。 機能追加より、 先に直すか、 後から直すか。— 人生踊れば丸儲け (@tomohi_ro) 2022年4月3日 まれによく目的の変更にリファクタリングを混ぜたプルリクのレビュー依頼を受けるので、そのたびに変更とリファクタリングは分けてねって話をしている。 レビューするときにもdiffが混ざっていて見にくいし、将来的に変更の経緯を追いかけるときにもノイズになってしまう。 コミットが分かれていたらまだマシなんだけれど、そういう場合はたいてい同じコミットに複数の目的が混ざってしまっている。 www.clear-code.com 僕は1コミットには1つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。 みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ
リファクタリングという行為自体は好きでしょうか？ A. 好きというかもはやストレス解消 B. 好きなのでノンストレス C. 少しストレス...仕事ならやるけど D. できればやりたくない 業務上の必要性とか、将来の人のためとか、時間の都合とか、報酬の高さとか、そういうのを棚に置いたとして。 ... 新しい機能開発をするのに比べてどうでしょう？ 新しいプログラミング言語やフレームワークを使うのに比べてどうでしょう？ 置き去りのリファクタリングチケット とある風景... seaさん「動いたけど、リファクタリングしたいね」 landさん「でも今は無理だな」 seaさん「チケットだけおいて作って後でやろう」 landさん「うん、そうしようー！」 (...1年後、まだ忙しい) seaさん「いつかやりたいねー」 landさん「いつかやりたいねー」 (...2年後、平和になった) seaさん「早く帰ろう
エンジニアの富岡です。2ヶ月ほど前まで、Wantedly 利用企業向けのプラン契約や料金請求周りのシステムの改修と機能追加を行うプロジェクトをやっていました。1年半ほどの長期プロジェクト、かつステークホルダーの多いプロジェクトだったので、プロジェクトマネジメントの観点でも書くべき話題はあるのですが、今回はより技術的な部分に焦点を当てて、プロジェクト開始時点でレガシー化していたシステムの状態を改善するために行った取り組みを紹介したいと思います。 背景Wantedly は SaaS 型のビジネスを提供しており、利用企業の契約プランに従って毎月の料金の請求を行ったり、契約の自動更新を行ったりといった処理が発生します。こうした処理を行うシステムは、今から8年ほど前までにそのベースとなるものが作られました。それ以降は消費税率の変更や、新しい支払い方法の対応など、必要に応じて散発的に変更は行われていま
文法を学んだ次に知りたいのは、ゼロから巨大なコードを書き上げる方法ではなく、"既存のコードの改修を適切にやれる方法"なんじゃないか - Magnolia Tech
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LINE MUSIC のパフォーマンスを向上させた Vue3 マイグレーション
フロントエンド技術負債解消WG「除雪部」を立ち上げた話 - STORES Product Blog
【動画付き】テストコードの注入から始めるレガシーコードのリファクタリング - ブロッコリー屋さん - BOOTH
テストコードにはテストの意図を込めよう #vstat
Backlogのフロントエンドをもっと楽しく開発したい！Reactでリプレイスしている話 | 株式会社ヌーラボ(Nulab inc.)
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
2022 年度新卒研修で「読みやすいコード」の研修を担当しました | DevelopersIO
共通化すれば良いとは限らない - Object.create(null)
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
Value Object (値オブジェクト) でリファクタリングしたら結構良かった
CSSのリファクタリングにあたって、意外と大事な考え方 - Qiita
「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
悪しきコードの痛みを知り、設計スキルを高める方法を学ぶ 全17章からなる『良いコード/悪いコードで学ぶ設計入門』
ComplexとComplicated - kawasima
書籍『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える
読書感想文「リファクタリング第2版」 | フューチャー技術ブログ
Sorbet + 100% cov makes Ruby refactoring possible
10年もののシステムをPHP・Twig・jQuery・BootstrapからNext.jsにリプレイスするときにやったこと - ハイパーマッスルエンジニア
8年続くPerlプロダクトをKotlinに書き換えた話。システムリプレイスの勘所
良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog
『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動
全てを書き換え続ける。N予備校Webフロントエンド実装6年のあゆみ - ドワンゴ教育サービス開発者ブログ
ボーイスカウト・ルール、先に直すか、後から直すか。 - ちなみに
保守性の高いReact hooksコードの指針
リファクタリングという行為が好きか？ - jfluteの日記
レガシー化していた課金周りのシステムを改善するためにやったこと | Wantedly Engineer Blog