タグ

ブックマーク / rabbit2go.hatenablog.com (14)

  • 心配性の人はソフトウェア開発に向いていないかも知れない - rabbit2goのブログ

    ふとソースコードの断片に目が止まり、これが妙に気になって仕方ないことがある。 public int Foo(int i) { // do something wonderful here return x; } 例えば、上記のようなコードの場合、こんなことを考えてしまう。 int型の引数を取っているけど、これは0とかマイナスの場合もあり得るのだろうか?有効な値の範囲は何なのだろう? 引数をいきなり配列の添え字に使っているけど、配列の範囲外だったら誰が何処で例外を捕捉しているのだろう? 引数を2倍して計算しているところが有るけど、もの凄く大きい値が指定されてきたら、ここでオーバーフローしてしまうよ。 ユニットテストは用意されているけど、引数の値のチェック範囲は要件を満たすほどに充分なのだろうか? 戻り値の変数にマジックナンバが使われているけど、呼び出し側でも同じようにマジックナンバで参照して

    心配性の人はソフトウェア開発に向いていないかも知れない - rabbit2goのブログ
    katzchang
    katzchang 2011/05/16
    オーバフローは気にしたことないけど、+演算でもあり得る話だよなぁ…。
  • 負の連鎖を断ち切れない開発者 - rabbit2goのブログ

    ソフトウェアの開発現場では、正しいことばかりではなくて、正しくないことも何故か平気で行われている。行われているどころか、問題を指摘する人がいないと、あたかもそれが正しいかの如く脈々と受け継がれていたりする。その一例。 正しくないAPIの使い方を続けている そのような使い方をしている開発者に理由を聞くと、「もともとそのような使い方をしている箇所が有ったので真似をした」とのこと。その更に元の開発者をSubversionの履歴で調べていくと、実はもう既に退職した人だったりする。 開発プロセスが形骸化している 仕様書レビューやコードレビューがまともに行われない。リーダに理由を聞くと「忙しいから」「この案件は急ぐから」とのこと。でも、いつも同じ返事が返ってくるし、それを見聞きしているメンバもそんなリーダを見習ってしまうので、悪しき慣習は決して途切れない。 同じ問題を繰り返し発生させている 興味深いも

    負の連鎖を断ち切れない開発者 - rabbit2goのブログ
    katzchang
    katzchang 2011/05/16
    前例主義との戦いです。
  • 開発現場の危機管理を考える - rabbit2goのブログ

    危機管理と言っても特にその方面の専門家では無いので、自分の周囲5mまでの範囲を対象に考えてみる。ただし、ソフトウェア開発の現場で頻発する「仕様変更」のようなものは、今回は対象外。開発現場の周囲の状況について考えてみたい。 ずっと同じところで働いていると、予期せぬことが時々起こる。例えば、下記は今までに社内で経験した一例。 台風が直撃したので、会社では昼過ぎに退去命令が出て全員帰宅。幸い被害は無かったので、翌日には通常常業に戻り、工程の遅れは半日分で済んだ。 朝、チームのメンバが交通事故に遭いそのまま2ヶ月入院。その時はやや個人プレイ状態だったので進捗状況が分からず、見舞いを兼ねて病院まで行き、仕事の引継ぎを行った。 社内でボヤ騒ぎが有った(電気機器の老朽化が原因だったらしい)。幸い、直ぐに消し止められたので大きな被害は無かった。 事故はいくら注意していても避けられるとは限らないし、天災など

    開発現場の危機管理を考える - rabbit2goのブログ
    katzchang
    katzchang 2011/03/29
    「最近はAmazon S3へバックアップしてくれるNASが有るらしい」
  • チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ

    Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は

    チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
    katzchang
    katzchang 2011/03/06
    Excelを使いたいんだよ。たぶん。
  • Objective-Cの宣言プロパティにはまる - rabbit2goのブログ

    iPhoneの開発において、Objective-C 2.0で導入された宣言プロパティ(declared property)にはまったので覚え書。プロパティ経由でアクセスする度にリファレンスカウンタが増加してしまい、結果としてリークするという状態が発生した。単に参照しているだけなのだから、インスタンス側の状態は何も変わらないハズだし、変わって欲しくない。それなのにリファレンスカウンタが増えてしまうとは、一体どういうことなのか? 試しにこんなテストコードを書いて、いろいろ調べてみた。 NSLog(@"(1) %d", [self.selectedImage retainCount]); NSLog(@"(2) %d", [self.selectedImage retainCount]); NSLog(@"(3) %d", [self.selectedImage retainCount]); プ

    Objective-Cの宣言プロパティにはまる - rabbit2goのブログ
    katzchang
    katzchang 2010/12/14
    プロパティ宣言でnonatomicオプションが指定されていない場合、参照カウンタが増加する問題。
  • Agile Tour Osaka 2010に参加してきた - rabbit2goのブログ

    昨日はAgile Tour Osaka 2010に参加してアジャイルを勉強してきた。一言でアジャイルと言っても、言葉を使う人によって、スタンスや方法論が微妙に異なっていたりするが、その幅広い考え方を柔軟に受け止めるのがアジャイルの特徴かも知れない。会場にはそのような多様なバックグラウンドを持ちながらアジャイルを目指す人が多く、非常に活気のあるイベントだった。 http://www.agiletour.org/osaka.html 10月30日 AgileTourOsaka2010 以下、講演メモの抜粋に感想を付記してみた。 チケット駆動開発がAgileになる理由 〜No Ticket, No Commit!〜あきぴーさん チケット駆動開発の基的な考え方や、その導入効果について紹介。障害も仕様変更も全てチケットで統一して管理することで、成果物を管理しトレーサビリティを確保できる。 Redm

    Agile Tour Osaka 2010に参加してきた - rabbit2goのブログ
    katzchang
    katzchang 2010/10/31
    いいまとめ。
  • 私家版テスト駆動開発 - rabbit2goのブログ

    テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由

    私家版テスト駆動開発 - rabbit2goのブログ
    katzchang
    katzchang 2010/09/05
  • 特許庁の動かないコンピュータ  - rabbit2goのブログ

    少し前の日経コンピュータに特許庁のプロジェクトが載っていた。もちろん、プロジェクトの成功事例ではなく、失敗事例としての記事だ。133億円規模の開発が予定より2年遅れていながら、まだ稼働できないどころか設計すら出来ていないらしい。 特許庁の基幹システム再構築プロジェクトがすでに2年遅れている。総額133億円の契約を結んでいるが、稼働のメドが立っていない。2006年末から始めた基設計すら終わっていない段階だ。レガシーシステムの刷新と分割発注によって開発・運用費を削減する構想だったが、足踏みが続いている。 動かないコンピュータ 特許庁 “野心的な”システム構想が頓挫133億円投じるも稼働のメド立たず | 日経コンピュータ | 日経BP記事検索サービス 原因は、そもそも受注業者が開発対象の業務を理解していなかったことにあるらしい。特許のシステムなんて俺たちなら作れるぜぇ、とか思い込んでいたのだろ

    特許庁の動かないコンピュータ  - rabbit2goのブログ
    katzchang
    katzchang 2010/07/08
    あれ?これってNTTデータが収賄した件?/あれ?買収するほうは贈賄だわ。
  • 問題の多いソースコードは縦に延びる - rabbit2goのブログ

    ソフトウェアの問題点を調査していたら、一つの関数で1000行を超えるものに出くわしたことがある。そんな長い関数を作るからバグが生まれるのだよと思いつつ処理内容をチェックしてみるが、24インチのモニタに表示させても全体像がサッパリ分からない。仕方ないのでプリントアウトした13枚のA4ペーパーを床に並べ「このif文がここまで延びて...」等と赤ペンを片手に構成を解きほぐしていく。同レベルの処理が並んでいるだけならあまり問題ないのだけど、来異なるレイヤーで行うべき処理を1箇所に無理矢理押し込んでいるので解読する方も大変だ。 開発者は当にこの長い長い処理を理解してコードの改変を行っているのだろうか?という疑問はあるが、その前にそもそも何故こんな巨大なコードになっているのだろうか?Subversionのリポジトリから変更履歴を参照してみると、長年に渡って多くの人がコードの改変を行っており、誰か特

    問題の多いソースコードは縦に延びる - rabbit2goのブログ
    katzchang
    katzchang 2010/06/04
    行数を監視するだけじゃだめで、どう直したらよいのか等をアドバイスできる技術リーダの存在が一番大事。
  • JUnitの使いこなし方を学ぶ本「JUnitイン・アクション」 - rabbit2goのブログ

    テスト駆動開発やJUnitを使い始めた頃に読んだ。手元のは2004年5月発行の初版なので、もう6年(!)も前のになる。JUnit自体は(やや乱暴な言い方かも知れないけど)Assertによる検証をシステマティックに行うものであり、特に難しいものではない。例えば、「1+1の演算結果」が「期待通りの値である2になるか?」を確認するというという基的なサンプルがよく紹介されているし、使い方としてはこれに尽きると思う。 むしろ難しいのは、ソフトウェアの設計として「いかにテストしやすい形の構成にするか?」という点だろう。仕様書通りに組み上げたソフトウェアでは残念ながら粒度が荒すぎるし、テスト対象も広過ぎる。様々なしがらみが付いて回るので、検証のためにはダミーデータを準備しておく必要があるかも知れない。だから、コードの設計を少し変えて、検証しやすい形態にする方がずっと重要なのだ。これらの考え方を総

    JUnitの使いこなし方を学ぶ本「JUnitイン・アクション」 - rabbit2goのブログ
    katzchang
    katzchang 2010/05/20
  • チケットキーパーという存在 - rabbit2goのブログ

    TracやRedmineを使って障害管理を行っていると、チケットが乱発されて収拾が付かなくなることがある。テスト担当者からの報告は結構だけど、あまりにたくさんのチケットが誰のチェックも受けずに存在しているのは問題だ。そこで、チケット全体に目を光らせて交通整理をする人が必要になる。主な作業は下記の通り。 チケットの分割 障害の内容が大きいとか、実は複数の問題が絡んでいた場合、複数のチケットを分割して管理しやすくする必要がある。もちろん、トレーサビリティ確保のため、相互のチケットにリンクを記載することは必須だ。 チケットの統合 上記とは逆に同じ内容のチケットが複数登録されたり、原因を調べたら実は同じだったといういう場合、一つのチケットのみを残して他はクローズする必要がある。これも、上記同様にチケットの相互リンクが必須だ。 チケット対応の進捗確認 障害の対処方法が理に適ったものであればよいけれど

    チケットキーパーという存在 - rabbit2goのブログ
    katzchang
    katzchang 2010/01/21
    あとでみる
  • 経営者のスキル - rabbit2goのブログ

    今週の日経ビジネスに興味深い記事が載っていたのでメモ。景気悪化に伴う業績の低下を人のせいにする経営者が多いけど、そのくらいの修羅場を乗り越えられずに社長と呼べるのか?という疑問を持つ人は少なくないはずだ。こんな経済状況だからこそ、優れた経営手腕を発揮して会社を立て直すべきではないだろうか。景気が回復するまでどうしようもありませんと弁解するようでは、経営者としての資質を疑われても仕方あるまい。こんな時にこそ、経営能力の有無が如実に現れるように思えてくる。 トップの仕事は危機管理以外にないと私は考えている。極端なことを言えば、平時の経営は誰にでもこなせる。決まり切ったことを繰り返せばいいのだから、社長でなくてもいい。有事の場合はそうはいかない。社長が舵を取ることが必要だ。「想定外のことが起きたから対応できない」と言うのは、私は危機管理ができないと告白しているようなもの。自分は経営者ではないと認

    経営者のスキル - rabbit2goのブログ
    katzchang
    katzchang 2009/12/21
  • 勉強しない技術者 - rabbit2goのブログ

    職場の雑談で、週末に読んだ技術書の話をしたことがある。特に難しいでもないし、気軽に読めるものだったのだけど、その時の相手の反応は「休みの日になんか読んで勉強しているのですか?」だった。自分ではを読むことくらいアタリマエの事であり、特に勉強という意識を持っていなかったのだけど、彼にとっては家で仕事に関する書物を読むなんてトンデモナイことだったらしい。勉強するから偉いなんて言うつもりはないけど、会社の外でスキルアップの努力をしない開発者の行く末は見えているような気がする。 学生時代は勉強していた人も、社会人になって勉強の習慣を無くしてしまうのは不思議なことだ。会社の仕事を言われた通りにこなしているだけでは、多数の中の一人に終わってしまう。多数の中に埋もれない自分だけのブランドを確立するには、それなりの努力が必要だろう。会社の上司が週末のゴルフの自慢話をするからと言って、わざわざ自分もレベ

    勉強しない技術者 - rabbit2goのブログ
    katzchang
    katzchang 2009/11/25
    これはむしろ強迫観念にみえる。
  • 仕様書をSubversionとTracで管理する - rabbit2goのブログ

    議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い(誰かが変更箇所を承認してしまった等)ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー

    仕様書をSubversionとTracで管理する - rabbit2goのブログ
    katzchang
    katzchang 2009/09/30
    CVS導入した翌日からやってたよ。
  • 1