タグ

*あとで読むとリファクタリングに関するwkubotaのブックマーク (8)

  • リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog

    皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの

    リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
  • リファクタリング - 西尾泰和のScrapbox

    「このコードは既に十分に綺麗だから、(コメントは追加してもいいけど)リファクタリングする必要はない」" 一生リファクタリングしている自分とは仲良くなってくれなさそう。

    リファクタリング - 西尾泰和のScrapbox
  • リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog

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

    リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
  • スタメンの技術的負債解消戦略 - stmn tech blog

    1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG(ツナグ)は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。来プロダクトチームはユーザーにとっての質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が

    スタメンの技術的負債解消戦略 - stmn tech blog
  • フロントエンドにおける「単体テストの考え方/使い方」

    稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方というを読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。このを読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 稿はこのを読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方にはを手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま

    フロントエンドにおける「単体テストの考え方/使い方」
  • リファクタリングは事前準備が9割 - freee Developers Hub

    会計チームで債権周りの開発をしている hachi (@hachiblog)です。会計チームが開発している freee 会計は freee の中で一番歴史が長いプロダクトです。加えて会計というドメインは複雑かつバグを生むと顧客の業務を大きく阻害するという点で一度作ったものを変更しづらいという特徴があります。 そのような環境で今回、債権のチームでは freee会計の初期からある「自動で経理」という機能の一部リファクタリングを行いました。リファクタリングのしづらい環境下でうまくリファクタリングをすすめるための tips は多くの人に役立つのではと思い、このエントリを書くに至りました。 今回「自動で経理」でリファクタリングしたときに事前に以下のことを行いました。 課題の発見 課題の具体化 設計とスケジュール見積もり テストコード実装 それぞれについて今回意識したことを書いていきます。 課題の発見

    リファクタリングは事前準備が9割 - freee Developers Hub
  • 主要データベースの増え続けるdisk容量の対応事例

    こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか? 何をしたか? メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提:データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基要素となるデータから、通知やお知らせメッセージなど付加的な機能

    主要データベースの増え続けるdisk容量の対応事例
  • データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳

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

    データベースリファクタリングについて話をしてきた #OSO2017 - そーだいなるらくがき帳
  • 1