« 2005年05月 | メイン | 2005年07月 »
2005年06月30日
システムの品質はコードに宿る
システムの品質はコードに宿る。
投稿者 tatsugoro : 23:27 | コメント (0) | トラックバック
2005年06月29日
技能はコピーできない
システム開発の技能(skill：スキル)は人から人へとコピーできない。
投稿者 tatsugoro : 08:41 | コメント (0) | トラックバック
2005年06月28日
市川さんp&p Champion awards受賞
http://enterpriselibrary.jp/の市川さんが「p&p Champion awards」を受賞されました。
http://cityriver.main.jp/Diary/archives/001244.html
おめでとうございます。
patterns & practices、EnterprisElibraryの日本での貢献を評価されたのでしょう。すばらしいことです。
p&p Champion awardsとは
「p&p ChampionsというのはどうやらMSMVPと同じくコミュニティへの貢献が認められた人が選出されるらしく、基本的にMSMVPがMSのプロダクト（製品）毎に選出されるのに対して、p&p ChampionsはMicrosoft Platformにおける広範なガイドラインを公開しているpatterns & practicesに対する貢献によって決まるというもののようです。」
だそうです。
投稿者 tatsugoro : 11:26 | コメント (1) | トラックバック
検索しやすさを考慮して名前をつける
検索しやすさを考慮して変数名・関数名・プロパティ名・クラス名等をつけるとよい。
ループ変数が「i」のコードをよく見かけるが、このコードの変数「i」を使っているところを検索すると(単語単位検索にしなければ)「if」まで引っかかってしまう。
目視で探すときにも見つけにくい。
そのループ変数が行を走査するものなら「row」を、列を走査するものなら「column」を、利用者を走査するものなら「user」を変数名の一部につけるだけで格段に視認性と検索性があがる。書くより読むほうが大変なのだから、書くときのこの程度の労力を惜しむのはもったいない。
投稿者 tatsugoro : 03:58 | コメント (0) | トラックバック
2005年06月27日
新規開発より改修の方が難しいのに
実際は新規開発よりも運用後のシステム改修の方が困難だというのに、この工程にお金と力と時間と、人材をつぎ込んでくれる現場は少ない。
システム改修の方が難しくなる一番大きな原因は、新規開発の責任者が「あとはどうにでもなる」という発想を持っているからだ。
新規開発は難易度が高い、とする。だけど、実際の現場は難しいことをするんだという布陣になっていない。
私が見聞きした実際の新規開発の現場は素人同然のリーダーたちが新人同然の実装者を使って行っている事が多かった。まるでリーダーと実装者の新人研修所だ。
難しいことをこなすことのできる、ある程度の技術力のある人をメンバーに入れるときも、他との掛け持ちだったり、十分な力を発揮できないような足かせをかけられてしまっていたりという始末だ。
これでは新規開発よりも改修の方がカンタンになるように作れるわけが無い。
もういい、改修の方が難しいのはあきらめるから、せめて、改修って難しいことなんだ、ということだけは理解して欲しい。やるきなくなるから。
知人の改修担当者の苦労談
投稿者 tatsugoro : 13:04 | コメント (0) | トラックバック
2005年06月24日
作るより読むほうが大変
作るより読むほうが大変なのだから、読むときのことを重視する。
後で読む人のことなどどうでもよいと考えてはいないか。
そのコードを読むのは、翌日の、5時間後の、1時間後の、5分後の自分かもしれないのに。
投稿者 tatsugoro : 18:37 | コメント (0) | トラックバック
2005年06月21日
アーキテクトを語るときマネジメントと混同してはいけない
アーキテクトを語るときマネジメントと混同してはいけない。
アーキテクト論の話を見聞きするたびに、プロジェクトマネージメントの話で終結することが多く辟易とする。
それは別の話なので、別のところでやってください。
投稿者 tatsugoro : 19:33 | コメント (0) | トラックバック
2005年06月20日
あとは次の人がなんとかしてくれるなどと思うな
あとは次の人がなんとかしてくれるなどと思うな。
あなたがそう思って作るなら、次の人も同じように思っている。
投稿者 tatsugoro : 16:12 | コメント (0) | トラックバック
2005年06月17日
短時間しか記憶できない
人間はよほど関心があること以外はたいてい短時間しか記憶できない。
だから、短時間の記憶しかできなくても読めるように書くとよい。
関心ごとが２箇所に分かれているだけでも、読みにくくなる。
投稿者 tatsugoro : 11:20 | コメント (0) | トラックバック
2005年06月16日
動かす様に書くのではなく、目的を表現する様に書く
動かす様に書くのではなく、目的を表現する様に書く
投稿者 tatsugoro : 11:39 | コメント (0) | トラックバック
2005年06月15日
目立たせ方に注意 どこかを目立たせると他が埋没する
目立たせ方に注意 どこかを目立たせると他が埋没する。
投稿者 tatsugoro : 08:55 | コメント (0) | トラックバック
2005年06月14日
ComboBox、ListBox、CheckedListBox項目追加削除
Windows フォーム ComboBox、ListBox、または CheckedListBox コントロールへの項目の追加または削除
簡潔で判りやすいサンプル群だなと思ったのでご紹介。
投稿者 tatsugoro : 18:55 | コメント (0) | トラックバック
2005年06月13日
VBのプロもいるJavaの素人もいる
VBのプロもいるJavaの素人もいる。
しかし、そう思っていない人が多く、驚く。
VBができる程度の人を募集しています。
Javaができる程度の人を募集しています。
技術レベルに差があると思われている。
VBが初心者に門戸を開いているからといって、全員が初心者ではない。
Javaで高レベルの開発ができたことがあるからって、全員が高レベルではない。
Javaのシステムがあちこちで、非常に多く失敗していますが、そういう失敗をした当事者でもプロだと胸をはっていられるのですか？
VBのシステムがあちこちでうまく動いていますが、それらが全て初心者のやった仕事だと思っているのですか？
言語やプラットフォームで技術「レベル」を語るのは、ばかばかしいし、はずかしいことだということに気づいて欲しい。
投稿者 tatsugoro : 13:17 | コメント (0) | トラックバック
2005年06月12日
Tech・ED2005ご招待
このBlogをご覧の方でTech・ED2005に行きたいという方がいらっしゃいましたらご連絡ください。
codeseektatsugoro＠yahoo。co。jp (＠を小文字に、。を.に変えてください)
ご招待させていただけるかもしれません。
Tech・ED期間中にINETA-Japanのイベントでお手伝いいただくことになりますが、それほど負担になるものではありません。
締め切りは6月13日(月)20時0分です。
http://www.event-registration.jp/events/te05/
投稿者 tatsugoro : 06:05 | コメント (0) | トラックバック
2005年06月10日
モードを持ち続けるな
フラグにより状況を保持してコードで判別する必要があれば、モードに入っていると言える。
モードが多かったり、長かったりすると読めないコードになる。
投稿者 tatsugoro : 05:27 | コメント (0) | トラックバック
2005年06月09日
完成したというお墨付き
システム開発で難しいのは、これで完成したというお墨付きがもらえないことだ。
顧客の検収では表面だけしかチェックできない。
だからこそ動き出した時点で完成したと思い込むこともできてしまう。
完成はコードの価値が十分になるまでオアズケにすべきだ。
投稿者 tatsugoro : 04:29 | コメント (4) | トラックバック
2005年06月08日
難しく書くから難しく出来上がる
難しく書くから難しく出来上がる。
簡単に書けないか再検討すること。
投稿者 tatsugoro : 16:44 | コメント (0) | トラックバック
リンクさせていただきます。中の技術日誌ブログ
投稿者 tatsugoro : 11:18 | コメント (0) | トラックバック
VS2005英語2005年11月7日出荷
Visual Studio 2005 Englishの出荷日が2005年11月7日にきまったもようです。
http://msdn.microsoft.com/launch2005/
http://pcweb.mycom.co.jp/news/2005/06/08/100.html
日本語版もぎりぎり今年中に出るかな。
Mooさんありがとう。
投稿者 tatsugoro : 11:12 | コメント (0) | トラックバック
2005年06月07日
情報を失わないように書く
仕様のもつ情報をすべてコードで表現できるわけではない。
仕様からコードに変えるとき情報がなるべく失われないように書くと読みやすくなる。
失ってしまった情報はコメントで補足する。
投稿者 tatsugoro : 14:06 | コメント (0) | トラックバック
2005年06月06日
多く書いてもっともよいものを残す
いろんな書き方を多く試してもっともよいと思ったものだけを残している。
主とする処理をより正しく書けたものがたいてい残る。
投稿者 tatsugoro : 22:28 | コメント (0) | トラックバック
2005年06月02日
一貫性よりも進歩を
一貫性が無くなるからと進歩をやめてはいけない。
よりよいコードのために積極的に変えていこう。