ウホーイが気になったところ

[uhooi]

ウホーイが気になったところを書いていきます！

[uhooi]

正直テストがあるだけで、「少なくともテストが書きやすい設計になってるんだな」とわかるので、それだけでも書くべきです！ 逆にテストを書かずに良い設計で実装できる人すごいと思います…

[sachiko-kame]

DispatchQueue.main.async はViewでやればいいと思います！ https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Presenter.swift#L46

viewの処理開始一番最初に書くか、実際に描画している所で書くかの違いなのですかね？

はい！ 描画の直前に書くと、そのメソッドを呼ぶたびに書かなくて済むので👍 あとは好みかもしれませんが、描画しないPresenterにこの処理があると違和感を感じます。

非同期の後に処理が遅くなるということでここに入れているのかな？と思いました。 正直今回の場合描画が遅いとかはなさそうなので『DispatchQueue.main.async』を書く必要がないのかもしれないと今更ながらに思ったりもしました。 非同期の中で描画が遅い時に出すでもいいのかとも思いました、、、

いや、そもそもiOSはメインスレッドでしかUIを更新できないので、データを非同期で取得するなら必須です！ 試しに外してデバックすると、紫のアイコンで警告が出ますよ〜

確かに処理2回も書くのナンセンスですよね！ 具体的に教えて頂いたのでとてもスッキリしました！ ありがとうございます！

[sachiko-kame]

https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L17

入れざるを得なかったという感じでした汗 cell内のボタンタップ時に値を送りたくて、、、 modelの方で変えるように実装した方がいいですかね？ すごく悩みます汗

タップしたセルのインデックスをキーに、Qiitaのリストから取得するようにすれば持つ必要がなくなる気がします！ 手を動かさないとわからないので、できなかったらすみません💦

cell内では今の所自分の力ではわからなかったのでmodel内で値変更を行うようにしました！ cellのボタンタップ　→　modelのisReadボタンを逆にして登録 という感じです。

[sachiko-kame]

ここでcellに分岐が入るのが気になります。 setRead() と setUnread() とセットのメソッドを2つ作って呼び分けると分岐をなくせます！ https://github.com/sachiko-kame/architecture_iOS/blob/feature/MVP/sample/sample/Parts/Cell/TableViewCell.swift#L38

確かにそうですよね。viewの方で分岐する方が良いって感じですかね？ viewでの分岐ではアイテムが『あり』『なし』で行っていたのでcellのセットならコードもそんなに多くないしとつい入れてしまいました。

分岐はできる限り親側（うまく言えない…呼び出し元側、ですかね）で行う派です〜 今回は呼び出し元がViewなのでテストしにくいですが、テストしやすくなることが多いので！

ありがとうございます！ 具体的に『〇〇だから〇〇が良い』と言ってもらえると納得します！ 修正します！

指摘されて書いて見たら案外スッキリして、あ、今までの自分は簡単な方にと怠惰だっただけだったことがわかりました。

[sachiko-kame]

正直テストがあるだけで、「少なくともテストが書きやすい設計になってるんだな」とわかるので、それだけでも書くべきです！ 逆にテストを書かずに良い設計で実装できる人すごいと思います…

そうですよね、お恥ずかしながらテスト自体をしっかり理解していないので勉強します！ すぐには出来ませんがより良いコードを書けるようになるために頑張っていきたいと思います！ なかなかこんなに丁寧に指摘して頂けることはなかったので本当に感謝です！ 自分は凄い優しい方に恵まれたなと強く感じました！ 本当にありがとうございました！ また修正確認後コミットしたいと思います！✨

[uhooi]

なんか楽しくなってきたので、自分でも手元でリファクタリングしてますー笑 ただ完全に自分の好みで失礼なレベルでガンガン書き換えているので、PR出すか迷います…

[sachiko-kame]

なんか楽しくなってきたので、自分でも手元でリファクタリングしてますー笑

そう言ってもらえると嬉しいです！時間を奪っちゃっているような気がして感謝と一緒に罪悪感もあったので、、

ただ完全に自分の好みで失礼なレベルでガンガン書き換えているので、PR出すか迷います…

意見を聞けるのなら聞きたい願望です。なのでもしよければお願いしたいです！！

[uhooi]

自分が勝手にやってるので罪悪感は持たないでくださいｗ そしたら完成したら上げますね！

[sachiko-kame]

ありがとうございます！！✨

[uhooi]

超ウホーイの好みにリファクタリングしてみました笑https://github.com/uhooi/architecture_iOS/tree/feature/fix_mvp/sample/sample

diffが出過ぎると思うので、Xcodeを2つ起動してソースを見比べるといいかもしれませんｗ あくまで参考で、間違っていることもあると思うので鵜呑みにしないでください〜

[uhooi]

気になったらここでもTwitterでもどこでもいいので、何でも聞いてください〜✨

[sachiko-kame]

超ウホーイの好みにリファクタリングしてみました笑https://github.com/uhooi/architecture_iOS/tree/feature/fix_mvp/sample/sample

diffが出過ぎると思うので、Xcodeを2つ起動してソースを見比べるといいかもしれませんｗ あくまで参考で、間違っていることもあると思うので鵜呑みにしないでください〜

ありがとうございます！！🙇‍♀️ 色々見比べたりして勉強させていただきたいともいます！！

[sachiko-kame]

気になったらここでもTwitterでもどこでもいいので、何でも聞いてください〜✨

嬉しいです！ 設計強い方が側にいるの心強いです！！ 本当にありがとうございます！✨✨✨✨✨

[uhooi]

設計強いかはわかりません笑 実はそんなに実務経験がないので、他で通用するのかわかんないんですよね…

[sachiko-kame]

強いと思います！ 理由がはっきりしているので通用すると思っています。 難しいとすぐ簡単な方に逃げてしまう私とは大違いで反省しています！ ウホーイさんを見習って勉強に励んでいきたいと思います！！✨

[uhooi]

ありがとうございますｗ 簡単な方に逃げる考えは間違っていないと思います！ 逃げ方ですよねｗ

[uhooi]

あ、 setRead() は get○○() と同様の理由でよくないです！ read というプロパティにセットするセッターに見えるので、 setupForRead() のようにするといいです！

[sachiko-kame]

あ、 setRead() は get○○() と同様の理由でよくないです！ read というプロパティにセットするセッターに見えるので、 setupForRead() のようにするといいです！

ありがとうございます！ 修正します！✨

ありがとうございますｗ 簡単な方に逃げる考えは間違っていないと思います！ 逃げ方ですよねｗ

ありがとうございます！ うまく出来るよう試行錯誤重ねていきたいと思います！✨

[uhooi]

あと if isRead == true {} は if isRead {} のように書くのが好みです。 前者は isRead が Bool? 型の場合に使うと、オプショナルかどうかがすぐにわかって可読性が上がります！ （ Bool? 型は if isRead {} と書くとビルドエラーになる）

[sachiko-kame]

あと if isRead == true {} は if isRead {} のように書くのが好みです。 前者は isRead が Bool? 型の場合に使うと、オプショナルかどうかがすぐにわかって可読性が上がります！ （ Bool? 型は if isRead {} と書くとビルドエラーになる）

確かにです！！ そう言った見方までできていなかったので非常にためになります！ ありがとうございます！✨