最初に ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います． これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです． 本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです． もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました． デブサミでの発表について id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません) @kakutani は興味なくても、あのスライドだと @yosh
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
変数の命名規則って名前がついているのですね・・・というのをさっき知ったので・・ほんといまさら聞けない感じです・・ｗ アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)（Pascal記法） キャメルケース - Wikipedia 複合語の先頭を、大文字で書き始める。 例 ： CamelCase ローワーキャメルケース (LCC)、または単にキャメルケース キャメルケース - Wikipedia 複合語の先頭を、小文字で書き始める。 例 ： camelCase アプリケーションハンガリアン（ハンガリアン記法） ハンガリアン記法 - Wikipedia アプリケーション ハンガリアンは、間違えたコードを間違えて見えるようにする記法である。 たとえば、論理座標にRelative Positionのrp、絶対座標にAbsolute Positionのapというプレフィッ
世の中には、"プログラミングができる人"と"プログラミングができない人"、この2パターンの人間がいることは紛れもない事実です。 2ヶ月前に「素人だけどプログラミングとかやってみたい。」というプロジェクトを発足させてしまったことは自分の中でも青天の霹靂であり、それはいつもの「プログラミングとかやってみたいんだけど、一緒にどう？」とかいう"適当な発言"に、思いのほか賛同者が食いついてきたために引くに引けない状態になってしまったことが事の発端でした。 まさか自分が、"プログラミング"をやることになるとは思ってもいなかったものの、いざプロジェクトでやると決めた以上はキチンと成果を出したいものです。しかし、いまこうしてパソコンの前でブログを書いているということは、とどのつまりがいまプログラミングはしていないということになります。 プログラミング学習からの現実逃避。世の中にはたくさんの楽しいことが溢れ
最近、会社でソースのコメントがらみで苦労して、ふと思った。 適切なコメントの書き方についての実践的な入門資料はないものか？ 『CODE COMPLETE 第2版 下 完全なプログラミングを目指して』の第33章や『Code Craft ~エクセレントなコードを書くための実践的技法~』の第5章では良いコメントについて結構なページ数を割いて詳しく論じているし、そこまで詳細でなくてよいのなら『プログラミング作法』の第1章で良いコメントの書き方の基本方針的なものが提示されている。参考になりそうな本はあるのだ。 ただ、ネット上でそれなりにまとまった資料となると、探し方が悪かったからかうまい具合に見つからなかった。本だと買って読んでくれる人が中々いないので*1、ネットで読めるものが欲しいのだ。 そこで、車輪の再発明であることを承知の上で、試しに自分で書いてみた。 対象読者は……そこまで考えていなかった。
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by Manuel_Marin なんとなく書いたら、アクセス数が10000件超えたソースコードをきれいに書くための方法の記事。r-westさんの「きれいなソースコードを書くために必要な、たったひとつの単純な事」と、uwiさんの「誰がためのきれいさ？」と、フォローのトラックバックまで頂きました。僕のも含めてそれぞれスタンスが違いますが、どれが正しいとか、どれが一番いいかというのはないと思っています。人によってどっちがいいかは別れるはずです。人によっていちばん苦労がなくて、モチベーションがあがる方法がそれぞれの人にとっての正解である、というのが僕の考えです。 モチベーションマネージメントというのがよく言われるけど、「モチベーションを上げろ」と言われて上がる人なんていませ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
