マストドンの設計が汚いという意見について

Question

デザインパターンを勉強中です。
2chの「今から学ぶならRubyとPythonどっちが良い？」というスレッドにてマストドンの設計が汚いという意見がありました。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
44 名無しのプログラマー 2017年05月03日 03:06 ID:bEURKOnF0
マストドンがきっかけでますますRubyが嫌いになった
正確にはRoRだけど
matzの作った美しい言語にクソ塗りたくった外人はしね

45 名無しのプログラマー 2017年05月03日 03:45 ID:anhuMTus0
まぁたしかにマストドンの設計は汚い
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
1.具体的にはどのようなところが汚いのか？

2.ではどのように設計すればよかったのか？

初心者なもので分かりやすく説明していただけると助かります。
（そもそも初心者が突っ込むレベルではないのでしょうか）
ちょっと気になったもので、よろしくお願い致します

Answer 1

マストドンでなく一般的な話をしますと、汚いソースというのは美しくないソースのことです。
美しいソースというのは、読みやすく保守し易いソースのことです。

読みやすく美しいソースは次のようなものです。

・モジュール化が進んでいる

何もかも同じところでゴチャゴチャやっていたり、形だけ分割されていてもオブジェクトの互いの依存度が高過ぎて一つ修正すると全てに影響が出たり、スコープが適切に設定されていなくてグローバル変数を多用していたり、一般化されていなくて再利用性が低かったり、そう言うのは汚いソースです。
美しいソースは明確な機能を持って独立した小さな部品から構成されています。

・命名が適切でコメントがしっかりしている

各々の部品は中を全部読まなくても何をするものかわかるのが美しいソースです。

・呼び出し制限が少ない

例えば配列やリストは範囲外のインデックスでアクセスすると例外を出したり配列内に無い特別なデータを返したりしますが、これは読む人にとって理解し易く意図が明確です。
しかし、例えばあるオブジェクトに依存しているのにそのオブジェクトを引数に取らないなど、ソース全体を見なければ呼び出し条件がわからないものがあります。
こういうのは汚いソースです。

・一カ所で定義できるものは一カ所で定義されている

同じことをするメソッドや同じ意味の文字列が複数定義されていると、一カ所直してももう一カ所が直っていなくて不具合が発生しまます。
文字列は可能な限りリソースにして後から読み込むか、マクロ定義し、数値は列挙体を使って適切に命名するようにします。

・標準的な手法を使っている

無意味に特殊な手法を使うと、そこにバグが入る可能性も増えますし、読む人の負担にもなります。
特別な事情のない限り、標準的な手法を使うべきです。

・ループを使える時はループを使っている

各条件に if を羅列するのでなく、可能な限り同一手続きで扱えるよう工夫したデータをループで処理します。

これらに気をつけた美しいソースを見慣れていると、そうでないソースは汚く見えます。

初心者のうちは美しかろうが汚かろうがどっちにしろ読みにくいかもしれません。
すると、説明されてもどうしてそれが汚いのかわかりにくいでしょう。

美しく書くにはどうするのかを心がけると、美しいものが美しく見えてくるのではないかと思います。

Comments

[grilled_python]

分かりやすい説明ありがとうございました。またこのサイトの趣旨である具体的な課題が記入されていない質問だったというご指摘を受けましたのでお詫び致します。今後利用する際には気をつけたいと思います。