크고 복잡한 일들, 더 큰 성과를 내기 위해서는 혼자서 하는 것보다 여러 사람들이 함께 일을 해야 한다.
학교에서도 선생과 학생이 함께 학생의 성장이라는 목표로 협력하며, 회사에서 일을 할 때도 회사의 이익이라는 목표를 위해서 다양한 사람들이 협력하여 일을 한다.
일을 더 잘하기 위해서, 더 큰 성과를 내기 위해서는 어떻게 해야할까?
회사든 학교든 결국 모든 일은 사람들이 하는 것이기 때문에, 사람들이 성장해야 회사도 성장하고 성취할 수 있는 결과도 더 커지게 된다.
함께 일을 하면서, 단지 목표만 보고 달려가는 것이 아니라 더 큰 관점에서 조직과 사람이 성장하는 방법에 대한 통찰력을 배울 수 있는 책이었다. 이전까지는 단순히 열심히 일에 집중하고, 부족한 부분은 스스로 찾아서 배우는 개개인의 역량에 의지하는 방식으로 일을 처리하였는데, 더 큰 성과를 내기 위해서는 일을 바라보는 시각이 개인에서 확대하여 같이 일하는 사람들을 바라보고, 그 사람들과 어떻게 협력하고 커뮤니케이션 하여 서로 윈윈할수 있을지 알게 되었다.
내가 알게된 내용을 주변 사람들과 함께 공유하고 현실에서 성과로 이뤄내는 것은 또 다른 문제이지만, 같이 일하는 사람들에게 선물해주고 싶은 책이다.
구글의 도움을 받아서 사용법을 익히고, 깃허브 아이디도 만들고 개인 프로젝트에서도 사용해보았지만, 지금 일하고 있는 회사에서는 SVN을 사용하고 있어서 Git을 개인적으로 사용할 때마다 더 체계적이고 잘 정리된 사용법이 있지 않을까? 하는 갈증이 있었다.
Git같은 경우는 강의로 들을 만큼 내용이 어렵거나 많은 것도 아니라 어떻게 공부하면 좋을까 고민한 결과 출퇴근 시간에 ebook으로 읽으면 괜찮겠다 생각해서 바로 교보문고에서 sam베이직으로 빌려서 독서를 시작했다.
본문 구성이 신입사원이 입사하여 개발자로 일하면서 git에 대한 필요성을 느끼고 사수에게 배운다는 시나리오를 설정하면서 스토리를 풀어가면서 얘기하는데, 딱딱한 기술이야기만 있는 것보다 친근감있게 다가와서 읽기 좋았고, 챕터도 출퇴근시간에 하나씩 읽기 적당한 단위로 나뉘어져 있어서 1주일정도 걸려서 완독을 하였다.
단순 사용법만 나열한 것이 아니고 버전관리의 역사부터 git의 주요 오브젝트, 어떤 방식으로 작동하는지 잘 정리되어 있으며, 소스트리를 통해 실제 사용 예제도 책에 삽입된 이미지를 보면서 시각적으로 볼 수 있어서 컴퓨터앞에 앉아있지 않아도 이해가 쉽게 되었다.
$* expands to all parameters that were passed to that shell script. $0 = shell script's name $1 = first argument $2 = second argument ...etc $# = number of arguments passed to shellscript
It means all the arguments passed to the script or function, split by word. It is usually wrong and should be replaced by "$@", which separates the arguments properly
리눅스에서 사용되는 명령어들은 인자값을 받을 수 있다.
예를들면 도커 이미지를 실행하는 명령어는 다음과 같다.
docker start [images]
위의 명령어를 보면 docker 명령어에, start와 images 인자를 함께 전달하여 명령어를 실행한 것인데
$* 같은 경우는 넘어온 모든 인자들을 하나의 문자열로 보기 때문에
[start images]라고 인식을 하며
$@ 같은 경우는 넘오온 인자들을 각각의 인자로 인식하기 때문에
start / images 로 인식하게 된다.
위에 언급한 인용문처럼 일반적으로 $*는 잘못된 사용법이며, $@로 바꿔야 한다고 이야기하고 있다.
신입사원 무지는 게시판 불량 이용자를 신고하고 처리 결과를 메일로 발송하는 시스템을 개발하려 합니다. 무지가 개발하려는 시스템은 다음과 같습니다.
각 유저는 한 번에 한 명의 유저를 신고할 수 있습니다.
신고 횟수에 제한은 없습니다. 서로 다른 유저를 계속해서 신고할 수 있습니다.
한 유저를 여러 번 신고할 수도 있지만, 동일한 유저에 대한 신고 횟수는 1회로 처리됩니다.
k번 이상 신고된 유저는 게시판 이용이 정지되며, 해당 유저를 신고한 모든 유저에게 정지 사실을 메일로 발송합니다.
유저가 신고한 모든 내용을 취합하여 마지막에 한꺼번에 게시판 이용 정지를 시키면서 정지 메일을 발송합니다.
다음은 전체 유저 목록이 ["muzi", "frodo", "apeach", "neo"]이고, k = 2(즉, 2번 이상 신고당하면 이용 정지)인 경우의 예시입니다.
유저 ID유저가 신고한 ID설명
"muzi"
"frodo"
"muzi"가 "frodo"를 신고했습니다.
"apeach"
"frodo"
"apeach"가 "frodo"를 신고했습니다.
"frodo"
"neo"
"frodo"가 "neo"를 신고했습니다.
"muzi"
"neo"
"muzi"가 "neo"를 신고했습니다.
"apeach"
"muzi"
"apeach"가 "muzi"를 신고했습니다.
각 유저별로 신고당한 횟수는 다음과 같습니다.
유저 ID신고당한 횟수
"muzi"
1
"frodo"
2
"apeach"
0
"neo"
2
위 예시에서는 2번 이상 신고당한 "frodo"와 "neo"의 게시판 이용이 정지됩니다. 이때, 각 유저별로 신고한 아이디와 정지된 아이디를 정리하면 다음과 같습니다.
유저 ID유저가 신고한 ID정지된 ID
"muzi"
["frodo", "neo"]
["frodo", "neo"]
"frodo"
["neo"]
["neo"]
"apeach"
["muzi", "frodo"]
["frodo"]
"neo"
없음
없음
따라서 "muzi"는 처리 결과 메일을 2회, "frodo"와 "apeach"는 각각 처리 결과 메일을 1회 받게 됩니다.
이용자의 ID가 담긴 문자열 배열id_list, 각 이용자가 신고한 이용자의 ID 정보가 담긴 문자열 배열report, 정지 기준이 되는 신고 횟수k가 매개변수로 주어질 때, 각 유저별로 처리 결과 메일을 받은 횟수를 배열에 담아 return 하도록 solution 함수를 완성해주세요.
제한사항
2 ≤id_list의 길이 ≤ 1,000
1 ≤id_list의 원소 길이 ≤ 10
id_list의 원소는 이용자의 id를 나타내는 문자열이며 알파벳 소문자로만 이루어져 있습니다.
id_list에는 같은 아이디가 중복해서 들어있지 않습니다.
1 ≤report의 길이 ≤ 200,000
3 ≤report의 원소 길이 ≤ 21
report의 원소는 "이용자id 신고한id"형태의 문자열입니다.
예를 들어 "muzi frodo"의 경우 "muzi"가 "frodo"를 신고했다는 의미입니다.
id는 알파벳 소문자로만 이루어져 있습니다.
이용자id와 신고한id는 공백(스페이스)하나로 구분되어 있습니다.
자기 자신을 신고하는 경우는 없습니다.
1 ≤k≤ 200,k는 자연수입니다.
return 하는 배열은id_list에 담긴 id 순서대로 각 유저가 받은 결과 메일 수를 담으면 됩니다.
2 ≤id_list의 길이 ≤ 1,000
1 ≤id_list의 원소 길이 ≤ 10
id_list의 원소는 이용자의 id를 나타내는 문자열이며 알파벳 소문자로만 이루어져 있습니다.
id_list에는 같은 아이디가 중복해서 들어있지 않습니다.
1 ≤report의 길이 ≤ 200,000
3 ≤report의 원소 길이 ≤ 21
report의 원소는 "이용자id 신고한id"형태의 문자열입니다.
예를 들어 "muzi frodo"의 경우 "muzi"가 "frodo"를 신고했다는 의미입니다.
id는 알파벳 소문자로만 이루어져 있습니다.
이용자id와 신고한id는 공백(스페이스)하나로 구분되어 있습니다.
자기 자신을 신고하는 경우는 없습니다.
1 ≤k≤ 200,k는 자연수입니다.
return 하는 배열은id_list에 담긴 id 순서대로 각 유저가 받은 결과 메일 수를 담으면 됩니다.
발상
신고 결과를 취합하고 -> 결과를 집계해서 정지여부를 판단하고 -> 신고한 사람들에게 피드백을 주는 문제이다.
1차 자료를 가공하고 가공된 자료를 활용하여 다시 2차 결과물을 만드는데, 약간 복잡했다.
1차원의 ID 리스트를 상관계수 표처럼 2차원을 확장하고, 확장한 y축을 신고결과를 누적하게 한 뒤, 취합하면 나중에 전체순회를 여러번 하지 않고 편하게 자료를 활용할 수 있을 것 같아서 2차원 배열로 구현하였다.
의사코드
1. 초기값 선언(2차원 배열)
2. 신고 결과 배열 마킹{
1. 신고자 배열위치 확인(스트림 인덱스)
2. 피신고자 배열위치 확인
3. 보드에 마킹(0일 때만 1)
}
3. 신고 결과 취합 및 정지여부 판단
4. 정지대상과 신고자 체크 후 결과값 반환
로또 6/45(이하 '로또'로 표기)는 1부터 45까지의 숫자 중 6개를 찍어서 맞히는 대표적인 복권입니다. 아래는 로또의 순위를 정하는 방식입니다.1
순위당첨 내용
1
6개 번호가 모두 일치
2
5개 번호가 일치
3
4개 번호가 일치
4
3개 번호가 일치
5
2개 번호가 일치
6(낙첨)
그 외
로또를 구매한 민우는 당첨 번호 발표일을 학수고대하고 있었습니다. 하지만, 민우의 동생이 로또에 낙서를 하여, 일부 번호를 알아볼 수 없게 되었습니다. 당첨 번호 발표 후, 민우는 자신이 구매했던 로또로 당첨이 가능했던 최고 순위와 최저 순위를 알아보고 싶어 졌습니다. 알아볼 수 없는 번호를0으로 표기하기로 하고, 민우가 구매한 로또 번호 6개가44, 1, 0, 0, 31 25라고 가정해보겠습니다. 당첨 번호 6개가31, 10, 45, 1, 6, 19라면, 당첨 가능한 최고 순위와 최저 순위의 한 예는 아래와 같습니다.
당첨 번호3110451619결과
최고 순위 번호
31
0→10
44
1
0→6
25
4개 번호 일치, 3등
최저 순위 번호
31
0→11
44
1
0→7
25
2개 번호 일치, 5등
순서와 상관없이, 구매한 로또에 당첨 번호와 일치하는 번호가 있으면 맞힌 걸로 인정됩니다.
알아볼 수 없는 두 개의 번호를 각각 10, 6이라고 가정하면 3등에 당첨될 수 있습니다.
3등을 만드는 다른 방법들도 존재합니다. 하지만, 2등 이상으로 만드는 것은 불가능합니다.
알아볼 수 없는 두 개의 번호를 각각 11, 7이라고 가정하면 5등에 당첨될 수 있습니다.
5등을 만드는 다른 방법들도 존재합니다. 하지만, 6등(낙첨)으로 만드는 것은 불가능합니다.
민우가 구매한 로또 번호를 담은 배열 lottos, 당첨 번호를 담은 배열 win_nums가 매개변수로 주어집니다. 이때, 당첨 가능한 최고 순위와 최저 순위를 차례대로 배열에 담아서 return 하도록 solution 함수를 완성해주세요.
제한사항
lottos는 길이 6인 정수 배열입니다.
lottos의 모든 원소는 0 이상 45 이하인 정수입니다.
0은 알아볼 수 없는 숫자를 의미합니다.
0을 제외한 다른 숫자들은 lottos에 2개 이상 담겨있지 않습니다.
lottos의 원소들은 정렬되어 있지 않을 수도 있습니다.
win_nums은 길이 6인 정수 배열입니다.
win_nums의 모든 원소는 1 이상 45 이하인 정수입니다.
win_nums에는 같은 숫자가 2개 이상 담겨있지 않습니다.
win_nums의 원소들은 정렬되어 있지 않을 수도 있습니다.
발상
요약하면 0으로 나눈 번호들을 모두 맞다고 가정한 순위와 모두 틀렸다고 가정한 순위를 구하여 반환하는 문제이다.
두 배열을 비교하여 일치한 번호를 세야 하고 0인 번호들을 세서 순위를 구해야 한다.
의사코드
1. 0인 번호 구하기
2. 일치하지 않는 번호 구하기
3. 순위를 만들어 반환
개선
스트림을 이용하여 나름대로 filter 안에 다시 다른 배열을 스트림으로 받아 비교하여서 읽기 쉬운 코드를 작성하였다고 생각하였다.
하지만 결국 순위를 구하는 로직이 후에 추가적으로 작성되어야 했고, 순위의 예외처리도 필요하여 코드가 복잡해졌었다.
다른사람의 풀이를 보니, 결과값을 만들 새로운 스트림을 기존의 배열이 아닌 초기선언 방식으로 선언해두고, 그 위치에 스트림을 이용하여 순위값을 만들어 넣었다.
그뒤 체이닝을 통해 순위로직을 처리하여 return 함수 한줄에 코드가 모두 정리되는 것을 확인했다.
스트림이 알고리즘과 코딩테스트에선 성능이슈가 큰 부분이 확실히 존재하지만, 익숙해진다면 빠르게 구현할 수 있기 때문에 여러 문제를 풀어야 하는 코딩테스트 상황에서 다른 문제에 더 시간을 집중하고, 나중에 다 푼 뒤에 최적화가 가능한 장점이 있다.
또한 코딩테스트만을 위한 최적화가 아닌 실제 업무에서는 읽기 좋은 유지보수하기 좋은 코드가 더 선호되기 때문에 성능이슈에도 불구하고 스트림을 계속 사용하는 것이 충분히 합리적이라 생각한다.