주말에 추가로 발표 자료를 만들고 영상까지 제작하느라 좀 고생이었다. 다른 조도 주말에 나와 작업하는 건 예삿일이 아니긴 했지만 괜히 시간 못맞춘 것 같은 느낌이 들었다.
뉴스피드 프로젝트 발표하기
발표 자료는 이번에도 1주차 때 웹 프로젝트 발표한 것처럼 날림으로 작성했다. 나는 ppt에 텍스트를 많이 적을 수록 오히려 말을 절고 ppt에 휘둘리는 느낌이라 점점 사진만 남기게 되어가는 것 같다. 어쩌다가 즉석에서 대본을 생각하는게 더 편해졌는지는 잘 모르겠다.
다른 조의 발표를 보면 다들 기능 구현은 정말 충실히 잘하셨고 오히려 디자인, 프론트앤드같은 디테일이나 확실한 테스트등 강점을 잘 챙기셔서 우리도 사람이 더 있었다면 저런 이슈도 처리할 수 있었을까 싶은 생각은 조금 들었는데 이미 초과 달성한 거라 아쉽지는 않다.
그렇게 시작한 우리 조의 발표는 깔끔하게 끝났다. 말은 여전히 빠르지만 다행히 루즈하진 않고 전달력은 그나마 평범함 이상은 가지 않을까라고 본인을 평가하기로 하고 이번엔 3명뿐이었지만 앞으로 자료나 발표도 다른 사람들이 가져가주지 않을까 생각한다.
피드백으로는 다행히 크게 지적받은 사항은 없었고 이번엔 강의에 맞춰서 그냥 기술 스택을 선정했지만 비교군을 선정해서 적절한 스택을 사용하는게 좋다는 전체적인 피드백이 있었다.
(사실 오늘 발표는 한 분이 예비군 이슈로 빠져서 그 마저도 2명만 남아있었다.)
KPT 회고
이번엔 프로젝트를 마무리한 거라 KPT 회고까지 진행하게 됐다. 2명이서 진행하는 거였지만 충분히 프로젝트를 즐긴 사람들끼리 하는 거라 회고에서는 좋은 내용들이 오고가게 됐다.
Keep
- 협업 과정이 마음에 들었다
- 약간 실무처럼 하는 느낌을 받을 수 있었다
- 팀 분위기가 좋았다
- 충분한 휴식, 평소 대화는 적지만 리뷰와 스크럼 회고는 적극적으로 참여하기
- 군더더기 없는 일정 관리가 된 것 같다
- 이슈 트러블 슈팅이 잘 진행됐다
- 슬랙이든 회고든 이슈 관리는 잘 되었다고 느껴졌다
Problem
- 코드 스타일 쪽도 컨벤션 조금 더 맞았으면 좋았을 것 같다
- 충돌 해결과 리뷰를 진행하며 코드 스타일 정립의 필요성이 느껴졌다
- 테스트의 절대적인 양이 부족했다
- 사람이 적기도 했지만 많은 시도를 해보기엔 노하우도 부족했고 불충분한 시간이었다
- 이벤트 스토밍 / ERD 설계 과정에서 나와야할 API가 명세서에 기록되지 않았다
- 명세서 자체도 리뷰하고 검토하면 좋았을 것 같다
- 발표 자료가 못생겼다
- 이슈에 필요한 레퍼런스를 찾는 데에 어려움이 있었다
Try
- 다음 프로젝트도 컨벤션 - Github 탬플릿 구성 - Slackbot 구성하면 더 좋을 것 같다
- 코드 스타일 컨벤션을 위해 Save action - Reformat code가 자동 설정이 가능하다
- 테스트 코드 작성은 미숙하더라도 이슈에 대한 테스트 시나리오를 먼저 세워보면 테스트의 귀찮음이 줄 것 같다
- 대안이 있을 경우 모든 방안의 장단점을 간략히라도 조사해보고 공부하면 좋을 것 같다
테스트같은 경우는 이전부터 스크럼이든 스프린트든 이런 식으로 테스트에 대한 아쉬움을 표출한 적이 많았는데 이번에도 그런걸 보면 개발자와 테스트는 정말 마주하기 싫지만 아쉬움이 남는 그런 관계가 아닌가 싶다.
이번 회고는 첫 기초 프로젝트치고도 상당히 스무스하게 흘러간 경우고 우리 조의 강점은 적은 인원으로도 잡음없이 진행된게 가장 크다고 생각한다.
의미있는 기초 프로젝트였고 다음 프로젝트에서도 잡음을 최대한 줄이고 개발에만 전념할 수 있었으면 좋겠다.
코드카타 - 프로그래머스 성격 유형 검사하기
나만의 카카오 성격 유형 검사지를 만들려고 합니다.
성격 유형 검사는 다음과 같은 4개 지표로 성격 유형을 구분합니다. 성격은 각 지표에서 두 유형 중 하나로 결정됩니다.
| 지표 번호 | 성격 유형 |
|---|---|
| 1번 지표 | 라이언형(R), 튜브형(T) |
| 2번 지표 | 콘형(C), 프로도형(F) |
| 3번 지표 | 제이지형(J), 무지형(M) |
| 4번 지표 | 어피치형(A), 네오형(N) |
4개의 지표가 있으므로 성격 유형은 총 16(=2 x 2 x 2 x 2)가지가 나올 수 있습니다. 예를 들어, "RFMN"이나 "TCMA"와 같은 성격 유형이 있습니다.
검사지에는 총 n개의 질문이 있고, 각 질문에는 아래와 같은 7개의 선택지가 있습니다.
매우 비동의비동의약간 비동의모르겠음약간 동의동의매우 동의
각 질문은 1가지 지표로 성격 유형 점수를 판단합니다.
예를 들어, 어떤 한 질문에서 4번 지표로 아래 표처럼 점수를 매길 수 있습니다.
| 선택지 | 성격 유형 점수 |
|---|---|
매우 비동의 |
네오형 3점 |
비동의 |
네오형 2점 |
약간 비동의 |
네오형 1점 |
모르겠음 |
어떤 성격 유형도 점수를 얻지 않습니다 |
약간 동의 |
어피치형 1점 |
동의 |
어피치형 2점 |
매우 동의 |
어피치형 3점 |
이때 검사자가 질문에서 약간 동의 선택지를 선택할 경우 어피치형(A) 성격 유형 1점을 받게 됩니다. 만약 검사자가 매우 비동의 선택지를 선택할 경우 네오형(N) 성격 유형 3점을 받게 됩니다.
위 예시처럼 네오형이 비동의, 어피치형이 동의인 경우만 주어지지 않고, 질문에 따라 네오형이 동의, 어피치형이 비동의인 경우도 주어질 수 있습니다.
하지만 각 선택지는 고정적인 크기의 점수를 가지고 있습니다.
매우 동의나매우 비동의선택지를 선택하면 3점을 얻습니다.동의나비동의선택지를 선택하면 2점을 얻습니다.약간 동의나약간 비동의선택지를 선택하면 1점을 얻습니다.모르겠음선택지를 선택하면 점수를 얻지 않습니다.
검사 결과는 모든 질문의 성격 유형 점수를 더하여 각 지표에서 더 높은 점수를 받은 성격 유형이 검사자의 성격 유형이라고 판단합니다. 단, 하나의 지표에서 각 성격 유형 점수가 같으면, 두 성격 유형 중 사전 순으로 빠른 성격 유형을 검사자의 성격 유형이라고 판단합니다.
질문마다 판단하는 지표를 담은 1차원 문자열 배열 survey와 검사자가 각 질문마다 선택한 선택지를 담은 1차원 정수 배열 choices가 매개변수로 주어집니다. 이때, 검사자의 성격 유형 검사 결과를 지표 번호 순서대로 return 하도록 solution 함수를 완성해주세요.
fun solution(surveys: Array<String>, choices: IntArray): String {
val scoreMap = mutableMapOf("R" to 0, "T" to 0, "C" to 0, "F" to 0, "J" to 0, "M" to 0, "A" to 0, "N" to 0)
surveys.zip(choices.toTypedArray()).forEach { (survey, choice) ->
val first = survey[0].toString()
val second = survey[1].toString()
when (choice) {
in 1..3 -> scoreMap[first] = scoreMap[first]!! + 4 - choice
in 5..7 -> scoreMap[second] = scoreMap[second]!! + choice - 4
}
}
val builder = StringBuilder()
builder.append(if (scoreMap["R"]!! >= scoreMap["T"]!!) "R" else "T")
builder.append(if (scoreMap["C"]!! >= scoreMap["F"]!!) "C" else "F")
builder.append(if (scoreMap["J"]!! >= scoreMap["M"]!!) "J" else "M")
builder.append(if (scoreMap["A"]!! >= scoreMap["N"]!!) "A" else "N")
return builder.toString()
}뭔가 마음에 드는 코드는 아닌데 다른 접근 방식이 생각나질 않아서 이대로 진행했다. 오늘이 프로젝트 마무리 날이라 뇌가 녹아내린 느낌이라서 번뜩이는 방법이 생각이 나질 않았다.
퍼포먼스가 나쁘다거나 하는 건 아닌데 가독성과 확장성이 좋지 않을 것 같다는 느낌이 강했다.
다른 제출을 보니 훨씬 가독성이 잘 풀린 답안을 확인 가능했다.
fun solution2(survey: Array<String>, choices: IntArray): String {
val scoreMap = mutableMapOf("RT" to 0, "CF" to 0, "JM" to 0, "AN" to 0)
survey.forEachIndexed { index, key ->
if (scoreMap.keys.contains(key)) {
scoreMap[key] = scoreMap[key]!! + choices[index] - 4
} else {
scoreMap[key.reversed()] = scoreMap[key.reversed()]!! - (choices[index] - 4)
}
}
var answer = ""
scoreMap.forEach { (key, value) -> answer += if(value > 0) key[1] else key[0] }
return answer
}이걸 보고 문제를 다시 읽어봤다. survey의 원소는 "RT", "TR", "FC", "CF", "MJ", "JM", "AN", "NA" 중 하나입니다. 나는 이걸 잘못 읽고 알파벳이 섞인다고 생각해서 하드하게 탐색하는 식으로 작성했는데 잘 보니 그냥 순서가 뒤집어질 수 있을 뿐이었다.
이대로 작성했으면 훨씬 값에 대한 계산이 쉬웠을 것 같다.
