メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
MOONGIFT: » VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア「Review Board」:オープンソースを毎日紹介
※ 画像は一部公式サイトデモより Web2.0（？）の特徴はCGMや共有と言ったキーワードだ。サイト側から与えられるコンテンツではなく、ユーザが皆で協力してコンテンツを作り上げていく楽しさがある。ブックマーク、ニュース、コミュニティ…様々な要素がシェアされている。 そうした中、これもまた新しい共有の要素になるだろう。それはソースコードだ。 今回紹介するオープンソース・ソフトウェアはReview Board、ソースコードレビュー共有サービスだ。 Review Boardはリポジトリを登録し、そのDiffファイルを使ってReview Board上でソースをグラフィカルに表示する。そして差分に対して皆でコメントしていくのだ。ソースの一部分に対して的確にレビューできるので、分かりやすい。 SubversionやCVS、Perforce、Git、Mercurialのリポジトリに対応している。興味深い
横着プログラミング
このページでは Unix Magazine 誌に 2002年1月号から 2003年2月号にかけて連載し ていた記事の元の原稿を公開しています。 目次 第1回: Unixのメモ技術 (2002年 1月号) 第2回: Migemo: 日本語のインクリメンタル検索 (2002年 2月号) 第3回: 履歴マニア (2002年 3月号) 第4回: ttyrec: 端末を録画再生するツール (2002年 4月号) 第5回: QuickML: 超お手軽なメーリングリスト (2002年 5月号) 第6回: chatty: 小うるさい端末 (2002年 7月号) 第7回: zphoto: ズーミングするオンラインアルバムを作るツール (2002年 8月号) 第8回: pdumpfs: 毎日のスナップショットを保存する (2002年 9月号) 第9回: Sary: Suffix Array のライブラリとツー
バグ見つけた→それってどんなテスト？もしくは、なんでＭＶＣなんて使うの？ - D-6 [相変わらず根無し]
バグ見つけた→それってどんなテスト？もしくは、なんでＭＶＣなんて使うの？ 最近ソフトウェアエンジニアリングに置ける開発手法に関して考えている。 ぶっちゃけ言ってしまうと「やっぱりTDDっぽいのがいいな」というところに落ち着きつつあるのだが、厳密にTDDをしたほうがよい、と思ってるわけではない。TDDとかExtremeプログラミング、Agileプログラミングにしても理想はいいんだけど、原理主義っぽい使い方は現実にそぐわないと思ってるからだ。 前置きはこれくらいにしておいて・・・重要だと思うのは以下の点： 開発サイクルに自動テストツールを組み込むエンジニアによるバグ／不具合発見時には「動かない」は許可しない。必ず再現コードを提出してもらうテストを自動テストツールを組み込む（＝次回リリース前にはかならずテストを実行できる状態にする）テストが通るまで修正を続けるという開発サイクルを取るべきだ、とい
アップルiPhone SDK発表！ ポイントのおさらい : Gizmodo Japan（ギズモード・ジャパン）, ガジェット情報満載ブログ
アップルがiPhoneソフト開発に使ってるのと全く同じAPIとツールが入ったソフトウェア開発キット（SDK）が、いよいよ公開になりましたね。 と言っても、このSDKで作った新しいアプリ君たちがiPod touchをお使いの日本の皆さまのお手元に届くのは6月のアップデートの時。しかもiPhoneはアップデートが無料なのにtouchの皆さまは有料で、アメリカでは｢なんで～｣の声がさっそく沸き起こってるようですが。 なんと言っても注目はエンタープライズのサポート、プッシュeメールなんかが全部できるようになったこと（Blackberryから乗り換え組も出そうな…？）、ゲーム（Spore!）、携帯ネットワークはダメですけどWiFiでならVoIPができるようになること、などですね。個人的には携帯振るだけでUNDOできたり、加速度センサの活用が｢へ～｣という感じでした。 優秀な開発者には起業のお金まで面
Apple、SDKを含む「iPhone 2.0」β版を発表
米Appleは3月6日、6月に正式版のリリースが予定されているソフトウェアアップデート「iPhone 2.0」のβ版を、一部の開発者と企業顧客向けにリリースすると発表した。iPhone 2.0のβ版は、iPhoneソフトウェア開発キット（SDK）に加え、データ同期サービスのMicrosoft Exchange ActiveSync、暗号化技術のCisco IPsec VPNなど、企業ユーザー向けサービスをサポートする機能を含んでいる。 iPhone SDKは、iPhoneおよびiPod touch向けのアプリケーションを開発するためのiPhone OS APIと各種ツールを提供する。iPhone SDKのβ版は無償でダウンロードでき（Apple IDによる開発者プログラムへの登録が必要）、Mac上で動くiPhone Simulatorで動作させることができる。 またAppleは同日、開発者
学習において『車輪の再発明』は『追体験』だ - Fight the Future
車輪の再発明とは 車輪の再発明ってのは、それがすでにあるにもかかわらず、同じものを自分で作るって感じの意味。 ソフトウェア業界においては、たとえばライブラリやフレームワークを使えば実現できるのに、同じようなものを作っちゃうってこと。 そういうライブラリやフレームワークがあるってことを知らずに作っちゃうって場合もあるし、オープンソースは使っちゃダメみたいな会社だと再発明だね。 学習においては車輪の再発明をしよう なので、車輪の再発明は無駄な作業ってことになる。 だけど、これはあくまでシステム開発の作業としてって意味を含んでる。 個人の学習を考えた場合、車輪の再発明はむしろ一番勉強になる。 たとえば、Strutsを使ったWebアプリケーションしか作ったことがない場合。 Servletまで戻ってStrutsみたいなプレゼンテーションフレームワークを作ってみるってのは、とても勉強になる。 追体験と
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？…
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？ プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。 そのため いつもつらい思いをしています。 環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。 マウスもゲーム用の高精度のものを使っています。 調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。 DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。 出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。 単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。 しかし開発速度は効率化とは無縁だとすら感じています。 仕事を減らすことが優先ではないか？と。 昔から創作活動は好
Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索
Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 ＃以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
http://shi3z.blog.so-net.ne.jp/2008-02-25
http://blog.so-net.ne.jp/shi3z/2008-02-25