개요
얼마 전 Github를 둘러보던 중 좋은 게시글 하나를 발견하였습니다.
능력있는 개발자는 어떻게 알아볼 수 있나? 라는 제목으로 투고 된 게시물인데, 회사가 개발자를 선별하기 위해 하면 좋은 방법에 대해 알려주는 글이였습니다.
지금 당장 제가 개발자를 채용해야 한다거나, 개발자를 채용할만한 위치에 있는 상황은 아니지만 좋은 개발자가 되기 위한 목표를 둔 사람으로서 회사의 시선으로 바라보는 개발자 평가법도 알아두면 좋을 것 같아 해당 게시글을 보게 되었습니다.
시장의 문제점
우리나라의 개발자 시장, 특히 압도적인 규모를 자랑하는 SI 시장에서는 개발자를 초중고급으로 레벨을 나누며 몸값을 받습니다.
이것이 문제인 이유는 단계를 나누는 기준이 학력과 경력에만 치중해있다는 것입니다.
개발을 해보신 분들이나 개발자들의 기술에 대해 알아보신 분들이라면 이것이 얼마나 위험한 일인지 알 것입니다.
비전공자, 지방대, 고졸 등의 경력 1, 2년차 주니어가 5년, 6년의 경력을 보유한 개발자보다 개발 실력이 무조건 열등(?)하다고 볼 수가 없기 때문이죠.
좋은 개발자가 되는 법
코드를 공개하라
개발자들의 대다수가 본인의 코드를 공개적으로 드러내는 것을 두려워합니다.
애초에 이건 코드에만 국한 된 얘기가 아니라, 본인이 가진 기술을 드러내고 비평을 들어야 한다는게 꺼려지는 것은 사람이라면 당연한 일입니다.
하지만 본인의 기술을 꽁꽁 숨겨두면 당신보다 잘하는 누군가의 피드백을 받을 수 있는 기회를 날려버리는 일이 될 수 있기 때문에 코드는 가급적 공개해야 합니다.
다른 사람의 코드를 봐라
당신이 당신의 코드를 만천하에 공개하는 것 처럼, 당신 또한 다른 사람의 코드를 볼 수 있는 권리가 있습니다.
더 나은 사람의 코드를 중점적으로 보고, 이 사람의 코드를 이해하지 못하더라도 이 사람의 코드를 모방하도록 노력하세요.
당신보다 더 낫다고 생각하는 사람이 짠 코드라면 분명 그 사람의 코드에는 그 사람이 겪은 모든 이슈에 대한 해결책이 녹아들어있기 때문입니다.
나만 잘하지 말라
많은 사람들이 착각하고, 저 또한 착각하고 있던 대목 중 하나인데, 프로젝트를 빠른 기간 안에 많이 끝내는 사람이 유능한 개발자라고 생각하면 안된다는 점입니다.
물론 이 또한 분명 회사에 많은 수익을 가져다주는 좋은 덕목이긴 하지만 이는 단기적인 사업적 관점에서 바라보는 개발자의 유능함이고, 진정 유능한 개발자는 본인의 속도를 조금 희생하더라도 구성원 모두가 좋은 코드를, 최대한 버그가 적게, 기한 내에 만들도록 유도하는 사람입니다.
전산학적으로 바라보라
예를 들어 아래와 같은 코드가 있다고 칩니다.
1
2
3
this.coords = [];
this.coordsMarker = [];
this.coordsInfoWindows = [];
팀의 구성원이 코드를 이렇게 구성했다고 하고, 이를 여러분들이 리뷰해야 하는 상황이라면 어떻게 해야할까요?
coords라는 접두사를 통해 연관성이 있는 변수임을 어필하고는 있지만, 컴퓨터의 시선에서 바라볼 때 각 변수간 연관성이 있다. 라고 설명할 수는 없겠죠.
그래서 이 점을 해결하기 위해, 클래스를 사용하는 것이 베스트입니다.
1
2
3
4
5
6
7
class Map {
constructor() {
this.coords = [];
this.marker = [];
this.windows = [];
}
}
이렇게 묶는다면 공통의 관심사를 갖는 변수의 묶음을 그 어떤 표현 방법 보다 확실하게 표현할 수 있습니다.
또한, coords와 marker가 특정한 로직으로 엮여있는 변수여야 한다면, setter를 작성하여 두 변수를 어떠한 규칙으로 강제할 수 있습니다.
이렇게 구현한다면 coords와 marker 변수 간 무결성을 검증하기 위한 코드를 작성할 수고를 덜 수 있겠죠.
마치며
저도 위에서 소개한 글을 읽어보며 알게 된 점이 많습니다.
특히 예문에서 들었던 prefix로 변수 간 규칙성을 표현한 코드가 저한테도 실제로 있었던 사례인데, 이 부분에 대해서 다시금 돌아보게 되는 계기가 되었습니다.