同期エンジンの心臓部を書き換える
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
動的解析を利用し、実働6日でレガシーコードを1/3削った話(Perl編) - CARTA TECH BLOG
こんにちは！株式会社VOYAGE MARKETINGで働くエンジニアの yopidax です。 約20年ほど続くサービス、ECナビの技術的負債の返済に取り組んでいます。 ecnavi.jp 今回は直近で、レガシーコードを大量に削除したので、そのアプローチをご紹介したいと思います。 目次 目次 解析の対象と抱える課題 アプローチ 実行されるファイルを洗い出す ログを出力するモジュール 実行 ログのサンプル いざ、大量削除 Perlファイルをgrepする リリース単位を細かくする 結果 工数 実績 まとめ 合わせて読みたい 解析の対象と抱える課題 ECナビを長年支える、Perlで書かれたバッチが対象です。コードはGitLabのリポジトリで管理されていて、規模をまとめるとこんな感じです。 ファイルの数 バッチ関連全体 : 3,315 うち、Perlファイル(.pm, .pl) : 1,111 P
3週間で48,000行のコードをこの世から抹消した話 – FiNC Engineering Blog – Medium
qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ
ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
10年でどう変わった? はてなブックマークでのPerlの使い方
計算ファースト vs. 型ファースト / Computation First vs. Type First
Ruby 2.6 新機能：本番環境での利用を目指したコードカバレッジ計測機能 - クックパッド開発者ブログ
技術部の遠藤（mame）です。1 ヶ月くらい風邪が直らず、苦しみながらこれを書いています。 昨日は Ruby 2.6 の NEWS を裏話付きで解説する記事を書きました（プロと読み解く Ruby 2.6 NEWS ファイル）。今日と明日は、その中でクックパッドのフルタイムRubyコミッタが主に担当したところを少し詳しく紹介します。 今日は、遠藤が作った "oneshot coverage" と言う 2.6 の新機能を紹介します。 背景：Ruby では不要コードの発見・削除が難しい クックパッドのサービスの多くは、cookpad_all という 1 リポジトリからなる、巨大な Rails アプリケーションとして実現されていました。しかし、このやり方ではメンテナンスが限界になってきたので、「お台場プロジェクト」という大整理プロジェクトが行われてきました。この辺の詳細は次の 2 つの記事が詳しい
混沌を極める jQuery のコードをいかにして Vue.js に頼らずに整理したか - Qiita
序 師走ですね。年の瀬が近づいてくると、酔っ払った元社員に絡まれることが稀によくあります。 私は jQuery から Vue.js への置き換えで何をやらかしたのか - Qiita 可能ならいきなりフロントエンドのライブラリを導入するよりも jQuery のみで MVVM パターンへ移行したほうがよかったかなぁと今になると思います。 結局のところ、jQuery で苦しんでいたのは、複雑な「状態」が表示やイベントハンドル系のコードとごっちゃになっていたから です。 うん、分かる。当時、この取組みを「大変そうだなー」と思いながら横で眺めていました。 まさか、続きを自分でやることになるとは夢にも思っていませんでしたが(｡◉ᆺ◉) ごあいさつ どうも、 @cesare と申します。 クラウドワークスでサービスの開発や運用を手がける傍ら、たまに機械学習とか VR とかに手を出して遊んでいます。 この
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ
ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
Railsでやってしまいがちな保守性を下げてしまうコードとその解決策 - Qiita
こんにちは。COUNTERWORKSアドベントカレンダー13日目担当の疋田です。 先月からエンジニアとしてJOINしました。現在、業務ではshopcounterというサービスのRailsアプリケーション開発や日々の運用、データ集計や分析を元にしたプロダクトの改善などをメインで行っています。 スタートアップのエンジニアを経験していく中で、常に素早くPDCA回してユーザからのフィードバックをプロダクトに反映することが重要になってくるため、エンジニアとしてはコードの変更のしやすさとか捨てやすさ、読みやすさってかなり重要だなーと改めて強く思ってます。 今回は3年くらいRailsやってきた中でちょっとずつ溜まってきたメンテするときこういうコード辛かったなって部分を共有できたらなと思います。 ちなみに、これらはすべて今までの自分自身もやっていた時期があるコードであり、反省の意味も込めて書いてみます。
RailsのObject#tryがダメな理由と効果的な代替手段（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Do. Or Do Not. There Is No Try - Object#try Considered Harmful 公開日: 2017/09/24 著者: Karol Galanciak サイト: BookingSync 原文タイトルは、よくあるヨーダのセリフのもじりです。 2017/11/07: 初版公開 2022/04/07: 更新 RailsのObject#tryがダメな理由と効果的な代替手段（翻訳） Object#tryは、Railsアプリでnil値を扱う可能性がある場合をカバーするときや、与えられたメソッドがオブジェクトで必ずしも実装されていないといった場合に柔軟なインターフェイスを提供するときに、かなりよく使われています。#tryのおかげでNoMethodErrorを回避できるのですから、これでNoMetho
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
Railsで効率的かつ安全に未使用のメソッドを削除した話 - てくすた
ピクスタ開発部で毎日ヒィヒィ言いながらエンジニアをやっております @muramurasan です。 今回はPIXTAのとあるリポジトリにおいて、未使用のメソッドを削除しようとした際、gemを組み合わせることで、効率的かつ安全に削除することができたという話をしたいと思います。 よくやる方式 外部の勉強会などで、「未使用のメソッドを削除する際にどうしているか？」ということを聞いた際、よく聞くのが「未使用らしきコードを見つけ次第、ロギングを行うメソッド呼び出しを挟み込んでいく」というものでした。 この方式は、動的なメソッド呼び出しにも当然対応できますし、お手軽なので、一般的に好まれているようです。 問題点 ただし、この方式では以下の問題点があると私は考えています。 そもそも、未使用らしいメソッドを見つけるのが大変 プロダクションコードを汚してしまう これらの問題を解決するために、PIXTAでは
DDDを使ってRailsアプリをリファクタリング - Qiita
経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状態となっています。 今回残りの機能をAPIサーバに持ってくるにあたり、下記２つのアプローチがありました。 1. 既存のソースコードからViewを切り離してほぼそのまま持ってくる 2. 設計を見直し、大幅にリファクタする チーム内で議論した結果、スタートアップと
朝Lint活動で細かな技術的負債を返済する - クックパッド開発者ブログ
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Concerns about Concerns
リファクタリング 目的・パターン・思考 / reprotech
フロントエンドに秩序を取り戻す方法 〜はてなブログ編集画面をリニューアルするためにやったこと〜 // Speaker Deck
