リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
3ヶ月かかる大規模リファクタリングをなぜ実行に踏み切れたのか？｜ham
こんにちは、すべての開発組織の生産性を上げたいhamです。 私の所属する開発チームでは、今年1月からフロントエンドのアーキテクチャを変更する大規模なリファクタリングを行いました。 アーキテクチャ変更の詳細についてはこの記事では触れませんが、以前SaaSにおけるフロントエンドの技術戦略 | SaaS.tech #6というイベントでLTを行いました。 このリファクタリングは5人で3ヶ月ほどかかる大規模なもので、1〜3月にエンジニア5名にほぼフルコミットしてもらい実施しました。 その間、施策開発も並行して行いましたが、施策開発を担当するフロントエンドエンジニアは2名に対してリファクタリングには5名アサインしたので、リソースの7割をリファクタリングに割いたことになります。 前述の通り施策開発はSTOPしていないものの、1〜3月は開発リソースの7割が施策開発に使えない状態になりました。 それにも関わ
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc
はじめに 当記事を開いてくださりありがとうございます。私は表題の通り、私は一般にメガベンチャーと呼ばれる自社開発企業で機械学習エンジニアとして勤務しはじめてからわずか半年で、鬱を発症し退職することになったものです。この会社は待遇も良く、社風としても労働者思いのとても素晴らしい会社であったと私自身振り返って思います。 そんな会社に運よく入社することができた私ですが、わずか半年で「鬱状態」と心療内科から診断を受け休職し、会社制度により退職することになりました。「え？そんなに素晴らしい環境なのにメンタル弱すぎでは？」と思われる方もいらっしゃることでしょう。返す言葉が全くありません。おっしゃる通りです。 しかし同時に、「何故鬱になったの？」と思われる方もいらっしゃるのではないでしょうか。本記事ではこの点について鬱を発症した本人の目線から「どうしてそんなことが起きてしまったのか」という点について考察
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く
はじめに、本エントリは特定の企業、チーム、個人を指して書いたものでは一切ない。100%僕の個人的な経験から来ている。 さて、職業プログラミングに従事していると一度は「これ書き直した方が早いっす」とか言ったことある気がする。自分の場合、多くは歴史のあるレガシーコードを読んだときだ。思い返せば、自分がこう思ったときはほとんどそれは間違いであった。 「なんだこのコード…」 「これ何書いてあるか分かんないっす」 「うーんこれもう書き直した方が早くないっすか？」 この流れは非常に危険だ。 なぜならプログラムというのは本質的に書いてある通りにしか動かないからだ。ちゃんと読めば絶対に何を書いてあるかは分かる。 ここで安易に選んだ書き直しという選択は、自分が慣れ親しんだやり方でその部分をそっくり置き換えるというだけで、それは他人にとってあたらしい「これ何書いてあるかあるか分かんない」を生む結果にしかならな
第二回社内読書感想会(テスト駆動開発)に翻訳者の t-wada さんをお招きいたしました! - Feedforce Developer Blog
ドーモ、社内 ニンジャスレイヤー 推進おじさんの id:kasei_san です。 先日、社内にてテスト駆動開発をお題に読書感想会を実施したところ、翻訳者の id:t-wada さんの目に留まり、なんと、id:t-wada さんをお招きして、第二回読書感想会を実施することになりました!! 素晴らしい取り組みだと思います。たぶんもう終わってしまったとは思いますが、御社内でまた『テスト駆動開発』を取り上げるときには、ぜひお気軽にお声がけください。— Takuto Wada (@t_wada) 2017年11月29日 読書感想会とは? 技術書などチームが読んだ本について、知見や疑問を共有する会です。 詳しい解説と前回の様子は、こちらの記事をご覧ください。 developer.feedforce.jp どんなことを話したの? テスト駆動開発の疑問や感想について id:t-wada さんに解説頂いた
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
今日から始められるリファクタリング10選 (1) - Qiita
概要 Martin Fowler 著「リファクタリング―プログラムの体質改善テクニック」を参考にしました 手軽にできる (と思われる) リファクタリングを抜粋しました (10 という数字に特に意味はなくキリがよかったので) リファクタリングカタログ名は「」で括り、()内にページ番号を振りました サンプルコードはPHPで記述しました テストコードがある前提です 「リファクタリング―プログラムの体質改善テクニック」について この本はリファクタリングのガイドブックです。系統だった効果的なリファクタリング手法を説明しています。コード中にバグを加えずに、ソフトウェアの構造を体系的に改善できます。 (Amazon 商品の説明より) オリジナル版と新装版があります。本稿ではオリジナル版を使用しました (新装版と目視で比較したが、リファクタリングカタログに違いはないみたいだった)。 リファクタリング―プロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to write maintainable JavaScript code in 2023 — Web or Node.js
Webフロントエンドのリプレースを支えるテストの考え方 / JSConf JP 2021