)
コードの品質を保つためのガイドライン
ここでは、コードの品質を保つための、さまざまなガイドラインを紹介します。 必須 一定品質を満たしたコードしかチェックインできないようにする。 後続の製品サイクルで問題が生じるような低品質のコードはチェックインできないようにします。 過度に複雑な問題、漠然とした問題、製品サイクルの終わり近くに発覚したような問題には、通常は対処できないことを理解しておく必要があります。 チェックリストを使用する。 自分が犯しやすい種類のミスは追跡してチェックリストを作成し、今後、コードを作成する際に役立てるようにします。 まず、所属するグループまたは部門で見られる一般的なエラーのチェックリストを作成し、それを基に自分用のチェックリストとしてカスタマイズします。 コード レビューを実施する。 コード レビューを実施することにより、自分が作成したコードを客観的に理解し、そのコードを第三者にチェックしてもらうことが
ユーザ受け入れテストでレガシーコードと戦っていく
レガシーコードとは、レガシーコード改善ガイドを参考にすると、テストのないコードを指しています。コードだけでなくレガシーなシステムも存在し、レガシーじゃないシステムよりレガシーシステムのほうが多いので、新しい要求への対応と、レガシーコードの改善をうまくやっていくスキルが求められるのではないかと思います。今日は、うまく戦っていく手段について考えてみました。 レガシーシステムでの問題 自動化されたテストのない現場にいたときに、以下の問題に直面しました。 レグレッションテストに時間がかかる 何をもって「ちゃんとテストした」のかがわからない 結果的に、リリース作業時間が長くなり、リリースにかけるコストが大きく膨れたり、テストを網羅しきれず、トラブルが継続的に発生してしまうというダメージを受けてしまいます。 1については、新しく追加した機能のテストはできても、追加した影響範囲まで特定できず、別の所で問
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
品質は作り込むもの - rabbit2goのブログ
ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善
プログラマーは自分のコードを疑え - 南極の図書館
若い頃にはよく陥る過ちだと思う。 最近やってしまったので自戒エントリ。 1.テストでバグ発見。 2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。 3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。 4.読み辛いながらも、そのメソッドのバグを探す。 5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。） 6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論） この歳になってこれはないよ。。。 でも「今更やってしまった」と実感できたのは良かった。 今後、バグを見つけたら、自分のコードを徹底的に疑う。 以下余談。 テストのコストが高いのがネックだと感じる。 数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを
技術的負債: 柴田 芳樹 (Yoshiki Shibata)
リーンソフトウェア開発と組織改革 作者: Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳出版社/メーカー: アスキー・メディアワークス発売日: 2010/10/09メディア: 単行本（ソフトカバー） 技術的負債 成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・ 誰が引き継いでも意図が明確に伝わるコードを書こうとせずに、不明瞭なコードがあっても受け入れてしまう。開発者は、特に経験の浅い開発者は、「クリーンなコード」の書き方を訓練されるべきだ。クリーンなコードとは、わかりやすいロジックに基づく、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
