プログラマーは自分のコードを疑え - 南極の図書館
若い頃にはよく陥る過ちだと思う。 最近やってしまったので自戒エントリ。 1.テストでバグ発見。 2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。 3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。 4.読み辛いながらも、そのメソッドのバグを探す。 5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。） 6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論） この歳になってこれはないよ。。。 でも「今更やってしまった」と実感できたのは良かった。 今後、バグを見つけたら、自分のコードを徹底的に疑う。 以下余談。 テストのコストが高いのがネックだと感じる。 数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを
今春“プロ”グラマーになる人が、あと1週間で学ぶ３つのこと（＋１） - 南極の図書館
元記事はこちら。 今春“プロ”グラマーになる人が、あと1週間ですべき7のこと | Act as Professional - hiroki.jp by HIROCASTER シリーズ化？ 今春サーバを触っていくのにびくびくしてる人が1週間ですべき7のこと - カイワレの大冒険 今春“組み込み”プロ”グラマーになる人が、あと1週間とはいわないけどこれからやってほしい7のこと - what you see is what you get 元記事はターゲットが広すぎたからか、対象を指定したエントリが書かれている。 私はもう一度、対象を広く戻して、自分なりのエントリとしてまとめてみた。 と、いうのも。 元記事は少なくとも「新卒」が一週間で準備すべきことには当てはまらない。 「新卒プログラマーがこの１年で意識すること（マスターすること）」という趣旨なら十分納得できるのだが。 見出し ・プログラミング
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
