最終的には学習スピードの速さとパターン認識能力の鋭さか！？
http://q.hatena.ne.jp/1171726729
http://b.hatena.ne.jp/entry/http://q.hatena.ne.jp/1171726729
より
多数気付いた事、思い出した事があります。
id:taninsw氏のコメント
やはり英語が鬼門だ。日本語と同じ速度で読めるようになりたい
これからこの日記でいつものように歎いている事*1
英語の読解力のスピードアップ
はやっぱり必要ですね。
id:adamrocker氏のコメント
結局同じことを二度やらない人ではないか？
から気付いた事
昔GPLやLGPL、BSD LicenseやMIT/X Licenseの法的解釈に苦労した覚えがある。
ライセンスが理解できないばかりに既存の便利なライブラリを使わず１から資料を集めて組みなおしたと言う事がある。
大変な時には一つのモジュールに１−２ヶ月かけることもざらだった。
だが、そのおかげでコーディングに関するバッドノウハウや既存のコーディングに関する問題点を見抜く事が出来たのだが･･･
確か、昔、ライブラリ製作とソフトウェアの生産性は反比例するかも〜みたいなジレンマを書いた覚えが･･･
http://d.hatena.ne.jp/studiokingyo/20061224
http://d.hatena.ne.jp/studiokingyo/20040617
よって、「オープンソースのライセンスに関する正しい理解」というのも必要だと感じます。
他には
- 状態数をなるべくなくす事（テスト効率UP＋パフォーマンスUP を狙うため）
- エラーハンドリングを完全に行う（プログラムの安全性に関する事 エラーしたのに実行されてしまったのではユーザーが迷惑するだけでなくセキュリティーホールの元になる事もありますし）
と言った事でしょうか。
C/C++でライブラリをフルスクラッチする時のバッドノウハウ
- C言語だろうがアセンブリだろうがの時はオブジェクト指向で
- 言語の可読性を下げない（C言語で#defineマクロを使って新しい命令を作って可読性を下げるとか MFCのフローが良く分からなくて可読性が良くなかったのはこのせい。 だけど、そのおかげで生産性は良くなっているはずなのだが･･･この兼ね合いが難しい。）
- 可読性を挙げるためならためらわずgoto
関連
http://q.hatena.ne.jp/1142519342#a503284
思い出したらこのエントリーに追記します。
