レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。

良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か

以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ

(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int

(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま

こんにちは、ミドルウェア開発チームの青木です。 先日、アプリケーションサーバーが応答を返さなくなるトラブルに遭遇しました。 今回はその時のトラブルの原因と対策の顛末についてお話しようと思います。 現象 アプリケーションサーバーが突如応答を返さなくなりました。 現象が発生したアプリケーションサーバーのスタックトレースを見ると、あるスレッドの先頭が上記のようになっていました。 "qtp258153142-514386" prio=10 tid=0x00007f40b8dbf000 nid=0x7b4e runnable [0x00007f415ccb0000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Loop.match(Pattern.java:4692) at java.util.regex.Pattern$G

仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持

いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり

僕がプログラミングに触れた当時は、プログラミングといえば「まず C 言語」でした。それから 10 年以上が経ちました。学校の授業や企業の研修では未だに C 言語を教えているところがあるようです。関数型プログラミング言語という波が来ている 2012 年にもなって未だに C 言語をやっているというのはまるで進歩が無く残念な気もしますが、比較的多くのプログラマに浸透している共通言語を最初に教えるというのは、一方では喜ばしい事だと解釈する事もできるのかもしれません*1。まぁとにかく、本意にせよ不本意にせよ現場で プログラム初心者に C 言語を教える羽目になった 人がたくさんいて、プログラム初心者なのに C 言語を学ばざるを得なくなった 若者がたくさんいるということです。 C 言語を教えるときに避けて通れないのがポインタで、プログラム初心者が C 言語を学ぶときにやたらとつまずく人が多いのがポインタ

本日社内向けのTechTalkにて、並列・並行プログラミングに関する話を行いました。 昨今、プログラムの並列化はなくてはならないものとなっています。しかし、そのプログラミング環境は依然としてロックを用いたものが主流です。今回の発表の主張を端的に申し上げますと、 “Locks must go！” ということになります。並列プログラミングに銀の弾丸はありません。しかし、ロックは別の何らかの安全性を確保したプログラミングモデルで置き換えられなければいけません。そうでなければ、再現しにくいバグに苦しめられ、終電を逃す日々と決別することはできないでしょう。また、ロックによるプログラミングの抱える本質的問題にも言及しています。 この界隈の最新の動向として、去年OOPSLA’10にて発表されたConcurrent Revisionsについての解説も行なっております。また、弊社研究開発において、先日Con

イデアルITスクールというところで、１時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出

オライリーが主催するイベント「Open Source Convention 2011」が7月25日から米国ポートランドで開催されました。 その中で、TwitterがなぜRuby on RailsベースのシステムをJavaVMベースへ移行しようとしているのかを解説したセッション「Twitter: From Ruby on Rails to the JVM」が行われ、ビデオが公開されています。 13分程度の短いセッションのポイントをまとめて紹介します。 世界最大のRuby on RailsによるWebサイトをJavaVMへ移行 Twitterのアプリケーションサービスグループ、Raffi Krikorian氏 Twitterは世界中からのツイートをリアルタイムで扱っている。リアルタイム処理が、ツイッターにおけるもっとも難しい処理だ。 Twitterは、おそらく世界最大のRuby on Rail

データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち

プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほ