クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
自覚 - naoyaの寿司ブログ
きれいなコードを書こうぜ、といってるのに対して製品の善し悪しに綺麗なコードがいいかどうかなんて関係ない、みたいな話とか 仕様書とかぜんぜん読まないから仕様書なんて全く必要ない、さっさとコード書けとかコードだけで語れ、とか TDD されてないからリファクタリングできないんだ、だからカバレッジ100%にするんだ、ぜんぶテスト書け、とか エンジニアは技術から出発して需要を考えない、だから問題から入れ、技術なんて関係ない、とか 企画屋は技術のことがわかってないから、夢物語りばっかり語るんだ、エンジニアがサービス作るべき、とか そういう、何かを反面教師に反対の考え方を支持するみたいなのは注目浴びやすいけど、視座をもうすこし中立にして考えると、だいたいおかしい。かくいうぼくもそんな風に煽ってる時期がありました、若さって怖いです ─ 中庸って知ってるか。伝統や、むかしから習慣として良しとされてきているこ
プログラミングの楽しさ。オープンソースとの出会い。 - 2nd life (移転しました)
100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊 が出版され、『私と Ruby と添削と』という内容で寄稿しました。私がどうプログラミング・オープンソースの楽しさを知ったかについての昔話です。公開して良い、とのことなので公開いたします。 なお、文章中に出てくる tdiarytimes.rb のコードは以下です。9年前に書いたコードなので今読み返すと恥ずかしいを通り越してもはや微笑ましいですね！！１これでも当時は、自分なりにできるだけ綺麗なコードにして公開した記憶があります。 https://github.com/tdiary/tdiary-contrib/blob/master/plugin/tdiarytimes.rb 私と Ruby と添削と プログラミング技術の向上させるには、どういう方法があるでしょうか。プログラミングに関する書籍を読む、オープンソースで公開されて
Creating an API // RailsTips by John Nunemaker
RailsTips One man, lazily posting some of the things he learns. subscribe » A few weeks back, we publicly released the Gauges API. Despite building Gauges from the ground up as an API, it was a lot of work. You really have to cross your t’s and dot your i’s when releasing an API. 1. Document as You Build We made the mistake of documenting after most of the build was done. The problem is documentin
小野和俊のブログ:メンテナビリティの高いソースコードを目指して
ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して
コードを書けることで僕は本当に救われている - ihara2525's blog
普段僕が仕事でコードを書くことはほとんどありません。 コードを書くことでチームや組織に貢献したい、という思いは常にあります。 同時に、僕はそうすることで自分の価値を一番出せるんだろうか、という思いもあって、やっぱりこっちが強いので、一年ほど前に僕は基本的にマネジメントに徹することにしました。 それでもたまにコードを書きたくなったりしますが、自分が中途半端に参加すると、結局他の人の動きを止めてしまったりすることになるので、やらない方がよっぽど良いです。 「いや、採用とか組織作りとかやめて、本気でやったら俺の方が絶対に書ける！」みたいなのもなくて、集中してやってもたいした結果にならないでしょう。逆に、そうなっちゃうようだったら自分よりも優秀な人を採用できてない、自分の仕事をできてないってことです。 なので、最新の技術への理解や、素晴らしいコードを書くことに関して、僕は確実に、簡単に、僕の周りの
無料で見られるプログラミング関連書籍一覧 - YAMAGUCHI::weblog
はじめに こんにちは、動画配信界の情弱です。年始からStackOverflow眺めてたら超絶便利な質問に神回答がされてたので忘れないうちにメモっておく。2012年どっかで役に立てばいいですね。 参考 オリジナルはこちら。ここではコメントにパラパラと載ってたので、まずは直近1ページ目だけにあったものを1個のリストにまとめてみた。ほぼGeorge Stocker氏による回答を載せただけだけど。あとちょっとだけ自分で和訳とか加えたので、知っているものがあればコメントに載せて下さい。追加します。まだDとかFactorとか載ってないし、Pythonも全然足りないし。 API Only - Stack Exchange もしかするとバージョンが古かったりするものもあるかも知れませんが、それもコメントで教えてもらえるとその旨追記します。 他にも過去に挙がったもののリンク ReadWriteWebのプログ
iPhoneアプリの通信エラー処理を考える - iOS Advent Calendar 2011 - ninjinkun's diary
こんにちは。お仕事でiPhoneアプリを開発しているid:ninjinkunです。このエントリはiOS Advent Calendar 2011 23日目の記事です。今回はあまり注目されることがなさそうなiPhoneアプリのエラー処理を取り上げてみようと思います。 エラー処理と言うとプログラマが粛々とやるものというイメージで、主に内部のエラーハンドリングのことが中心になりがちです。しかしエラー処理はそれをユーザーに通知するところまで考えて初めて完結します。この記事ではユーザー体験の面と内部処理と両方に言及してみようと思います。自分の今までのアプリでもあまり実践できていなかったので、自戒の念も込めて…。 エラーは様々な状況で発生しますが、ここでは主にHTTP通信のエラーを想定します。HTTP通信はiPhoneのようなモバイル端末では高い確率で失敗します。移動中、地下鉄、山の中の中など通信が不
フレームワークで語るMVCの話 : PHP Advent Calendar #19 - basuke の日記
この記事はPHP Advent Calendarの19日目の記事です。 プログラマ１０人集まれば、誰かMVCうんちく語るのが常。みんな大好きMVCの話です。僕は今年でPHPプログラマとして10年が経過しました。この節目の年に、これまで触ってきたフレームワークを振り返り、徹底的な個人的主観でMVCについて語っていきたい思います。忘年会シーズンでお疲れの皆様、ご安心ください。コード・ゼロでお届けします。 いろんな言語のいろんなフレームワークを触ってきたつもりですが、Javaはやってなかったんであまり詳しくないです。主にRails以降のフレームワークを見ていきます。 Railsの功績 PHPプログラマとしてRailsの登場で何にびっくりしたかというと、次の三つです。 router ActiveRecord cliと対話型shell ActiveRecordは魔法のように見えましたが、いずれ出ても
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
オブジェクト指向について語った時に使ったメモ
今日、オブジェクト指向について1時間ほど語りました。整理するため自分用に書いたメモを公開します。大まかな構成はメモどおりに話しましたが、メモに書いていないこともたくさん話していますし、書いていても話さなかったこともあります。 前提として自分自身のオブジェクト指向へのスタンスを書いておきます。 自分のプログラマとしてのキャリアとオブジェクト指向の隆盛の重なりを考えると客観的に見て自分はオブジェクト指向世代のプログラマなんだと思います。一方で、世間で過剰にもてはやされる技術には反発してきました。オブジェクト指向も例外ではありません。オブジェクト指向を否定はしませんが、金科玉条のように扱う人の前では、オブジェクト指向なんて技法のひとつに過ぎないと、冷たく突き放してきました。 ただここ数年、かつてに比べてオブジェクト指向の威光は下がっている気がします。関数型プログラミング支持者から、オブジェクト指
なぜ次に学ぶ言語は関数型であるべきか - YAMAGUCHI::weblog
はじめに こんにちは、Python界の情弱です。ちょっと前にOCaml系のエントリを色々と眺めていたらYaron Minsky氏のエントリを見つけたので翻訳してみました。 OCaml for the Masses - ACM Queue Yaron Minsky氏はJane Streetで第一線で活躍されるエンジニアで、Jane Streetの技術ページをはじめ多くの場所でOCamlに関しての知見を語ってくださっています。 Jane Street Tech Blogs 本エントリはJohn Hughesの名エントリ「なぜ関数プログラミングは重要か」を受けてACM Queueに寄稿されたものの日本語訳です。 なぜ関数プログラミングは重要か Why the next language you learn should be functional YARON MINSKY, JANE STREE
どうして開発者がドキュメントを書くべきか - 2011-10-27 - ククログ
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント（リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント）の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。（どのツールを使えばよいかわからない。） 一方、書く理由はこ
自分のコーディングルールとその理由
・横80列で折り返す。 普段80列で開発してるわけじゃないけど、横に長いコードも見にくいので。 ・1funtionは30行にする。 これも列指定と同じ意味で。 数字自体はそこまで意味がないけど、長いコードはそれ自体問題がある可能性が高い。 ・1ファイルは200～300行 「JSを1ファイルに200行以上書くと人間は死ぬ」と言われてるけど、実際はもうちょっと多くても大丈夫。 ・インデントは8タブ タブを使う理由は「タブはスペースに一括置換できるけど、スペースはタブに一括置換できない」から。 なので、コード中にコードインデント以外でハードタブは記述しない(文字列内に記述する時は¥tで記述する) タブの表示数はエディタ毎の設定次第だけど、インデントの深いコードが書きにくくなるので8タブで書く。 ただし、インデントの文字数に依存するインデントはしない(4タブでも正常なインデントになるように記述する
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
安全なバッチ処理の作り方 - KAYAC engineers' blog
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理？ Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件（時間やサービスの状態）で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき？ バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作業効率が10倍アップする Chrome Developer Tools の使い方