開発環境（3）: 柴田 芳樹 (Yoshiki Shibata)
継続的インテグレーション（Continuous Integration）を行うために、CIツールを使用して、ビルドからテストコードの実行まで行っている開発組織は増えてきていると思います。その場合、CIツールを動作させているサーバではビルドごとにテストコードの実行は1回行ってパスするかどうかを調べることになります。テスト対象のソフトウェアがマルチスレッドで動作するのでなければ、これで良いかもしれません。 テスト対象のソフトウェアがマルチスレッドで動作するのではあれば、1回の実行では不十分です。何千回と繰り返したり、システムに様々な負荷をかけて実行したりということが必要になってきます。そうなると、サーバだけでなく、各開発者の環境でも動作させて、夜間にテストを実行し続けることが必要になってきます。 しかし、ここで注意しなければならないのは、CIサーバーがマルチコアで動作しているのに、開発者にはシ
技術的負債（2）: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェア開発においては、週に1回だけの進捗確認を行っている組織も多いのではないかと思います。そして、その内容といえば、スケジュール通りか遅れているのかだけを報告させて、技術的にきちんとレビューされたのか、妥当な人を入れてレビューしたのかを一切聞かない、あるいは、関心がないような報告会があると思います。 品質の作り込みよりも、一度立てたスケジュールを守っているような報告を行うことが優先されて、結果としてスケジュール通りに開発が進んでいるように見えたりします。しかし、結合テストやシステム全体のテストにおいて、障害が多発して、その対応に追われてしまうことになります。 障害対策は、障害の原因が分かって修正および確認が行われるまでは、「終了」という報告ができません。つまり、このフェーズになるとごまかしがきかなくなってしまいます。そして、最後は、製品開発スケジュールを守ることができなくなってしまい
「テスト駆動開発入門」コース: 柴田 芳樹 (Yoshiki Shibata)
昨日、「テスト駆動開発入門」コース（社内教育）の今年最後の教育を行いました。少しずつですが、その必要性が認識され始め、実践されて始めてきました。しかし、ソフトウェア開発は、複雑な活動であり、様々な面があり、きちんと定着して実践されるようになるまでは何年も要するでしょう。 テスト駆動開発に関連したブログとして、以下の内容を過去書いています。 The Boy Scout Rule 書籍『Agile Testing』 テスト駆動開発とClean Code リファクタリングしてますか？ The pillars of good tests テスト駆動開発の先駆者はDijkstra! 技術はできて当たり前の管理職 技術はできて当たり前の管理職（２） コードを読むこと 防御的プログラミングとテスト駆動開発 夜間ビルドとテスト駆動開発 リファクタリングと作業 Javaプログラミング道場 夜間ビルドとテスト
学ぶのに遅すぎることはない（２）: 柴田 芳樹 (Yoshiki Shibata)
「学ぶのに遅すぎることはない」では、Kathy SierraのTwitterからメッセージを紹介しています。その最後では、100歳の女性が「60歳の時にバイオリンを始めていれば、40年間はバイオリンを弾き続けてきたことになったのに」とインタビューを受けた時に述べたことを紹介しています。 ソフトウェアエンジニアとして、若い頃は勉強していたが、30代、40代となって学ぶのを止めてしまっても、再び再開すれば、長い人生の中、あるいは少なくとも会社人生の中で、10年以上は学習を続けることになると思います。 今更新しいことを勉強するのはという人は、自分が経験していて良く知っているけど、若手が知らないことを一緒に勉強するような技術書の読書会を開催してください。適切な技術書を選んで、業務時間外にその本の読書会を開催することを案内して、若手の参加者を集めて開催するのです。 週に1回で60分や90分であっても
書籍『知識労働とソフトウェア開発』: 柴田 芳樹 (Yoshiki Shibata)
荒井玲子さんの新刊も出るようです。SE新書の2冊を1冊にまとめて、加筆・修正が行われているようです。 技術評論社の紹介ページ http://gihyo.jp/book/2010/978-4-7741-4386-6 著者プロフィールを見ると分かりますが、彼女も富士ゼロックス情報システム（株）に在籍していました。富士ゼロックス情報システムは、1990年代にはオブジェクト指向では代表的な会社の1つでした。ちなみに、私は、1998年に入社したので、その当時には著名な人はほとんどいなくなっていました。その状況で同じグループだったのは、荒井さんや、XMLの村田真さんでした。
ソフトウェア技術者のレベル: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェア技術者のレベルを客観的に測定するのは簡単ではありません。知識や経験を問う試験を行って、その結果で判断することは、ある程度は可能ですが、そこには本質的な限界があります。 知識を問う場合には、最低限知ってほしい知識を問うのであれば、残念ながらそれらの基礎教育をきちんと先に行っておく必要があります。しかし、最低限の知識を問う試験を行って、それで良い成績を上げたとしても、レベルの高いエンジニアとは言えません。なぜなら、知っていて当たり前だからです。逆に、成績が悪いとなるとやはり、最低限の基礎教育を行う必要があるということになります（「基礎教育」）。 一方で、開発業務を遂行するための最低限の勉強しかしない人がいたりもします（「業務を通した学習の落とし穴」）。あるいは、その最低限も勉強していなったりする場合もあります。そのような継続した学習をしない技術者に対して、最低限の知識を問う試験を行
リファクタリングと作業: 柴田 芳樹 (Yoshiki Shibata)
テスト駆動開発はテストがパスするように実装して、テストがパスすればリファクタリングを行います。つまり、「Red Green Refactor」がマントラ（mantra）です。 書籍『Refactoring』が出版された当時（1999年）は、まだEclipseはまだ登場していなくて、リファクタリングを行うとうのは、「クリエイティブな活動」と「作業」の組み合わせでした。 どのようなリファクタリングを行うかを考えるのがクリエイティブな活動であり、人が行えるものです。たとえば、簡単なメソッド名の変更において、変更後の名前を考えるのがクリエイティブな活動です。その活動は、コンピュータは行ってくれません。そして、新たな名前に変更するというのが作業です。 Eclipseが登場する以前は、この作業を手作業で行わないとリファクタリングは終わりませんでした。しかし、幸いにこのような作業は、今日ではEclips
防御的プログラミングとカバレッジ: 柴田 芳樹 (Yoshiki Shibata)
防御的プログラミングでは、外部からの呼び出しから防御します。しかし、それ以外に、自分自身の誤りに対して防御するということがあります。 次のコードは、『Effective Java 第2版』（p.147）に掲載されているコードです。// 値によって切り替えるenum 型- 問題が多い public enum Operation { PLUS, MINUS, TIMES, DIVIDE; // 定数で表される算術操作を行う double apply(double x, double y) { switch(this) { case PLUS: return x + y; case MINUS: return x - y; case TIMES: return x * y; case DIVIDE: return x / y; } throw new AssertionError("Unknow
防御的プログラミングしない後ろ向きの理由（２）: 柴田 芳樹 (Yoshiki Shibata)
拙著『プログラマー現役続行』では、防御的プログラミングについて、次のように述べています。 防御的プログラミングを行っているか コードの読みやすさは、名前付けに最も左右されます。一方、効率よくデバッグするためには、防御的プログラミング（defensive programming）も重要です。 関数、コンストラクタ、メソッドなどに渡されたパラメータが正しい値になっているかを調べ、正しくなければassertする必要があります（Ｊａｖａ言語の場合には、assertではなく、この場合はIllegalArgumentExceptionをスローします）。 コードレビューでは、必要なassertが書かれているかを調べる必要があります。また、処理の前と後で、事前条件や事後条件が成り立っているかを検査したりする必要があります。 防御的プログラミングを全く行っていない開発は、「バグの原因を発見しにくい実装を行っ
リファクタリングの第一歩: 柴田 芳樹 (Yoshiki Shibata)
一年前に書いたブログ（「リファクタリングしてますか？」）では、「リファクタリングの第一歩」として、Martin Fowlerの『リファクタリング』から次のことを紹介しています。 リファクタリングを開始するとき、最初にすることは常に同じです。対象となるコードについてきちんとしたテスト群を作りあげることです。リファクタリングは非常に順序だっていて、新たなバグを生み出しにくくなっていますが、人間が作業する以上、間違いを犯す可能性があります。このためテストは大切で、きちっとした一連のテストを用意するべきなのです。しかし、残念ながら（自動実行可能な）テストコードを書くことなく、「コードを書き直す行為」を指して言葉「リファクタリング」が広く使用されているのではないでしょうか。
保守できないコードは「がらくた」（２）: 柴田 芳樹 (Yoshiki Shibata)
以前書いたブログ（保守できないコードは「がらくた」）で紹介した「ソフトウェアエンジニアの責任」の話しは、10年近く、教育や講演を通して話してきたことです。 さらに、昨年後半から次の2点を追加しています。 ソフトウェアは機能が実現すれば資産になるとは限らない。保守できないコードは、負債となる 初心者だからと言って、汚いコードを書くことが許される訳ではない ソフトウェア開発組織として、「初心者が書いたコードだから、名前付けがいい加減で、作りもいい加減なのは仕方ない」という言い訳が許されることはありません。もちろん、初心者は、どのようなコードが良いか悪いかを自分で判断することは難しいです。そのため、ソフトウェア開発組織としては、きちんとしたレビューを行って名前付けを含む様々な指導を通して、初心者の経験不足に起因する負債作りを防止する努力を行う必要があります。 社員だからとか派遣だからとかも、全く
コードを読むこと: 柴田 芳樹 (Yoshiki Shibata)
Programmers at Work（『実録!天才プログラマー』）の中で、Bill Gates は、「プログラ ミング能力を確認する最高のテストの1 つは、約30 ページのコードをプログラマに渡して、どれだけ素早く彼がコードを読んで理解できるかを見ることです」と述べています。彼は重要なことを認識していました。コードから直接知識を素早く吸収できる人は、すぐに非常に優れたプログラマになります。なぜならば、今までに生まれてきたすべてのプログラマが書いたコードの1 行1 行すべてが、先生だからです。 外に公開されない会社内のソースコードを読む場合には、私自身の長年の経験からすると、学ぶというよりも、読んでいて嫌になることが多いのではないでしょうか。私自身も社会人になった頃は、今日の私が見たら嫌になるコードをたくさん書いていたと思います。その悪い癖を、自力で直すのに、ずいぶんと遠回りしてきました。
保守できないコードは「がらくた」: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェアエンジニアの責任に関して、『Taligent's Guide to Designing Programs: Well-Mannered Object-Oriented Design in C++』には次のように書かれています。 ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すことです。ソフトウェアエンジニアが、他人の書いたコードを理解することができない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおかしくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。コードを読みやすく保守性を高めることは、コードを正しく動作させることと同じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作するように修正することができます。保守できないコードは、がらくたに過ぎません。資産としてのソフトウェアを開発することが重要ですが、
有隣堂ヨドバシAKIBA店：「世界に放つAKIBAエンジニア育成計画」フェア: 柴田 芳樹 (Yoshiki Shibata)
昨年と同様に、有隣堂ヨドバシAKIBA店で、「世界に放つAKIBAエンジニア育成計画」と題したフェアが開催されています。5月中旬ぐらいまで開催されるようです。私も、メッセージと（昨年と同じ）写真を寄せています。 （「コンピュータ書籍 人気作家フェア」）
Golden Lock（錠前）: 柴田 芳樹 (Yoshiki Shibata)
プログラマによっては、気付かないうちにモチベーションの罠に捕らえられてしまいます。書籍More Secrets of Consulting（Dorset House）（『コンサルタントの道具箱』、日経BP）の中で、Jerry Weinberg は、この現象を黄金の錠前（Golden Lock）、すなわち、「私は何か新しいことを学びたいが、私がすでに学んだことが十二分に利益を生み出している」と説明しています。黄金の錠前のリスクは、熟達への願望を必要とする長い道のり（The Long Road）とあなたのモチベーションの歩調を合わせることの重要性を強調しています。黄金の錠前が必然的に現れますので、熟達を願望するには、黄金の錠前に用心深く注意しなければなりません。職人として成長するに伴い、困難な決断に直面します。それは、長い道のり（The Long Road）を歩み続ける自由を持っているのか、あ
【社内連絡】 勉強会開催: 柴田 芳樹 (Yoshiki Shibata)
なぜか、ブログに書いていますが、社内向けの内容です。 勉強会（読書会）を開催したいと思いますので、希望者は社内のNotesの私のメールアドレスに、『勉強会参加希望』と題したメールをください。 開催日： 毎週、月曜日と水曜日の2回 朝7時40分から8時40分 開始日： 5月10日（月） 場所： 私が勤務している事業所の会議室（会議室は未定） 書籍： 『アジャイルソフトウェア開発の奥義 第2版』（各人購入してください） 申込み〆切： 4月16日（金） 定員： 10名以下（申込み順？） 進め方： 基本的に事前予習は不要です。テキストを先頭から順番に音読しながら、分からない箇所や疑問点を議論しながら進めます。 業務ではありませんので、非業務扱いです。
書籍『Webを支える技術』: 柴田 芳樹 (Yoshiki Shibata)
昨日帰宅したら、献本ということで、出版社から送られてきていました。内容はまだ見ていませんが、読み終えたら、内容を紹介したいと思います。
Podcastによる英語のリスニング: 柴田 芳樹 (Yoshiki Shibata)
私が大学生になった頃（1978年）と比べると、今日ではネイティブの英語に接するのが非常に簡単になりました。PodcastでCNNのニュースをiTunesに取り込んで、簡単にiPodに転送できます。 ネイティブの英語のスピードに耳を慣らして、リスニング力を伸ばすためには、ニュース番組がお勧めです。ニュース番組は、情報を伝えることが目的ですので、あまり難しいい言い回しはしませんし、日本語で同じ内容のニュースを見たり聞いたりしていますので、何について話をしているのか、だいたい見当がつく場合も多いからです。 ニュースが良いと言っても、アンカーマンやアンカーウーマンの話し方には癖があったりしますので、色々なニュース番組を聴いてみて、最初は自分に合いそうな1つに絞って、毎日聞き続けるのが良いかと思います。 iPodは、nanoを使用しているのですが、通勤中は映像を見ることはなく、音声だけ聞いています。
書籍『The Design of Design: Essays from a Computer Scientist』: 柴田 芳樹 (Yoshiki Shibata)
The Design of Design: Essays from a Computer Scientist 作者: Frederick P. Brooks出版社/メーカー: Addison-Wesley Professional発売日: 2010/04/01メディア: ペーパーバック ソフトウェアエンジニアが読むべき古典である『人月の神話』の著者Frederick P. Brooks氏の新刊です。Brooks氏は来月で79歳です。私も何歳まで活動できるでしょうか・・・・
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
勉強会を開始しました: 柴田 芳樹 (Yoshiki Shibata)