読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

Joel on Software

Joel on Softwareを読み終えました。
なかなか面白かったです。
印象に残った項目を挙げてみます(数字は章番号です)。

8 仕様書は可笑しくすべし

退屈な仕様書は読んでもらえないので、ちょっとふざけた感じのユースケースシナリオにした方が良いとの意見です。
実際にできるかどうかはさておき、確かにそういう仕様書もいいかもしれません。

17 検索は多くの件数を集めるのではなく、ユーザーが欲しい順に並べることが重要

Googleがそれを実践したと言われて納得。
単純に日付順とかID順でソートしがちですが、意識を改める必要があるかもしれません。

23 2つ以上の作業を同時に進めると遅くなる。良いマネージャはメンバーが1つのことに集中できるよう手助けをする

これは非常に同感。
おいらも1つのことに集中したい〜!!

24 プログラムをフルスクラッチで書き直すな

どんなに汚いコードでもバグ修正されてちゃんと動いているからだそうです。
フルスクラッチで書き直すのではなく、少しずつリファクタリングしろと書いてあります。
確かにそうかもしれませんが、致命的なバグをいっぱい抱えたままのプログラムを見つけた場合は例外としても良いでしょうか?先生・・・。

25 ユーザーは開発の進捗を画面の出来具合だけで判断する

あまり実感はありませんが、ありえる話かも。
今後はちょっと気をつけてみます。

25 ユーザーはシステムを見た目で評価する

分かっていてもついつい後回しになってしまいがちですね・・・。
Apple製品が好きなら自分が作るシステムの見た目にもこだわるべきなんでしょうけど。。。

26 抽象化は作業時間の節約をするが、学ぶ時間までは節約しない

たとえばASP.NETの生産性は高いが、HTMLやHTTPの知識を完全に不要にする訳ではない、といった感じです。
確かにそうですね。どれだけ新しい技術が出てきても基礎的な勉強は不可欠です。

27 評価が測定に基づく場合、労働者は測定のために働くようになる

これはまさしくそうかも(これまでの自分を振り返って・・・)。
公平で客観的な評価って難しいですね。

31 出来の悪いプログラマを封じ込めるにはひたすらバグ修正をさせるべし

コードを書き直す誘惑にとらわれるな、とのことです。
5年ぐらい前に作られたシステムがありますが、未だにバグだらけなのでできることなら今からでもバグ修正させたい。。。(エラー発生件数は1日あたり平均約30件!!)

37 パッケージ製品の後方互換性は非常に重要

だからMicrosoftはここまで大きくなれた、と。
今まで当たり前だと思ってきましたが、パッケージ製品を作る側からすると後方互換性の維持っていうのは無くしてしまいたい面倒な仕様なんですね。


Joel on Software

Joel on Software