れいんぼー日記

日々思ったことを徒然と。
マスゴミの悪事を暴こう

収穫

2005年06月29日 | 日記
今日はオブジェクト倶楽部が主催する、オブジェクト指向実践者の集いというイベントに参加してきました。

非常にフランクなイベントだったんだけど、ほんとに良かった。

何が良かったかって、
・良い環境を作るにはどうすればよいか?のヒントが沢山あった。
・社外の人との交流が出来た。
・何よりも面白かった!ライトニングトークスなんて最高でした。

エンジニアって暗い人の方がおおいのかと思われがちだけど、参加していた人たちは
ほとんど芸人でしたヽ(゜∀゜)ノ

黒電話を携帯と合体させて、携帯黒電話とか言って自慢しにきていたりする人とかもいたし(´ロ`;)
いろいろと刺激になりましたっ。

いやー、また参加しよっとっ。

バリボー

2005年06月26日 | 日記
セットポイントやマッチポイントのときに出てくる画面分割が24みたいでどきどきする。。。

しかし、日本超強いな。。。
ブラジルを圧倒してるよ。

#菅山かおるはきれいな人だねぇ。(・∀・)イイ!!


健康診断

2005年06月24日 | 日記
なんじゃ今日の気温は。。。。暑すぎる。。。

今日は健康診断だったので、2時半ごろ会社を出て溜池山王へ行って診断受けてきた。
身長、体重ともほとんど変わらず。良かった、太ってなくて。
って、筋肉落ちて脂肪増えたって可能性もあるけど。。。

健康診断といえば、懐かしい思い出が。


新入社員のころの話。

同じように2時半ごろに会社を出た。明るいうちに会社から出たせいか、なんかテンションが上がってた。電車の中でもあほなことばかりいって、同僚からウザがられていたです。

そんな状態のまま診断を受けた。


そして、検尿の時に事件が・・・。

一緒にいたやつが、

「お前、入れすぎだよ!」


と、言って来た。


そう、容量200mlの検尿カップに、並々と尿を注いでいたのです。

事前に看護士のお姉さんから、「50mlの線まで注いでください」って言われてたのを、まったく
聞いてなかったのです。。。

泡立ちも良く、まるでのようでした(´ロ`;)


さて、これから飲みに行ってくるか。_| ̄|○オエッ

ブラジル戦見逃した。。

2005年06月23日 | 日記
コンフェデ杯のブラジル戦、携帯の目覚ましを3時半にセットしてリアルタイムで見ようと
思ったんだけど、まったく起きられなかった。。

しかも、1-0で日本が勝っている夢を見てぬか喜び。。。

うー、しかし、リーグ突破は出来なかったけど、2-2だなんてものすごく善戦じゃないかっ
ほんとに見たかったなぁ・・・。

飲み

2005年06月22日 | 日記
携帯から更新。

今日は久しぶりに地元のお友達との飲み。

両国のちゅらさんて店で沖縄料理を堪能。
おいしかった&楽しかったです。

ふー、久しぶりに自分を開放したってかんじかな。

やっぱ旧来のお友達と話すのは楽しいっ。
またいきましょ~。

合格発表・・・

2005年06月18日 | 日記
情報処理試験のテクニカル:エンベデッドを4月に受けて、16日に合格発表があった。

で、HPから成績照会ができるのだが。。。。


結果は、不合格でした・・・


以下、照会したデータの抜粋。

午前試験のスコアは,595 点です。

・備考
合格基準は,午前,午後I,午後II試験のいずれも600点です。


_| ̄|○

リファクタリング

2005年06月13日 | プログラミング・ソフトウェア開発
エクストリーム・プログラミングで知った概念、リファクタリングについてちょっとだけ。



リファクタリングとは、
「外部から見た振る舞いを変えることなく内部構造を改善すること。」
である。



建築でいったら、内装のリフォームみたいなものか?

・リファクタリングが必要な理由
リファクタリングが必要な理由は、
  • プログラミングは、基本的に複雑な作業である。よって、初めから最適な解でコーディングできるとは限らない。(プログラマの腕の差もある。)
  • 仕様が変化したり、始めは見えなかった仕様が見えてきて、例外的な処理がどんどん増えてくる
  • 仕様追加などが発生し、そのままのコードで対応しようとするとさらに複雑なコードが出来上がる。

    複雑な作業であるが故、一発でよいものが出来る可能性が低い。そのため、最適な形に
    作り直すという作業が必要になる。

    最近流行の開発環境:Eclipseや、最新バージョンのVisualStudio(まだβ?)でも、リファクタリングの機能を持っている。



    以下、経験談。

    ・その場で思いつく限り一番シンプルなやり方で実装せよ
    何の本で読んだか忘れたのだが、こういう言葉があった。

    それで、自分は以下のようなインクリメンタルな開発をするようになった。

    動く→正しく動く→仕様が明確な形にする→保守性、拡張性を考慮した形にする→チューニング

    ソフトウェアってのは動いてナンボなので、動いていることが確認できながらやるというのは
    ストレスがたまらなくてよいです。

    ■動くこと
    まず大まかな設計を行う。
    そして、クリティカル・パスのみを実装し、自分の思いついた形で実装を行う。
    エラー対処などは行わない。これにより、短時間で動くことが確認できる。

    ■正しく動くこと
    クリティカル・パス以外のものを実装し、エラーコードも追加する。
    エラーも全体の流れを考慮し、どこにおけばよいか考えて置く。
    そうすることによって、例外処理は最低限の形になってくる。

    ■仕様が明確な形にする
    この段階では重複した分岐などをまとめ、シンプルにする。そして、詳細動作設計図を描く。
    大体動いていて確認できているので、設計が間違っていることも少ない。

    ■保守性、拡張性を考慮した形にする
    今後どういう仕様変更が発生するのか?を予想し、同じ動きのまま拡張できるように
    しておく。
    ここは、不変なものと変わるものを見極めることが必要。
    まぁ、大体アルゴリズムとデータの分離がちゃんと出来ていればたいていはOKかな?

    ■チューニング
    最後に、パフォーマンスが悪いところがないかを見て、もし、悪いなら他の方法を考えてみる。
    この最後のフェーズは、調べることはやるけど、大体実装することはないかな。。。

    こんな感じ。

    はじめから保守性、拡張性を考慮した形にすることって難しくって、時間もかかる。
    でも、そうやって作らないと後で大変になる。
    そのため、段階を踏んでインクリメンタルにプログラミングしてく。
    一度に全てやらないほうが時間がかからない。一般的なことだとなんか逆っぽいんだけどね。
    ソフトウェアの開発は順々に確認しながらやったほうが早くできる。


    ☆注意すべきところは、
    ・ちゃんと動作確認すること
    ・一度に2つの変更を行わないこと
    ・仕様変更と同時に変更しないこと(仕様変更・リファクタリングと、2段階にわける)

    そうしないと、リファクタリングによって余計な不具合を入れてしまう。
    この対処には、単体テストを行うってのが非常に有効になってくる。

    まぁ、バージョン管理ツールがないとつらいと思うけど、いまどきソースコード管理ツール
    使っていないところはなさそうだし。

    #今はこんな感じでプログラミングしてます。

    リファクタリングの副次的なメリットとしては、「コーディング・設計能力が高まる」というのが
    あると思う。

    その理由は、
    ・問題を分けて考えられるので、考えるのが楽
    ・同じ仕様でも、複数の実装方法があるのが判ること
    ・自分で最適解を探すことにより、どうすればよくなるのかが判ってくること
    ・同じ仕様を追加するのに何度もコーディングして、そのぶん経験が深まること
    ・すばやいフィードバックにより学習効果が高まる

    と、いうところから。

    こうやって、複雑なものをシンプルにするというのが、自分のコーディングスタイルに
    なって行きました。


    XPの中では、一番好きなプラクティスかな。


    ■リファクタリングに関するリンク
    リファクタリング-プログラムの体質改善テクニック
    「不吉なにおい」はカナリ有名な言葉ですね。私は借りてぱらぱら読んだ程度ですが・・・。


    すんげー長くなっちゃった。。。