プログラミングの生産性を上げるには - 聞かれてもいないことを喋る
Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで
テストを書きましょう、という話はもっともだと思うのだけど - 聞かれてもいないことを喋る
テストを書きましょう、という話はもっともだと思うのだけど、テストを書けばバグのないリリースができるかといえばそんなことはない。テストで保証できるのは、自分が認識している仕様が正しく満たされていることであって、逆にいうと自分の想定から漏れているものは網から外れる。ここからバグが生まれる。 テストの不足によるバグと考慮漏れによるバグは自分の感覚では2:8くらいな気がする。テスト戦略にまつわる議論がここまでされるのだから、考慮漏れをいかになくすかという議論は、もう少しされても良いのかなぁという気がした。 今パッと思いつく限りで考慮漏れを根絶する方法をリストアップしてみる。 検証項目を脳内に持たずどこかに書き出し、それを誰かにレビューしてもらう。 毎度イチから検証項目を考えるのでなく、共通する検証項目はどこかに書き残しておき、それをベースに作成する。 動作チェックを第三者にやってもらう。 …ああそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
