처음에 과제를 내어준다길래 웹으로 구현하는 과제인줄 알았는데 1주차는 주로 문자열을 다루는 알고리즘 코딩테스트에 가까웠다.
다른 사람들의 코드를 보고 깨달은게 몇 가지 있다.
일단 함수로 추출을 하는 내 기준은 해당 로직이 재사용이 되느냐였다.
(한 줄일 경우 3번이상)
그 이유는 재사용이 되지 않으면 굳이 함수로 추출할 필요가 없다고 느꼈고
한 줄 짜리 코드가 2번 재사용 되었다고 함수로 추출해봤자 함수 정의 부분 한줄,
사용 부분 2줄해서 코드 줄 수는 더 늘어나 추출의 필요성을 느끼지 못하였다.
하지만 우테코와 다른 사람들의 기준은 달랐다.
indent depth 기준으로 함수를 추출한다.
예를 들어 if 문이나 for 문 등으로 3번 이상 중첩 되어 있으면 함수로 추출한다.
2 depth 까지만 허용하는 것이다.
이 후 나의 기준도 바뀌어 2주차에서는 코드가 옆으로 너무 길거나
depth가 많을 경우 함수로 추출하였다.
하지만 2주차는 숫자 야구 프로그램 구현이고 클래스로 구현하는 방식인 반면
일반 알고리즘 코딩테스트에서는 주어진 문제 이외에 추가 기능 구현 요구가 들어와
코드가 더 이상 길어진다거나 일부 로직이 중복 사용 가능성이 생긴다거나 하지 않는 것이
확실하고 대체로 길이가 짧기 때문에 알고리즘 코딩테스트에서도 굳이?
라는 생각을 하긴 하지만 이왕 버릇 들일거 그냥 알고리즘 코테에서도 최대한 새로운 기준으로 함수로 추출하는 버릇 들여야겠다.
예를 들어 설명해보겠다. 나의 경우 문제의 제한사항에 input 값이 특정 자료형으로만 주어진다고 하면 그 외의 값이 들어올 것이라고 전혀 고려하지 않고 아예 예외처리 하는 코드를 작성하지 않았다.
하지만 대다수의 사람들이 잘못된 자료형의 값이 들어왔을 경우까지 고려하여 예외처리를 해놓았다.
우테코측도 실무에서는 어떤 값이 들어올지 전혀 모르기 때문에
최대한 에지 케이스를 고려하여 예외처리를 하는 것이 좋다고 하였다.
이를 반영하여 2주차 과제에서는 사용자 입력 값에 대한 예외처리를 꼼꼼하게 하였다.
하지만 또 다시 같은 의문이 든다.
알고리즘 코딩테스트에서도 제한사항에 분명 그런 값이 들어오지 않는다고 했음에도 불구하고
예외처리를 해야 하는가? 에 대한 의문이 든다.
결론은 '이번에는 그럴 필요가 없다'이다.
애초에 알고리즘형 코테는 프로그래머스 같이 플랫폼을 통해 채점하고 해당 플랫폼 들에서는 예고한대로만 값이 들어오기 때문이다. 그래도 최대한 에지 케이스를 고려하는 습관을 들이는게 좋을 듯 싶다.
결론 부터 말하자면 나는 문제를 풀 때 기능 구현 목록을 작성하지 않는다.
요구사항 명세서에 기능 구현 목록을 작성하고 해당 기능 단위로 커밋을 하라고 되어있다.
하지만 나는 그게 문제별로 제출하라는 뜻으로 받아들였다.
이 부분은 크게 바뀌어야 될 필요성을 느꼈다.
알고리즘 코테에서도 이를 지켜 기능 구현 목록을 작성하고 항목 단위로
함수를 작성하는 버릇을 들여야겠다.
2주차 부터는 아래와 같은 사항을 지켜서 제출하였다.
기능 구현 목록 작성
기능 구현 항목 단위로 함수 구현
기능 구현 항목 단위로 커밋 메시지 작성
아직 알고리즘을 공부중이라 정확히 알지 모르지만 분명 한 문제가 그리디였던 것 같다.
그리디 알고리즘을 아직 배우지 않아 모르지만 어찌저찌 풀긴 풀었다.
지난번에도 프로그래머스인가 다른 곳에서 피보나치 수열 문제를 재귀로 풀었더니
콜 스택 터지길래 어떻게 하면 재귀를 안쓰고 피보나치를 구현할 수 있을까 하다가
배열을 이용하는 방법을 썼는데 알고보니 그게 DP Tabulation 기법을 쓴 것이었다.
동적 프로그래밍을 배운적이 없는데 구현해내는 것을 보면 재능은 있는 것 같으니
이제 열심히 하여 지식만 쌓으면 영어도 하겠다 네카라쿠배당토 FAANG MAGAT는 따놓은 당상은 무슨 프로그래머스 레벨 1도 다 풀지 못하는 개발지망생이다.
Github : 1주차 온보딩 미션 풀이 링크