「書き直した方が早い」は9割のケースで間違いだった - 怠惰を求めて勤勉に行き着く
はじめに、本エントリは特定の企業、チーム、個人を指して書いたものでは一切ない。100%僕の個人的な経験から来ている。 さて、職業プログラミングに従事していると一度は「これ書き直した方が早いっす」とか言ったことある気がする。自分の場合、多くは歴史のあるレガシーコードを読んだときだ。思い返せば、自分がこう思ったときはほとんどそれは間違いであった。 「なんだこのコード…」 「これ何書いてあるか分かんないっす」 「うーんこれもう書き直した方が早くないっすか？」 この流れは非常に危険だ。 なぜならプログラムというのは本質的に書いてある通りにしか動かないからだ。ちゃんと読めば絶対に何を書いてあるかは分かる。 ここで安易に選んだ書き直しという選択は、自分が慣れ親しんだやり方でその部分をそっくり置き換えるというだけで、それは他人にとってあたらしい「これ何書いてあるかあるか分かんない」を生む結果にしかならな
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
レガシーコード改善ガイド・知識編 - Strategic Choice
書籍「レガシーコード改善ガイド（Working Effectively with Legacy Code）」の「第1部 変更のメカニズム」より、レガシーコード改善作業の前提となる知識をまとめます。目次レガシーコードとは変更：ソフトウエア一般 ソフトウェア変更の課題ソフトウェア変更のリスクソフトウェア変更の方法回帰テストによるソフトウェアの保護回帰テストの問題点単体テストによるソフトウェアの保護単体テストの境界線変更：レガシーコード特有 レガシーコード変更の課題レガシーコード変更の心構えレガシーコード変更の方法関連エントリレガシーコード改善ガイド・知識編（本エントリ）レガシーコード改善ガイド・戦術編レガシーコード改善ガイド・戦略編出典レガシーコード改善ガイド (Object Oriented SELECTION)作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉
汚コードが我慢ならないエンジニアに使ってほしいリファクタリングツールまとめ｜TechClips[テッククリップス]
エンジニアにとって一度書いたソースコードを改善するリファクタリングは欠かせないものです。特に中長期的に修正や拡張が繰り返されるような場合、書いた本人だけでなく、ほかのエンジニアであっても理解できるようにしておくことはとても重要。 万が一怠ってしまうと、それはもう目の当てられない状況になることもあります……。そうならないためにも、常日頃からリファクタリングという作業をルーチンとして取り入れたいところです。そうしたリファクタリングを少しでも効率化できるツールをいくつかご紹介。 もちろん、事前にデバッグしておくことも重要ですので、後半ではデバッグツールもいくつかあわせてご紹介します。日々、コードレビューに時間を取られているような方にとっても作業を円滑にするうえで参考になると思いますので、是非ご一読してみてください。 grunt-plato https://github.com/jsoverson
![汚コードが我慢ならないエンジニアに使ってほしいリファクタリングツールまとめ｜TechClips[テッククリップス]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d065d176533eb4ce3238953d8860cd2e4c665dd/height=288;version=1;width=512/https%3A%2F%2Fobject-storage.tyo1.conoha.io%2Fv1%2Fnc_261159609ad84809af5afcb9e5f56abb%2Ftechclips%2Fimages%2F260%2Fimage.png)
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
Rubyのリファクタリングでオブジェクト指向設計に沿った美しいコードになるまでの方法を書いた。 元ネタはこちらのBen Orenstein氏のリファクタリングで、そこに私なりの解説とコードを加えた。かなり追加したのでOrenstein氏の原型とはだいぶ違う箇所もあるがオブジェクト指向設計とリファクタリングに対する考え方は同じなはず。 github.com 全３回に渡ってリファクタリングする。 「イケてない」から「マシ」にするためのリファクタリング 「マシ」から「いいね」にするためのリファクタリング 「いいね」から「スゲーいいね」にするためのリファクタリング 今回は1.の「イケてない」から「マシ」にするためのリファクタリング。 イケてないコード 以下にあるのがなんかイケてないコード。一応動くし、テストもパスしている。でもそのコード品質は平均よりちょっと下。 範囲を指定してその間の売上の総合計
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
リファクタリングコンテスト in Ruby 審査結果発表 - Grooves開発ブログ
大変長らくお待たせしました。Forkwell Jobs にて、2015年11月24日〜12月31日の期間で開催していた【リファクタリングコンテスト in Ruby 】の審査結果がようやく出揃いました。 今回、なんと最もよいコードに贈られる Ruby賞 を1人のユーザーが独占する結果となりました。 気になる審査結果の前に、あらためて審査員をご紹介します。 松田 明 ( @a_matsuda ) Ruby / Rails / Haml / CarrierWave等のコミッター。kaminari / action_args / active_decorator / motorhead 等の作者。 好きな寿司：アナゴ 和田 卓人 ( @t_wada ) タワーズ・クエスト株式会社取締役社長、プログラマ。日本におけるテスト駆動開発（TDD）のスペシャリスト。 好きな寿司：赤貝 藤村 大介 ( @ff
パワフルではない言語が必要 – 表現力と合理性のトレードオフについて、Pythonを例に考える | POSTD
多くのシステムは“パワフル”であることを売りにしています。パワフルであることを悪いことだと指摘するのは困難に思えますし、この言葉を使う人々はほとんど全て、良いことと想定して使っているようです。 この記事では、 パワフルではない 言語やシステムが必要なケースも多いということを論じたいと思います。 まずその前に、この記事を書くにあたって、私自身のオリジナルの知見はほんのわずかしかない、ということを述べておきます。ここに述べた一連の考えの背景には、Hofstadterの著作 『Gödel, Escher, Bach: An Eternal Golden Braid』 （訳注：日本語版があります。 『ゲーデル、エッシャー、バッハ – あるいは不思議の環』 ）を読んだことがあります。この本を読んだことで、私自身の経験から得てきた原則について、考えがまとまりました。Philip Wadlerの投稿、
ちょっといいJavaコードを書こう - Qiita
一人でプログラムを書いてたりすると、環境によってはあまりコードの書き方には指摘を受けなくて困りますよね。プロになっても、曲がりなりにもちゃんと動くコードを書けてしまうとあまりに当たり前のことなんかは指摘されることも稀で、そのままある程度偉くなっちゃった日には、もはや自分で気付くしかなくなってしまいます。 FindBugsとか、Effective Javaなら使ったり読んでみたり読ませたりすることはできますが、それ以前のところって難しいんですよね。よいコードと言うよりそれが当たり前だと思われているので、指摘するにしても「こうすればいいよ」（アドバイス）じゃなくて「なんでこうしてないの？」（詰問）になってしまいがちです。 そこで、最近そういうJavaニュービーに指摘している（したい）ことの多い、Javaの基礎的な事柄をまとめてみました。ワタシJavaチョットデキルって人は、これ以外にもやりがち
クソコードをクソで終わらせないために僕らが出来ること - 何か着ていればいいよ
あけましておめでとうございます。 新年最初のエントリーですが、こんな話題でなんだかな？って感じもしますが気にしない！ 本題 仕事でプログラマーをしていると避けられないのが、既存のくそコードです。 このエントリーではクソコードを プログラマーが読んでいると小声で「クソっ！」とか悪態が自然と出てしまうようなコード などと適当に定義しておきます。 クソコードにやられてばっかりいられない クソコードにまみれて地べたを這いつくばっている我々プログラマーですが、ただやられているのも癪に障りますよね。 そこで、なんとかクソとみそを美味しくいただけるようなアプローチは無いものか？と思案して最近やっていることをクソポエムとして残しておきます。*1 クソな部分を抜き出して一般化アンチパターンとして何か名前をつける なぜクソなのかを把握し、書き残す どのような経緯でクソにまみれてしまったのか？を探ってみる*2
Shibuya.rbで発表してきた #shibuyarb #rubymotionjp - ainameの日記
以前、書いた記事(最近投げたpull requestとかソーシャルコーディングとかリファクタリング )の反響が若干あったので、RubyMotionTokyo meetupの宣伝も兼ねて発表してきた。 ibをリファクタリングして、tsort依存関係解決の機能を導入したという話。 tsortの使い方の話は一切してなかったのですけど、公式ドキュメントの通り使うとすげー簡単に使えます。 http://doc.ruby-lang.org/ja/2.0.0/class/TSort.html require 'tsort' class Hash include TSort alias tsort_each_node each_key def tsort_each_child(node, &block) fetch(node).each(&block) end end {1=>[2], 2=>[3, 4]
認定試験問題のリファクタリング結果をGroovyにとりあえず移植してみました - 達人プログラマーを目指して
最近Groovyから遠ざかっていたため、勘を取り戻す練習も兼ねて、先日Javaプログラミング能力認定試験課題プログラムのリファクタリングレポート（その３） - 達人プログラマーを目指してでご報告したサーティファイJavaプログラミング認定試験のリファクタリング結果をGroovyに移植してみました。また、使い始めたばかりで良くは理解できていないのですが、ビルドもMavenからGradleに切り替えてみました。 現時点ではテストも不十分ですし、十分にGroovyらしいコードにも修正できていませんが、一応コードは以下に登録してあります。（ビルド方法は後述） リファクタリングGroovy版 一方、もともとのJavaのリファクタリング結果は以下にあります。 リファクタリングJava版 Javaからの基本的な修正手順 Java版のリファクタリング結果に対して、基本的には以下の手順で修正を加えました。
Eclipseのリファクタリング機能を極める その１
Eclipseにはリファクタリングという便利な機能があります。このシリーズではその使い方をお送りしたいと思います。 まずは手始めにrename機能からです。 Eclipeのリファクタリング リネーム機能 リファクタリングの初歩としてリネーム（名称変更）が挙げられます。 Eclipse3.4では以下の要素に対してリネームを行うことができます。 型（クラス・インターフェース・列挙型） メソッド メソッドの引数 フィールド ローカル変数 ジェネリクス型パラメータ 列挙 コンパイル単位(.javaファイルのこと) パッケージ ソースフォルダ プロジェクト Eclipse3.4ではリネームの際にテキストフィールド上で操作を完結することができますが、オプションを指定したい場合は▼をクリックすることでダイアログを開くことができます。 "Open Rename Dialog"を選択します。すると、選択中の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いコードとは
Blogger
5524行→233行リファクタリング！！！ はてなフロントエンドの秩序を支えるスピリット #nodefest #nodefestB
テストコードのリファクタリング