はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
会社のBlogにも書いたのですが、ISUCON 8 予選で負けてきました。 さて、 ISUCON の初期実装の定番として、初心者が書いたようなSQLやコードになっている点が挙げられます。 今回の Go の初期実装もその定番にもれず、初心者がやりがちな、Goの良さを殺してしまうコードがありました。 今回負けた反省点の一つとして、アプリの書き換えを二人でやっていたのでコンフリクトを恐れてそのリファクタリングを怠ったというのもあります。 Goで本戦に参加されるチームの方にはぜひこれを克服してもらいたいと思います。 アンチパターン: 長い無名関数 例: https://github.com/isucon/isucon8-qualify/blob/9d7890f5433bdaf2cec75b4cdf1ebd0d9a531281/webapp/go/src/torb/app.go#L404-L492
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
あらまし 別の業者が構築したという客先のホームページのcssが非常に読みづらく、 誰も手が付けられてない状態でヤバい（compactの状態で約350行）。 そこでリファクタリングをしようと思った際に、考えた。 「どうせならsass/scss対応にした方が可読性も可用性も上がる！ヤバい！」 sass/scss → css は当たり前として、 css → sass/scss って出来るのかよ、と思い調べてみると、数個発見した。 そのうちの１つ、今回ご紹介する「css2scss」が非常にエレガントだった。 実際に使用して感激して落胆したポイントを、それぞれ３つに絞ってご紹介。 css2scss sass/scssについては、まずはアレなcssを突っ込んでみて挙動を確認して頂ければ幸い。 また、下記のリファレンスが総括的で解りやすい。ご一読あれ。 Sass 3.2 オレオレリファレンス ヤバいを連
先日認定試験問題のリファクタリング結果をGroovyにとりあえず移植してみました - 達人プログラマーを目指してにてJavaプログラミング認定試験のサンプルプログラムのGroovy化について紹介しました。その記事を書いた時点では、とにかくGroovyとJavaとの親和性という特徴を生かし、あまりGroovyらしさということを考えずにとりあえずGroovyに移植しました。 ここでは、Groovy言語の特徴をいくつか活用することで、さらなる、プログラムの簡易化に挑戦してみたいと思います。 ソースコードは以下（GitHub - ryoasai/certification-refactoring-groovy: Java認定試験のリファクタリングサンプル（Groovy版）） 配列のListとの互換性の強化 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プ
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 ＜アレスネットをご契約のお客様へ＞ 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
Domain-Driven Design(DDD)の１６章の最後の数ページは、パターンとして定義してないけど、構造設計について、興味深い内容が書かれている。 構造設計の良し悪しの判断？ ソフトウェアは、バグがあったり、性能問題が発覚すれば、開発チームのメンバーは、みんな問題だと思うし、修正しようと思う。 そして、直ったか直らないかは、いちおう確認できる。 構造設計になると、そうはいかない。 ソフトウェアがちゃんと動いていて、ソースの中身も、まあまあ、追いかけることができれば、全体の構造なんて、あまり気にしない技術者、チームが多いのかもしれない。 クラスが肥大化して、参照関係が入り組んできて、コードが読みにくくなり、修正の副作用が恐くなってくると、さすがに、これじゃまずい、という「感覚」はでてくる。 ファウラーが「リファクタリング」で書いているように「コードのいやな臭い」を感じる度合い、感じ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Java言語で学ぶリファクタリング入門: 結城浩: 本