「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス
404 Blog Not Found
2017年07月20日09:00 カテゴリVALU If you can't beat them, join them. 君子は豹変す ⇔ 豹変しなけりゃ君子じゃない。続きを読む dankogai コメント( 2 ) 2017年03月19日16:30 カテゴリevalparkOpen Source evalpark - Swift入園しました というわけでおしらせです。続きを読む dankogai コメント( 0 )トラックバック( 0 ) 2017年03月17日10:30 カテゴリevalparkOpen Source ようこそevalparkへ え?もう本番ですか…? Welcome to Evalpark! 続きを読む dankogai コメント( 0 )トラックバック( 0 ) 2015年12月03日19:30 カテゴリMath 「「0÷0＝」を実行すると「エラー」になる理由」を見
オライリーのSafari BookがiPod Touchで読める Safari Bookbag
► 2021 (1478) ► 8月 (182) ► 8月 13 (20) ► 8月 12 (11) ► 8月 11 (11) ► 8月 10 (10) ► 8月 09 (22) ► 8月 08 (6) ► 8月 07 (36) ► 8月 06 (19) ► 8月 05 (9) ► 8月 04 (2) ► 8月 03 (7) ► 8月 02 (18) ► 8月 01 (11) ► 7月 (371) ► 7月 31 (10) ► 7月 30 (20) ► 7月 29 (36) ► 7月 28 (26) ► 7月 27 (27) ► 7月 24 (10) ► 7月 23 (7) ► 7月 22 (27) ► 7月 21 (6) ► 7月 20 (22) ► 7月 19 (3) ► 7月 18 (11) ► 7月 17 (7) ► 7月 16 (5) ► 7月 15 (11) ► 7月 14 (
金融危機についての入門的まとめ - 池田信夫 blog
年末になって、本屋にはぞろぞろ「大恐慌本」が出てきた。現在の不況を「大恐慌」などと名づける本は、それだけで読まないほうがいい。それは著者が1930年代と現在の違いを理解していないことを示すからだ。しかし官僚やメディアにはそのレベルの理解も共有されていないようなので、今年の記事をまとめて金融危機についての入門的な知識をまとめておこう。ちょっと長いので、いつも読んでいる読者は飛ばしてください。金融危機の原因は大恐慌とは違う：今回のアメリカの金融危機の最大の原因は、住宅バブルの崩壊にともなって、複雑でリスクの見えにくい金融商品の逆淘汰が起こったことによる金融システムの崩壊だ。これは30年代の大恐慌とも日本の90年代とも異なる21世紀型の危機であり、既知の処方箋はない。マクロ政策は、一時的な「痛み止め」の意味はあるが、今回の危機はそれだけで自然治癒するほど軽傷ではない。 大恐慌は再来しない：シュ
西原理恵子の言葉 - レジデント初期研修用資料
西原理恵子の新刊 ｢この世で一番大事なカネの話｣からの抜き書き。 努力のしかた 順位に目がくらんで、戦う相手を間違えちゃあ、いけない 目標は「トップになること」じゃない。これだけは譲れない、大切な目標を実現すること 肝心なのは、トップと自分の順位を比べて卑屈になることじゃない。最下位でも出来ることを探すこと。自分の得意なものと、限界点を知ること。やりたいこと、やれることの着地点を探すこと。最下位の人間には、最下位の戦いかたがある 「どうしたら夢が叶うか」って考えると、全部あきらめてしまいそうになる。「どうしたらそれで稼げるか」って考えれば、必ず、次の一手が見えてくる 「カネ」を失うことで見えてくるもの 銀玉親方に教わったのは、まず｢負けてもちゃんと笑っていること｣。これはギャンブルのマナーの、基本中の基本 ギャンブルでした失敗を、もし、どうにも笑えなくなったなら、それはもう、その人が受け止
実践的な Haskell の本 - あどけない話
Perl6 は何年経っても正式にリリースされません。そんな Perl6 を Audrey Tang さんは、たったの数ヶ月で作りました。その実装は Pugs と呼ばれています。短期間の開発を可能にした秘密兵器は Haskell です。 その Audrey さんが、2006年に日本で Haskell について説明してくれました(資料)。残念ながら、そのころの僕は Haskell に興味がなかったのでチュートリアルは受けていませんが、その概要にはこう書かれています。 コーナーケースを探すのにユニットテストを書くのに疲れた？ QuickCheck を使ってコンピュータに書かせちゃいましょう。正規表現ベースのパーサはメンテナンスしにくいのに気づいた？ Parsec を使って 15分で Perl6 の完全なパーサを書く方法を勉強しましょう。デッドロックやレースコンディションはもううんざり？ STM
ある編集者の気になるノート : 立川談志が弟子に教えた、醜い嫉妬の解消法。
この本は、頂き物ではなく、ちゃんと自腹で買いました。 『赤めだか』 読む前から評判が高く、売れているようなので、つい敬遠してしまったのですが（編集者にありがち）、いや、もっと前に読めばよかった。 近頃読んだ本の中でも、一番のオススメです。 今日はその中でも、僕にとって一番「しみた」部分をご紹介。 ＊あとから入門した弟弟子の志らくを、師匠の談志が何かにつけてほめ、著者（談春）が腐っていたときの話 翌日、談春（ボク）は談志（イエモト）と書斎で二人きりになった。突然談志（イエモト）が、 「お前に嫉妬とは何かを教えてやる」 と云った。 「己が努力、行動を起こさずに対象となる人間の弱みを口であげつらって、自分のレベルまで下げる行為、これを嫉妬と云うんです。一緒になって同意してくれる仲間がいれば更に自分は安定する。本来ならば相手に並び、抜くための行動、生活を送ればそれで解決するんだ。しかし人間はなかな
なつみかん＠はてな - Software Design 10月号のPlagger特集が分かりやす過ぎる
Software Design (ソフトウエア デザイン) 2006年 10月号 [雑誌] 技術評論社AmazonSoftware Design (ソフトウエア デザイン) 2006年 10月号 [雑誌] 技術評論社Amazon 特別企画 Plagger3分Hacking 俺流Plagger活用術 1章：Plaggerって何？……竹迫良範 監修 2章：Plaggerを使ってみよう……竹迫良範 監修 3章：俺流Plagger3分Hacking……竹迫良範 監修 コラム：Plaggerのアイデア……宮川達彦 そもそもPlaggerってなに？ と言う所から始まり、具体的な機能解説、そして「はらへったピザ」などの応用例まで。約30ページの特集ですが、こんなに分かりやすいPlaggerの解説は初めてかも。プログラムとか全然分からない人でも普通に読める内容です。超初心者でも問題ありません。興味のある方
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「わたしと仕事、どっちが大事?」はなぜ間違いか
タイトルで惹かれて一読、これはイイ！ これは使わせてもらおう。 ロジカルシンキングやMECEといった論理的思考ツールは、確かに仕事に使えるまで砥いできたが、肝心の議論に役立ってはいない。あ、いや、「自分の考えを的確に表現し、相手に理解させる」ツールとしては有効だけど、 ・議論が紛糾したとき ・自分の結論へ誘導したいとき ・自分の主張に言いがかりとつけられたとき これっぽっちも役に立たない。「おまえの意見はよく分かったが ── ── そんな話はここでは通用しないよ」 ── SEにはカネのことなんか分からないんだ」 ── 他の人もみんなそうじゃないと言っているよ」 と断言されると、一瞬、どう返していいか言葉に詰まる。議論は黙した方が負け、というルールに従って引き下がらざるをえなくなる。しばらくたって、その「反論」は何の根拠もないことに気づくが、議論はもうあさっての方向へ行っている。 仕事の場に
お世話になったPerl本のまとめ - Unknown::Programming
僕が今までPerlの勉強、及び学習のために利用したPerl関連の書物についてのまとめをば書いてみます。 Perlデバッグ明快技法 作者: Martin Brown,岡田長治出版社/メーカー: オーム社発売日: 2001/05メディア: 単行本 クリック: 1回この商品を含むブログ (4件) を見る まずは僕が始めて購入したPerl本。 会社に置いてあったラクダ本をざっと一通り読み終わったときになんか自分でも本が欲しいなと思ってたときに見つけた本。 バグやエラーに対する心構えやstrictとwarningsの詳細な使い方と説明、シグナルハンドラについて色々と学ぶところがあって良かった。あとはプロファイラについての説明が熱くてこれを知った当時はプロファイラ使っていろんなプログラムの負荷テストとやってみたりしたもんだ。 最後に付録として診断（エラー）メッセージもついててナイス。 そういや診断メッ
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
mir the archive
Contents 更新:2007/08/31 MySQL内部アーキテクチャとソース解析 モジュールと相関図 主要クラスと構造体 ユーティリティ関数 プリプロセッサマクロ グローバル変数 ストレージエンジンインタフェース MySQL Hacking Tips InnoDB関連のソース解析 InnoDB起動プロセス InnoDBバッファプールに関するソースコメントの和訳 InnoDB Record構造 MySQLの拡張 可変引数を持つNativeなSQL関数の実装方法 WarningとErrorの出力方法 HelloWorldネタ GNU AutotoolsでHello World! その他 サンプルコード集 当サイトと管理者について
Life is beautiful: リーダーに必要とされる感情知性（Emotional In...
MBAプログラムに参加したおかげで、大量の論文を読まされることになったのだが、頭の中を整理する意味で文章にするのは役に立つし、それがブログのちょうど良いネタになる。今日のエントリーは、Daniel Goleman という人の書いた”What Makes a Leader?” という論文の要約。 筆者は（企業などの）リーダーになるためには、ただ高い知性と専門知識を持っているだけでは不十分で、筆者がEmotional Intelligence(感情知能)と呼ぶ能力を持っていることが不可欠だという。 Emotional Intelligenceには５つの要素がある。 Self-Awareness 自分のムードや感情を常に冷静に把握しており、それが他の人に与える影響を十分に認識していること。Self-Awarenessが低い人は、自分の性格の欠点を指摘されたりするとそれを「個人攻撃」と見なして不必
アジャイルレトロスペクティブズ - 強いチームを育てる「ふりかえり」の手引き : 小野和俊のブログ
『アジャイルレトロスペクティブズ』読了。献本感謝。 GoF本がデザインパターンの教科書であり、XP本がソフトウェア開発の手法に関する教科書だとすれば、本書はチーム開発における「ふりかえり」の教科書であると言ってよいのではないだろうか。 本書では、「ふりかえり」に関するパターンが50近く紹介されているのだが、一つ一つがとても実用的かつユーモラスにまとめられている。 本書で紹介されている方法はゲーム的で、模倣可能で、隠れてしまっている改善へのヒントを引き出すものとなっている。 以下、おもしろかったものをいくつか、コメントを交えて。 ■ アジャイルレトロスペクティブなチーム まずいきなりインパクトがあるのが、アジャイルレトロスペクティブなチームの会議の例。一見何ともない普通の会議に思えるが、この箇所だけ見ても、明確なゴールと時間の設定、冒頭に全員に発言させる点など、参考になる点がいくつもある。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
治療の体験記を病名から探せる 闘病記ライブラリー
東大で学んだ卒論の書き方★論文の書き方