開発生産性の観点から考える自動テスト(2024/06版) / Automated Test Knowledge from Savanna 202406 Findy dev-prod-con edition
開発生産性の観点から考える自動テスト(2024/06版) / Automated Test Knowledge from Savanna 202406 Findy dev-prod-con edition
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に(長期的にみて)効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く