2018年03月08日 (木) いい言葉いただきました。「魔法の手順問題」■この問題に対する意見です。「おかしなことが原理的にできるようになってるのがおかしい。」「コメントやドキュメントで注意喚起をしても無駄。」「コードの表現力が足りていないのをコメントで補おうとするのが間違い。」■３番目に関しては自分もつい最近やった。それを修正したのがこちら>「コメントをスクリプト化しました。」■どこからこういう意見が出てくるかっていうと、自分が、暗黙的手順を見落とさず明示的手順を四角四面に守り潜在的な落とし穴を周到に避けるような振る舞いができないからっていうのがある。できないんですよ。ありとあらゆる落とし穴に１回以上はまらずにはいられない人間なんですよ。だから「穴があります」と看板を立てるだけでは足りない。自分は、それでは落ちてしまう。■なぜそうなのかは自分の行動指針に理由がある。つまり、禁止されていないのに最短ルートを選ばない理由がないじゃない？ 最短ルートが禁止されていても、ひょっとしたらもう事情が変わっていて問題がないかもしれないじゃない？ かくして穴にはまるまでは最短ルートに突進するんですね。２回以上はまるのは単純にアホだからです。■３ページ目の影響範囲と重複の問題について。とりあえず重複は悪という流れで例が挙がってるけど、重複を嫌うあまり似てる部分を手当たり次第に関数化して共有することからも影響範囲の問題が出てくると思う。ある部分ある機能の変更が、影響してほしくない別の機能に影響してしまう、共有コードのせいで。■どんなガイドラインであっても、それが有用であっても、根本を理解しないで機械的に当てはめるだけではひどい結果を導きうるのだよね。クラス化関数化の目安とか途中return禁止とか、目的はわかるし過去にどういう失敗があったか想像もできるけど、ありとあらゆるガイドラインが乱用の結果悪に転ぶ。過去に引用した>「“一般的なSI現場”の定義...(略)...それなりのフレームワークを使用し、規約やレビューで、極端にひどいコードが生まれないように統制するものの、それを突破する規格外のポンコツが必ずいる」 「突破する」というのは必ずしも「守れない」「無視する」ことと同じではないだろう。馬鹿正直に遵守することによっても馬鹿をやらかすことができる。■コールグラフで見つけられる方が問題は少ないのかな>コピペコードといきすぎた共有。■普通に書かれてた>「コードが予想もつかない場所で使いまわされていて、テスト範囲が膨大になる(駄目なDRY)」 やっぱりそういうのあるよね。
ツッコミを入れる
