第8回：おんなじやるんやったらちゃんとやろうや(下)
「PH1-ProⅡ」の回路ブロックの一部。色の違いがサ ブブロックの領域を表している。赤い点線で示した上 部の紫色，オレンジ色，薄水色の領域がミッキーマウ スのシルエットに似ていなくもない。 PH1-ProⅡ の開発が正念場を迎えるのは，ここから先だった。ソフトウエアのバグが一向に減らなかったのである。BDレコーダーの量産を予定する2007年9月まで半年を切っていた。 ソフトのバグが終息しない 限られた時間の中でマイクロコードからアプリケーション・ソフトまで，すべての要素を並行開発する必要があった。マイクロコードを部分的に動かすと，すぐにデバイス・ドライバを積み上げ，デバイス・ドライバがある程度動くと，アプリケーション・ソフトを開発した。このため，アプリケーション層で問題が見つかると，その原因がどこにあるのか見極めが付かない。こうしたトラブルが多発し，進捗の足を引っ張っていた。 そこで楠見
RoRのmigrationで思ったこと - masayang's diary
最近、それなりに本格的なシステムをRailsで開発しているのだけど、ActiveRecord::Migrationに衝撃を受けた。これはすごい。 昔話 20年ほど前、ソフトウェア開発の生産性が目に見えて向上した時期がある。ここで話しているのはビジネスソフトウェアのことね。 自分が入社した87年は、こんな感じで開発する文化がまだ残っていた。おそらく最後の頃だと思うけど。 ロジックの設計をするSEがいる それをもとにコードを「紙に手書きする」プログラマがいる。専用の用紙があったのだ。 その紙を元にコードを入力するコーダ→コードは80桁のカードに入力 プログラマはカードの束をカードリーダに突っ込む バッチ処理でコンパイルされて、結果がリストに出力される コンパイルが通らない場合はプログラマが原因を突き止めて、修正したコード入力をコーダに依頼する 以下繰り返し[*1] 要するにプログラマはコーダへ
改善と改革 - masayang's diary
ソフトウェア開発プロセス改善。 言葉の響きは良いが、自分はこの手の活動が大嫌い。新人の頃から何回この手の活動があったろう。そして現実は、改善活動の都度、仕事はつらくなっていくのであった。会議が増えたり、作業工程が増えたり、報告資料が増えたり。映画Office Spaceの「テスト手順書には表紙をつけること」みたいな話はシャレじゃなくて現実なのだ。 分業制度が抱える根本的問題 20年前の話にも書いたけど、昔はプログラマとコーダが別だった。プログラマはコーダに指示書を書き、コーダはその指示書に従ってコードを入力する。出来上がったコードはフロッピーではなく、カードに打ち込まれる。 [*1] そのカードを計算機センターの読み取り機にかけて、コンパイルジョブが走る。結果は紙のリストに出力され、それがプログラマに返される。 指示した仕事の結果を検証できるのは数時間先だ。つまり、指示に間違いがあるとそれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
