• 처음 코드를 설명 할 때 어떻게 설명하는지 생각을 해보라
    • Language / Structure 를 먼저 설명하는분들이 많음
    • 50% 정도는 클린아키텍처라는 단어로 먼저 시작함
    • 실제로 클린아키텍처를 말하는 순간 질문할 거리가 엄청나게 많아짐
    • 클린아키텍처를 옆사람에게 설명 / 신입에게 설명 해보라, 핵심은 무엇일까 ?
      • 소프트웨어를 계층으로 분리하고 종속성 규칙을 준수함으로써 본질적으로 테스트 가능한 시스템을 만들 수 있다.
      • 기반지식
        • SOLID / 아키텍처 / OOP / Domain / 최적화 / 관심사 분리 / 리팩터링 / 데이터 구조 / DDD / 모델의 이해 / ...
        • 위 개념들에 대해 다 물어볼 수 있게 됨
    • 클린아키텍처가 이론적인 것인지 / 코드화 할 수 있는것인지 확인 해보라
      • 엉클밥은 실제로 코드적으로 설명하고 있지 않음
  • MVC / MVP / MVVM / MVI
    • 어떤 것이 가장 좋을까 ? → 정답은 없고 최선만 있다
    • 자신의 성향 / 자신의 팀의 성향에 맞게 아키텍처는 변경 될 수 있으며, 변화 할 수 있음
    • 자신만의 기준이 필요하다
      • 더 많은 기능을 원해서 ? / 코드 안전성 때문에 / 유명해서 ? / 해보고싶어서 ? / 비즈니스 업무보다 우선시 되어야 하나 ?
      • 비즈니스 업무보다 이것이 중요한지는 정말 잘 생각해보라
        • 개발팀에서 사용하는 시간은 개발팀 뿐 아니라, 회사 전체적인 일이다.
  • 좋은 코드란 ?
    • 읽기 쉬운 코드 / 중복이 없는 코드 / 테스트가 없는 코드 ... 등의 가치가 있을텐데, 제일 중요한건 무엇을 핵심 가치로 둘 것인지를 정하는 것이다.
    • 코드 퀄리티 / 클린 코드 / ... 등 보다 더 중요한건 경제적 비용 ( 시간 + 돈 ... ) 이다
  • Use Idioms
    • 정말 Mutable한 변수가 활용되어야 하나 ?
    • list ( collection ) 안에 있는 API를 잘 활용하는것이 좋음
  • Start Line
    • 고쳐야 할 코드들이 많은 Sample Repo를 줄텐데, 한번 수정해보라 !
  • 리팩터링 + 약간의 오버엔지니어링 과정
    1. 먼저 실행을 해보자
      • Gradle 자체가 변경이 없었다면, 캐싱되어 빠르게 되지만, 두번 세번 빌드해도 전체 빌드가 이루어진다면 꼭 줄이도록 확인해보아야 함
      • 그래서 2번 3번 빌드해보고, build가 줄어드는지 화인을 꼭 해보심
    2. 필요없는 gradle option을 확인해보자
      • multiDex가 들어가있는지 / view, data binding 등 이 중복되어 있지는 않는지 / desugar가 필요 없는데 추가되어 있는지 / .... 등을 체크 해보라
    3. 뷰에있는 네트워크 콜 부분을 분리하라
      • viewModel / repository ... 등 활용
      • 잘 없긴 하지만, 이렇게 제출하시는분들이 생각보다 많음
    4. 데이터를 생성하거나, 하드코딩된 데이터를 생성하는것도 view 안에서 하지 마라
    5. Unit Test를 작성하라
      • 빠르게 UnitTest를 작성 할 수 있도록 뷰모델을 작성 해야만 한다.
      • 실제로 짜보라고 면접때 요청하는 경우도 잦음
      • 유닛테스트를 작성 할 수 없도록 짠다면, 리팩터링을 고려해보라
    6. import Android
    7. 즐겨찾기 등 로컬 캐싱도 뷰에 두지 마라
      • preference 등을 view에 두고 활용하는건 뷰의 관심사로부터 분리 할 필요가 있다.
      • 유닛테스트를 위해 viewModel에 context를 넘기는것 자체를 지양하는것이 좋다
    8. User event in recyclerviews
      • Adapter / Holder가 비대해 지는것을 막도록 개발하라
    9. 뷰모델에 데이터 캐싱을 하는것보다, 다른 곳으로 넘기는것도 좋다
      • 데이터 보관을 뷰모델 대신 다른곳에 맡기고 싶다면 Repository에 넘기는것이 좋다
    10. ViewModelProvidor Factory를 만들어서 활용
      • DI 라이브러리 내부에서는 내부적으로 해주고 있으나, 꼭 체크해보길 권장
    11. Inline class를 많이 활용하라
      • 실제로는 내가 쓸 컬러 값 중 하나만 받을건데, int로 타입을 두면 너무 다양한 값이 올 수 있음
      • @JVMInline으로 인라인 클래스를 활용하여 데이터를 받을 수 있음
    12. Migration wrapper data
      • list loop를 돌며 탐색 할 때, 시간 복잡도 이슈가 있을 수 있음
      • Set / List 등 데이터를 감싸고 있는 데이터구조를 잘 활용하도록
    13. Use stream
      • 데이터 추가 / 갱신을 활용하는 기능을 rx / flow 등을 활용하여 간단하게 처리 할 수 있음
    • 위의 점수가, 기본 점수 과정 !
  • 과제 제출전 Final Check
    • Exclude git history
    • Code Formatting
    • Lint
    • No Internet
    • Configuration changes
    • Contrived complexity
    • Side effects
    • Large class
    • Too many parameters
    • Long method
    • Excessively long line of code
  • 1%를 챙겨보자
    • 리팩터링 / 견고함 / 빌드개선 / 가독성 / SOLID ...