![見出し画像](https://assets.st-note.com/production/uploads/images/85908910/rectangle_large_type_2_71fe8ef541197b6e3042c9e2e27a42e4.jpeg?width=1200)
[#42] Xcodeをネタに考えてみよう : 開発環境とプログラマの指向性 その1
初出: MacPower 2004年 1月号
Xcodeが発表されてから早いもので、もう半年近くになる。Pantherの発売とともに正式版1.0も登場し、以前に比べるとバグも減りずいぶん安定してきた。まだまだ未完成なところも多く突っ込みどころは満載なのだが、ここいらで話題として取り上げてみるのもいいだろう[*1]。
Mac OS Xの開発環境の前知識を簡単にまとめてみると、まずXcode の前身としてProject BuilderってのがMac OS X標準の開発環境として存在していた。これは無料で手に入る。それに対して米メトロワークス社のCodeWarriorというものがあり、こいつは有料。機能的にはシンプルだけど使い勝手はとてもきびきびしており、なおかつコンパイルの速度が圧倒的に速かったので、Mac OS9時代からの開発者に好まれて使われている。
しかし時代は流れ、最新の機能をフルに使うためにはアップル純正の開発環境のほうが適しているということは身にしみており、とはいえ、Project Builderのお硬いインターフエースと、まったりとした速度には耐えられない……。こうしたジレンマに陥っている開発者が多かった。以上、前号までのあらすじ(うそ)。
そんな状況でのXcodeの登場は、こうした問題点をアップルが把握してくれていたことの証とも言える。コンパイルも速くなったし、インターフェースも前に比べて格段によくなった。まぁ、これについては後でまた述べる。ともかく、使い勝手が格段に向上したので、それだけでも開発者の印象はずいぶんよくなったように思う。オレはこれを機会に、「よし、本格的に移行しよう」と心に決めた。というのも実は肝心のメトロワークス社のCodeWarriorのほうも、Mac OS Xに対して本腰なのかどうだかわからない感じがしてしまうのだ。いまひとつ対応が遅い / Mac OS Xの機能をフルに生かしていない(ライブラリも開発環境自体も)/ 年間の更新料も馬鹿にならないなどが主な理由だ。まぁあくまでオレの感想なのだが、ともかくそんなCodeWarriorの更新を見送って、涙を飲んでXcodeでがんばってみることにしたわけだ。
実際、我々開発者がCodeWarrior という開発環境をいかに愛していたか、それを想像してもらうのは非常に難しいと思う。まずなにより付き合いが長い。CodeWarriorはPowerPCの登場とほぼ時を同じくして姿を現し、それから10年近くにわたり我々とともに歩んで来た開発環境なのだ。また、成長を見守って来たクラスライブラリのPowerPlantに関しても、時代についていけなかった悲しみというのもある。System 7からMac OS 9にかけて、古いAPIから新しいAPIへアップルが移行していく過程の中で、その変化を受け止める役割をしたのがPowerPlantだ。この当時にPowerPlantがなければ当時のアプリケーションの半分も生まれていなかったであろう。感謝の念は尽きない。
しかし、Mac OS Xになる直前あたりでの変更に、うまくついていくことができなかったように感じる。かなり迷走した歴史もある(アップルの方向が定まらなかったから、という理由はもちろんある)。そのあたりで、どうもMac OSへの情熱が冷めてしまったのではないか、と感じてしまうのである。そうでなければ、もっと早い時期にMac OS Xに対応したクラスライブラリを提供できただろうし、開発者の期待に十分応えることができたのではないだろうか。残念なことだ。Xcodeへの移行に関して開発者の無念さというもの、多少わかってもらえるだろうか。
さて気持ちを新たに。先ほどコンパイル速度の向上といったが、実はXcodeはそれ以外の違った方向への発展の仕方を見せている。アプリケーションを開発し動かすためには、コードを書く、コンパイルする、リンクする、テストする、そしてまたコードを書く…..というビルド・サイクルの繰り返しが必要だ。開発中には、満足のいく動きをするまでこのサイクルを何度も何度も繰り返す。コンパイルというのは、実はそのうちの1つの工程でしかない。つまりほかにも速くできる場所はあるわけだ。
コードを書くのはプログラマの仕事だから仕方ないとして、コンパイルした結果をアプリケーションの形にまとめるリンクという行程が、実は意外と時間のかかるものなのだ。Xcodeはここを縮めるために、ZeroLinkという技術を導入してくれた。またさらに、テスト中にコードを修正したくなったときには、その場で修正することができる機能など、とんでもない離れ業まで用意してくれている。分散ビルドやバックグラウンドでのコンパイルなどと合わせると、ビルド・サイクルは大幅に短縮されるのである。
ビルド・サイクルの短縮というのは、開発者にとっては、ものすごくありがたいのだ。作業の効率が上がるからという単純な理由もあるのだが、それ以上に、開発中の脳みその短期記憶を消耗させないという、大事な効果がある。我々の脳みそは想像以上に小さいらしい。そのためか、テストしなければ、と思っていたことも、ビルドしている最中に忘れてしまうことがたまにある。いや、決して大げさではなくホントにあるのである。試しに、何かの作業中に3分間という微妙なインターバルを入れてみてほしい。さて、オレは何をしなくちゃいけないんだっけ、というつまらない時間が必ず流れるはずである。積み重なるともったいない時間となってしまうのだ。サイクルの短縮、これに勝る開発環境のなすべきことはないのでは、とオしみたいな開発者は思っている。
一方、世の中ちょっと違う方向に進みつつあるようである。開発者が最低限やらなければいけない、管理しなければいけないと思われていたことにメスを入れる動きが起こっているのである。これについては、次回述べてみようと思う。Xcodeとの対比が面白いと思うので。では、また来月。
バスケ(http://www.saryo.org/basuke/)
祝! Apple Store GINZA オープン!大好きな街に大好きなアップルのお店ができるというのはたいへんうれしい。というわけで、オープン初日の午後3時ごろ、行ってみたら凄まじい行列。恐れをなして帰って来ちゃいました。しかし、そこで買い物するかと言えば、ちょっと微妙。ビックカメラに行っちゃいそうだな(笑)。
[*1] 取り上げてみるのもいいだろう - 実はXcode特集と聞いたので書きました。すみません。
この記事が気に入ったらサポートをしてみませんか?