kuniku’s diary

はてなダイアリーから移行(旧 d.hatena.ne.jp/kuniku/)、表示がおかしな箇所はコメントをお願いします。記載されている内容は日付およびバージョンに注意してください。直近1年以上前は古い情報の可能性が高くなります。

プログラミングばか じゃないけど・・・

また、ホワイトボードで開発者とやり取りしながら素早くシステムを作りたいというので、プログラミングファースト開発の話をしたら、非常に乗り気でぜひやってみたいとのことです。



というわけで、私と一緒にプログラミングファースト開発をやりたい方を募集します。私も4割くらいは、そのプロジェクトに参加する予定です。


フレームワークは、SAStrutsS2JDBCJavaでいかに素早くシステムを構築するかという先進的な試みになるはず。

「プログラミングばか」募集

こうゆうの興味あるな〜。参戦するにも頭の固い私には難しいね。
難しい前に面接で落ちるっちゅーの。

自分が今までやってきた開発の多くは、(実装する際に)詳細設計ってものはない。
注)実装後もドキュメントがない場合もある。

  • 詳細設計を記述するほど余裕がない
  • 詳細設計が納品物じゃない
  • 詳細設計をしても、要件や仕様が変わる
  • (まともな)詳細設計の書き方知らねー。処理フローや処理順程度しか書けない。

基本設計みたいなもの(お客さんがイメージするhtmlや画面)があって
そこから、やりたいこと(表示したい情報や技術的に可能なのか)がお客さんとの話しで決まり、
実装側はイメージを膨らませて実装する。そんなものが多かった。

ある意味一部分だけ
「プログラミングファースト開発」だったのかも。
でも、ただ仕様を先延ばしにしただけじゃん? とも思える。

詳細設計ではないけど、場合によっては、後付けのドキュメントを書いてた。
(半年後、数年後にやってくるであろう改良に備えるためのドキュメントが多かったけど)

例えば、
・プログラム内で生成するXMLの要素は・・・・とか、 XMLのタグの説明とか。
・外部Webサービスとの連携に関する際のパラメータ仕様やエラーが発生した場合にどうするとか。
・リリース用とテスト用の設定ファイルに関するreadme.txtみたいなものとか。
・プログラムを動作させる際の設定に関するものとか。
・テンプレートファイルやiniファイルに関することとか。

でも、後付けのドキュメントって開発者によるドキュメントで、実装した側の視点で書いてるから、他の人から見ると(レビューしてないから)「ん??」「はぁ?」というのがあったりする。



今までのダメな(自分にとってよろしくない)開発

  • 何人かによる開発をあまり経験したことがない。
  • 何人かでやったこともあったけど、お互いを意識して開発したことがにゃい。

そのためか、プログラミング(javaを使った場合も、そうでない場合も)やってて自分のコードや発想が正解なのかがわからない。
 正解:ここでいう正解は、動けばよいというものでない

  • 別のやり方があるのでは?
  • この書き方よいの?
  • こうゆう書き方のがよいのでは?
  • どうゆう書き方(やり方)がよいのかわかっていない

という問題(疑問)がある。一般的にいうソースレビューというやつをほとんどしてきていない。
業務(仕事)でソースを書いてもテスト止まり。
そのテストも、最近では単体テストのコードを書いたりするけど、その単体テストのコードが十分満たしているのかは、自分だけの世界だし。
会社でやるのは、テストクラス書かないものが多いし。自分としては積極的にテストクラス書くようにしてるんだけどね。

そんなためか、現状の打破のためか、最近(ここ1年くらい)になって

なんてことを始めた。

でも、まだ知識が追いついてないというか スーパープログラマの人の足下にも及ばぬ。
もっと頭使って、手動かさなくちゃ。