벌써 본 캠프 들어온지 2주차가 끝났다. 시간은 정말 잘 가는데 문제는 쉬는 시간도 정말 짧게 느껴져서 주말이 불타는 느낌이 드는 건 아직 어색하다.

오늘은 마지막으로 팀원 분들의 과제 마무리 과정에서 짚어줄 수 있는 부분들을 최대한 차근차근 짚어봤고 맨 처음에는 코드 짜는 법 자체를 모르셨으니 아바타처럼 원격 코딩의 느낌이 좀 있었지만 날이 지날수록 기본 틀을 짜시고 문법을 이해하는 과정을 어려워 하시는 거라서 나도 퀴즈를 내고 예상 결과를 여쭤보면서 이해를 최대한 끌어내는 방법을 쓰게 됐다. (다만 시간은 이게 더 오래 걸리긴 한다.)

어쨌든 다들 할 수 있는 만큼만 마무리 하셨고 모르는 코드는 최소화하고 로직적인 부분에서 막히신 부분들을 피드백 받으시면 분명 더 발전하실 수 있을 것 같다.

과제 Readme 작성하기

과제를 Github 레포 주소만 딸랑 제출하는 방식이라서 Readme 얘기를 여러번 하신게 복선이었구나 생각하며 부랴부랴 과제의 Readme를 작성하기 시작했다.

실무할 때 Readme를 착실히 작성해본 적은 없고 최근 Velog 에서 TIL 작성할 때나 열심히 쓰고 있었어가지고 과제의 Readme를 충실히 내용 채우는 건 사실 좀 생소했다.
(앱 개발 당시는 그냥 아주 간단한 개요만 작성했다.)

매니저님이 어제 여러 예시를 보여주기도 하셨고 사실 잘 짜여진 틀을 대충 복사해와도 되는 거라서 처음엔 내가 잘 써먹던 iOS, Android 라이브러리를 찾아봤는데 예쁜 건 둘째치고 계산기 과제에 적용할 내용이 그닥 많진 않았다.

그래서 Collapse 로 코드 블록들을 숨기고 인용문이랑 목차로 조금씩만 정리하고 과제의 레벨별로 다르게 짠 핵심 코드만 정리를 해서 제출을 했다.

전혀 예뻐보이진 않는게 문제인데 꾸미기 자체는 영 젬병인 데다가 예쁜 헤더 이미지 생성기도 굳이 이미지가 들어갈만한 레포가 아니라고 생각이 들어서 안 썼더니 좀 칙칙하긴 했다.

이것도 그나마 IntelliJ Plugin으로 Markdown이 프리뷰까지 해서 잘 지원되니까 한 거지 직접 짰으면 엉망이었을 것 같다.

과제 제출하고 해설과 비교해보기

제출 마감이 되자마자 튜터님의 시선에서 생각한 과제의 해설을 줌으로 같이 작성해보는 시간을 가졌는데 들어보면서 내가 귀찮다고 넘긴 부분이나 새로 배운 부분들을 정리하기로 했다.

1. 팀에서 리뷰할 때 설명할 거리가 늘어나고 화면공유할 때 귀찮아서 패키지 관리도 안했고 클래스 파일 분리도 안했는데 튜터님은 Lv1, Lv2 처럼 패키지를 짜고 클래스도 분리해서 맛깔나게 해설해주셨다.
2. 예외 처리중 Divine by zero는 수학적 오류니까 ArithmeticException 를 사용하셨다. (나는 그냥 Exception 이나 IllegalArgumentException을 썼다.)

• 연산자가 잘못 들어온 에러엔 RuntimeException을 사용하셨다.

3. 클래스의 기능 분리를 2명이 하는 연극에서 3명이 연극하면서 부담을 줄인다고 표현하셨는데 좋은 비유같다.
4. 유지보수중 기능의 의존성 설명에서 함수의 변경을 What 과 How 를 키워드로 표현해주셨는데 분리의 설명에 덧붙이기 좋은 비유같다.
5. 협력에서 요청을 보내는 쪽의 객체는 Client 객체라고 부르면 된다.
6. 대충 이름만 알던 의존성 역전의 법칙 을 좀 구체적으로 알았다.
   6-1. 이미 Interface로 잘 써먹던 구조의 명칭이 의존성 역전의 법칙(DIP) 인줄은 몰랐다.
7. it 은 item이었다.

아무래도 용어를 정확히 설명하지 못하는 나로서는 비유로만 커버치려는 경우가 많았는데 키워드를 명확하게 설명해주셔서 재밌는 강의가 됐다.

---

갑자기 KPT 회고

강의를 듣고 응용하는 개인 프로젝트 기간이었고 팀은 있었지만 팀 프로젝트가 아니라서 KPT 회고를 하라는 말씀은 이번 주엔 딱히 없으셨지만 우리 조는 돈독하기도 했고 항상 뭐라도 같이 해보려는 시도라도 했으니 KPT를 또 해봤다.

물론 팀 프로젝트가 아니니 많이 적을 건 아니었지만 쏠쏠하게라도 다들 자기 경험을 얘기하셨다.

• K
  • 쉬는 시간을 학교 시간표처럼 중간에 10분씩 가져가는 건 아주 효율적이었다.
    저번 주 대비 바뀐 내용중 가장 효과적이었고 멘탈 관리에도 좋았던 것 같다.
  • 개인 과제라도 진척도 공유를 하는 건 꽤 고무되는 일이었다.
    여기엔 추가로 팀 내 분위기가 좋다는 게 크게 작용한 것 같다.
    분위기가 좋지 않았으면 공유 시간은 피하고 싶은 시간으로 다가왔을 것이다.
  • 무의미한 내용을 얘기하던 데일리 스크럼과 회고 시간이 알차졌다.
    이전에 스크럼 하실 때는 같은 내용을 4번 얘기하셨다고 하신다.

• P

  • 과제를 코드 공유해서 다 같이 보긴 하는데 코드 리딩이 안되는 단계라서 사실 몰입이 안된다.
  • 인터넷 강의라서 집중을 유지하기가 힘들긴 하다.

• T

  • 말이 코드 리뷰지 거의 1:1로 답을 찾아나가는 튜터와의 페어프로그래밍에 가까우니 선택적 참여를 하는 게 효율적일 것 같다.
  • 필기를 하며 듣거나 바로 응용을 해보는 등 강의를 끝까지 보기 전에도 계속 액션을 해줘야 집중이 잘 된다.

뭔가 내용들은 인강을 수강하는 스터디 모임에서 나올 것 같은 내용이지만 그래도 우리 팀의 일주일이 녹아든 경험을 공유하는 시간이었고 사실 재밌는 수다가 훨씬 많았지만 내일배움캠프 시간 자체가 피하고 싶은 시간이 아니라 이렇게 수다떨며 재밌는 거리가 있다는 점이 차라리 더 나을 것 같다.

---

코드카타 - 프로그래머스 문자열 내 마음대로 정렬하기

문자열로 구성된 리스트 strings와, 정수 n이 주어졌을 때, 각 문자열의 인덱스 n번째 글자를 기준으로 오름차순 정렬하려 합니다. 예를 들어 strings가 ["sun", "bed", "car"]이고 n이 1이면 각 단어의 인덱스 1의 문자 "u", "e", "a"로 strings를 정렬합니다.

문제 링크

fun solution(strings: Array<String>, n: Int): Array<String> = strings.toList().sortedWith( 
        compareBy<String> {
            it[n]
        }.thenBy {
            it
        }
    ).toTypedArray()

안그래도 제출 날이라 조금 신경쓸 게 많아서 바빴는데 다행히도 알기 쉬운 문제가 나와서 푸는게 어렵진 않았다.

처음에는 strings.sorted().sortBy 형태였는데 안써보던 것중 sortedWith 생각이 나서 이번에는 sortedWith를 사용했고 내 생각엔 이게 문제의 의도에 더 맞지 않을까 싶다.
(그런 것 치고는 실행 시간이 생각보다 많이 나와 놀랬다.)

다른 풀이에 비교해도 성공적인 답변이었고 조금 디테일이 부족한 부분이라면 toList 처리할 것 없이 바로 갖다 꽂았어도 됐는데 생각없이 처음에 굳이 List로 변환한 건 아쉬움이 남는다.
(퍼포먼스도 변환 작업 안 거친게 더 좋았다.)