関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘
関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘 一般にプログラムは多くの関数などから構成されています。関数には数百行に渡る長いものから数行程度の短いものまでさまざまな長さがありますが、果たして関数にとって適切な長さというのはあるのでしょうか？ マーチン・ファウラー氏は関数の長さについて書いたコラムで、重要なのは意図と実装の分離であり、適切な名前を付けることが大事だと指摘します。同氏のブログは翻訳が許可されているので、記事「FunctionLength」の本文を翻訳しました。 FunctionLength（関数の長さ） 私のキャリアにおいて、関数の長さはどれくらいであるべきか、という議論を何度も聞いてきた。これはより重要な問いに置き換えることができる。それは、どのくらいの長さのコードになったらそれを関数にすべきか、ということだ。 い
リファクタリングをいつ、どのようにやるか
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？ リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
PHP: Clean Code (clean-code-php) 蜜柑薬 - Qiita
もくじ はじめに 変数 関数 オブジェクトとデータ構造 クラス S: 単一責任の原則 (SRP) O: オープン/クローズドの原則 (OCP) L: リスコフの置換原則 (LSP) I: インターフェイス分離の原則 (ISP) D: 依存逆転の法則 (DIP) 同じことを繰り返すな (DRY) はじめに この記事はRobert C. Martinの本「Clean Code」のソフトウェアエンジニアリングの法則をPHPに適合させたものです。これはスタイルガイドではありません。読みやすく、再利用しやすく、そしてリファクタリングしやすいPHPコードを書くためのガイドです。 ここで挙げられるすべての原則は厳密に守らなくてはいけないわけではなく、少し守らなかったところで一般には許容されます。あくまでガイドラインですが、Clean Codeの著者たちがみな長年に渡って経験してきたことです。 この記事(
xUTPの著者から教えてもらった「テストのクラフトマンシップ」 - PoohSunny's blog
はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma
実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
複雑さに潜り込む - 大規模PHPアプリケーションにおける例外・モニタリング・ロギング - すずけんメモ
みなさん、PHP書いてますか？ここ2ヶ月くらいPHPも書いていたのでその話を書きます。 この記事はVOYAGE GROUP techlog / Advent Calendar 2016の記事です。 例えば以下のような話に身に覚えはありませんでしょうか。 例外がどこかで握りつぶされており、例外的状況なのにエラー表示がまちまち。レスポンスステータスも一貫性がない。エラーログが適切に出ていない。 エラーログ出力用コードがいろんなところで散乱している。エラー文字列整形のための適当なヘルパメソッドがクラスごとに実装されている。 エラーごとにエラー表示のためのメッセージを設定するのが面倒になり、「システムエラーが起きました」とだけ表示されるようになってしまった。 例外ハンドリング周りのコードは考えるのが面倒なのでコピペだらけになっている。 オブジェクトの依存関係がクラスのプロパティに大量に埋め込まれて
クソコードレビュー会なるものに参加してきた - そんな今日この頃でして、、、
転職活動でもお世話になったCodeIQで↓のような問題があったので回答を出したところ、 レビュー会への招待が来ていたので行ってみた！ codeiq.jp 問題 出題はじゃんけんを行うプログラムをリファクタリングするという問題。 「標準入力として与えられた文字列を2人分のじゃんけんの手として解釈して勝敗を標準出力する」というもの。 元はnode.jsだったのだが、僕はjsが不慣れだったりもするのでperlで再現。 sub func02 { my ( $a, $b ) = @_; if ( $a eq 'g' ) { if ( $b eq 'c' ) { print "win"; } elsif ( $b eq 'p' ) { print "lose"; } else { print "draw"; } } if ( $a eq 'c' ) { if ( $b eq 'p' ) { print
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - その１ - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
Rubyのリファクタリングでオブジェクト指向設計に沿った美しいコードになるまでの方法を書いた。 元ネタはこちらのBen Orenstein氏のリファクタリングで、そこに私なりの解説とコードを加えた。かなり追加したのでOrenstein氏の原型とはだいぶ違う箇所もあるがオブジェクト指向設計とリファクタリングに対する考え方は同じなはず。 github.com 全３回に渡ってリファクタリングする。 「イケてない」から「マシ」にするためのリファクタリング 「マシ」から「いいね」にするためのリファクタリング 「いいね」から「スゲーいいね」にするためのリファクタリング 今回は1.の「イケてない」から「マシ」にするためのリファクタリング。 イケてないコード 以下にあるのがなんかイケてないコード。一応動くし、テストもパスしている。でもそのコード品質は平均よりちょっと下。 範囲を指定してその間の売上の総合計
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
railsのdefaultでは用意されていない考え方や設計、リファクタリングについてのリンク集 - Qiita