[TIL] 21.02.24.(Wed)

오늘은 거의 일기네요. 동료 피드백 주시는 분들께 죄송하다는 말씀 먼저 드립니다 ㅠ.

수행 내용

• 숫자야구 프로그램 Step 1 기능 구현
• 모둠원 Kio와 각자 Step 1까지 기능 구현한 숫자야구 프로그램 코드 리뷰하며 병합 작업
• 병합 작업한 내용 Pull Request 및 리뷰어 태태 의견 개인 코드에 반영
• 태태 리뷰 의견 반영한 코드 개인 브랜치에 Commit, Pull
• 변수, 함수명 명명에 대한 고민
• Step 2 일부 기능 구현
• 진행 중인 프로젝트의 함수 단위를 최대한 분할
• 야곰닷넷 TechCast 참석 (iOS 개발자 코딩테스트 이야기)

학습 내용

함수를 독립적인 기능 단위로 나누면 편리하다.

정수 생성 후 배열에 중복되지 않도록 삽입하는 함수를 작성하며 초기에는 전역변수를 대상으로 기능하는 함수를 작성하였는데, 요구사항에 따라 입력부를 자동 생성한 배열로 대체해야 하는 일이 생겼다. 함수의 기능을 어떤 변수에도 적용이 가능하도록 함수 내부에 임시 배열을 만들고 배열을 리턴값으로 받아 사용하였더니 입력과 정답값에 모두 활용이 가능하였고, 향후에도 이렇게 만드는 편이 더욱 편하겠다고 생각했다.

이해를 위해서는 그림 그리기도 도움이 된다.

프로젝트 프로그램 이해를 위해 노트에 끄적이다 제대로 해보자 생각하여 도식으로 표현하였더니 구현할 기능과 수행해야할 주체, 필요한 변수가 더욱 명확해졌다. 아래는 보안을 위해 단순화한 도식임.

함수의 리턴은 유용하다.

캠프를 시작하며 야곰이 이야기한 "한 가지 함수에 많은 기능을 넣는 것은 좋지 않다"라는 말이 계속 마음에 걸렸다. 어떤 것이든 제출하면 모자란 부분이 보이듯이, PR을 하고나니 리턴을 통해 함수 내부에서 활용한 값을 획득할 수 있다는 것이 떠올랐다. 지금까지는 부끄럽지만 "함수를 기능별로 쪼개어 만들고 싶어도 필요한 값이 없는데 어떻게 하나"라고 생각했는데, 이렇게 리턴으로 값을 획득하여 다른 함수에 인수로 넣으면 충분히 가능해보였다. 결과적으로 현재는 이전보다 함수들의 기능을 더욱 분할하는데 성공했다. 하지만 과한 정도를 알아보려면 경험이 필요해보인다.

협업자와 하나의 코드를 만들기는 어렵지만 더욱 만족스러운 결과물을 얻을 수 있다.

페어 프로그래밍 프로젝트에서 Pull Request 진행 방식을 정확히 파악하지 못해 나와 모둠원 모두 각자 자신의 스타일로 기능을 구현한 후 합치는 방향으로 프로젝트를 진행하였다. 결과적으로는 둘 다 기능 구현이 잘 되었지만 변수의 이름과 선언하는 위치, 조건문과 반복문 사용 스타일이 다소 다른 부분이 있어 PR을 위한 하나의 코드를 만드는데 생각보다 오랜 시간이 걸렸다. Jinie에게 문의하여 페어 프로그래밍 프로젝트에서 코드를 하나로 만드는 방법은 모둠원의 저장소를 포크하여 PR하는 방법과 Driver/Navigator 방식이 있을 수 있음을 조언 받을 수 있었고, Kio와 협의하여 Step 2 병합 시 오늘보다 더 효율적인 방법으로 병합 작업을 진행할 수 있도록 해야겠다.

코드 리뷰는 소중하다.

오늘 Kio에게 한 번, 리뷰어인 태태에게 한 번 코드 리뷰를 받았는데, 보여주거나 PR할 때까지는 자신있던 코드가 리뷰를 받으니 생각해볼 내용들이 한 두가지가 아니었다. 앞으로도 동료, 선배, 리뷰어, 선생님들께는 감사함을 표해야지.

iOS 개발자를 위한 코딩 테스트 (야곰의 TechCast)

• 유형 파악 → 개념 공부 → 문제 풀이 순으로 진행

• 문제 유형 파악을 위해 자료구조/알고리즘 단계별 공부

• 자료 구조/알고리즘 공부 병행

• 문제 풀이는 제한시간 안에 풀 수 있도록 반복 숙달

• 엄선된 문제 먼저 풀 것

엄선된 문제는 어디서?

• 프로그래머스 - 코딩테스트 고득점 Kit
• 백준 Online Judge - 단계별 풀이

코딩테스트 문제 푸는 과정

1. 문제 정독
2. 요구사항 및 테스트케이스 파악
3. 문제 유형 파악
4. 문제 풀이 (IDE 활용 추천)
5. 테스트케이스 검증
6. 코드 제출

준비하며 추가로 유의할 것

• IDE에서 문제를 푼다면 코드 복붙 되는지 확인
• 제출 전 요구사항 다시 확인하기
• 엣지 케이스 고려하기 (input이 0일 때, input 데이터가 중복될 때 등)
• 시간이 남는다면 다른 방법으로도 풀어보기

제출 이후

• 제출했던 코드는 따로 보관
• 문제 풀이 중 아쉬운 점이 있었따면 꼭 다시 풀어보기
• 코딩 테스트는 알고리즘 역량만을 검증
• 이후 채용 프로세스에 합격하려면 코테뿐만 아니라 CS, 개발 공부가 필요
• 코테는 최소한의 검증일 뿐 진짜는 기술면접이다!
• 하지만 코테를 통과하지 못한다면 면접은 없다.
• 단순히 문제를 푸는 것 외에도 코드의 퀄리티에도 신경 쓰는 것이 좋음.

문제점 / 고민한 점

현명하게 페어 프로그래밍 프로젝트를 진행하는 방법

Unconditional unwrapping을 사용하지 않고 공백이 있는 입력을 받아 배열로 만드는 방법

코딩 테스트 준비

해결 방법

[미해결] 현명하게 페어 프로그래밍 프로젝트를 진행하는 방법

오래 걸리긴 했지만 오늘과 같은 방식도 나쁘지 않았다 (화상 화면으로 두 명의 코드를 나란히 보며 동일한 기능을 하는 부분을 보며 좋은 쪽을 선택하여 병합). 하지만 모둠원 입장에서 보면 병합할 때 본인이 작성한 코드가 채택되지 않는 경우 어쩌면 본인보다 실력이 떨어지는 사람에게만 코드 리뷰를 받고 자신의 코드를 실력 있는 리뷰어에게 받지 못한다는 생각을 할 수도 있지 않을까? 우리 모둠은 해결 방법은 아직 찾지는 못했지만 지금부터 이야기해볼 예정이다.

[해결] Unconditional unwrapping을 사용하지 않고 공백이 있는 입력을 받아 배열로 만드는 방법

코딩 테스트를 입문 수준으로만 공부한 기억을 되살려보면 초보자용 문제에서는 공백으로 구분된 요소를 입력으로 받는 경우가 꽤 있었다. 그 때 기억으로 관련 내용을 찾아보니 아래와 같은 코드를 발견할 수 있었다.

// input : 1 2 3 4 5
let inputNumbers = readLine()!.split(separator: " ").map { Int($0)! }
print(inputNumbers) // [1, 2, 3, 4, 5]

코딩 테스트에서는 정제된 입력만을 받기 때문에 주어진 코드와 같이 unconditional unwrapping을 코드 작성자의 판단에 따라 사용하여도 될 것으로 판단되나, 개발의 관점에서 보면 어떠한 입력이라도 받을 수 있다고 가정하는 것이 옳다고 생각한다. swift에서 optional을 지원하는 이유가 있을 것인데 강제로 해제해서 사용한다는 것이 옳을지 생각해보아야 할 일이다.
결국 실제 사용을 위해서는 여러번의 optional binding 과정이 필요해보였고, 실제로 그렇게 구현하였다. 공백이 포함된 입력을 optional binding과 readLine()을 통해 String 형식으로 통째로 받아들여 split과 map을 통해 [String] 형식으로 변환한 후 for문을 통해 각 요소를 Int형으로 변환시켜 새로운 배열에 append하는 방식으로 해결하였다. map에서 사용된 closure는 더 공부해 보아야할 내용이다.

[미해결] 코딩 테스트 준비

야곰의 TechCast를 들으며 다시 고민하게된 내용이다. 코딩 테스트에 능한 사람이 좋은 개발자인지에 대해서는 갑론을박이 있으나 기업에서는 좋은 개발자를 원해도 좋은 개발자를 모두 검증해서 뽑을만한 인력은 부족하다는 사실은 틀림이 없다. 그리고 실제로 쓸만한 사람이 채용 과정에서 탈락하는 부정 오류는 괜찮지만 업무 능력이 떨어지는 사람이 합격하는 긍정 오류는 받아들이지 않는다. 코딩 테스트는 면접과 함께 이를 가려내는 한 가지 관문인 것이다. 결국엔 준비해야 하고 하루에 한 가지 개념, 문제 한 개라도 풀어봐야겠다. 시작은 역시 전에 사 둔 책부터!

참고자료

• Swift 알고리즘, 공백 유무별 readLine 입력값 처리방법 (MungGu Story 블로그)