消耗せずに「良いコード」とはなにかを考える

次の記事が最近公開されたので、読んでみました。 結論としては、例えば同著者の「良いコード／悪いコードで学ぶ設計入門」という書籍と比較すると、だいぶ受け入れやすい主張になっていると感じました。（以前の書籍についてのコメント記事へのリンク） ところで、私は「良いコード」についての議論や指摘や検討を積極的にやったほうがよいと思っていますが、主に「消耗しない」という観点でこの記事についていくつかの構造理解やテクニックの部分で補足できそうだったので、以下補足していきます。 ざっくりとした主張でいうと、 トレードオフに見える部分は学習・教育で解決できるケースも多くある 品質特性への還元が難しいがコードの良し悪しを定める概念がある Webアプリにおいても再利用性は必要だし、モバイルアプリでも再利用性を求めて失敗することがある 再利用性というよりは、現実に即した概念の線をどこで引くかのバランスを大事にする

[strawberryhunter]

私は再利用性はほとんど考えないことにしている。3回くらい同じようなコードが出てきてから考えればいいことなので。

[hogeaegxa]

元記事でも触れてる、SOLID原則みたいな古典を単に学んで実践してれば、そんな酷いもんにはならんだろうとは思う。現実の酷いコードは「メソッドとか関数って、自分でも定義できるの知ってる？」ってレベルだし

[turanukimaru]

元記事の再利用は別システムで再利用する汎用的なものを指すがこちらでは同じあるいは連携してるシステムで再利用することを考えてるので多分再利用の意味が違う。私はこちら側で元記事の人は趣味が合わないんだよな

[ku__ra__ge]

DRYは同じコードじゃなく、同じ知識を繰り返し書くなという話なので、真にそれを守るにはドメイン知識が必要。

[baronhorse]

うまい指摘だなー。経験の裏付けのない設計論をどう扱うかみたいな話は大事だよ。

[pmint]

良い実装は設計通りの実装。コード内の矛盾と同様に、メンバー間の矛盾にも気を払う。汎用の原理原則よりも、身近な設計に従うほうが確かな指標になる。異論があるなら、実装以前の工程で出さないと手遅れ。

[hdampty7]

積み木で例えると▲を詰んだらそれ以上は何も詰めない。次の改修は▲を取っ払う作業＋本修正となる。ここで多くの場合計画が狂う。エンジニア以外は▲分は既に前回作ったので差分だけが今回コストと思うので

[toyama_gf]

ISO25010ソフトウエア品質特性における再利用性の定義は「別システムに再利用可能か」みたいですね。（どうして移植性ではなく保守性の副特性なのか謎…モジュール性とセットだから？同一システム内も十分条件だから？

[ymchng]

いやもう他人と開発している限り消耗はどうやってもするのよ……他人の書くプログラ厶をコントロールしようなんておこがましいとは思わんかね。

[soybeancucumber]

消耗している時点でいろいろ直すべきポイントが他に多々ありそう

[lycolia]

良いコードを浸透させるまでに発生する障害をまとめた資料。

[hatest]

悪いコードでないものが良いコード（消耗しない考え方）