【開発】An efficient programming!

小野和俊のブログ：プログラマーの開発速度は「はまる」時間の長さで決まる
http://blog.livedoor.jp/lalha/archives/50261226.html

このブログを書かれている小野氏は、開発速度が早いプログラマの特徴として以下のことを述べられてます。
　「はまる」時間が極端に短い

自分は普段はいい調子ですが、一度嵌ると悶々としているタイプでありんす。（;´-ω-）
調子いいときは工数の半分以下で終わらせちゃうんですが、嵌った時は期限いっぱい、ぎりぎりになっちゃいます。
開発速度のムラがありすぎて線表にリスク乗っけられることが多(ry

というのは置いておきまして、氏は開発速度が遅くなる原因は以下の6つだと述べられています。
1. クラスやメソッドの命名が不適切
2. 「とりあえず」書いたコードが悪さをしている
3. 「このままでは何かがおかしい」と感じながら作業を続けている
4. ツールに振り回されている
5. 「よくあるつくり」に対する理解が乏しい
6. クラスライブラリの存在を認知できていない

1については、たくさんの『良い』コード、しかも英語で書かれたコードを読んで命名則を見つけるってのが一番効率が良いのではないかと思います。
5についても同様のことが言えますね。これもどれだけ良いコードを見たかに尽きるかと。
Code Projectだったり、オープンソースのコミュニティ参加は最高のカンフル剤になりそうです（´ω｀）

2については・・・あ〜これ結構あるな〜
大抵コメントに"TODO： とりあえず動く 後で考える"みたいに書いておいたりしますｗｗ
使用が限定的な処理についてはあまり問題になることはないですが、いろんな処理とからむ部分だと、なんとなく追加したコードのせいで動かなくなるといったことがありました。
これについては、

• 単体テストを徹底する
• 処理間の依存を無くす設計にする（オブジェクト指向あたり参照）

ことで対処できるかと思います。

3、目的の明確化が必要ですね
本当にそれは必要なのか？本当にその対応でいいのか？と疑問に思うことが必要です。
自分これ苦手っす（´･ω･｀）
や、一応良い方法ってのを常に模索するようにしてはいますが、難しく考えすぎてあさっての方向に突っ走ってしまいます。orz
元の処理の方がいいやん！な状況に陥ることはしばしばです。
逆に時間かかって工数無駄にするなんて言語道断ですね。学習しよう俺。

4、これに関しては小野氏の指摘に同意しています。
主にVisual stdioやEclipseなどの開発用IDEアプリケーションを使ってる人にはありがちなのですが、影響範囲を絞らないうちからデバッガを起動させるのはかなり時間がもったいないです。
もちろん、実際にデバッグしないと問題が解決しないケースはあるのですが、それよりもどのあたりが問題の主原因なのかを割り出してから動かしたほうが効率よく開発できます。
まったく関係のない処理までデバッグしてると時間の無駄ですよ！（｀･ω･´）

6については・・・勉強しましょうとしかいえないですな〜
全てとは言いませんが、現在使われている開発言語というものは、かな〜り似ています。
一つの言語だけ極めても、全ての言語が使えるというわけではないですが、2つ、3つと覚えていくうちに使える言語の幅も劇的に増えていきます。
個人的には、C、C#（Java）、Perl(PHP、Ruby、Python)あたりをマスターするとほとんどの言語で開発できると考えています。
（Cobol？うーん・・・これはどうだろう・・・ある分野に特化した言語をマスターしてもそれしかできない気がするので、必要に応じて覚えるのがいいんじゃねーかい）

ここまでいろいろと偉そうに能書き垂れてまいりましたが、自分もまだ勉強中の身です。
常日頃、頭の片隅にしっかりとメモして、精進していきますお

Code Complete第2版〈上〉—完全なプログラミングを目指して
日経BPソフトプレス
スティーブ マコネル

ユーザレビュー:
プログラマになるつも ...
初心者にかなり評判が ...
入門書でありながら奥 ...


Amazonアソシエイト by ウェブリブログ