ソフトウェア開発の現場でよく聞く言葉の一つに、今の問題を一旦棚上げして、最初からやり直そうというものがある。ややこしいソースコードや問題を相手にしていると、その解決方法の一つとしてやり直しを考えるらしい。例えば、こんなものだ。 度重なる修正…

昨日は某所で行われた形式仕様記述言語VDM++の基礎を学ぶセミナーに参加してきた。講師は「VDM++によるオブジェクト指向システムの高品質設計と検証」の翻訳者としても著名な酒匂寛氏。VDM++の書籍に目を通して、そのサンプルを動かす程度の経験しか無かった…

昨日はJava Cloud Meeting(2010 in Kansai)に参加してきた。Javaをメインにクラウドを取り上げるイベントだったので、Google App Engine(GAE)だけではなくAmazon Web Services(AWS)に関する話題も多く、質疑応答も活発で熱気にあふれたイベントとなった。一…

2年ほど前にGoogle Developer Day 2008に参加して以来、Google App Engine (GAE)に興味を持ちアプリケーションを作っていろいろ試している。その時のGAEは開発言語としてPythonしかサポートしていなかったので、GAEと同時にPythonを学ぶところから始めたのだ…

Tracを使い始めたきっかけは、情報共有用のWiki(PukiWki)、障害管理（影舞）、ソースコードビューワ(ViewVC)というツール類を一つに統合出来ると分かったからだ。元々、リポジトリ内のソースコードや障害情報をウェブブラウザ経由で参照していたのだけど、そ…

Tracのマイルストーンは、開発しているソフトウェアのリリースバージョンに合わせて設定している。もちろんメインの開発（svnのtrunk）だけではなく既存バージョンのマイナーリリース版（svnのbranch）も同時に作業をしており、それぞれ個々のマイルストーン…

島敏博氏のブログにプロダクトラインに関する話題が載っていた。いくつもの類似ソフトウェアを継続的に同時開発していく場合、その共通部と可変部に注目して可変部分を分離し、共通部分の比率を徐々に高めていくことで、高い品質と生産性を目指すというもの…

ソフトウェア開発のプロジェクト開始時には「キックオフ」、完了時には「ふり返り」などと称して、プロジェクトとしてのけじめを付けたりすることが有る。開発契約などの実務上の作業は別として、プロジェクトの現場としては一区切りを付ける意味で必要だし…

柴田芳樹氏のブログに「考えないエンジニア」というエントリが載っていた。言われるままに矛盾を含んだソフトを平気に作ってしまうとか、問題を予見することなく実際に作った後でようやく問題を考え始めるとか問題が多いエンジニアが多いことは事実だと思う…

ソフトウェア開発の現場に関わっていて惜しいと感じるのは、開発者自身が自分の守備範囲を自ら決めてしまい、そこからなかなか脱却出来ないことだ。例えば、こんな類の発言を聞いたことがある。 開発は組み込みが対象なので、クラウドサーバを触った経験は有…

昨日はAgile Tour Osaka 2010に参加してアジャイルを勉強してきた。一言でアジャイルと言っても、言葉を使う人によって、スタンスや方法論が微妙に異なっていたりするが、その幅広い考え方を柔軟に受け止めるのがアジャイルの特徴かも知れない。会場にはその…

TracやRedmineを障害管理に使うことに慣れてくると、会議のアクションアイテムや各自の作業項目をチケットに入れて管理するようになってくる。いわゆるチケット駆動開発により、作業の見える化、効率化を進め、管理負荷の軽減を図るわけだ。何でもチケットに…

昔から疑問に思っているのだけど、ファイルやストリームでのclose処理ではどんな条件の時に例外（エラー）が発生するのだろうか？例えば、open処理ならファイルが存在しないと直ぐに例外が発生するし、write処理はディスク容量が無いとか書き込み権限がない…

ソフトウェアの品質を改善するのに必要な姿勢は「そもそもバグを作り込まない」ことである。問題を生じさせなければ、テストでがむしゃらに頑張る必要は無いし、開発者はもちろんマネージャもテスターも誰も困らない。テストで分かるのは問題点のマイナスの…

ソースコードレビューを行ってもどかしく感じるのは「ソースコードの書き方に正解が無い」ということだ。同じ仕様書をベースにコードを書き上げても、開発者によってその構成や実装方法は様々だし、何が正解かという絶対的な指標は存在しない。デザインパタ…

昨日はIBM Innovate 2010に参加してきた。主催がIBMだし（表向きは）有料なので、会場のスーツ率、参加者の平均年齢は高めで、カジュアルなGoogleのイベント等とは大違いの雰囲気だった。プログラムを見れば分かるようにセッション自体は他のソフトウェア開…

画面仕様書やソースコードを見ていると、時々否定文（に相当するもの）に出会うことがある。 □オプション設定を有効にしない。 is_not_success = false;好みの問題とは思うけれど、個人的には少々分かりにくい記載だと思う。否定文の否定なんて結果としては…

日経ものづくり2010年8月号に、プリウスのブレーキ制御の問題を取り上げた「ソフトが揺さぶる製品安全」という記事が載っていた。プリウスの問題については既に様々な媒体で取り上げられているけれど、原因を簡単に言ってしまえば仕様と検証の漏れという点だ…

チームでソフトウェア開発を進めていると、他の開発者が書いたコードを自分が呼び出したり、逆に自分の書いたコードが他の開発者のコードから呼び出されることがある。その境界はクラスやライブラリだったりする訳だが、何らかのデータのやり取りが発生する…

ソフトウェア開発の現場では、学校では決して教えてくれない「作業手順の基本」なるものが少なくない。業界や開発対象にもよるので一概には言えないけれど、仕様書作成の過程において下記のルールに該当するケースが多いのではないだろうか。 仕様書の記述を…

OSの仕組みを解説した本はいろいろあるけれど、専門書になるとやたらと分厚いものが珍しくない。確かに巨大なOSの中を詳しく解説したら分量が増してしまうのは仕方ないとはいえ、そこまで詳しくなくても良いので、もう少し手軽に、しかし専門家が書いたしっ…

以前にTracのプラグインと連携させて動かしたPlantUMLを、今回はDoxygenから使ってみた。下記のサイトに概要が載っているので分かると思うけど、目標は「ソースコードのコメントに書いた記述に従ってPlantUMLにUML図面を生成させ、これをDoxygenが出力するHT…

.NET/C#の参考書はたくさん出ているけれど、APIの使い方のようなリファレンスでなく、そのようなAPIの何に注意してどのように開発すべきかを示したのが「C# .NETアプリケーション開発徹底攻略」だ。「APIを使い過ぎない工夫が必要だ」でも書いたように、API…

Javaや.NETを始めとするフレームワークやライブラリは、非常にたくさんのAPIを持つものが多い。たぶん、それなりの必然性があったり、バージョンアップを重ねる毎に、より使いやすい形に機能強化されてきた結果だと思うのだけど、JavaDocやMSDNのAPI資料には…

昨日はS-openミニセッション「ソフトウェアレビューの価値を再考する〜なぜ形骸化するのか？」に参加してきた。講師は奈良先端科学技術大学院大学の森崎先生。ソフトウェア開発の現場でレビューに困る人は多いらしく（私もその1人だ）、会場には50人近い人た…

テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがある…

新人にソフトウェア開発の作業手順を教えていると、思いも寄らぬ質問を受けて戸惑うことが有る。例えば、先日はこんな質問を受けた。 「仕様書はどの程度まで書けばよいのですか？」 あまりにストレートな質問なので何と答えるべきか一瞬戸惑ってしまったが…

終戦の日と言うことで第2次世界大戦に関連した記録映画を見ていたら、インパール作戦が出てきた。歴史の教科書で名前を聞いた程度しか記憶に残っていなかったのだけど、番組の中で紹介された旧日本軍の無茶苦茶な作戦や戦い方にすっかり驚いてしまった。軍隊…

優れた仕事をする技術者は、一体何を考えて作業をしているのかずっと興味がある。どのような自己研鑽を行い、どんな事に注意を払ってコードを書き上げ、どの視点から技術を評価しているのだろうか？もちろんIT業界にはその類の偉人が既に存在しているし、本…

派生開発をメインに行っていると必要になるのが、既存コードの解析作業だ。ソースコードがどのように開発されてどんな構成になっているのか、資料が有ればそれを手がかりにコードを読み砕くことが出来るのだが、多くの場合、コードの追加・拡張の連続なので…