かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
MVVMパターンのViewModelで、INotifyPropertyChangedをいちいち実装すんのかったるい。かといって、AbstractなViewModelBaseは継承したくないでござるよ。 - Bug Catharsis
INotifyPropertyChanged インターフェースを実装した抽象クラス ViewModelBase は、残念な俺俺設計MVVMパターンでViewModelを実装する場合、INotifyPropertyChanged インターフェースを実装するのが面倒という理由もあって、 INotifyPropertyChanged インターフェースを実装した抽象クラス「 ViewModelBase 」を用意したりすることが、 世の中的に割と定番となっているような雰囲気がありますが、これはお世辞にもあまりよい設計とは言えないと思う。 確かに、ViewModel は INotifyPropertyChanged インターフェイスを実装したものかもしれないが、 これは実装を簡略化することだけを目的とした俺俺設計にすぎないからです。 抽象クラスはインターフェイスよりも抽象的な表現力が低いということMV
XPもいいけれど、先ずはSQLが出来るようになるべき。:なにわのITベンチャー社長Blog - CNET Japan
hisyamadaより: XPの導入をしようとした私はすぐに大きな壁に突き当たりました。それは「全員同席」と「ペアプログラミング」でした。全員同席とはユーザ、マネージャ、開発者が一箇所で開発を行うという考え方で、システム開発のスピードを加速させ、利害関係の不和を解消するために考え出された手法です。特筆すべきは顧客と開発者を同席させると言うもので、開発過程で明らかになる不明瞭な要求や仕様を、同席している顧客に即決させる［続きを読む］ XPもよいと思うのですけれど、弊社はＳＱＬにこだわっています。 一般的にＤＢ（ＳＱＬ）のスキルがなさすぎなんですね。 弊社の入社試験の変形型で説明します。 使われるテーブルは 得意先マスタ 得意先コード 得意先名 住所 ・・・ 受注テーブル 受注ＩＤ 受注日 得意先コード ・・・ 受注明細テーブル
テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
