あーるPG - 社会人のデジタル生活

日曜プログラマになろうかなーと思った30代理系社会人の、キャリアアップや趣味(特にデジタル情報)の記録。らーめんとビールが好き。

Joel on Software(1)


かつてMicrosoftExcel VBAを作ったっぽい人のブログをまとめた本です。
内容が多岐にわたり豊富で、ドキュメント書きの手習いからウィットに富んだ記述をしていていかにもアメリカン・・・いや、楽しく読めます。ざっくりとまとめます。


・ジョエルテスト
ソフト開発会社が真っ当かどうかを判断する指針を簡単化したものです。
1.ソース管理しているか
2.ワンステップでビルドできるか
3.デイリービルドしているか
4.バグデータベースはあるか
5.新しいコードを書く前にバグFixしているか
6.適宜リスケジューリングされるか
7.仕様書はあるか
8.プログラマは静かな環境で作業しているか
9.手に入る最高のツールを使っているか?
10.テスタは居るか?
11.採用面接時にコードを書かせているか
12.ユーザビリティテストをしているか
1〜5はコーディング環境の条件、6〜7、10はその他部門の条件、あとはその他という感じです。日本でも少なくとも1〜6と10ぐらいは全うしたいですね。


高級言語について
新しい言語はプログラミング、コーディングの手間を軽減するように作られるが、応用的な使用時や不具合対応ではハードウェアレベルの知識が必要となります。開発時にどの言語を選択すれば良いか議論になることがあるかもしれませんが、シンタックスの差などどうとでもなるものです。UIやインストール時間、実行速度などユーザビリティに注目したほうが懸命です。
同じように、ネットワークストレージを抽象化してローカルと同じように使えるようにしたとしても、それにはネットワークの切断や遅延などの問題が発生します。ネットワークを介していることを気にせず使用することは不可能です。


仕様書を用意しろ
まず機能仕様書を作るべきです。ここでいう機能仕様書とは要件定義〜外部設計レベルのものです。机上、つまり機能仕様書レベルでテスト、デバッグするのはコードについてのそれよりも何倍も楽だからです。ソースが引き継がれるなら尚更です。他人のソース(≒2ヶ月前の自分のソース)を読むのは困難です。また、ユーザーヘルプを書く人がコーダ自身しか居なくなります。自分でヘルプを書くつもりならいいですが。また、ちゃんと更新しましょう。
作成時は身近な例を多く含め、面白くしましょう。記述のフォーマットを作成するのは冗長化や平凡化の原因となるのでオススメしません。


・コーダとプログラムマネージャの関係
仕様書を書くのはプログラムマネージャで、その人はコーダとは別です。ただ、プログラムマネージャの配下にコーダを配置するのはコーダが仕様を差し戻しできなくなるので止めましょう。
#これはスクラムっぽいですね。
コーダとプログラムマネージャは別の能力が必要なので相互にランクアップするのは上手くいきません。また、営業は大口を叩いたり顧客に取り入るのが仕事なのでプログラムマネージャには向きません。・スケジューリング
MS Projectとか専用ソフトがありますけど、Excelがオススメです。何故ならExcelチームがExcelでスケジュール管理するために機能を追加しているからです。タスク項目は単純化し、自分で日々更新しましょう。PMにスケジューリングさせてもいいですが、正確な見積もりが出来るのは本人です。


デバッグ
バグを発見するための環境を十分に用意するべきです。例えばコアダンプをネット経由で送信する、E-Mailで楽に問い合わせ可能にするなどです。
また、バグを含んで発売するコスト、バグを修正するメリットを数値化すると良いです。1日のバグFixを惜しんで回収騒ぎになったり、問い合わせが1日1件きたりするようでは結果的に損になります。


・ゲームの特殊性ゲームの場合はリリースが一回限りです。Officeはオンラインアップデートやメジャーバージョンアップのチャンスがありますし、洗剤は消費者の反応や社会的背景を基にバージョンアップすればシェアを伸ばすことができますが、ゲームの場合はそうではありません。


(続く)

Joel on Software

Joel on Software

広告を非表示にする