誰がためにレポートを書く？ バグレポートを改善せよ － ＠IT自分戦略研究所
あなたも＠ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある！ コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 WACATEは若手中心のワークショップですが、年齢制限はありません。ベテランの人も参加できます（WACATEでは35歳以下を若手、36歳以上をベテランと定義しています）。これは、WACATEが単に若手エンジニア同士の交流にとどまらず、若手とベテランが交流することを目的としているからです。交流によってベテランは自らの知見や技術を若手に継承できますし、若手がどういう考えを持っているかに気付くこともできます。 私はWACATEの定義でいうところの若手テストエンジニアです。もともとは開発担当でしたが、3年ほど前にテストエンジニアに転向しました。WACATEを知ったきっかけは、テストの部署
「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
