주변에서 취업하신 분들 소식을 듣게 될 때가 많음.
예전에는 기업에서 경력, 포트폴리오 등을 중시해서 뽑았다면, 요새는 코딩테스트(이하 PS)의 비중이 늘어났음. 어떤 곳은 코드포스 성적을 보고 우대해준다는 소리도 들리니, PS의 비중이 얼마나 늘었는지 실감하게 됨.
안타까운 건 나쁜 소식도 가끔씩 들려온다는 거임. 일부에서 PS 출신에 대한 불만을 토로하거나, 심지어 PS충이라는 단어를 듣게 될 때가 있었음.
가장 많이 들리는 불만 중 하나는 "코드를 더럽게 짠다는거임"
PS 갤러리의 다수 인원은 취업이 목적이거나, 최소한 프로그래밍 관련 일을 하고 있다고 생각함. 물론 본업이 프로그래밍과 아무런 관련이 없고 취미로만 하는 사람도 있겠지만, 많은 사람들은 반은 취미고 반은 공부/취업 대비의 목적으로 하고 있다고 생각이 됨.
미래 직장에 대한 사전 공부 목적으로의 PS는 생각보다 많이 도움이 됨. PS를 하면서 언어의 다양한 기능을 사용하며 익숙해지고, 어려운 문제를 잘게 쪼개서 푸는 경험은 나중에 현실 문제를 풀 때도 큰 도움이 될 거임.
문제는 PS는 프로그래밍의 가장 중요한 요소를 하나 빠뜨리고 있다는 것임. 바로 유지보수임. 모든 코드는 한 번 작성하고 끝나는 게 아니라 관리하는 과정에서 지속적으로 읽히게 됨. 하지만 여기에 있는 많은 사람들이 내 코드가 읽기 좋을까를 고민한 적은 별로 없을 거라고 생각함.
예를 들어, 많은 프로그래머들이 "변수 이름 짓기"가 프로그래밍을 하면서 가장 어려운 일이라고 함.
그런데 PS하면서 변수 이름을 오랫동안 고민해본 사람 있음? 별로 없지 않을까?
당장 동작하는 코드를 빠르게 작성하는 것에 집중하고 깔끔한 코드 작성을 연습하지 않다가, 취업해서 갑자기 깔끔한 코드를 작성하려고 하니까 잘 안 되는거임.
"당장 디자인패턴 공부하라는 거냐?" 그건 아님. 디자인 패턴 같은 아키텍쳐 공부는 실제 써먹을 때가 없으면 "왜 배우지?" 싶을 때가 많을거다.
PS하면서 따로 사이드 프로젝트를 해보는 것도 좋고, 아니면 PS 문제 풀고 난 뒤에, 소스코드를 보면서 어떻게 하면 더 깔끔하게 작성할 지 연습하는 해보는 것도 좋음.
오늘 내가 소개할 책은 이런 식의 깔끔한 코딩하기를 배워볼 수 있는 책임.
이 책은 디자인 패턴, 아키텍쳐, 개발론 이런 내용을 다 빼고, "어떻게 하면 더 좋은 코드를 작성할 수 있는지"에 집중한 책임.
매우 실전적인 책이라 예제도 많고, 변수 이름 짓기 같은 사소한 부분부터 코드 리팩토링까지 폭 넓은 주제를 다룸.
PS를 하면서도 충분히 참고할 내용이 있기 때문에 병행하면서 공부하기 좋다고 생각함.
다음 글에서는 이 책의 내용을 참고해서 어떻게 읽기 좋은 코드를 작성하는지 예시를 보여주도록 하겠음.
PS충들이 코드 지저분하게 작성하는 이유 중에 하나가 C언어로 시작한다는 점이라고 생각함 #define MAX 같은 매크로가 횡행하는데 왜냐하면 c언어는 min, max 함수 없으니까 (실제로 현업에서도 c++프로젝트인데 버젓이 저런 매크로가 지저분한 코드에는 만연함) 다른 언어는 상식적으로 이해안되는걸 c언어 문법으로 작성하면 강제되는 경우가 많음
그리고 회사에서 코드에 #define FOR 이 ㅈㄹ하는 사람 보고 황당했던거 기억난다
int a, b, c, d; 국룰 아니었냐고 아..
PS충들 특징이 리팩토링은 잘 하는데 클린코딩은 때려죽여도 못함
클린코드가 뭔지 모르는데 리팩토링이 가능한가 클린한 방향으로 코드를 개선하는게 리팩토링인데
맞어 그래서 나도 웬만해선 한자리 알파벳 변수 안쓰고 playerStrength 이런식으로 쓰려고 노력중 변수는 좀 길어지지만 알아먹기는 편하더라. 바이트 짧다고 무조건 좋은게 아님.
나는 그래서 신입 들어오면 그냥 일단 변수 메서드 클래스 이름 무조건 컨벤션 맞춰서 길고 장황하게 쓰라고 함. int num; 이딴 식으로 쓰는 새끼들 워낙 많이 봤고 어짜피 IDE 자동완성 쓰면 되는데
근데 과도하게 장황한 네이밍도 클린코드에서 하지 말라는 짓 읽다보면 그것도 눈테러임
신입애들은 어짜피 그런거 모르고 저렇게 말해줘야 그나마 적당히 읽을만한 수준으로 짬