「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
steps to phantasien t(2008-05-31) - 近況
2008-05-31 近況 "Working Effectively With Legacy Code" (WEwLC) の 読書会 があるというので参加させてもらった. 13-17 時で 4 時間の長丁場なのと, 担当の人が色々準備しているのがすごいなーと思った. 本を読むんじゃくて, 担当の人が準備してきた資料や説明をもとに進行するんですね. 最初の高木さんはほとんど抄訳に近い勢いだし, その次の川西さんはスライドつき. 水準が高い. 実は最近は読書会なんてなくても必要なものは根性で読めばいいと思うようになっていたけど, これだけ準備してもらえるなら読書会の方がいいわ. 私もどこかを担当しないとなあ. パラサイトになってしまう... あと, 読書会では無理に全文を読む必要もないんだなということがわかった. 私のやっている RTR の読書回は通読が基本で, アルゴリズムなんかの厄介なとこ
発表のすすめ - m-takagiの日記
Working Effectively with Legacy Code読書会でChapter1からChapter3までのまとめを担当しました。例によって資料はhandsOut.jpに公開……できません*1。我ながら恥ずかしくなるほどのグダグダな発表だったわけですが、参加者のみなさんに助けられていい議論ができたかと思います*2。 最近私は、勉強会や読書会などに参加するときにはできるだけ「発表する側」にまわることを心がけています。単に「○○勉強会に参加しました。楽しかったです」だけで終わってしまうのが怖いからです。発表を担当すると、「自分ではその内容を何となくわかっている(つもり)。でも、それを資料にまとめようとすると筆が進まない。口頭で発表しようとすると言葉に詰まってしまう」ということがよくあります。今回もまさにそんな状態で、後半なんか自分が何を言っていたのかも思い出せないようなひどい状態
Working Effectivelry With Legacy Code（WEwLC）読書会 第1回（at 横浜某所） - ヤドカリデンキ商会（ブログ版）
t-wadaさんは結局来なかった。仕事のほうは大丈夫だったんだろうか ちなみにTDDは（※自主規制※）の略という説があるらしい 新しい技術に興味がある人というよりは本当に悩みを持ってる人が集まったという感じでとてもよかった。他の勉強会が浮ついているという意味ではないが Lingrはよかった。今度からノートパソコン持っていこう メモを本に書き込んでいくスタイルを個人的に採用してみた 懇親会で腰リールに「EDD」と書いているのを見つかってしまった ちなみにその前にメモしていたのが「レガシーハラスメント」 くだらないことしかメモしないのがt-wadaさんと同じと言われました 「ツンデレガシー」という表現が話題に 以下、内容のメモ 健康な人をさらに健康にするのではなく、いわば病人に対する手術 社内的に「成功した」と言われているシステムにテストがなかったり リファクタリングねた 単なる修正のことをリ
WEwLCの1stMeetingに参加 - maeda.na@はてな
メインの読書会 id:t-wadaさんのブログを炎上させたことで話題の「WORKING EFFECTIVELY WITH LEGCY CODE」読書会に参加してきた。 正直、英語の本ってことで敷居の高さを感じていてギリギリまで参加していいのかどうか悩んでたんだけど参加 してよかった。本そのものの内容も勿論いいんだけど、フリーディスカッションでの各参加者のリアルな悩みとかが 個人的に凄く面白かった。（ブログには書きづらい話もあったけど） lingrのログを見れば大体の流れがわかるはず。 http://www.lingr.com/room/wewlc id:t-wadaさんは結局諸事情で来れなかった…。 懇親会 mootohさんがvim使いだということがわかった。mootoh++ 東京でもvimの勉強会やりたいねーという話をした。 普段やってることが面白そうだった。 今日の裏目的の「id:to
Working Effectively with Legacy Code 読書会1回目 - ただぶろぐ
WEwLC読書会に参加してきました。 読書会って初めて。洋書も初めて。 読み合わせる感じのものを想像していたけど、白熱した議論があり、Lingrからの突っ込みもありでとても楽しかったです。 特に印象に残っているのは リファクタリングの誤用の話 やっぱりあちこちで誤用されているみたい。自分も微妙な使い方をしないよう気をつけないと。 参考1:http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism 参考2:refactoringの意味・使い方｜英辞郎 on the WEB：アルク 英辞郎すげぇ。 テストを書く動機付けの話 みんなにテストを書いてもらうにはどうすべきか。現状、あまりテストコードは書かれていないみたい。そして、動機付けも難しい。 テストコードを書くには書いたけど、いかにメンテしていくか（資産としていくか）という
2008-05-31
メモ koido Blog - koido Blog HttpUnitを利用したWeb画面テストの自動化 （1/2）：CodeZine id:t-wadaさんがこられることをずっと、prayしていた第1回勉強会。 なまなましい現場の話が話題に出てきたり、 書籍の内容を読んで、あるあるっていう話があったり、 と、現場ドリブンな、有意義な勉強会でした。 懇親会もまた深い話で盛り上がれました。 せとさん、はじめ、参加されていたみなさん、 どうもありがとうございました。 読書会の内容で、気になったことを書くとすると、 第1章のソフトが変更することになる理由について。 第1章 ソフトが変更することになる理由 機能追加 バグ修正 設計の改善 リソースの最適化 新規開発、運用・保守の切り口で考えると、 開発、保守の立場の帽子をかぶると、 現場としてすごくやりたいことは、「設計の改善」 「設計の改善」、「
WEwLC読書会 - kunit’s diary
本日はWEwLC読書会でした。 Working Effectivelry With Legacy Code読書会 普段Legacy Codeに悩まされている方々が集まって濃い読書会になりました。いろいろな分野の方がいて、そこでの困った話とかが聞けて本当に楽しかったです。 通常のセミナーとか勉強会というのは同じドメインの人が集まるのでそれはそれでとんがった話はできるんですが、今回のようにいろいろとバラエティーにとんだ層があつまるのは本当にたのしいですね。 次回はどこかの章を担当させてもらおうと思います。こういう読書会で聞くだけってのは申し訳ないし、発表したらそれはそれで自分のためになるし。 私はもうすっかりテスト厨なわけですが、UnitTestをする意味を理解してもらうための努力とか、そもそもリファクタリングの誤用が多いってのは何とかしたいところ。 まずはみんなリファクタリング読もうよ。 リ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
deadbeaf.org