TOEICで125点しかとれないような人でもできる英文バグレポートの方法。 - tokuhirom's blog
または、Pros と Cons をまちがえて書いてしまうような人でもできる英文バグレポートの方法。 まあ小手先のノウハウだけど、俺はこうやってるよ、という話。 ともかく再現可能なテストケースをかく再現可能なテストケースを書けば、コミュニケーションコストを大幅に削減することが可能。これは日本人同士の場合でもそうだし、プログラマにとっては必須の技能の一つであるから、是非身につけて実践するべき。 マルチスレッドに起因するものなど、再現可能なテストコードがかきづらいものはともかく、それ以外であれば、再現テストコードを書くべき。 再現テストコードを書けない場合、そもそも自分がバグの原因を把握できていない場合がおおいので、そんな状況でなれていない言語によるコミュニケーションをとるのは困難。
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
