「可読性」 vs 「設計思想」 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
・可読性と設計思想はしばしば対立する。
・設計思想はもちろん重要で、変更修正の行いやすさとか
定番パターンを導入して綿密に考えられたシステムを構築できる。
・しかし、その実装コードは、その思想を本当に理解していない人が見ると
何でこう書いてあるのか意図が読み取りにくい不可解なものになるかもしれない。
・人間の目に一度に入る情報は空間的な限界があり、
「隣り合って配置されているもの空間的に近いもの同士が関連度が高い」
と直感するし、
・コードに使われている「単語」について「自然言語としての意味の先入観」
を持っているので、「見慣れない単語」が使われると困惑する。
・設計思想の中には、これらの直感に反して、ある1つのものを空間的に
バラバラに配置したり、「抽象概念」を表す単語を使わなければならない
場合が多々ある。
・もし、これらが原因設計思想を「間違って解釈」して実装してしまった場合、
目も当てられない状況になり、実装者は「設計を理解していない」し、
・設計者側も実装コードををみて「何がしたいのか」が分からない。
・「可読性」だけを重視して実装する人は、設計思想を無視して暴走して
しまうかもしれないし、
・「設計思想」だけを重視している人は、周囲の人間を置き去りにして
しまうかもしれないし、「実際に出来てしまったモノ」に対して
柔軟に受け入れたり、その実装状態を分析することが出来ないかもしれない。
・この問題に対して、落とし所を発見していく必要があると思う。 >>4
是非、どうすれば両立できるか教えてください。
>>2
設計書にも必ず「解釈の違い」が出て来る。
設計書のボリュームが肥大化することもあり、
バタバタと付け焼き刃で改定される場合もあり、その場合はなおさら。
>>3
すまん。 >>5
だから設計書書かないって思想がウンコじゃん
解釈の違いってそれレアケースだろ
レアケースを基準に持ってきて全体を回すっておかしいだろ？
レアケースなら個別対応をするべきだ 要求と設計思想はしばしば相反する
改訂と設計思想はたびたび相反する
工数と設計思想はむなしく相反する >>6
ああ、たしかにそのとおりだ
レアケースに注目しすぎるからそうなるんだろうな
設計書を書くときはレアケースは気にしすぎないほうが
いいのかもしれない。
あと、俺は設計書要らないなんて言っていない。 設計思想って具体的にどういうものをいってるのか例を上げてよ
詳細設計書を書くやつとコード書くやつを別人にしてて
そいつらの距離が遠いから発生してる問題のような気もするな Lispがシンプルな設計になっている
代わりに読みづらいみたいなことだな イマドキの可読性高いって小学生にも読めるくらい簡単って意味で使われてないか？
思想を理解できる教養のある奴に読んでもらえよ 設計思想をソースコードの形で記述できる言語がほしい。
機械解釈できないコメントはなるべく減らせ >>8
レアケースこそ項目用意して詳細に書けよｗ
ルールに沿ってる項目なんてルール説明して表に載せときゃいいじゃねぇか 設計にも色々有るけど、ディレクトリ構造も
設計の一つなんだよな。
そのディレクトリ構造に入れるクラスはどんな種類か
ってのも決まってくる
そういうことをソースコードで書いて
コンパイル時に検証したい 設計思想に誤りがある時点で、要求を満たしてねーからな。 設計の意図のことを設計思想と呼んでるんだな
設計思想というと設計哲学みたいなもう少し抽象度の高い話だと思ってたわ 物事を分離する粒度が細かすぎないか
迷うことはある。 デザインパターン、オブジェクト指向などを覚えたてで使って見たい人は、特に若い人は、それが良い設計に思えてしまう罠に掛かる。
典型的な例が、アジャイルで言う「やり過ぎたコード」だと思う。
可読性と言うよりは、設計の基本が理解できていない状態だ。 設計の基本は常に、
モジュール凝集度は高く、
モジュール結合度は下げる
事にある。
ダメな例の典型は規模によって凝集度が変わる事を理解出来ていない事だ。
例えばjavaの１クラス、１ファイルの思想があるとする。この状況でステートパターン等で１ステート毎にクラス分けしたとする。
仮に３０ステートあり、各クラス内部のソースコード（例えば1,000行）が密接に連携し、逆にクラス間の結合度は低く、クラス毎に担当者を分けて並行して実装出来る状況であれば、これは素晴らしい設計だ。
しかし１ステートが実質１０行ぐらいしか無ければどうだろう。コンストラクタやお決まりの定形処理に引きずられて、全体で見ると、１ファイル３００行にまとめた時より凝集度は下がるだろう。
定形処理を変更しなくてはならない場合、規模が小さいと相対的に変更量が増えるため凝集度が下がるのだ。 多分、これを可読性と言っていると理解したが、基本、なぜその設計をしなくてはならないのか？ どう言うメリットがあり、どの規模や状況なら、そのメリットがデメリットを上回るのか？を常に考えないと、その設計思想は良い設計なのかの判断はつかないだろう。
良い設計思想＝良い設計 では無い。 >>19
>例えばjavaの１クラス、１ファイルの思想があるとする
それは設計思想じゃなくて単なる慣習
Convention over Configurationとかが設計思想
設計思想は設計時に発生するトレードオフに対する判断基準となるもの Java言語を作った人たちが考えた設計思想かな。
convention over configrationsは初めて知った。が、内容見ても話しが噛み合わない。
＞設計思想は設計時に発生するトレードオフに対する判断基準となるもの
→ほんとにそうなの？ >>22
最近はconvention over configurationsやたらと目にするけど、本当に初めて？ 初めて。
やっぱり、1が書いている以下の文からして、何でも新しい単語を覚えると、それだけが絶対に素晴らしいって勘違いするタイプだよな。
〉・設計思想の中には、これらの直感に反して、ある1つのものを空間的に
バラバラに配置したり、「抽象概念」を表す単語を使わなければならない
場合が多々ある。
多々あるから、状況に合わせて、様々な人が考えた設計思想でも何でも良いから、その中から最適なものを選んで、時には自分で作り出す事を設計って言うんだよな。
バラバラに配置して分かりにくい単語使った挙句に、あんまりメリット無かったら単なるクソ設計何だよな。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
6DEWX ■ このスレッドは過去ログ倉庫に格納されています
