「xUnit」を含む日記 RSS

はてなキーワード: xUnitとは

2020-12-20

プライベートメソッドテストすべきか

「すべきでない」というのがたぶん多数派

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートメソッド関数テストする必要は無いと考えていますプライベートメソッドは、実装の詳細であるからです。

多くの場合、そのクラスパブリックメソッド経由でプライベートメソッドテストも同時に行えます

プライベートメソッドのテストは書かないもの? - t-wadaのブログ

ほとんどの場合プライベート メソッドテストする必要はありません。 プライベート メソッド実装の詳細です。

プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテスト記述します。

単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs

プライベートメソッドテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テスト必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)は「ひとつテストひとつオブジェクトで表し、それによってテスト独立性を高める」というアイディアがある(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身ひとつオブジェクトとして独立しているなら、テスト対象となるオブジェクトプライベートメソッドテストできないのは当然のことになる。

しかし「プライベートメソッドテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。

例えそのクラスがprivateメソッド依存関係があっても。

コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするとき最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。

私は元々メソッドはprivateにしない主義なのでメソッド場合問題ないのだけれど、ファイル内の「関数」が問題になる。和了計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドテストすべきか問題原則論だけだと袋小路に入りがちだから、private メソッドテストしたくなる具体的な場面について議論したほうがいいと思う。

自分レビューでよく見る例としては、複数の public メソッドの重複部分を private メソッド抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッド可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。

自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラム挙動を変えること"の方が、「privateなメソッドテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)


メソッドプライベートパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドテストするかどうか? まず最初に言っておきたいのは public/private は抽象設計問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定言語の貧弱な機能思考制限を受けて誤った結論を出している典型的な例。

"テストを書くべき"と"上位層から可視性"は直交する概念

https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テスト粒度メソッドアクセス権は独立したものなので、「プライベートメソッドテストすべきか否か」という切り方自体ナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能テストインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)


プライベートメソッドテストがしやす言語での意見

RustやGoではプライベートメソッドに対するテスト簡単にできる。

そのためかプライベートメソッドテストすることに対して拒否反応があまりないようだ。

Rustのテストファイル内とtests/以下の2箇所に書ける。

テストには開発用のホワイトボックステスト仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。

例えば度々議論になるプライベート関数テストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。

概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。

Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに

assertionチックにprivateメソッドのすぐ下にテスト書きたい

ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストプロダクションに混ぜる方式はおれもいいと思ってて、テストプロダクションを分離することで private 関数テストができない問題があるけど(テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね)、そもそもこの議論不要になるよね (twitter/nunulk)


go言語だとプライベートメソッドテスト普通にやりますね。(twitter/mattn_jp)

昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)

golangのテスト書いてたけど、テストプログラム名前空間(パッケージ)が、対象プログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)

Goテストコードテスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)

プライベートメソッドテストするか?」とは別にドキュメントソースコードと同じファイルに書いていい(文芸プログラミング)なら、単体テストテスト対象と同じファイルに書いてもいいのでは?」というのも論点になるかもしれない。

2017-02-11

職場の開発スタイルが古すぎて限界なんだが

IT業界プログラマなのですが、どれだけ技術進歩しても何年も同じ開発スタイルから一向に改善しなくて限界を感じています

例えば次の点が挙げられる

バグ個人責任のせいにする

 ・世渡りが上手い奴は口だけ出して手は動かさな

  ・こいつが手を動かすのは最小限で、なおかつビビりなのでよく確認する

 ・手だけが早くリリースしてから考えようぜって思っているタイプバグを出すたびに個人攻撃される

開発プロセスが雑

 ・レビューがない

 ・仕様最初から作るつもりがなく、毎回担当者が長年の勘で仕様を考える

  ・故にどこかで矛盾が生じる

  ・担当者の長年の勘が頼りなので、作り手としては要求に答えるしかない

   ・仕様明確化されていないので、言われた通りに作るしかない

   ・一部しか担当していないので、一部しか知らないのだがそれを「もう何年もやっているのに担当したところしかできない」と言われる

    ・尚、これに対し口答えは許されない模様

 ・仕様がないので自分なりに担当者確認して作る

  ・このあたりはOKなのだが、その内容は一切ドキュメント化されていないしするつもりもない

  ・いつでもこの仕様担当者の気分で変更できる

   ・変更できるのは問題ないが、言い方が「お客さんがバグ報告がきた」みたいな切り出し方

   ・バグではなくただの仕様だし「作る時にそう言いましたよね?」と言ってもドキュメントがないので根拠なし

テストを書かない

 ・開発スピードが遅くなるから理由テストを書かない

 ・というか書き方を知らない

  ・xUnitすら使えない

MVCを知らない

 ・単語は知ってて理解しているつもりなんだけど的外れ(いわゆる Fat Controller が普通だと思っている)

・新しい知識を覚えるつもりがない

 ・自分達で勉強した最新の知識デザインパターン

 ・新人が入ってくるもこの調子なので2〜3年もすると社内の仕事はできるが若いのに技術力は10年以上前技術者レベルになる(仕事必要なことしか知らないのでそれ以下か)

 ・そして、いつまで経ってもこの開発スタイル改善しない

けものフレンズがバズったので、ついカッとなってやった。

2017-01-11

システムエンジニアについて

誰向けかよくわからないけど、なんとなく書いてみる。

自分大手SIerとか言われるところに在籍してる。

システムエンジニアをかなり適当に分類すると2つに分ける事ができる。

SIerかそれ以外。

SIer…客が要求するものを作る

・それ以外…客に売るものを作る

日本エンジニアの8割くらいはSIer側に属しているんじゃないかな(根拠なし)。

そしてこの2者では求められるスキルが大きく異る。

SIerに求められる物

一番重要ものは、顧客が何を望んでいて、どういうもの提供すれば一番幸せになれるか、を判断できること。

ここには技術的な要素もあるにはあるけど、どちらかというと顧客言葉やら背景やらを読み取って現実との折り合いをつけたり現場運用想像したりする部分が大きかったりする。もちろんどの技術適用すれば一番効率的とか、安価に済むとかいう話はあり、最低限の技術知識必要だけれど、世界最先端とか特殊な固有スキルとかが必須という世界ではない。一般的SIでは難しい数式とか出てこない。

なので、文系っぽい空気があったりする。これが悪い方向に加速すると技術軽視のプロマネ至上主義になる。

それ以外に求められる物

オリジナリティ

何か他とはちがう売りが無いと買ってもらえない、使ってもらえない。

この要素として技術があったりもするけど、技術を売りにするのはハードルが凄く高いため、そういう会社は少ない。

技術のものを売りにしなくとも、新しいものを数多く試行錯誤するために技術必要不可欠で、SIerに較べて技術水準は圧倒的に高い。


で、この2つは会社ごとに別れているわけではなく、大手SIerと呼ばれているようなところには大抵両方が含まれている。

ただし、それ以外、の割合は大抵小さい。

自分はどっちの職場経験した事があるんだけれど、同じ会社でもプロジェクトによってまったく状況が違ったりするので会社単位で一概に何かを断言するのは難しいと感じていたりする。

十年以上前から普通にアジャイルやってる部署もあれば、未だにxUnit知らなそうな部署もある、みたいな。


システムエンジニアになりたい、と思う人はどの会社を選ぶかを決めるにあたり、ここらへんのことは知っておいたほうが幸せになれるかもしれない。

技術を追い求めてガリガリ戦いたい情報処理系の人が大手SIerで望むことが出来る可能性は低いかもしれない。

まり情報処理知らないけどシステム開発に携わりたい文系の人でも大手SIerでは活躍出来るかもしれない。

2014-08-02

戦う気力をなくした

普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。

ソフトウェアを自社開発していて、顧客自身Webアプリケーションを作れるようなマルチテナントサービス提供しています

直属の部長

上下関係にとにかく弱い

後述する彼の上司であるCTOの言いなり。

全てをイエスで返していくからCTOには都合がいいみたい。

とある機能設計CTOが「コレ出来るよね?」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、

別の部署の部下がちゃんと理由((CTOには言葉意味すらわかってなかったらしい))を説明して何度も断ってたのに、

無関係なうちの部長が呼び出されて「出来るよね?」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。

自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当開発者たち。

社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署所属しているわけでもなく、

最近方向性技術動向に関しては全然理解していないにも関わらず。

普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。

自分が板挟みになりそうなら部下を責める。あなた意図はどこ?

前例主義

思考停止と思えるほどに「今までもこうやって来たんだし」がバンバンから出てくる。

それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。

そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。

たった4人の小さい部署から毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、

彼以外の3人がミドルウェアフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社規則に関する話が出てくるようになって、

最終的に「忙しいから」というよくわからない理由で勉強会が消えた。

3人共「楽しかったのになぁ」って口を揃えたんだけどね。

製品開発

部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。

僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д`)ハァ…」とか言ってたくせにCTOの前ではハハハと笑っている。

以前指摘したけど、彼は新製品に関するプロダクトマネジメントステークホルダー立場ではなく、あくま開発者らしい。

じゃあ誰が責任者ステークホルダーなんだよと思ったけど、そんなもの既存製品にもいなかった。

おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。

CTO

CTO(最高技術責任者)とは名ばかりの役員

CTO技術

基本的技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。

バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。

でもそれでCTOっぽく技術リードしていると思っているらしい。

その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。

社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。

来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。

CTO案件相談と業績

目の前の利益にはすぐ食いつく。

「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズ必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。

サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。

うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。

そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者運用者、更には顧客への次の担当者を苦しめる。

現行製品仕様を切り替えた時にカスタマイズ問題が起こったおかげで製品仕様カスタマイズ考慮したあれやこれやを要求されてがんじがらめ。

ええっと、マルチテナントって一体なんだろう。

ちなみに、コレよりひどい自称SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから

突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。

もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守運用は彼の仕事じゃないしね。

CTOと新製品

CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分理解範囲内に収めるべく発言しまくるし、

新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの?」で畳み掛けてくる。

もちろんそれを聞いた部長は「そうですよね。それも必要ですよね!」って援護してきて考えてきた設計がことごとく旧製品になっていく。

どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。

そんなもん誰が使うんだろうねぇ。

「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。

最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。

そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、

それすら新しい案件で潰されていくことだろう。

当初は「お客さんにはあくま実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、

今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。

現行製品の話

まともなデバッグシステムエディタを使わず果たしてユーザPHPコードを書いて開発をするだろうか?もちろん、否。

お客さんから依頼を受けたら営業担当者四苦八苦しながら開発代行を行い納品する。

それでも難しい場合パートナー企業に依頼をして開発をしてもらい、納品する。

あれ?うちって受託開発会社だっけ?

そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの?」と迷うレベルだし、

想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから

どれが正しい仕様なのかすら不明瞭になっている。

現行製品の開発の話

Javaってオブジェクト指向プログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの?って状態。

クラスがただの関数置き場になっててメンバー変数をいじるもんだから副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。

それを避けるにはどうするか?もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。

とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。

もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。

あちこちにDBコネクションとか埋め込んであって都度データ取得するからさなコードでも動作するにはDBコネクションが必要なんだ。

僕は新卒メンバーには「会社内の書き方は(どの会社でもそうだけど、ここは特に)独自のやり方だから、コレが正しいと思わないように。

今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身勉強するんだよ。」と言っておいた。

どの部署保守的

Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。

自分部署立場を守る発言は多いけど、1年後2年後3年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。

未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。

製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、

役員会でCTO勝手に「仕様検討にかかった時間負債になった」と報告したらしい。

僕の話

「なにより、こんなことで諦める俺が憎い!」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。

誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端

運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端

製品の1モジュールもきっと中途半端になるだろう。

そういった点は大変に申し訳ない。

でも、今のまま居たって僕に未来はない。

僕は僕自身未来の為に活動していかなきゃと思った。

こんなところでこんなグチグチ言ってちゃダメなんだ。

から、ゴメン!

2012-05-17

日陰者はろくろの夢を見るか

ソフトウェア開発会社新入社員として入社して1年とちょっと

今俺は先行きについてものすごく悩んでいる。

配属されて初めての仕事、それはレガシーコード保守だった。

こういうのは業界柄よくあることなので致し方ない、とは思う。

別にそれはこの際どうでもいい。

問題は、現場の同期や上司ととことん話が合わないことだ。

俺はずっと、新しい技術を追いかけて来た。

一世を風靡するしたJavaも今では一部でオワコンと呼ばれる時代だ。

IT業界の流れはとにかく速い。

俺はそこに取り残されないように必死勉強した。

近くで勉強会もやってたから、行ける限りとにかく参加した。

適当コード書いたり、色々なツールを使ってもみた。

新卒面接の時には「新しい技術を追いかけ続け、会社に貢献したい」とか言った気がする。

だが、その想いは入社半年を過ぎたあたりから見事に裏切られた。

とにかく、上司や同期が技術に興味がない。

レガシーコードとの戦いも覚悟はしていたが、俺が想定していたスマートレガシーコードとの戦い方とはひどく遠いものだった。

彼らはレガシーコードレガシーコードのまま保守する。

テストなんてものは書かない。テストExcel方眼紙で書かれたテスト項目が全てだからだ。

xUnitだとかSpecなんてものはもちろん知らないし覚える気もない。

極めつけはExcel方眼紙テスト仕様書兼報告書と呼ばれる代物の抜けの多さ。素人でもわかるレベル

足りなさそうな部分は経験則に則り適当テストする。だがその結果は報告書には書かない。

バージョン管理なんてもの存在しなかった。上司に聞いたところ、あるにはあるらしいがCVSらしい。

だがそんなもの社内のどのチームを見ても使っている様子すらない。唯一のバージョン管理ファイルサーバー上の日付が書かれたフォルダーのみ。

そんな現状だ、BTSCIももちろん存在しない。

とにかく現状がひどい現場だが、誰も変える気がない。

現場改善に向けていくつか提案もしてみたが、ただただ否定の言葉けが帰ってくる。

なんとかしてやろうとも思い、個人的にいろいろやってみたものの、必要かどうかもわからない大量の雑務に押し潰された。

彼らには新しいものを学ぶ気なんて全く無かった。

会社を変える気も無かった。

俺はとにかく現場失望した。憧れた業界はこんなものなのか、と。

そう思った時から、俺は現場で笑えなくなった。

同期や上司と気軽に話ができなくなった。

雑談でさえも話を続けることができない。

現場問題点だとか新しい技術だとか業界の動向だとか、話したいことはたくさんあるのに。

彼らはそんな話に見向きもしない。

元々静かな現場であった上、コミュ障気味であることも災いし、その結果会社で話せる人はほとんどいなくなった。

雑談でもいいから話せなかった俺も悪い。だが今更何かを話にいく気にもなれない。

明日の飯を食うだけのために、1ヶ月、あるいは1年、もしくはそれ以上かかるようなつまらない仕事でも淡々とこなす。

そういう生き方も決して間違ってはいないとは思う。

生きていく上でのれっきとした一手段だとは思う。

だが俺はそんな生き方をしたいと思わない。

そんなことをするために俺はこの業界就職したわけじゃない。

だが、現場ではどれだけ訴えても理解してはくれなかった。

俺は今、先行きに不安を感じすぎて俺自身が潰れそうになっている。

会社で居場所がないように感じている。

転職すればいいのかもしれないが、第二新卒枠がまだなんとか使えるとはいえ、今の実力でどこまで通用するのかわからない。

世間じゃ会社入ってから辛くても3年はやってみろ、と言う。

1年ちょっと会社を辞めてしまう奴などクズだと見られるだろう。

その上就活もうまくいっていたほうではなかったから、その時の思いが蘇り、踏み出すこともできない。

それに、今まで養ってくれた親を心配させるわけにもいかない。

八方塞がり。

きっとこの業界自殺を考える奴の心境ってこんな感じなのかと、今日も1人日陰者としてExcel方眼紙の画面を睨み、与えられた作業を淡々とこなす。

そしてExcel方眼紙の先には果たして何が待っているのだろうかと、希望情熱燃え尽きたまま思索にふける。

2010-07-09

ビジネスロジックをストアードプロシージャで実装してはいけない

ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジッククライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。

ストアードプロシージャと単体テストは食い合わせが悪い

RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語デバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語記述した場合よりもはるかに時間がかかる。

また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。

さらに、カバレッジツールは大抵の場合使えないだろう。

ストアードプロシージャは、たいていの場合、静的解析が行えない

ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。

ストアードプロシージャは、バージョン管理されたコードとの整合性に問題がある

仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイル管理し、それをバージョン管理システムに含めたとしても(というか、最低そうすべきなんだが)、あるリビジョンコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。

ではトリガーはどうなのだ

リガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。

さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。

では一体いつストアードプログラムを使うのか

一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合

もう一つは、複数クライアント言語で同一データベースを使用することが決定済みな場合

2008-10-05

社内オープンソースプロジェクトについて(まとまらない版)

うまくやる方法を考えてみた。

っつうか、社内オープンソースってのが既に矛盾か・・・

目的

社内でオープンソースプロジェクトを行うことにより以下の4つの価値を生み出すことができる。

 1.部門間におけるノウハウの共有

 2.外部に公開した場合の宣伝効果

 3.新製品新サービス実験の場

 4.仕事そのものを作る効果

 (4補足)

   ・新入社員研修などが発生した場合に効果的に仕事を割り当てることができる。

   ・在宅勤務をせざる得ない状況における作業の割り当て。

    

【前提】

基本的に下記の事項を前提として考察を行う。

 1.社内の人間であれば、誰でも参加できる。

 2.途中で各人の任意のタイミングで抜けても、問題とならない。

 3.社内の人間であれば、だれでもアクセス可能なWebサーバー上で情報を管理する。

  ただし、必要に応じてアクセス制限をかけることができる。

  インターネット接続されている、Webサーバー存在しているものとする。

 4.各開発者は場所的、時間的に同じところにいないことを前提とする。

Webサーバーが用意すべき機能】

以上の前提より、下記の機能を有したWebサーバーの準備を行う。

1.構成管理機能

 簡単にソースコードの取得、更新を行えるようにして、その履歴を残す。

 案:Subversion

2.Wiki

 マニュアル、方針、仕様などを記録する。

 Wikiにすることにより、誰でも編集が容易になる。

 案:Trac/Redmine/Pukiwiki

3.フォーラム

 意見や質問を容易におこなえる掲示板を用意する。

 これにより、場所と時間にとらわれずに意見交換を行うことができる。

 案:Wiki/Redmine

4.タスク管理、バグ管理

 どのようなバグタスクが残っているか管理を行う。

 これにより、リリース時期の予測、作業の有無を効果的に確認できる。

 案:Trac/Redmine/BugZila

5.テスト管理

 テスト仕様テストの状況を管理する。

 これにより、リモート環境であってもリアルタイムテストの進捗状況を確認できる。

 案:TestLink

6.コードレビューサポート

 ReviewBoardの使用

 http://blog.monospace.jp/2008/03/24/reviewboard_installation/

 (※要調査)

7.フィードバックを受ける場

 関係者モチベーションを保つため、成果物に対して、フィードバックを受ける場を作成する。

 案:社内のソーシャルブックマークアンケート機能

【効果的な手法】

その他、効果的な開発の進め方を考察する。

1.xUnit使用

 xUnitテストコード記述することにより以下の効果がある。

 ・修正後でも修正前と同じ動作するかどうかが、確認できる。

 ・テストコード自体が一種のリファレンスになる。

 これにより、人の作成したコードでも修正を行いやすくなり、前提1、2の人の出入りに対応する。

2.自動ビルド

 自動ビルドを定期的に実行する。また、1のxUnit使用して単体テストの失敗も監視する。

 これにより、サーバー上にコンパイルが通らないソースコード単体テストに失敗したコード存在をチェックすることができる。

 これは不特定の人間がかかわった場合に異常を検知するためである。

3.短期的なリリース

 開発者モチベーションを保つため、一定のめどがついた時点でα版という形でリリースを行う。

 

だめだまとまらん。

 
ログイン ユーザー登録
ようこそ ゲスト さん