InfoQ ホームページ Software_Craftsmanship に関するすべてのコンテンツ
-
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
デザインとコードレビューに関する興味深い記事でKirk Knoernschild氏は、レビューを行うということは、ソフトウェアの品質を改善することを約束し、基準の順守を保証し、そして価値ある開発者の教育ツールとなると述べている。しかしながら、レビューの実施方法にその効果は左右される。レビューは、ある組織ではソフトウェア開発工程で本当に意味のあるものであるかもしれないが、その一方で別の組織では形式的なお役所仕事の一部となってしまっているかも知れない。
-
Article: ３つのM - リーンの３要素
リーン主義をソフトウェア開発に適用することについての議論では、主にムダ（無駄：Muda）なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ（無理：Muri）とムラ（ばらつき：Mura）を削除することも目指しています。
-
拡張照会機能およびユーザ文書を備えたDbFit 1.0
近ごろGojko Adzic氏がDbFitのバージョン1.0のリリースを発表した。それは、データベースコード上でTDDを実行する際に使用されるFIT/FitNesse拡張機能である。
-
Article: XMLをユニットテストする
XMLUnitはBSDライセンスの下で認可されたオープンソースプロジェクトです。XMLUnitは相関クラ��の小さなライブラリを提供しますが、それは、前のセクションで概説された幾つかのXMLをテストする異なった方法のそれぞれを簡素化します。
-
テストと復元性をめぐる議論: オブジェクト指向 vs. 関数型プログラミング言語
Michael Feathers氏の最新の投稿をめぐり、ブログのコミュニティ上で活発な議論が行われた。Feathers氏は、オブジェクト指向プログラミング言語に組み込まれた機能を使うと、テストが容易に行うことができ、コードの復元性を簡単に高めることができると主張した。
-
Cockburn氏テスティングを語る: 本物のプログラマにはガッツ(GUTs)がある
Alistair Cockburn氏は、InfoQのビデオ記事「Coplien and Martin Debate TDD, CDD and Professionalism」に対するフォローアップ記事を自身のブログへ投稿した。その中で氏は、いかに多くの人たちがTDDを誤解しているかについて言及している。
-
プラグマティックが止まらない ――「現実駆動開発」のススメ
ソフトウェアアーキテクトであるGustavo Duarte氏が、物理学者Richard Feynman氏によるスペースシャトル・チャレンジャーの爆発事故に関する調査結果について、優れたソフトウェアの工学的側面との関連を論じたところ、そのことが物議をかもした。
-
クランチモードがスーパースターを平凡に
James Golick氏とReg Braithwaite氏は最近の一連の投稿で、チームを「クランチモード」（開発チームに追い込みをかけて高負荷状態で仕事をすること）に入れることが、実際にどれだけの *望ましくない* 結果を生じるかについて議論している。
-
機能テストの今後
ここ最近、開発主導型の機能テストの分野において活発な動きがある。Jennitta Andrea氏とWard Cunningham氏が、「機能テストツールの次世代を予想」というテーマでウェブ放送を開催した。また、Thoughtworksがこの分野において製品を発表する意向を示した。
-
議論: アジャイルプロジェクトの成功を顧客視点で測定する
最近、Scrum開発のユーザグループで、「顧客はアジャイルプロジェクトの成功をどのように測定するか」という問いに答えようとする興味深い議論があった。ここで重要なのは、「測定する」ということだ。この議論では、顧客の観点からの成功を測定することは重要であり、その実施にはさまざまな方法があるということで意見の一致が得られているようだ。最も良い測定方法は、状況と顧客によって異なるだろう。
-
オピニオン: スタイルを強制するのはプログラミング言語ではなくチームであるべき
大規模なマニュアルにはプログラミングに関する問題を解決するために従うべきシンプルなルールが必ず書かれていると信じている人たちがいる。これはウォーターフォール型の開発手法ではよくある考え方だろう。XP だと、安全な構造とクリーンなスタイルを開発者に強制するプログラミング言語を求める人がいる。Reg Braithwaite 氏はこの信念を批判している。
-
「完了」は「シップ可能」ということか？
「完了」と「シップ可能」との相違について、アジャイルに関するさまざまなフォーラムやブログで活発な討論が起こっている。両者は同じことを意味するような気がするが、リストやさまざまなブログ上での討論が提言するのは、この2つはいまなお広範囲にわたって誤解されており、誤使用されている用語であるということである。これは「完了」の取り扱い方についての提案をまとめたものである。
-
プラットフォームの知識ではなくて、多様なデザインスキルを好む
Martin Fowler氏は自身の最新の記事において、チームの構築において一番大切なのは経験でも特定のプラットフォームとビジネスドメインに関する完全なる知識ではなく、むしろ高品質なソフトウェア、また価値をもたらすことができる多様なスキルであると述べている。
-
アジャイル開発者の責任
顧客が間に合わせのソリューションを求める場合、開発者の責任は何か? 結局は顧客が支払いをするのだから、顧客の言うことを聞いて近道をすべきか? それとも、開発者は自分の考えで技術的に「最適な」選択肢であることを常に行うべきか? それとも、中間の妥協点があるだろうか?
-
開発のスピードとは本当に素晴らしい「ものさし」なのだろうか？
近い将来を予測する能力以外に開発のスピードを測定することによって、どんな価値が得られるのだろうか？J.B.Rainsberger氏は速度を追求する時間を削減し、また削除することによって最大の益がもたらされるような、チームに無駄な労力を使わせている領域が何なのか特定する事を推奨している。