「オブジェクト指向・システム開発」カテゴリーアーカイブ

もっとVersionControlを! From Martin Fowler’s Bliki in Japanese

Martin Fowler’s Bliki in Japanese – もっとVersionControlを!

私はVisioなどを使って設計図を作っている。 diffを使うと、バージョン間でどこが変わったのか、他のひとがどこに変更を加えたのかが分かる。これは素晴らしいことだと思う。だが、こういったものから本当に価値を得ようとするなら、 セマンティックdiffをサポートしたツールが必要になるかもしれない

VisioのDIFFツールは真剣にほしいかも。
テキストファイルは比較的楽に管理できるのですが、バージョン管理をしたいんだけど中々上手くできないのが、Word, Excel, Visioの類ですね。モデリング/設計文書なんかで必要なものはVSSで管理しているのですが、バイナリファイルでしか使えないので、まるっとファイル毎差し替えるしか方法がないんですよね。部分的にここだけ戻したいってこともあるので、そこを何とかしたいですよね。結局シェアポータルサーバーなんかもそこまでは面倒見てくれないですしね。
そういえばVSTSではWhitehorseとかでのモデル成果物のバージョン間でDiffってとれるんですかね。無理そうですね。

くーす本が出版されるようで

はてなダイアリー – ひがやすをの「なれるものなら押切もえ」

正月休明けに最後の章をレビューにかけられれば、ぎりぎりセーフ。3末出版の予定です。

ということで3月末の発売のもよう。もうしばらく待たないといけないですね。
後はどう.netにアレンジしていくかだなぁ。

くーす本

@江青日記の昨日分を読んで、私もくーすは書籍として出版されるべきものだろうと思いました。
マイクロソフトはソフトウェアファクトリでこの先突っ走って行くのでしょうが、いつ如何なる時、如何なる場所でもソフトウェアファクトリが正しいかといえば、それは話が別でしょう。比較的小規模なシステム開発が主で、客先の業種が固定できないような、つまりは地方にたくさんあるSIerではソフトウェファクトリが必要とされることはまずないでしょう。プロダクトラインの整備に投資する正当性がありません。それよりも、軽量で顧客のニーズにもう少し細かくこたえていく開発方法が適しているように思います。
くーすはSeasar2とJavaで開発を行うためのICONIXを元にした方法論ですが、基本的には.NETでの開発でも応用できると考えています。そういう意味でも多くの人に、特に非Javaで開発をしている方々にくーすを知ってもらうのにも書籍化は良い話だと思うのですが。

続きを読む くーす本

「SOAはシステム統合の“魔弾”ではない」–BEAコンサルタントが語るSOA導入の留意点 – CNET Japan

「SOAはシステム統合の“魔弾”ではない」–BEAコンサルタントが語るSOA導入の留意点 – CNET Japan

SOA自体が百発百中の魔弾なわけではないということだ。BEAでは、SOA実現のためのツールや製品を提供するだけでなく、専門家による知識で正しくSOAを実装するための支援を行う。顧客を成功に導くには、ツールだけ与えてもどうしようもないからだ」(アラワリ氏)

SOAでのシステム開発が難しいと思うのは、現状の開発者の視点を上空に上げていく方法が中々思いつかないからです。SOAや分散オブジェクトでシステムを開発するときには、設計するときの視点をその時々で上下に自由に動かしてもらう必要があるのですが、中々その必要性を理解してもらえません。(たぶんその人にとって楽な)低空飛行を維持して上昇して全体を見ようとしてくれません。
本人が勉強して気づいてもらうのが一番なのですが、そうもいかず、良い方法は無いか思索する日々です。疲れます。

自分の技術の棚卸し

新しい技術を学ぶときに大事なことのひとつに、自分の現在の技術の棚卸しをするということがあります。その時点での自分が持っている技術をできるだけ客観的に並べ、その並べたものと今から学ぼうとしてる技術とを比べて自分自身に何が足りないかを判断して、学ばなければならないことを見つけていくことが重要だと思います。また、この棚卸しと比較をしていくことで、新しい技術が登場したとしても、頭からすべてを学び直すことが必要なくなります。足りない部分だけ学んでいけばよいのです。あるいはすでに持っている技術に足して肉付けすれば済みます。
これはオブジェクト指向を学習していく過程でも同じで、自分が学んできたそれまでの技術、例えば構造化設計手法とオブジェクト指向との違いを確認していくことで、ある程度差分的に知識を増やしていくことができると思います。
ソフトウェア開発の現場では当然パラダイムシフトとよべれるような大きな変化がありますが、そのようなときでもこのやり方で乗り越えて良く事ができると僕は思っています。

オブジェクト指向でなぜつくるのか

たまに書籍の紹介を。また、申し訳ありませんがmixiのレビューに書いた内容とほぼ同じです。
オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―
オブジェクト指向開発に関する入門書。オブジェクト指向の基礎概念、歴史的背景から、最新の開発方法論まで一通り網羅しています。
特にこの本が入門書としてすばらしいのは、オブジェクト指向プログラミングと、オブジェクト指向分析・設計をきちんと分けて説明している点、比較的平易な語彙を選んで書かれている点、余計な誇張や嘘が無い点が上げられます。
これからオブジェクト指向言語を学ぶ方、オブジェクト指向開発に新規にかかわる方は、詳細な個別技術ごとの書籍を読む前にウォームアップとして本書を読まれると良いでしょう。
また、プログラミング初学者の方は、本書を読む前にこのシリーズの第1弾を読んでおくことをお勧めします。

続きを読む オブジェクト指向でなぜつくるのか

スパゲッティってどうすればいいの その2

結局スパゲッティか、そうでないかの判断は、そのソースコードを書いている時の自分ではなくて、他人や3ヶ月後の自分が判断します。
つまり、如何に他者に理解してもらいやすく記述するかが大事です。難解な資本論を書く必要はないのです。
プログラムコードも自己の思考の表現方法の一つであるので、他人に理解してもらえるように記述しましょう。
せっかく苦労して書いたものが、ゴミのように捨てられたら悲しいでしょ。

スパゲッティってどうすればいいの

中さんのBlogに「スパゲッティに立ち向かうときのハウトゥ10カ条」がのっております。
すでにスパゲッティになってしまっているものに対しては、中さんのBlogのようにするしかないです。
逆にスパゲッティにさせない(しない)為にはどうするのがいいのかと言うことなんですけど、これはプログラムを適切なモジュールに分割して、その間のシーケンスとして設計し、コーディングしなさいと言うことになります。つまり、プログラムを一度で考えられる(管理できる)大きさに分割して、プログラムを分割統治せよと言うことになります。これをオブジェクト指向では、モジュールをオブジェクトと、シーケンスをメッセージパッシングという用語に置き換えます。
プログラムが人から見てスパゲッティと呼ばれるような状態になってしまうのは、充分に考慮せずにプログラムを作り始めてしまうため、本来プログラミングコードを書き始める前に終えておくべき思考が、コーディング中に行われ、思考の過程がプログラムコード中に分散して記述されてしまい、その結果収拾がつかなくなってしまうためです。つまり、設計が行われていないか、充分ではないために、プログラマの思いつきで関数の分割したり、不必要な構造体を作ったり、辻間あわせのグローバル変数を作ってしまう事になります。これでは、そのプログラマのコーディング中の思考の過程が他人や3ヶ月後の自分には理解が出来ないので、それらがそのプログラムコードを読もうとしてもわけのわからないコードとなってしまいます。
ですので、プログラムコードをスパゲッティにしないためには、コーディングを行う前に一呼吸置いて、自分が作るべきものが何者かを考えもう一度整理する必要があります。何も関数内のロジックを詳細にフローチャート化する必要もないとは思います(全部いらないって事じゃないですよ)が、モジュール化する単位と、各モジュールの関数間の関係とそれらの呼び出し順序ぐらいは紙にメモをとるなりしないと、コーディング中に収拾がつかなくなります。そしてそのメモは何らかの形で残すべきです。(本来はそれが設計書となっているはず。)
とりあえずは設計の重要性を認識する(してもらう)事が、スパゲッティコードを書かない、または、それを修正しなくてすむようにするためには必要となります。

J2SE Ver. 1.5

Java Ver1.5というか、Java2 Standard Edition Ver5について変更点がまとまっているところがないかなーとさがしていたのですが、以下のページがばっちりでした。
J2SE5.0トラの穴
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html
しかし一番の謎はJavaのバージョニングですね。なぜVer.5.0。