会社組織

■「キミのコードが汚い理由」という記事に例示された「クリーンな」コードが汚い件
http://d.hatena.ne.jp/haruyutaka/20070115/p2
正直、上記で書かれている事は一切分からないが、
プログラムは組む手間よりも、バグを見つけたり、修正したり、プログラムの意味を他人に分かるよう仕様書を書いたりする方が、手間が掛かると聞いた。プログラマーのモチベーションも、自分のやり方で自分の好きにプログラムを組む時は高いが、他人の論理で書かれた他人のプログラムを読んでデバッグして、仕様書を作るときは低いと聞く。
会社でプログラムを作るときは、プログラマー歴二・三年の新人プログラマーの技術に合わせて作る。大人数でチェックや修正や仕様書や説明書を作れるようにするには高度な技術を使い過ぎないことが大事だという。プログラムの性能よりも、プログラマー間の汎用性の方が大事なのだと思う。その意味で高度な技術・論理構造が使われ過ぎているエレガントなコードよりも、汚いコードの例として出されたシンプルなコードの方が会社において重宝される。
http://d.hatena.ne.jp/haruyutaka/20070109/p1
深いなと思う。