ShareXのソースを眺める⑥（おわり）～適当リファクタ～

１週間がんばったせいか

①https://blog.hatena.ne.jp/couraeg/couraeg.hatenablog.com/edit?entry=26006613447498044
②https://blog.hatena.ne.jp/couraeg/couraeg.hatenablog.com/edit?entry=26006613447550453
③https://blog.hatena.ne.jp/couraeg/couraeg.hatenablog.com/edit?entry=26006613448560237
④https://blog.hatena.ne.jp/couraeg/couraeg.hatenablog.com/edit?entry=26006613450041829
⑤https://blog.hatena.ne.jp/couraeg/couraeg.hatenablog.com/edit?entry=26006613450405332

感想

ステップ数の極端に短いソースはやっぱり見やすいし、テストも書きやすいな。

　やはり人のコード読むのは参考になる。
　今回読み込んだ個所はpublic祭りで、setterにもまみれてた.
　それでも少なくともクラス内においては何がやりたいのかはっきりしていたように思える。
　1メソッドに１役割。というかまぁ、凶悪に意識してもいいと思えた。
　反対に、スコープは後回しでもいいのかもしれない。特に個人で開発する場合においては。
　（開発者のレベルのバラバラな場合、スコープ押さえないとすぐ暴れるけど）

テスト書くの面倒。が、しかし・・・

　テストから書き始めるにしても、後からテストを書くにしても、
　それ相応にじっくりコードをみて、設計を読み込む必要があった。
　テストがない。ということはその分のステップが省かれていることになる（あるいは別のレビューでやっているかもだが）ので、
　設計的に劣るだろうな。
　

テストの派生。というか、スコープのコントロール

　保護がどうのこうの。っていうより、テストを書きやすいように。という指標も、
　やみくもに「可読性」がどうのこうの言うよりわかりやすい指標のように思えた。
　ただ、テストのために公開範囲が広がったり、そういったところは内容にしないとねぁ
　ほな、なんでもかんでもpublicじゃーわっしょーい。はどうなの・・・という。めちゃくちゃテスト書くのは楽だったけど。
　難しいなぁ。隠蔽。だれが何を知ってなくちゃいけない。ということを設計しないとなぁ。

つぎはPythonであさる。