  |
開発効率性を重要視するか、モジュールとしての錬度を重要視するのか、それが問題だ。ここで一つの提案をする。
開発途上において、どの変数を private にすべきで、どの変数に getter が必要で、どの変数に setter が必要で、
どの関数を private にすべきなのかを悩んでいては、本当に重要なところ、つまりアルゴリズムに時間をかけられない。
まずは、アジャイルプロトタイピングをするのだ。その時にカプセル化に頭を悩ますのは良い方法ではない。
コードでやることが決まった後、それをモジュール、ライブラリとして完成度をあげるリファクタリングの段階で、
カプセル化、クラス、関数名、関数の再利用性について頭を悩ますのが効率が良い。
ただし、イケプログラマに限る。
ダメプログラマにやらせると、アジャイルプロトタイピングの段階で、全ての処理が１つの関数に書いてあるなどということになりうる。
類似の処理がほぼコピペということになりうる。リファクタリングの作業が、もはやリファクタリングではなく、リストラクチューリングになりうる。
完璧超人ならば、どういう手順で仕上げてもいいよね。 優秀な奴がうらやましいぜ。
モジュール錬度と開発効率性ってそれほど相反するとも思えない。 よくできたモジュールにしておくと保守偏向や再利用もしやすく効率は上がるはず。 あと企業として集団で開発すると...
池プログラマと同レベルでの保守は池プログラマが居ないと無理だろうけど どんなコードが書かれているとしても、そのときその場に居るプログラマのレベルで保守が行われるんじゃな...
保守できるかできないかの二つしかないわけじゃなくて保守のしやすさにも段階はある。 コード規約というのはプログラムの内容というよりは書き方のルール。 スキルが高ければどんな...
うん、それはそう思う でも、言ってるのは、高スキルな人の書くプログラムで読みにくいのって パラノイア的な物くらいじゃないかね？ マルチスレッドで多重継承で実行時型参照とかや...
なんか誤解してそうだが、オーソドックスなコード規約で誰も従わないようなむちゃくちゃな規則なんかないぞ。DQN社員ばかりなら従わない人続出するから知れないけど。
や、だから、スキルが高くなくてもちゃんと出来る様なオーソドックスなコード規約って何よ？ マルチスレッドにして、スレッド間連携入れて、実行時に型参照して、型によって実行コ...
いやそういうアルゴリズムの話じゃなくてどういう書き方にするかのルールがよくある規約だから。再帰関数多重継承禁止とかやるところもあるけど。
そ〓、だから、スキルの断絶を埋めれる様な規約は無理なんじゃないかね？と 再帰や多重継承を禁止の規約とか、トリッキーなコード量産して欲しいんですか？って感じだし それぞれ使...
スキルの断絶といっても大きさに違いはあるわけでアセンブラレベルでまったく同じコードでも書き方によって読みやすさは違ってくる。読みやすさが違うと当然ケアレスミスの頻度も違...
>よくできたモジュールにしておくと保守偏向や再利用もしやすく効率は上がるはず。 だからそれは後でちゃんとリファクタリングすると言っている。 >コード規約に従っておくのが...
11
