タグ

2011年1月23日のブックマーク (9件)

  • 「それ、どうやってテストするの?」(続) - masayang's diary

    http://d.hatena.ne.jp/JavaBlack/20070808/p1 ほとんどのまともなプログラマーなら,無意識のうちにそういうテスト可能/デバッグ可能なコードを書くことを心がけている.テスト/デバッグ不可能なコードを書く人というのは,まともなプログラマとは思えない. JavaBlackさんは「自分で何を作るか考えてコードを書く人」について語っているとみた。完成像を理解しているプログラマなら、「コードのあるべき姿」もわかっているからテスト機械化のハードルも低いだろう。 問題なのは下記のような分業状況。 何を作るかは考えるけどコードは書かない人(別名:設計担当) 何を作るか考えることは許されず、言われたとおりにコードを書く人(別名:開発担当) 設計担当はコードを書くことはない。書くのは設計書なる文書だけ。「その設計書、どうやってテストするの?」と聞いてみるがよい。答えに窮す

    「それ、どうやってテストするの?」(続) - masayang's diary
  • 細かいところまで指定する設計書は実在する。 - プログラマーm-matsuokaの生存記録

    http://d.hatena.ne.jp/masayang/20070808/1186636298 「設計書」を書く人はコードの細かいところまでは考えていないから 詳細設計書と称して、日語で1行ずつ処理を記述して、その1行ごとに対応するようにソースを書かせる。 で、その詳細設計書とソースを1行ずつ照らし合わせて、詳細設計書のとおりにソースが書かれていないと作り直しさせられる。という地獄のようなプロジェクトがありました。 詳細設計書で処理が100行で記述してあれば、ソースも100行でなくては駄目だという…。複数の詳細設計書に同一の10数行程度のチェック処理がコピペで書いてあれば、ソースにも同じチェック処理がコピペで並ぶ。 プロジェクトの統率者がホストあがりで、ホスト開発で実行していた開発手順をStrutsでのWEBアプリ開発に無理矢理当てはめた結果らしい。 新卒という未経験者を3ヶ月の研

  • ■ -  ( ・ω・)ノ<しすてむ開発。

    「誰が書いても同じコード」は大事なことなのか http://d.hatena.ne.jp/higayasuo/20080325/1206421786 言葉だけの意味ならボクは「大事なことだ」と答える。 大手SIerにそれが実現できないのは方法がマズイから。 そこで出てきたのが、「誰が書いても同じコード」になることが重要で、 それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。 大手SIerは、大体同じことを考えていると思います。 見てきた中でこれ同意。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。 だからこれも同意。 「設計」の範囲がどーのこーのと論議のタネになることは多いけれど、 プログラム作り大好きニンゲンの1人として言えることがある。 (,,゚Д゚)<ドキュメントで何とかしようとしているのはみんな要求定義の一部だ。 システム開発

    ■ -  ( ・ω・)ノ<しすてむ開発。
    sinsengumi-2
    sinsengumi-2 2011/01/23
    システム開発の真っ当な進行に必要不可欠なのは技術力を伴った技術者であり、プログラム大好きニンゲン達である。
  • 仕様書やプログラムを書く大変さ - GeekFactory

    大御所のブログを引用するのはおそれ多いのですが、それでも元請けの視点で書きたいことがあります。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 http://d.hatena.ne.jp/higayasuo/20080414/1208155494 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラムをいきなりかけ

    仕様書やプログラムを書く大変さ - GeekFactory
  • その「プログラム設計書」が何を指してるのかわからないから土壇場で混乱する - @katzchang.contexts

    仕様書やプログラムを書く大変さ - GeekFactory http://d.hatena.ne.jp/oredoco/20080415/1208222548 プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - yvsu pron. yas 上の方々の記事を読んで、その「プログラム設計書」って何なんだろうと思ったわけで…。 例えば、契約が「プログラム設計書一式によりプログラムを製造する」みたいなのだとしますよね。 でも、そのプログラム設計書はクラス図+シーケンス図みたいなものなのか、一つのまとまった処理…バッチ処理とかユーザイベントとかgetリクエストとかの入力に対するDBとか画面への出力を示したものなのか、内部変数とか内部ループのブレイク条件とかも示したものなのか、よくわからない*1。だから、受け取る段階になって混乱する。よくある話じゃないですか。 正直なところ、

    その「プログラム設計書」が何を指してるのかわからないから土壇場で混乱する - @katzchang.contexts
  • http://japan.internet.com/developer/20060523/25.html

  • 女性写真素材のビジンソザイ

    肌のトラブルを気にする SHIKI 肌のトラブルを気にする NIKA クリーム、ジェルでスキンケアする ANNA クリーム、ジェルでスキンケアする NIKA クリーム、ジェルでスキンケアする SARAH

  • CSVファイルが好きな人たち - torutkのブログ

    プログラム間でのファイルのやり取りや、人間系で作成したデータをプログラムに読み込ませるとき、仕事上でよくCSVファイルにしようとする人に直面します。(というか、CSVファイル以外を採用する人にあうことは稀) CSVファイルというだけでは、ファイルフォーマットを決めたことにはならず、プログラムで扱えるようにするには、いくつも決めなければいけないことがあります。 文字コード 改行コード 文字列をダブルクォートで囲むか否か 文字列中にダブルクォートおよび改行が含まれる場合の扱い 数値の表現方法(符号、小数点形式) 日時の表現方法 そもそもCSV形式といっても明確な仕様は存在してなく、数年前にRFC 4180でCSV形式について文書が出されている程度です(なぜかRFCなんだろうか?という疑問が生じますが)。 でも、このような決め事をせずに作ってしまい、あとでいろいろ問題が発生するというアンチパター

    CSVファイルが好きな人たち - torutkのブログ
  • Javadocにクラス図 - torutkのブログ

    一昨日、id:torutk:20110119で、Javadocにシーケンス図を埋め込む方法を書きましたが、次はクラス図を埋め込みたくなります。 ということで、まずは調査フェーズから。 Javadocにクラス図を埋め込むツールを探す UMLGraph(BSDライセンス) APIviz(LGPL) UMLGraph http://www.umlgraph.org/ 定番と言えるツールで、あちこちで言及されています。 万人のためのオートメーション: プッシュボタンによるドキュメント作成 http://java.dzone.com/articles/reverse-engineer-source-code-u?page=1 日語が化ける問題があって回避方法の言及が以下URLにあります。 http://blog.livedoor.jp/fitskater/archives/20231.html