もり ひろゆきの日々是勉強

日々思ったことやIT関連のメモなどをのほほんと綴っていきたいと・・・。(^^;

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  1920  : 記事  12  : コメント  16429  : トラックバック  163

ニュース

Microsoft Innovation Center

MICでは各種無償セミナーを実施しています。
こちら
そして、スピーカーは僭越ながら私がお話させていただいております。
一生懸命努めさせていただきますので、よろしければご参加くださいm(__)m

平行運用はじめました。

  • 現在、こちらのほうで平行運用を行っております。

自己紹介

  • もり ひろゆき(森 博之)と申します。

    極東IT Engineersというコミュニティの代表です。

    本業は東京でソフトウェア開発のお仕事をしております。いわゆるDeveloperですね(^^;

    仕事ではVB,C#といろいろと渡り歩いてはおりますが、主に.NET系の業務アプリの開発が多いです。

    というか仕事となったら必死で何でも勉強しますが(^^;;;;

    最近ではMicrosoft Innovation Centerで講師もさせていただいておりますが、撃たれ弱いのでお手柔らかにお願いしますm(__)m

    まったく関係ありませんが、たこ焼き機も持っています。 関西人です。

    エントリの内容は私が個人的に収集した情報を元に書いていますが、あくまで個人的なメモ用途ですので内容の正確性を保証するものでありません。あらかじめご了承くださいm(__)m

Microsoft MVP

MCP


  • 70-316 Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET

    70-536 Microsoft .NET Framework 2.0 - Application Development Foundation


  • MCTS: :.NET Framework 2.0 Web アプリケーション
    70-528 Microsoft .NET Framework 2.0 - Web-based Client Development


  • MCTS: Microsoft SQL Server 2005
    70-431 Microsoft SQL Server 2005 - Implementation and Maintenance

Wankuma MVP


  • Wankuma MVP for OOO(= Original Object-Oriented)

iKnow!

etc.

  • 人気ブログランキング - もり ひろゆきの日々是勉強

    スカウター : もり ひろゆきの日々是勉強

    あわせて読みたい

書庫

日記カテゴリ

リンク

なんか、仰々しいタイトルをつけましたが、ヨタ話です(^^;

刈歩 菜良さんのこのエントリを読んで、少々思ったことを・・・。

システムが動けばいいというのが目的で、本当にその通り動いているのであれば、それはそれでいいと思います。

ただ、多くがシステムが動いたと思っても、それが要求通りでなかったり、思っていたものとは違っていたり、要求したものが変化したりとなるもんで、どうしても1度作ったものを何らかの形でメンテナンスする必要があります。

もちろん、正常に動かない場合もあるワケで、やっぱりメンテナンスが必要となります。

そうすると、やっぱり「動けばいい」ってことにはならなくて、それなりにメンテナンス性(つまり変更に強い構造、もしくはバグの見つけやすい構造)も求められてしまうワケで・・・。

きっと動けばいいの中にはこれらも含まれているワケです。

こう考えると既に依頼者と開発者の間で意識の差異が生じてしまう(^^; 怖いですねー。

投稿日時 : 2006年11月4日 14:06

コメント

# re: システムが動けばいいが本当に目的なのか? 2006/11/04 14:57 刈歩 菜良
そうなんですよねぇ。
メンテナンス性ってものすごい大事ですよね。
レスポンスなんかよりも重要な場合が多いと思います。

でも、納期に追われて結局行き当たりばったりのやっつけ仕事が多くなっているような。

結局、
時間がない→OOに則さないきちゃないコード→メンテナンス性低し→メンテに時間がかかる→時間がない→・・・
の悪循環ですよね。
で、結論として、きちんとOO勉強する暇がない。ってのがつくんですねぇ。

暇がないながらも志の高い方はきちんと勉強するんですけどね。
あ、ごめんなさい。わたくし全然人のこと言えません。
(v_v)

# re: システムが動けばいいが本当に目的なのか? 2006/11/04 15:12 ひろえむ
# 刈歩 菜良 さん

何にもましてOOがいいとは言わないですが、OOらしいコードってわかりやすかったり便利だったりするんですよね。

でもって、OOだけに限らず、そういう人のコードってのはよく考えてあって、可読性が高かったりするんですよね。 

なので、私はOOだけに限らず、必要な手間はかけるべきで、それを省いた分だけ後から苦労しちゃうんじゃないかなぁと。

なので、そうじゃないコードをメンテする前に、まずコードの整理から始めちゃいますね。 その方が結果的に早かったりするんですよね。

結局、何に時間がかかるとコストがあがるかというとバグ(ココで言うバグは単にシステムバグだけでなく、仕様の取り違いによる仕様バグや、検討不足で発生するバグなんかも含まれます)の停滞する時間が長いと長いほどコストが高くなるって言う話を聞いたことがあります。

つまり、バグが少ない・見つけやすい・直しやすいことが最終的に早く要求したものができるコツなんじゃないかなぁと。

なので、必要な手間はかけておけば、後からその恩恵にあずかれると思うんですよー。


# re: システムが動けばいいが本当に目的なのか? 2006/11/04 15:58 koka

こんにちわ!kokaと申しますm(_ _)m

悩ましい問題ですねぇ。
1回使ったら移行いらなくなるシステムもたまにありますが、ほとんどのシステムは使い続けると思います。さらに滅多なことで仕様が「変わるもの」と「変わらないもの」とに分かれますよね。
すると「変わらないもの」にたいして事前に保守性を考慮して開発したって意味がないですし、「変わるもの」を保守性を考えず、とりあえずでっち上げるのも後が怖いです。よくやりますがw

大切なのはこの「変わる変わらないの判断」を顧客からでる少ない情報の中から的確に行う能力なんですよね。多分。


OOに則さないきちゃないコードが必要な場面って多分「開発者が2人以上」かと・・・
最終的に人が減ったときに他の人のソースが容易に分かればよいわけで、OOは規模によって内容と厳密さがかわりますね。

ちなみに最近は開発は主に1人なのでやりたい放題ですw

長文失礼しましたm(_ _)m

# re: システムが動けばいいが本当に目的なのか? 2006/11/05 0:19 ひろえむ
#kokaさん
よろしくお願いしますm(__)m

んー、おっしゃることも解らないでもないですが、保守性といっても、特別なことをするのではなく、ましてやOO的なプログラミングって日常的に行うものなので、こっちはOO的に、こっちはOO的じゃなくて・・という切り分けをするもんじゃなくて

簡単に言えば、たとえば

For count As Integer = 0 To 10
Console.WriteLine("{0}", count)
Next

でConsole.WriteLineの行はインデントしますよね? じゃなきゃ見にくいですものね。 そんな類のもんじゃないかなぁと思うんですよ。

そうなもんで、その便利さが解っていたらわざわざベタで書いたりしない気がするんですよね。

最初は確かにいろいろ考えると思うんですよ。 ただ、慣れてくると自然とそうなるというか・・・ インデントにしてもそうですよね。 最初はここにインデントしてみて・・・するとベタで書くよりコードが見やすくなったとなって次からはインデントにしちゃう・・・みたいな。

保守性といってもその程度のものの延長線上にあるんじゃないかなぁと。
なので、わざわざ、その前に戻るのは非常に苦痛を伴ったりする気がするんですよね(^^;;;

ルールというより経験則でそっちのほうが便利だなってなるものなので、則ったとかってならないと思うんですよ(^^;

いや、自分のコードがそうだとは決して言わないですが、慣れてくるとそうなるんじゃないかなと思うんですよね(^^;;;

# re: システムが動けばいいが本当に目的なのか? 2006/11/07 0:23 koka
こんばんわ!
>ひろえむさん
そういう意味での保守性ですね。
私はその作業はコーディングする上で必ずやってます。具体的には最終的に記述レベルを「その時点で一番分かりやすい状態」にしてます。
分かりやすさを突き詰めてくときりがないのでリリース前で区切ってます。

まぁVSを用いたコーディングではインデントなんかは勝手にやってくれますし、つらかったのはASPとかVB2003のHTMLですね。2003は最近だ(汗

とはいえそれを他の人の作業にまで波及させるのは手間なのでw
最初にそういったコーディングの指針を決める機会があれば「提案」はしてます。「やれるならやりませう」って。。。
多分几帳面な性格が1かけらでもないと苦痛でしかないと思いますので強制はしません。
そういったソースをメンテすることになったらもうそれはハズレを引いたものと諦めてますw

と言うわけで最初のコメントはそれを前提にしてますので例えば、クラスや関数のリファクタリング(でしたっけ)やらの作業を指してます。

にしてもコードの記述方法は私も毎回書き方が変わってきてます。時代を追っかけてみてみると多分葛藤の歴史が垣間見えるかもしれませんw

Post Feedback

タイトル
名前
Url:
コメント