柴田芳樹 (Yoshiki Shibata)：SSブログ

	ブログをはじめるログイン

2010年10月｜ 2010年11月｜2010年12月ブログトップ

『Elements of Programming』翻訳作業終了　 [プログラマー現役続行]

作者: Alexander Stepanov
出版社/メーカー: Addison-Wesley Professional
発売日: 2009/06/19
メディア: ハードカバー

6月から始めた『Elements of Programming』の翻訳作業がやっと終了しました。当初4ヶ月程度で終わる予定でしたが、なかなか進まず、6ヶ月要してしまいました。

2010-11-30 06:48 nice!(1) コメント(0) トラックバック(0)

技術者のレベルとソフトウェア開発の難易度（8）　[プログラマー現役続行]

「技術者のレベルとソフトウェア開発の難易度（6）」で技術者のスキルレベルと開発ソフトウェアの難易度の表を掲載しています。

ソフトウェア開発における外部公開用APIの設計の難易度は、非常に高いです。機能を提供するだけでなく、不正な操作に対しても堅牢であり、使いやすく、誤った利用ができないように設計するのは容易ではありません。一方、機能は提供しているが、不正な操作に対して脆く、使いにくく、誤った利用が簡単にできてしまうようなAPIを初心者は作ってしまいます。

両者の成果には大きな差があり、その意味で外部公開用APIの設計の難易度は高いのです。仮に難易度を5（「技術者のレベルとソフトウェア開発の難易度（6）」を参照）とすると、スキルレベルが5以上の人でないと正しくできないはずです。

ところが現実の開発では、スキルレベルが2の人が担当してしまって、酷いAPIを設計してリリースしてしまうことがあります。そして、それが技術的負債となり、（そのソフトウェアが使用され続ける限り）企業はその負債を背負うことになります。

スキルレベルが5の人は、難易度5までであれば、何でもこなせてしまいます。たとえば、難易度としては2か3であるようなビルド環境の構築や継続的インテグレーションのためのツールの導入などもできるのです。

したがって、難易度3と5の仕事があり、スキルレベル2と5の人がそれぞれ居れば、仕事の割り当ては必然的に決まってしまいます。スキルレベル2の人が難易度3の仕事をして、スキルレベル5の人が難易度5の仕事をする割り当てです。

しかし、現実の開発では、スキルレベル5の人は年齢も高いので、若い人の育成を理由にして、逆の割り当てをしてしまったりします。あるいは、仕事の難易度が分かっていないために逆の割り当てをするのです。運が良ければ、スキルレベル5の人が最後には難易度5の仕事も片付けてしまうかもしれません。しかし、API設計などでは、残念ながらそのようなことは起きる確率は低いでしょう。

仕事の割り当てを間違えると、上手く短期間で終わるはずの開発が、遅れたり、技術的負債を残すことになったりします。

2010-11-18 08:33 nice!(1) コメント(0) トラックバック(0)

『アプレンティスシップ・パターン』電子版　 [本]

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得

作者: Dave H. Hoover
出版社/メーカー: オライリージャパン
発売日: 2010/07/08
メディア: 単行本（ソフトカバー）

『アプレンティスシップ・パターン』の電子版がオライリー・ジャパンのサイトから購入できるようになりました。

O'Reilly Japan Ebook Store

2010-11-17 02:56 nice!(0) コメント(0) トラックバック(0)

清澄庭園　 [プログラマー現役続行]

11月12日（金）に、セイコータイムシステム株式会社で「ソフトウェアエンジニアの心得」の講演に行った際に、時間があったので最寄り駅の清澄白河駅のそばにある「清澄庭園」を見て回りました。

清澄白河駅には今まで降りたことがなかったので、清澄庭園の存在も初めて知った次第です。庭園を30分ほど見た後、セイコータイムシステム社にお伺いしました。講演は、15時から17時30分までQ＆Aも含めて行い、時計の世界のソフトウェアと今まで関わってきたデジタル複合機のソフトウェアでは規模が大きく異なるのを実感しました。また、スポーツ競技会では、計測できて当たり前なのですが、それを支えるための話も聞くことができました。

2010-11-16 08:44 nice!(0) コメント(0) トラックバック(0)

手作業から自動化　 [プログラマー現役続行]

継続的インテグレーションは、多くのソフトウェア開発組織で今日では実践されているかと思います。一方で、すべてを手作業で行い、その作業手順を文書として残すことを行っている開発組織も多いのではないでしょうか。

特に一人のエンジニアが同じ手作業をずっと担当している場合には、手順書には書かれていない手順があったり、逆に書かれている内容が間違いだったりすることもあります。つまり、同じ手順書を見て、他の人がその通り再現できるかも怪しい場合もあります。

仮に、手順書が正しくて、その通り行えば、誰が行ってもできるというものであっても、手順書通り作業を進めたかを監査する手段はありません。手順書を書いて、書かれた手順をエンジニアに強制させるのではなく、すべてを自動化する必要があります。コンピュータによる自動化では、自動化のスクリプトの内容を監査（チェック）することはできます。そして、それが正しければ、コンピュータは忠実に実行してくれるのです。

単純作業はコンピュータに行わせて、エンジニアは創造的な活動に時間を費やすべきです。コンピュータによる自動化が可能な作業を、手作業で行って仕事をした気になってはいけません。

2010-11-11 08:34 nice!(1) コメント(0) トラックバック(0)

技術的負債（３）　[技術的負債]

企業にとって、技術的負債があっても、商品を出し利益を出して、会社を維持する必要があります。しかし、技術的負債が大きい場合には、若手にとっては、良いコードを読んで学習する機会を与えるのではなく、汚いコードと格闘させるだけとになります。さらに、製品となっているコードは、手作業による膨大なテスト工数を考慮して、リファクタリングして良くする活動もできなかったりします。

見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。

2010-11-10 05:21 nice!(0) コメント(1) トラックバック(0)

技術的負債（2）　[技術的負債]

ソフトウェア開発においては、週に1回だけの進捗確認を行っている組織も多いのではないかと思います。そして、その内容といえば、スケジュール通りか遅れているのかだけを報告させて、技術的にきちんとレビューされたのか、妥当な人を入れてレビューしたのかを一切聞かない、あるいは、関心がないような報告会があると思います。

品質の作り込みよりも、一度立てたスケジュールを守っているような報告を行うことが優先されて、結果としてスケジュール通りに開発が進んでいるように見えたりします。しかし、結合テストやシステム全体のテストにおいて、障害が多発して、その対応に追われてしまうことになります。

障害対策は、障害の原因が分かって修正および確認が行われるまでは、「終了」という報告ができません。つまり、このフェーズになるとごまかしがきかなくなってしまいます。そして、最後は、製品開発スケジュールを守ることができなくなってしまいます。仮に、プロジェクトが遅れて完了したとしても、「技術的負債」を最初から埋め込んでしまっていることが多いです。

2010-11-09 05:42 nice!(0) コメント(0) トラックバック(0)

考えないエンジニア　 [プログラマー現役続行]

プログラマー”まだまだ”現役続行 (技評SE選書)

作者: 柴田芳樹
出版社/メーカー: 技術評論社
発売日: 2010/09/04
メディア: 単行本（ソフトカバー）

拙著からの抜粋です。

考えないエンジニア

　今日では、コンピュータ技術の急速な発展のおかげで、コーディングをしてからあっという間にコンパイルができ、すぐに実行可能です。プログラミング初心者の特徴として、コンパイルエラーのエラーメッセージや、実行時エラーが発生した場合のスタックトレースの表示をきちんと読まないということがあります。
　その結果、書いたコードにエラーがあると、「なぜエラーになったのか」を考えることなく、ちょっとだけソースコードを修正して、すぐにまたコンパイルと実行を行ったりする人が少なくありません。さらに、動作させてうまくいかないと、その理由をじっくりと考えることなく、またちょっとソースコードを修正して、同じサイクルを繰り返したりします。
　つまり、ソースコードやエラーメッセージをじっくりと読んで考えることなく、試行錯誤を繰り返すのです。
　このようなことを繰り返していると、自分が書いたプログラムであっても、コードを実行せずにコードの動きを頭の中でシミュレーションしながら、正しいかどうかを冷静に判断することができなくなります。そして、どのように動作するかを実行することだけで確かめようとするのです。
　このように、コンピュータ技術の急速な発展は、皮肉にも、論理的に思考あるいは推論をしないでソフトウェアを開発するエンジニアを増大させる一因となっているような気がします。

『プログラマー”まだまだ”現役続行』（57頁）

初心者でなくても、「エラーメッセージの一部を見て思い込みで判断する」ことがあります。判断した結果の対処を行ってもエラーメッセージが消えなくて、よくよくエラーメッセージの内容を確認したら、原因は違うところにあったりするのです。

（「エラーメッセージを読まない人達」）

2010-11-05 05:19 nice!(0) コメント(0) トラックバック(2)

開発環境（２）　[プログラマー現役続行]

Robert Loveがインタビューの中で、使用している開発環境について述べています。

An Interview with Robert Love

会社（Google）で使用しているメインのワークステーションが、次のように述べられています。

Dell machine with quad core Gainestown-based Xeons and 24GB of DDR3 RAM
It is connected to a 30" HP monitor outputting 2560x1600
My workstation runs Google's in-house version of Ubuntu, creatively named Goobuntu

ちなみに、会社では、経費節減ということで、開発者にさえ、私の観点からすると開発用マシンと呼べる代物は与えられていません。私が会社で使っているPCの仕様は、次の通りです。

PC with Pentium, 1GB RAM, and 38GB HD
It is connected to a 17" monitor
It runs Windows XP

一体、何年前のPCだという感じです。個人で自宅で所有している環境の方が遙かに良いというのが実情です。

Googleのように、個々のソフトウェアエンジニアのスキルが非常に高い場合には、良い環境を与えることで、開発組織としての生産性がさらに高くなると思います。しかし、個々のソフトウェアエンジニアのスキルが非常に低い開発組織では、良い環境を与えても、組織としての生産性や、より良い品質のソフトウェア開発には直接貢献しないかもしれません。

どの言語でプログラムしようとも、プログラマとしてのあなたの仕事は、使えるツールを使ってベストを尽くすことです。優秀なプログラマであれば、低レベルの言語、あるいは扱いにくいシステムであっても克服しますが、優れたプログラミング環境は、できの悪いプログラマを救済してはくれません。

― Brian Kernighan, Rob Pike, 『プログラミング作法』

優れたソフトウェアは、CASEツールや、ビジュアルプログラミングや、ラピッドプロトタイピングや、オブジェクト指向技術から生まれるものではありません。優れたソフトウェアは人が作るのです。ダメなソフトウェアも同様です。

― Larry L. Constantine, 『The Peopleware Papers』

並のプログラマが良いツールや良い言語を使っても並のシステムしか開発できないが、優れたプログラマは、粗末なツールや並の言語を使うハンディを負っても、すぐれたソフトウェアを作り出すことができる。このことは過去には正しかったが、これからもずっと正しいだろう。

― Edward Yourdon, 『ソフトウェア管理の落とし穴』

ソフトウェアは、統合開発環境などのツールによって設計されるのではなく、プログラマーの頭の中で考え出され、作り出されるものなのです。

― Andy Hunt, 『リファクタリング・ウェットウェア』