成長の場を求めないソフトウェアエンジニア？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
業務を通した学習の落とし穴: 柴田 芳樹 (Yoshiki Shibata)
拙著『プログラマー現役続行』では、「業務を通した学習の落とし穴」（110頁）として次のように述べています。 新たな技術を習得するのに最も効率的な方法は、業務で使用している技術について学習することです。業務で使用していますので、すぐに業務に役立ちますし、多くの時間その技術に接しているため、効果的に学習することができます。 業務を通じての知識の蓄積は効果的なのですが、落とし穴もあります。それは、業務をこなすのに最低限必要な事柄だけしか学ばないで終わってしまうことです。業務で使用する技術が自分にとって初めての場合に、その技術を学習方法には、大きく次のどちらかのパターンに分かれるのではないかと思います(極端な分類ですが）。 初心者本を買ってきて、それを読んで、あとは、詳細を理解することなく、他人のコードをコピー＆ペーストしてソフトウェア開発を行う。 その技術のバイブルとなるような書籍を探して、それ
防御的プログラミングとカバレッジ: 柴田 芳樹 (Yoshiki Shibata)
防御的プログラミングでは、外部からの呼び出しから防御します。しかし、それ以外に、自分自身の誤りに対して防御するということがあります。 次のコードは、『Effective Java 第2版』（p.147）に掲載されているコードです。// 値によって切り替えるenum 型- 問題が多い public enum Operation { PLUS, MINUS, TIMES, DIVIDE; // 定数で表される算術操作を行う double apply(double x, double y) { switch(this) { case PLUS: return x + y; case MINUS: return x - y; case TIMES: return x * y; case DIVIDE: return x / y; } throw new AssertionError("Unknow
防御的プログラミング: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェア開発でのデバッグ効率を左右する要因は多くあります。長年、様々なソフトウェア開発を行い、デバッグに苦労していると、デバッグ効率を向上させるためどのようなことを行うと良いかを考えたり、書籍を通してヒントを得たりして、色々と工夫をするようになります。 デバッグ効率を向上させる方法の1つとして、防御的プログラミングがあります。防御的プログラミングでは、たとえば、メソッドのパラメータが正しい値であるかをきちんと検査して、不正であれば、例外をスローするということがあります。あるいは、switch文のdefaultラベルでは必ずAssertionErrorをスローするとかも一種の誤った設計に対する防御的プログラミングです。もちろん、呼ばれた側の設計上のバグであれば、それを検出してもAssertionErrorをスローしたりすると思います。これは、自分の想定している設計以外の状況が発生したらそ
防御的プログラミングとテスト駆動開発: 柴田 芳樹 (Yoshiki Shibata)
1978年に大学でプログラミングを学び始めてから1990年代まで、私自身は防御的プログラミングを行ったことはほとんどありませんでした。また、ソフトウェアのテストと言えば、手作業でテストするのが普通の時代でした。それは、私一人が防御的プログラミングをしていないとか、私だけがテストを手作業で行っているとかではなく、それまで属した開発組織がすべてそうでした。 2000年になり、コンサルタントとして設計レビューやコードレビューを行ってきたソフトウェア開発組織に対しては、徹底的に防御的プログラミングを指導してきました。防御的プログラミングを行うことは、トータルで開発コストを下げる活動です。 パラメータの値を検査するコードを書き加えるのは、ほんの数分のプログラミングで済みます。しかし、防御的プログラミングを一切行っていないモジュールを結合して、発生した不具合の原因を調べるのは、数分では終わりません。数
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
