자의적으로 frame 기반으로 요청주신 것을 autolayout으로 처리했다. 모르면 좀더 정확하게 물어보는 습관을 가지자. 왜 굳이 autolayout으로 하는지..? 한번만 더 물어보면 한번에 일할 수 있다.
블로그 글을 더 많이 못썼다. 아무래도 글 하나 쓰는데 자료조사가 많아서 그런 듯하다.
트위터에 글을 많이 공유하지 못했다. 아침에 조금 귀찮더라도 올리는 습관을 가지자.
저녁에 더 자주 샐러드를 먹지 못했다.
옷을 사는데 자꾸 잘못된 사이즈를 산다. 왜지?
키보드 싸게 사겠다고 중고로 샀다가 키보드가 3개가 되었다. 그냥 처음부터 회사에서 새걸로 살걸. 때로는 새거사는게 좋을 수도 있다.
Learns
강제 크래시내고 싶은 경우: indexOutOfRange, divisionByZero
Autolayout이 무조건 적으로 좋은 것은 아니다. computed cost가 들어가기 때문에 frame기반으로 처리하는 것이 더 좋을 수 있다.
Clean code를 보면서 인수 관련해서 인수가 적을 수록 좋다했는데, 함수형 프로그래밍과 약간은 상충되는 내용이 있는 것 같아 질문했다. 내 생각대로 상태값을 최대한 없애는 방식으로 가는 것이 테스트나 유지보수에 있어 보다 좋다는 결론이 났다. 인수가 여러개라면 따로 struct를 만든다던지, 함수를 쪼개서 처리하는 방식을 만드는 것이 보다 좋겠다.
Exception의 경우 case로 나누지말고 subclassing을 통해 처리하자.
factory로 다형성을 관리할 수 있다.
addSubview시 [view1, view2].forEach { self.view.addSubview($0)와 같은 방식으로 처리할 수도 있다.