tokuhirom's Blog

ともかく再現可能なテストケースをかく

再現可能なテストケースを書けば、コミュニケーションコストを大幅に削減することが可能。これは日本人同士の場合でもそうだし、プログラマにとっては必須の技能の一つであるから、是非身につけて実践するべき。

マルチスレッドに起因するものなど、再現可能なテストコードがかきづらいものはともかく、それ以外であれば、再現テストコードを書くべき。

再現テストコードを書けない場合、そもそも自分がバグの原因を把握できていない場合がおおいので、そんな状況でなれていない言語によるコミュニケーションをとるのは困難。

誤り訂正符号をいれる

多少の文法、英語の誤りをいれても文意がとれるように、冗長な表現をつかうことにより誤解を防ぐライフハック。

(チャットでやりとりする場合は)顔文字を多用する

:P :D :(

あたりを使いわけるだけでだいぶ円滑にコミュニケーションをとれる。気がする。

英語の誤りを指摘されても凹まない

「こちとら日本語が不自由な人のためにあわせてやってんだ」ぐらいに気を大きくもって、相対すると気が楽。

'a' をいれちゃいけないところで 'a' をつけたりすると "Syntax Error" っていってきたりする人もいるけど、あまり気にしすぎてはいけない。

pull request を活用する

bug report あげるより、github の pull request をつかう方が楽。再現テストコードとパッチをコミットし、コミットログに「なぜこの変更が必要か」をかき、pull request にコミットログまんまはっつけておくればいい。

issue tracker よりも気楽にできるとおもう。

Conclusion

再現テストがあるバグレポートは基本的に無視されることはないので、気楽にやればいいとおもう。

あと、英語ができるにこしたことはない。