undo,redoの実装って何十回もやってる気がする。毎回同じパターンだ。undo,redoが登場するような編集ソフトは大体同じパターンに落とせる。フレームワークも作った。ブログにそういう内容を書きたいが面倒くさい。需要があれば面倒でも書くんだけどなあ http://twitter.com/youpychan/status/994486992 という発言をしたら何人か反応を頂いたので書いてみることにする。 需要があるなら書こう。undo,redoだけじゃなくてグラフィカルな編集ソフト全般の話をいつかまとめたいと思っていたので、ちょいとシリーズで書いてみようかとおもう http://twitter.com/youpychan/status/994636764 書こうと思う。 まずUndo,Redoについて。 Unod,Redoってみなさんどういう風に実装しているでしょうか？ 私はコマンドパタ
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
シェルスクリプト リファクタリング ～遅いシェルスクリプトが供養されてたので蘇生して256倍に高速化させました～ - Qiita
はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
PHP では以下のように new してすぐメソッドを呼べない <?php new DateTime()->getOffset(); なので、引数をそのまま返す関数を作ってやると <?php function expr($a) { return $a; } expr(new DateTime())->getOffset(); // OK! 便利だなー おまけ 配列アクセス用のも作っておくと便利 <?php function expr($a) { return $a; } function idx($array, $i) { return $array[$i]; } echo idx(idx(expr(new DateTimeZone('Asia/Tokyo'))->getTransitions(), 0), 'abbr') . "\n"; おまけ2 無名関数をそのまま呼ぶときにも使える。 <
増井さんが「今、気になる人」に直撃する連載。前編では、PHPの独自フレームワークで開発したチャットワークをScalaで刷新すると宣言したChatWorkの山本正喜CTOに、プロジェクトの進捗と、このプロジェクトがもたらした影響について聞きました。 後編では、チャットワークの未来像や、技術的負債を抱えないための方法論などについて、話を進めていきます。 苦労して育て上げたPHPを捨てるメリットとは？ 増井：現行のシステムはまだPHPで動いてるんですよね？ 山本：そうです。 増井：10万4000社が使っている大規模サービスなのに、特に大きな問題はないんですか？ 山本：今は安定していますから問題はありません。でも3年ぐらい前までは、大きな障害を起こすことが度々あったので、正直、大丈夫とは言い切れない部分がありました。増井さんならよくご存じでしょうが、大規模なシステムでPHPを使う時には、気をつける
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
大きな Rails アプリケーションをなんとかしよう。まずは計測と可視化からはじめよう。 - クックパッド開発者ブログ
こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開
ここは、Martin Fowler's Bliki の翻訳Wikiです。 Martin Fowler氏本人の許可を得て公開しています。 Wikiですので、どなたでも参加可能です。 ご自由にページの追加、修正、変更を行ってください。 まずは およみください をどうぞ。 ご意見は ご意見箱 までどうぞ。 ページ一覧からページをご覧いただけます。 まだ翻訳していないページは、InHandOrNotまたはKeywordListUntranslatedで確認できます。是非、「新規作成」してください ;-)。
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
@herablog さん、@shunke07 さんと共に Muddy Web #3 で発表した資料です。 https://cyberagent.connpass.com/event/261115/ news.ameba.jpは5年前にデスクトップ版ではReact化、モバイル版ではAMP化が行われました。当時は最先端の技術でしたが時が経つにつれて技術的なトレンドも変化しています。TypeScriptやTanStack、Core Web Vitalsの登場によりWebフロントエンドの技術構成は日々進化しています。 時代の流れに合わせてAmebaNewsでは、脱AMP、脱SPAやTypeScript化などを行いましたので紹介いたします。
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
先に境地を 個人開発の場合、少ないコード・最低限のシステム構成は正義。 なぜなら、時間やお金に制限がある個人開発者にとってサービスの継続に関わる問題だからです。 例えば、自分のサービスを世に広めたいとか、一発当てたいとか、作ったサービスで生活をしたいとか、 なにか目標があるなら達成する方法は、達成するまでやめないことです。 なのでサービスを提供し続けることは最も大切なことです。 これまで個人開発者としては↓の気持ちで開発を進めてきました。 しかし、この経験の後にこの↓の名言の大切さを改めて感じることができました。 シンプルにしておけ愚か者 また、本記事本文より たくさんプラグインやモジュールを入れたシステムはメンテナンスがしんどいです。「デフォルトで使う」ということの魅力を改めて実感しています。リソースが限られている個人開発の場合、このような時間の消費は極力なくす方向にしていくべきです。
) 4月1日に10年続くとあるWebサービスをフルリニューアルしました。 リニューアルの目的は、システムが度重なる機能拡張により、必要以上に複雑化してしまい、ちょっとした修正でも非常に時間がかかるので今後、事業のスケールを拡大していく上のが難しくなってきたためです。 特に大きなところですと、スマホサイトがリニューアル前のサイトだと、スマホとPCで機能が完全に分断されてしまっていました。サイトを立ち上げた当初はスマートフォンすらなかった時代なのでしょうがないとは思いますが、これをこれ以上保守していくのはしんどいので、スマホファーストの思想を取り入れサイトを設計していきました。 技術的にも、PHPからRubyに変更して、ELBやS3をとりいれ、Githubベースの運用に変更することで、時代の流れに取り残されていたWebサイトを今風な感じの仕組みへと変更しました。 リニューアル自体はプロジェクト
qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ
Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside
CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい！と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ
リファクタリングチームに入ってから学んだ理解しやすいコードを書くための基本的なこと - クラウドワークス エンジニアブログ
こんにちは！ 去年の４月に新卒入社してからお酒ばかり飲んでいるエンジニアのd4teです。 4月から11月まではUX改善チームにてお仕事検索画面のフロントエンド開発を担当しておりましたが、11月からはリファクタリングチームにてcrowdworks.jpのリファクタリングをしています。 現在のcrowdworks.jpの状況 過去の記事にもあるように、crowdworks.jpはサービスインから約8年が経過し、30万行を超えるモノリシックなRailsアプリケーションになってきていて、コード行数の増加量やファイル変更数の推移は年々鈍化してきています。 内部には開発生産性を低下させる技術的負債が溜まってきており、技術的な投資がしづらくなってきているという課題があります。 自分が所属しているチームは、外部から見た動作を変えずに内部のコードを整理するリファクタリングで技術的負債を解消し、開発生産性の向
はじめに 本稿は、拙書のエンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリングに関する参考となる書籍を企画意図とともにあげていく試みです。できる限り、専門書ではなく平易な文体の書籍を参考としてあげていきますので、このあたりを深掘りしたいなと思ったら、その箇所のみの参考書籍を併読していただけるとより理解が深まると思います。 Chapter 1 思考のリファクタリング 第１章は、「仕事」と「学力テスト」という２つの違いを論じながら、１６世紀から２０世紀初頭にいたるまでの科学哲学の歴史を辿っていくというのが「裏テーマ」となっています。そこから、「知識を得る」とは何かということを浮き彫りにし、それこそが<エンジニアリング>であると論じるということが本書を通じた論理展開の骨子です。 そのため、直接の参照ではありませんが、科学という概念が西洋社会でどのように生まれてきたのかとい
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える - エンジニアHub｜Webエンジニアのキャリアを考える！
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える 技術的負債、デザイン面での課題など、サービスを構成するシステムを全面にわたってリニューアルしたプロセスを、オミカレの高橋一騎さんが克明に伝えます。 株式会社オミカレでテックリードをしております、高橋一騎（たかはし・いっき／ @ikkitang ）です。私たちが提供する婚活メディアサービス「オミカレ」は、2019年3月にシステムのフルリニューアルに踏み切りました。本稿では、このリニューアルのプロセスをできるだけ詳細にお伝えしたいと思います。 さて、「技術的負債」という言葉を耳にすることがあります。なぜ負債が生まれるのか。「品質を犠牲にしてでも早々にサービスをリリースし、短期的にビジネスの速度を上げる」という判断はその理由の一つに挙げられるでしょう。エンドユーザーへの価値提供スピードを得るための見返り
ソフトウェアエンジニアが品質保証を学んでわかったこと / What software engineers have learned about quality assurance
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
Refactoring at Scale – Lessons of Rewriting Instagram’s Feed
About the content This talk was delivered live in September 2016 at try! Swift NYC. The video was recorded, produced, and transcribed by Realm, and is published here with the permission of the conference organizers. When the Instagram team rewrote their iOS feed from the ground up, they learned more than they anticipated about collection views, diffing, and the dangers of too much spaghetti code.
サーバサイドエンジニアの @b4b4r07 です。この記事は Go Advent Calendar 2016 の 19 日目です。今回は Go (Revel フレームワーク) で書かれていた API サーバをフルスクラッチで書き直したお話をします。 Revel とは A high productivity, full-stack web framework for the Go language 公式の説明にあるように、Revel は高機能でフルスタックな Web フレームワークです。 複雑なルーティングや、パラメータのパーシング、テンプレート機能など、Web アプリケーションを作ろうとなったときに必要な手段はたいてい兼ね揃えているようです。公式ドキュメントに詳しく書かれています。 Revel 以外にも Go 製の Web フレームワークは多数あり、有名どころだと以下のようなものが挙げられ
リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。
汚いcssを整形するWebアプリ「css2scss」でリファクタリングした際、「ヤバい」と感じた３つの機能と３つの点 - Qiita
汚いcssを整形するWebアプリ「css2scss」でリファクタリングした際、「ヤバい」と感じた３つの機能と３つの点HTMLCSSSassscssCompass あらまし 別の業者が構築したという客先のホームページのcssが非常に読みづらく、 誰も手が付けられてない状態でヤバい（compactの状態で約350行）。 そこでリファクタリングをしようと思った際に、考えた。 「どうせならsass/scss対応にした方が可読性も可用性も上がる！ヤバい！」 sass/scss → css は当たり前として、 css → sass/scss って出来るのかよ、と思い調べてみると、数個発見した。 そのうちの１つ、今回ご紹介する「css2scss」が非常にエレガントだった。 実際に使用して感激して落胆したポイントを、それぞれ３つに絞ってご紹介。 css2scss sass/scssについては、まずはアレな
3ヶ月で20万行を消すためにやったこと
SwiftUIでビットコインの価格チャートを改善・再実装した話 / Improving and Re-implementing the Bitcoin Price Chart Using SwiftUI
iOSDC Japan 2023登壇資料
TechCrunch
Over the weekend, Paddy Cosgrave and Web Summit made the bombshell announcement that Cosgrave would step down from his post as CEO of the technology conference business — a move made to try to c
GitHub: jackfranklin/the-refactoring-tales 読んだ日付: 2015年1月11日 まだ4章の途中までしか書かれてないですが、ウェブ版は無料で読めてPDF版等は買えるようになるようです(6-7章ぐらい予定) The Refactoring Tales - JavaScript Playground またGitHubにソースが公開されています(ウェブページはまだ反映されてない感じのtypoの修正等がありました) 感想 1,2章はフロントのJavaScriptで、jQuery世界を例にjQueryでべったり書いてしまったものをどうやって分けていくかの話。 1章はとても読みやすくて完成度もあるので読んでみるといい気がします、2章のカヌーセルの話はもっと深くやっても良かったような気がします。 縦に並ぶ$を見かけるとつらい感じになりますが、まずは手が出しやすい場
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
実践クリーンアーキテクチャ - 複雑化した大規模ECサイトをモダナイズしたモノタロウの事例 - エンジニアHub｜Webエンジニアのキャリアを考える！
実践クリーンアーキテクチャ - 複雑化した大規模ECサイトをモダナイズしたモノタロウの事例 クリーンアーキテクチャのメリットとは？またいかにして導入するか？難解なイメージのあるクリーンアーキテクチャの概要を採用事例に学びます。今回、取材したのは工業用間接資材オンラインストアの「モノタロウ」。サービスの開発を続けていくにつれ、同社のシステムは複雑化、肥大化していき、様々な課題が生じたそうです。こうした課題に対応すべく、システムのモダナイゼーションに取り組む際、取り入れたのは、クリーンアーキテクチャでした。同アーキテクチャをどのように実装したのか、モノタロウのエンジニア3人に聞きました。 受け入れテストを自動化し、システムの正常動作を保証 ユニットテスト導入の秘訣は「テストを書くハードルを下げる」こと クリーンアーキテクチャ化は、“幹”の処理から手をつける クリーンアーキテクチャを全社的に展開
JJUG CCC 2012 fall / 札幌Javaカンファレンス2012での発表資料です。 ソースコードは https://github.com/shuji/demo-refactering-unittest から取得してください。
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Undo,Redoの実装って何十回もやってる気がする - あしあと日記
PHP で引数をそのまま返す関数を作っておくと便利 - IT戦記
苦労して育てたPHPを捨てるメリットは？ チャットワークに聞く（後編） | HRナビ by リクルート
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
Martin Fowler's Bliki in Japanese - FrontPage
if文の条件式の書き方あれこれ | GuildWorks Blog
ActiveRecord のモデルを整理する7つのパターン - tkawachi Blog
リリースから5年、Webフロントエンドの経年劣化と向き合う
GitHub - airbnb/javascript: JavaScript Style Guide
【個人開発】収益化したサービスのコードを50%以上削除して得られた境地
10年以上続くサイトを初めてリニューアルして感じた事 | Basicinc Enjoy Hacking!
3週間で48,000行のコードをこの世から抹消した話 – FiNC Engineering Blog – Medium
エンジニアリング組織論への招待：リファレンスガイド第１章/第２章 - Qiita
既存のAndroidアプリをリファクタリングしていく話
ドキュメント作成時のあるあるアンチパターン20 - Qiita
sudoとsuがRustで書き直される。メモリ安全性向上へ
GoでとあるAPIサーバを実装し直した話 | メルカリエンジニアリング
Martin Fowler's Bliki (ja)
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
ソースコード検索エンジン「Sourcetrail」OSS化、GitHub上で公開
実践 よくないコードに立ち向かう整理術 〜あなたのコードはどんな色？〜
複雑さに立ち向かうためのコードリーディング入門
The Refactoring Tales - JavaScriptのリファクタリング本を読んだ
僕が考える「良いコード」 - give IT a try
テストコードのリファクタリング
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD