さびれた勉強会を復活させる 文化のリファクタリング // Speaker Deck2017/07/28 @ Developers Summit 2017 Summer A-5セッション「組織と文化のリファクタリング」後編資料
絶対に笑ってはいけないRailsコード集 - Qiita
株式会社LITALICO のklrutsaです。 『LITALICO Advent Calendar 2016』13日目の記事です。 はじめに 私が遭遇した、Railsアンチパターン集です。 笑えるよりも、笑えないコードのほうが多いですが、よろしくお願いします。 前回の、負債を抱えすぎたRailsアプリのリファクタリング - Qiitaでは、複雑な状態遷移への対応方法を書きましたが、その他の負債をどうしたかみたいなことについて書いてみます。 一般的に書いてはいけない、とまではいえないかもしれないですが、 個人的には書かないほうが良いと思っているコード集です。 default_scope class Article < ActiveRecord::Base default_scope { where(status: 'publish') } end 要点 プログラマの認識している動作と実際の
FLOCSSを使ってCSSファイルを20,000行から9,000行にした話 - Qiita
入社して僕が最初にアサインされたのがこのプロジェクト。 サービスをスタートさせたのは今年の２月。最初は外注でとりあえずサービスを作ることに集中していたらしい... その結果、どのスタイルがどこに作用するか全く分からないCSSの魔境でした。 これでは簡単なページを追加するにも一苦労。 そこで、20,000行あるCSSファイルのリファクタリングに踏み切りました。 当時の問題 スタートアップのサービスなのでもっと機能を追加したり、変更したりしたいと言う要望は日に日に大きくなっていました。 一方で、実際に機能を作ったとしてもそれを view に反映させるのも日に日に苦しくなっていました。 僕たちを苦しめていた理由は以下の通りです。 どこにスタイルが作用しているか分からないので、CSSを安易に変更ができない。 新しい部品を付け足す時にCSSの影響範囲を考慮しなくてはならず、プロダクトのUI変更が困難
RubyのリファクタリングでNull Objectを使ってコードをスッキリさせる方法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
前回、Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法という記事を書いて、いい反響をいただいたので第２弾を書いた。 Ben Orenstein氏の講演で話されていた前回のとはまた別のリファクタリング方法。元ネタはこちら。 github.com 【リファクタリング前のコード】 class JobSite attr_reader :contact def initialize(location, contact) @location = location @contact = contact end def contact_name if contact contact.name else 'no name' end end def contact_phone if contact contact.phone else 'no phone'
イケてないRubyのコードのリファクタリングって奴をSmallTalkでやってみる - Line 1: Error: Invalid Blog('by Esehara' )
本日の料理 コードも豚肉も煮こむに限る はじめに Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ - Ruby on Railsのビシバシはぁはぁ日記というブログの記事がどうもバズっていて、色んな方面からつっこみが入っていたりする。また、別にこれはオーバーエンジニアリングだから、この程度のコードでもいいのではないか、という指摘も挙がっている。 自分ならどうするかというとこういう感じかな。要するに条件に合う注文を足し算したいだけなので、条件に合う注文を足し算しようよ、という。https://t.co/HEhsO5q2nr— Rui Ueyama (@rui314) 2016年7月17日 コードを書く人によって「これが良いアプローチだ」というのは千差万別であることは間違いない。元の記事を読む限り、これはどうもRubyの特殊事情な
Rubyのリファクタリング:「聞くな、言え」の法則 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
元ネタはこちら。 Tell, Don't Ask キャッチフレーズから非常に分かりやすい。 Tell, Don't Ask 言え！、聞くな理想的なオブジェクト指向設計においてはオブジェクトに対してただやって欲しいことを「言う」だけ。 こちらでどうればいいのか聞いたり、判断したりしないこと。 サンプルで見るとそれは明快。 悪い例 <% if current_user.admin? %> <%= current_user.admin_welcome_message %> <% else %> <%= current_user.user_welcome_message %> <% end %>これはいちいちcurrent_userがAdminかどうか、聞いて（判断して）からメッセージを送っているので、そこがダメ。 ただしくはただ言うだけにするべき。 良い例 <%= current_user.we
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その２ - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
前回からの続き。 Rubyのリファクタリングでオブジェクト指向設計に沿った美しいコードになるまでの方法を書いた。 「イケてない」から「マシ」にするためのリファクタリング 「マシ」から「いいね」にするためのリファクタリング 「いいね」から「スゲーいいね」にするためのリファクタリング 今回は２.の「マシ」から「いいね」にするためのリファクタリング 「マシ」から「いいね」にするためのリファクタリング 今回の変更は主にはオブジェクト指向設計の考え方によるリファクタリングになる。 前回までの変更点を反映した全体像 class OrdersReport def initialize(orders, start_date, end_date) @orders = orders @start_date = start_date @end_date = end_date end def total_sale
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その３ - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
前回からの続き。 Rubyのリファクタリングでオブジェクト指向設計に沿った美しいコードになるまでの方法を書いた。 「イケてない」から「マシ」にするためのリファクタリング 「マシ」から「いいね」にするためのリファクタリング 「いいね」から「スゲーいいね」にするためのリファクタリング 今回は３.の「いいね」から「スゲーいいね」にするためのリファクタリング 「いいね」から「スゲーいいね」にするためのリファクタリング 前回までの変更点を反映した全体像 class OrdersReport def initialize(orders, date_range) @orders = orders @date_range = date_range end def total_sales_within_date_range orders_within_range.map(&:amount).inject(0
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
