コミットについて語ってみる - wyukawa's diary
途中から難しくなってきてとばし読み気味になったが実用Gitはすばらしい本だ。 入門Gitもすばらしかったがそれにも劣らない（この２冊ほどでは無いかもしれないが入門gitもいい本だ）。 読んでいて感じたのはGitは歴史を書き換えてでもいいコミットを作ることに関心を持っているように思う。 間違えたコミットコメントを修正したいと思うことは誰でもありそうだが、それだけではなくコミットをまとめたり、順番を変えたりすることもGitではできる。さながら歴史をリアルタイムで作り替えているようだ。 そうやって作られたある意味では完璧なコミット履歴を見てみたい気もする。 コミットについて語る場合２つのパースペクティブがある。１つは粒度でもう１つはコメントだ。 コミットの粒度は論理的にまとまった単位であるべきだ。例えば１つのバグ修正で３ファイルいじったなら１コミットであるべきでファイル毎に３回コミットされたら後
コードのクリーンアップ - 技術的負債の返済に役立つ 9 つの戦術
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 技術的負債の返済に役立つ 9 つの戦術 David Laribee MSDN Magazine の 2009 年 12 月号では、技術的負債に取り組むために、問題を特定して主張を展開するためのアドバイスを書きました。簡単に言えば、近い将来に問題になりそうな負債を特定することが重要だと信じています。コードベースのほとんど触れられない部分で、価値ある技術を確立しても、明日の生産性向上の実現には役立ちません。 また、負債返済の重要性について経営陣からお墨付きを得ることの重要性を理解し、同じ理由から手堅い主張を展開するための基本ツールを用意してください。 では、利息の高い技術的負債を返済するうえで役立つ可能性がある戦
コードのクリーンアップ: アジャイルな手法を使用して技術的負債を返済する
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 アジャイルな手法を使用して技術的負債を返済する David Laribee すべてのコードベースには、暗くて恐ろしい隠れた場所や小道があります。非常に脆弱なコード、回帰バグが発生するコード、および処理をたどろうとするとイライラしてしまうようなコードのことです。 Ward Cunningham は、コードの、変更が困難でエラーが発生しやすい部分を金銭的負債ににたとえて、みごとな隠喩を作りました。技術的負債があると、前に進んだり、利益を得たり、"黒字" の状態を維持したりすることができなくなります。現実世界と同様に、安い負債もあります。低リスクの金融商品よりも利率の低い負債です。また、負債をさらに増やしていく高利
劣化するソフトウエア
1960 年生まれ，独身フリー・プログラマの生態とは？ 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，順次公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており，現在では異なる場合があります。 私たちが顧客に納めるソフトウエアなどの成果物に対しては，瑕疵担保責任というものが課せられている。そのため，あらかじめ合意した期間内に不具合などが見られた場合には無償で対応しなくてはならない。 一般的には，検出されるソフトウエアの不具合というものは時間が経つにつれて少なくなっていくはずであり，それによるリスクも減ってい
テスト駆動開発とレガシーコードのトラブル
原文(投稿日：2009/11/19)へのリンク Alan Beljeu 氏は古い (レガシー) C++ コードベースで TDD を行っていて，トラブルに見舞われた。その理由はこうだ。 機能を完全に実装できていないクラスが最後に残ります。いつか必要になるかも知れない，というやつです。他のクラスからそれを利用しようとして，実装を完成させる時がきた，まさにその時になって当初の設計不足が明らかになるのです。設計は新たにやり直し，外部仕様(とそのテスト)も修正が必要。そのクラスを使っていた既存コードも変更しなければなりません。 そして彼は，"事前の大規模設計 (Big Design Up Front)" がこの問題の解決策ではないか，と考えるのだが，アジャイルコーチである George Dinwiddie 氏は，Alan のこの例が訴えているものを指摘する。すなわち，きれいなコード (clean c
ソフトウエア開発に役立つマインドマップ
ソフトウエア開発は，コーディングやテストばかりではありません。顧客との打ち合わせやエンドユーザーとの会話，さらには開発者同士のミーティング，ブレインストーミング，仕様の構想といった「アイデア」と「コミュニケーション」に本質がある活動がたくさん含まれています。マインドマップは，このような柔らかな人間活動をビジュアルにうったえることでサポートする発想法であり図解法です。この連載記事では，話題の書籍『ソフトウエア開発に役立つマインドマップ』（右図）から，すぐに使えるマインドマップの利用法を抜粋してお伝えします。 目次 ・第1回 マインドマップって何？ --- 注目技術の理由と特徴 ・第2回 議事録と会議ナビ --- チームの合意をすばやく作れ！ ・第3回 ブレインストーミング --- 広がるアイディアをつかまえろ！ ・第4回 ロジカルシンキング --- 概念を分類・整理しよう！ ・第5回 まとめ
ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
IEEE Transaction on Software Engineeringの論文Raymond P.L. Buse and Westley R. Weimer: Learning a Metric for Code Readabilityから。120人の被験者が10種類のオープンソースプロジェクトのソースコードの一部（20行等、非常に局所的）をもとに読みやすさに影響を与えることを実験結果から示している。 25種類のメトリクスと読みやすさとの相関を求めている。メトリクスには、コメント行数や予約語の数、空行の数、括弧の数、変数名の長さ、変数の個数などが含まれる。このうち、読みやすさに最も影響を与えやすいメトリクスとして、1位に変数の個数、2位に行数、3位に括弧の数、9位に空行数、15位にコメント行数が示されている。 この論文では、多くの人に短時間で読みやすさが評価できるように、対象ソース
やぼったい開発
ウォータフォールモデルによる開発手法の基礎(w) ...ソフトウエア開発手法の基礎をまとめてみました。 レビュー(r) ...レビューの仕方 コード作法・設計作法(c) ...コード作法 デバッグ(d) ...デバッグの仕方 JUnitとは(u) ...ソフトウエア開発手法における JUnitの使い道をまとめてみました。 eclipseメモ(e) ...eclipseのショートカットなど デバッグ技法について明確に書いてある。事例がハードウエアよりだが、文脈を読めば問題なくわかる。 ルールが9にまとめそれぞれがわかりやすく、基本的で大事な物ばかり。当たり前のルールだが意識化して行くにはとても役に立つ。デバッグ時に焦ってしまう人にお勧め
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラム・ドライバー・Windows サービスを管理「Comodo Programs Manager」NOT SUPPORTED
技術的負債は技術的な問題か？
ソフトウェアの負債には多額の費用がかかる