5월 17일부터 20일까지 오후 7시-8시 반, 4일 동안 진행하는 단기 스터디를 함께할 스터디원을 모집합니다.

주제

Building Mobile Apps at Scale을 읽고, 책에 나오는 사례를 위주로 각자의 실제 경험을 나누는 시간을 가지려고 합니다. 저자는 앱 개발을 하면서 겪을 수 있는 다양한 문제와 해결법 몇 가지를 알려주긴 하지만 너무 짧고 간단하게 설명하고 있는 부분들이 아쉬워서 스터디를 계획하게 됐습니다. 실제로 문제를 겪고 해결했던 사례를 공유하면서 더 자세히 파고 들어가보면 어떨까 합니다.

장소

온라인 화상미팅

참여 방법

요일별로 주제가 다르니 책을 읽고 나서 관심있는 주제나 관련 경험이 있는 주제에 해당하는 요일에 구글폼 제출해주시면 개별 연락드려서 참여 확정을 하겠습니다.

요일별 주제

Day 1(월요일): 앱의 특수성으로 인한 어려움 (세부 주제 및 신청 폼)
Day 2(화요일): 앱이 커지면서 발생하는 어려움 (세부 주제 및 신청 폼)
Day 3(수요일): 팀이 커지면서 발생하는 어려움 및 크로스 플랫폼 관련 (세부 주제 및 신청 폼)
Day 4(목요일): 앱을 고도화할 때 발생하는 어려움 (세부 주제 및 신청 폼)

TDD는 설계 방법론이 아니다 글을 읽고 쓴 글입니다.

TDD는 안해봤지만 1년 동안 진하게 유닛 테스트 추가하고 레거시 코드를 테스트 가능하게 리팩토링 하면서 느낀 점과 유사하다. 요약하자면

1. 테스트 가능한 코드는 강한 결합을 회피하고 의존성 역전 원칙만큼은 지키게 해준다.
2. 단일 책임 원칙과 인터페이스 분리 원칙은 알아서 챙겨야 한다.

작년에는 코드를 테스트 가능하게 만드는 것부터 시작했다. RIBs는 워낙 기본 구조가 잘게 분리되어 있고 각 요소가 단일 책임 원칙을 지키고 있어서 그에 맞춰 짜기만 해도 중요 로직은 어느정도 테스트 가능하다. MVC를 제외한 대부분의 아키텍처가 비슷할 것이다. 그래서 모바일 개발 환경에서는 아키텍처의 손이 뻗지 않은 그 외 15-20프로 정도의 코드에서만 개발자의 설계 역량이 중요한거 같다.

그런데 그 15-20프로의 코드가 매우 중요하다. 앱의 디자인이나 기능과 유사하게 코드도 템플릿화되어 쉽게 복사되고 퍼진다. 어느 정도 코드베이스가 쌓이면 완전히 새로운 설계를 하게 되는 경우는 드물고 기존에 있는 비슷한 기능을 하는 코드를 찾아 쓰게 된다. 그리고 대부분의 사람들은 기존의 코드를 손쉽게 복붙해서 가져간다.

잘못 설계된 공통 모듈이 그에 의존하고 있는 모듈 수십 개과 수십 명의 개발자에게 안 좋은 영향을 주는걸 봤고, 누군가가 집어 넣은 잘못 설계된 구조가 스멀스멀 퍼져나가는걸 목격했다. 불필요한 의존성이 덤으로 딸려오는 바람에 인터페이스 분리 원칙도 못지키게 되고 빌드 시간도 늘어난다. 또한 누군가가 만든 테스트 불가능한 구조가 다른 개발자들이 별 생각없이 가져가 쓰면서 점점 증식되기도 한다. 코드가 안좋아지는 것 뿐아니라 의미없는 코드 리뷰어가 강제되어 리뷰 받으려는 사람, 리뷰 해야하는 사람의 시간을 허비하게 만들었다.

그래서 공통 모듈을 만들거나, 새로운 구조를 도입할때는 앞으로 이 코드가 오랫동안 남아서 미칠 영향을 고려하여 특히나 책임감을 가지고 설계해야 한다. 구글은 코드 리뷰 대원칙에서 이와 같이 말한다. ‘개발자는 맡은 일을 완수하면서도 코드 품질을 개선시켜야 한다. 꾸준히 개선하지 않으면 품질은 절대 나아지지 않는다.’

This is a text written after reading about TDD is not a design methodology.

I haven’t tried TDD but it’s similar to what I felt while intensely adding unit tests and refactoring legacy codes so they’re able to undergo testing for a year.

In summary,

• Testable codes avoid strong coupling and allow for the dependency inversion principle.
• The single responsibility principle and interface segregation principle need to be taken care of on their own.

Last year, it started by making the codes testable. The basic structure of RIBs is divided into fine parts, and because each element adheres to the single responsibility principle, important logic is testable to some extent. Most architectures are similar except for the MVC. I think that’s why the developer’s design ability is important in only the 15-20% of codes that are out of the architecture in a mobile development environment.

But the 15-20% of code is very important. Similar to an app’s design or features, codes are templatized and easily replicated and spread. If there’s enough codebase, it’s rare to do a complete redesign, but you get to find an existing code that serves a similar purpose. Most people simply copy and paste the existing code.

We’ve seen a poorly designed common module having a bad effect on dozens of modules that depend on it as well as dozens of developers. We’ve also seen a poorly designed structure that was put in by someone spread out. Because an unnecessary dependency is added as a bonus, we are not able to adhere to the interface segregation principle and the build time is increased as well. Also, an untestable structure created by someone might spread due to other developers taking it and using it without much thought. Not only did the code become bad, but a meaningless code review was forced, wasting time for the code author and the reviewer.

Therefore, when creating a common module or introducing a new structure, it should be designed especially with responsibility considering its long-term effect in the future. Google says in the code review guideline, “a developer needs to improve code quality as he/she completes the given tasks. If there is no constant improvement, the quality will never improve.’