Karen
7k
2017-01-18 15:23:36.0 작성 2017-01-18 15:28:39.0 수정됨
29
15245

능력 있는 개발자는 어떻게 알아볼 수 있나? by 황준식님


생활코딩 페이스북에 황준식님께서 올리신 글입니다.

(https://www.facebook.com/groups/codingeverybody/permalink/1501967613177103)


"해외 개발사의 제의를 받았다고 글쓴이 입니다.

지난 글은 제 생각이상으로 많은 분들이 공유하는 모습을 보았고, 
또 단순히 공유를 넘어서 서로 권하는 모습도 보았습니다.
그리고 저에게 자신이 앞으로 어찌할지 문의하는 분도 있었습니다.

사실, 지난 글은 그저 제 경험담일 뿐입니다.

그래서 이번에는 생코에 github을 통해 모듈을 공개하신 김재원님의 동의를 받아 코드 리뷰와 함께 
해외 CTO가 말한 really impressed with the quality에 대해서 하고 싶은 말을 몇자 적었습니다

ps. 다른 곳으로 퍼가도 됩니다."






능력 있는 개발자는 어떻게 알아볼 수 있나?



제 생각보다도 제 글은 더 센세이션 했던것 같습니다.

오퍼가 왔다고 해도 딱히 가지도 않아서 크게 생각 안하고 살았는데 말이죠.


여튼, 제 글이 400회 가까이 공유가 되었습니다.

공유한 분들 중에서는 이제 막 프로그래밍 공부를 시작하는 분들이나 현직 개발자는  물론이고, 사장님들도 보였습니다. 그리고 나름 영향력을 가진 분들도 있더군요.

저에게 자신이 어떻게 해야되냐고 문의하신 분들도 있습니다.


앞선 제 경험담은 솔직히 읽으신 분들의 일상이 달라지는 것은 아닙니다.

그래서 이번 글은 읽어주신 분들이 구체적으로 어떻게 해야하는지를 전달 할 수 있기를 바라면서  “really impressed with the quality” 에 대해서 제 생각을 적습니다.



솔직히 말해서...


우리나라의 개발 문화는 엉망입니다. 초중고급으로 구분된 개발자 등급제, 과다한 야근, 무리한 일정, 신입 개발자에게 사수도 없이 덥썩 일을 맡기는 현실, 학원 말고는 배울 곳이 없는 환경 등 끝이 없습니다. 해결을 위해 여러가지 논의가 되긴하나 신통한것은 없죠.


이 악순환 속에서 개인이 어찌 할 수 있는 것이 별로 없습니다. (네.. 헬조선이죠..)


하지만 선순환이든 악순환이든 중요한 고리가 있기 마련입니다.

순환을 가속하던지 끊어낼수 있는 고리 말입니다.


저는 개발자의 능력을 신뢰성있게 알아볼 방법이 이런 악순환을 끊을 수 있는 고리라고 생각합니다.

개인이든 조직이든 능력있는 개발자와 함께하면 악순환에서 탈출 할 수 있다고 생각합니다.


그래서 저는

능력있는 개발자로부터 무엇을 얻을 수 있는지?

그리고 어떻게 능력있는 개발자를 구분해 낼 수 있는지?

에 대해  제 방법을 공유하고 합니다.


이를 많은 사람들이 알면

이 악순환이 조금은 해결될 것이라고 기대하며

제 방식과 그에 필요한 Code Quality가 무엇인지 적습니다.   




본론 들어가기 전에..


감사를 표할 분이 있습니다.  생코에 easy-map 소스를 올린 wonism님입니다.


github에 적절한 수준의 소스를 올려주신 덕분에

제가  해외의 CTO가 말한  Code Quality가 무엇을 말하는지 작게 나마 공유할 수 있게 되었습니다.




능력있는 개발자를 왜 알아봐야 하나?


개발자의 능력은 우리나라에서 통용되는 초중고급 경력 구분으로 파악 할 수 없습니다.

현재 제가 기준으로 삼는건 드레퓌스 기술 습득 모형입니다. (자세한것은 http://blog.lastmind.io/archives/593 한번 읽어보세요.)


드레퓌스 모델과 우리나라의 초중고급은 사실상 비교가 불가능합니다.

옛날 등급제를 따르면 대학 나오고 경력 13년이면 특급입니다. 개발자가 20년간 일할수 있다고 하면, 전직하지 않으면 전체의 40%는 특급이 겠네요. 실상 드레퓌스 모델에서는 1%만 expert에 도달합니다. 숫자만 따져도 뭔가 말이 안되는 구조입니다.  


또한 슈퍼 개발자의 능력에 대한 개념이 우리나라는 잘못 되어 있습니다.

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20141106211852

윗 글은 영국의 개발문화를 체험한 기사입니다. 글에서 언급하듯이 슈퍼 개발자는많이 / 빨리 만드는 사람이 아니라, 다른 사람의 실수 / 삽질을 사전에 막아내는 사람입니다.


프로그래머 생산성의 차이가 10배 이상도 벌어진다는것은 이미 공공연한 사실입니다. expert 레벨이 아니어도 3배 정도 개인 생산성은 우습게 벌어집니다.


하지만 능력 좋은 사람을 잘 대우해야 하는 이유는 그 사람이 3~4배의 일을 하기 때문만이 아닙니다. 게임에서 히어로가 정말 좋은 이유는 팀 버프가 있기때문이죠. 개발자도 마찬가지 입니다. 본인 생산성도 좋지만, 타인의 학습 속도/생산성를 올려줍니다.




때문에 능력있는 개발자는

조직 전체로는 일을 효과적으로 할수 있도록 해주고,

개인에게는 빨리 실력을 키울수 있게 해줍니다.

(꼭 알아봐야 할 것 같죠?)





우선 드레퓌스 모델을 기준으로 능력있는 개발자는 Competent부터입니다. 그림에서 보듯이 Coach가 가능한 레벨이기도 합니다. 그리고 제 경험상 우리나라에서 Competent 이상에 해당하는 사람은 10~20%라고 생각합니다.

여튼, Competent가 구체적으로 무엇을 할 수 있는 사람인지 적어 보겠습니다.



1.  영향력 있는 분들에게 하고 싶은 말입니다.


일단 수준 이상에 도달한 개발자에게 팀 전체의 개발 생산성을 늘리도록 할 수 있습니다. 기술을 리딩하게끔 권위를 실어주면, 팀 생산성을 1.5배나 그 이상도 늘릴 수 있습니다. Advanced Beginner는 개발 과정에서 등장하는 지뢰를 전부 밟고 터트려서 확인해야 합니다. 하지만 Competent에 이르면 절반은 피해서 갈수가 있습니다. 팀 전체의 삽질에 빠지는 총 시간이 줄어들면 그것만 계산해도 팀 생산성이 1.2배는 충분히 늘어납니다.


다만 아주 중요한건 일단 Competent수준에 들어서야 다른사람을 코치하는게 가능합니다.

교과서  내용을 전부 외운 Advanced Beginner라도 다른 사람을 코치하는 것은 거의 불가능 합니다. Competent는 지식의 양이 많은게 아니라 지혜를 가진것입니다. (물론 지식의 양도 경력만큼 충분히 받쳐주지만요.) Competent 이상 수준은 정말 얼마 안됩니다. 이런 사람을 찾으면 중용하시기 바랍니다. 중용하라는 건 월급 더 주는것으로 끝내라는 소리가 아닙니다. 팀 전체가 Competent의 업무방식을 배울 수 있게끔 강권하는 것이 좋다는 소리입니다. 지극히 개인적 생각이지만 가볍게 권장 해봐야 소용없는 것 같습니다. 그리고 제가 팀장일때는 저는 독재자 스타일이기도 합니다.




2. 신입 개발자분들과 대학 3~4학년 정도의 학생들에게 하고 싶은 말입니다.


잠재력이 있는 Advanced Beginner라고 해도 Competent가 기술을 구사하는 것을 관찰하지 못하면, 평생 실력 향상을 하지 못할 가능성이 매우 높습니다.

마찬가지로 Competent는 Proficient나 Expert를 찾아서 모방해야 성장에 유리합니다.


자신이 닮아야 하는 모습을 보지 못한다는 것은

별자리도 등대도 없이 망망대해에서 신대륙을 찾는 것과 다를바 없는 일입니다.


여러분들은 무조건 실력자의 바지를 붙잡고 늘어져야 합니다. 전 글에서 실력향상을 위해 수단 방법을 가리지 말라고 조언했습니다. 그 구체적인 실행방법은 Competent를 찾아서 무조건 물고 늘어지라는 것입니다. 제가 권하는건  C++/JAVA 1000제 풀기, JAVA 책 10독, 디자인 패턴 세미나 이런게 아닙니다. 여러분이 모방해야하는 더 나은 기술을 가진 사람은 기껏해야 10~20% 정도입니다. (분명 얼마 안되지만 그렇다고 찾을 수 없는 정도는 아닙니다) 이런 사람을 찾으면 뭐 하나라도 더 배우기 위해서 노력해야하는 것은 당연한거고, 왜 그러는지 이해가 가지 않더라도 기술을 모방해보시기 바랍니다. 모방하고 혼나고, 모방하고 혼나고... 최소한 그렇게는 해야 이해의 실마리라도 잡히게 됩니다. 그러자면, 같이 일 할 기회가 오면 그 일을 택 하세요. 먹고 사는데 지장만 없으면 고민할 필요가 없을 정도의 문제입니다. 능력있는 개발자를 따라 그 아래서 일하는 사람들이 함께 이직하는 것은 이런 이유가 큽니다.


또 회사를 고를 때는 여러분들도 회사를 평가하시기 바랍니다. 그렇다고 주식 투자자들이 생각하듯, 소스 보유량으로 결정되는 회사의 기술 역량을 평가하면 안됩니다. 그곳에 일하는 사람의 기술 역량을 판단해야합니다. 그냥 잘한다, 빨리 만든다가 아니라, 조언/업무지시를 얼마나 효과적으로 주는가? & 보고 배울게 있는가?를 생각해야합니다.


일단 찾는다면, 어떻게든 최대한 가까이서 관찰하고 모방하고 질문하기 바랍니다.



2.1. Advanced Beginner에게 조언하고 싶은 것 한가지 더.


Competent를 찾았을때, 조언하고 싶은 것이 하나더 있습니다. 자신의 코드를 보여주는 것에 용기를 가지세요. 솔직히 Code Review하면, 혹자는 발가벗겨져서 홀로 나체로 서있는 기분이라고도 합니다. 분명 그런 기분이 들겠지만, 그래도 용기를 내서 Code를 내밀어야합니다. 자신의 실패를 그대로 보여 줘야 한다는 두려움을 이겨내지 못하면 제대로 배울수가 없습니다.



3. 입문자에게 하고 싶은 말입니다.


입문자는 대학 1~2학년을 비롯해  이제 막 프로그래밍 공부를 시작한 분들 입니다. 굳이 드레퓌스 모형으로 분류하면 Novice입니다.


저는 개발 코칭을 할때, 코칭받는 분의 최소 조건이 자력으로 취업용 포폴을 구현할수 있는 사람입니다. 즉 Novice는 받지 않습니다. 이유가 있습니다. 그 아래 단계에서는 일단 절대적인 지식의 양과 기초체력이 부족해서 코칭 받은 것을 실습 할 수가 없습니다. 예를 들면, 제가 차범근 감독님을 코치로 섭외해서 현란한 발기술을 보고 배워도 기본 드리블과 90분간 뛸 체력이 없어서 제대로 배울 수가 없습니다.


이 단계 분들에게 권할 것은 따로 있습니다. 책을 보세요. 가능하면 외우세요. 어느정도로 봐야하는지 기준을 제시 한다면, 대학 학부 교재의 목차만 보고 섹션별로 관련된 키워드를 전부 쓸 수 있어야 합니다. 보통 제가 이런 수준을 요구하면 과하다고 합니다. 하지만 그 키워드를 외우고 있지 못하면, 여러분들이 기초 개발 능력을 갖추고, Advanced Beginner가 되어서 Competent를 마주했을때 그 조언을 이해할 수가 없습니다. 어렵게 Competent를 찾아도 제대로 배울 수가 없다는 소리입니다. 더 안타까운 것은 Competent입장에서 가르쳐 볼만한 사람은 많기 때문에 기회가 다시 오기 어렵다는 것입니다.


그러니까 나중에 후회하지 않으려면 일단 교과서는 다 외우고 가라는 겁니다. 굳이 책을 고르자면, 언어책 2~3권, 데이터구조, 알고리즘, DB, OS, 네트워크, OOP, 소프트웨어 공학, 병렬 컴퓨팅(Thread & 분산)  정도에 각자의 분야에 따라서 몇개 더 보태는 정도 입니다. (대충 10권 정도겠네요)




능력있는 개발자는 어떻게 알아보나?


능력있는 개발자, 즉 Competent를 찾아야 겠다고 결심했다면 어떻게 찾는지를 알아 봐야겠죠.


알려져 있듯이 드뤼퍼스 기술 습득 모형은 경력하고는 관계가 매우 적습니다.

소처럼 년 몇 이상 키운다고 1등급이 되지 않습니다. 기술 레벨은 직급이나 직위, 또는 경력 년수에 상관없이 어떻게 개발을 하는가만 보고 판단해야합니다.


문제는 자기보다 윗레벨을 인터뷰로 파악하는건 거의 불가능하다는 점입니다. 어쩔수가 없는게, 표면을 보는 사람에게는 심층부를 보는 사람의 대답은 선문답이나 사기꾼 같이 들리기도 합니다.


예를 들어 저에게 객체가 뭐냐고 물으면, 객체라고 대답합니다. 사기꾼 같게 들릴수도 있지만, 객체를 가장 잘 표현하는 단어는 “객체”입니다. 객체라는 속성이 가진 각각의 측면이 가진 특징을 강의 할만큼 알고는 있지만, 그 개개의 설명이 객체를 표현했다고 하기에는 너무 빠진게 많습니다.

아니면 반대로 연봉이 걸린 면접 자리면 최대한 능력 어필을 해야하니까, 아예 고급 주제로 갈수도 있습니다. 일반적으로 다루는 Class 기반 객체가 아니라 Prototype 기반 객체와 비교를 한다거나, 아예 사전 템플릿이 없는 Duck Typing 중심으로 객체를 사용할때를 예를 든다거나, 시맨틱 웹의 온톨로지에 나오는 Class 개념과 결부시켜 설명한다거나…

(이러니 저러니 해도, 지식적으로 내가 좀 더 나을것이다 정도 밖에 안됩니다)

제가 생각하기에는  어렵게 설명하나 쉽게 설명하나 듣는 사람에게는 항상 뜬구름 잡는 설명 일 뿐이라고 생각합니다.


반대로 아랫줄을 파악하는 것은 크게 어렵지 않습니다. 15분정도 면접하면 알 수 있어요.


하지만 이래서는 Competent를 찾을수가 없겠죠.


그런데 자기 보다 윗줄인 Competent를 비교적 쉽고 정확하게 구분할 방법이 하나 있습니다.

여러분들의 (코딩 모르는 사장님이면 회사내 직원의) 코드를 리뷰하여 고치게 해보세요.


온라인으로 하면 안되고 현장에서 1시간쯤 고치게 하면 됩니다. 즉, 코드 리뷰를 시킵니다.

그리고 코드 리뷰어가 왜 코드를 이렇게 작성했는지 의도를 알 수 있게,  코드 작성자에게 질문을 할수 있어야 합니다.


수정해서 나온 결과물이 교과서에서나 보던 그런 코드 같다면, 적어도 Competent라고 볼 수 있습니다.



이에 대한 이유는 생각보다 간단합니다.


Advanced Beginner는 교과서를 흉내내려고 하지만 생각처럼 잘 되지 않습니다. 고친다고 해도 책을 보면서 고쳐야 합니다.


Competent는 교과서 내용 정도는 몸에 베여있습니다. 코칭을 할 수 있다는 것은 자기 몸이 교과서라는 의미입니다. 그래서 1시간이면 충분히 고칠수 있습니다.


Proficient 레벨은 몸이 교과서인건 마차가지지만, 직관적 레벨에서 결정을 내리기 때문에 Competent보다 더 빨리 고칩니다. 저같은 경우에는 코드 크기나 기능에 따라 다른데, 5분 ~ 15분이면 교과서적인 구조로 고칠수 있습니다.



교과서적인 코드라는 것은 퀄리티가 좋은 코드를 의미합니다. 교과서에는 전산학의 개념을 가장 잘 보여줄 수 있는 코드를 실어 놓습니다.


그러면 어떤 코드가 퀄리티가 있는 건지, 코드 품질에 대해서 예시를 들겠습니다.




The Quality Of Code


코드에는 품질이있습니다.

이건 기능에 돌아가는 것과 전혀 상관없이 코드 자체의 질입니다. 똑같이 4인승을 실어 나를수 있지만 티코와 링컨 컨티넨탈은 다른겁니다.


리뷰 대상 코드를 제공해주신 wonism 님에게 감사를 표하며  

https://github.com/wonism/easy-map/blob/master/src/easy-map.js 를 가지고, 코드 품질에 대해서  애기해보겠습니다.


wonism 님이 생코에 소개한 글에 따르면 아래 기능을 수행합니다.


정의된 생성자로 객체를 생성한 뒤 특정 메소드를 실행하면,

마커와 인포윈도우, 클릭 이벤트, 거리 표시 등의 기능이 자동으로 구현됩니다.

현재는 구글, 네이버 지도만 사용가능하지만,

다음 지도, 바이두 지도도 추가해보려 합니다.

사용 방법, 데모 실행 방법 등 README.md 파일에 상세히 설명해두었으니, 가볍게 살펴봐주세요.



우선 코드의 첫 인상은 Advanced Beginner가 작성한 것으로 보인다 입니다..



멤버 변수 이름부터가 중복이 과합니다. prefix  형태로 쓰였는데, 그런 반면에 같은 대상에 대한 데이터를 같이 묶는( structure나 Class를 쓰는) 기법이 보이지 않습니다.


아래가서 찾아보니,



역시나 2개는 같이 묶여서 다닙니다.

외부가 Class EasyMap로 감싸여져 있긴하나, Class를 교과서처럼 쓸 수 없다고 판단 할 수 있습니다.




조금더 보니 Switch문이 보입니다.

oop에서 Switch가 과하게 등장하면, 추상화 개념을 아직 적용못했다는 의미 입니다.



혹시나 해서 검색해보니, 다해서 7군데 switch (this.mapType)이 쓰였습니다.

보다 보니까 함수 길이도 엄청나게 깁니다.


markCurrentPosition() 함수는 120줄 정도, createMarkers()  140줄 정도 subscribeInfoWindow()도 100줄 정도 입니다.


그리고 저 함수들 마다 Switch가 다 들어가 있네요.


작업자는 문제 해결하는 루틴을  함수 하나 안에 주르륵 쓰고 있습니다.

따라서 체계적으로 계획을 세우는 함수 단위의 사고 적용을 잘 못한다 고 평가할수있습니다.



전체 코드를 다 본 평가도

아직 교과서를 자기 몸에 체화하지 못한 Advanced Beginner로 결론을 내리겠습니다.


이제 본격적으로 고쳐보겠습니다.


일부나마 좀 더 전산학적으로 이쁘게(= 교과서에서 보던 것처럼) 고치려면 이렇게 해야합니다.



우선 Marker를 클래스를 사용해서 데이터를 묶습니다.

markerNames와 Ids는 없애고, markers = [] 로 선언하고, Marker클래스는 name과 id를 가지게 합니다.

그리고 위 루틴은


for (let j = 0, len2 = tempCoordsArr.length; j < len2 ; j++){
	var coord = tempCoordsArr[j];
	var marker = new Marker(coord.__id, coord.__name )
	this.markers.push(marker);
}

으로 고쳐야 겠습니다.

Marker의 생성자는 (id,name)을 받아서  486, 487 라인과 동일한 일을 하도록 합니다.


이렇게 함으로써, markerName과 markerIds가 일치하지 않아,

문제가 발생할 가능성이 사라졌습니다.


그리고 대대적으로 고칠것은  Switch를 수정하는 것입니다. 전체 함수 영역에 걸쳐서 switch분기가 나오는 것은 추상화가 안된것입니다.


그러니 NaverMap Class와 GoogleMap 클래스를 따로 만들어서 각각에 해당하는 기능만 넣습니다.


정리하자면 구조가 아래와 같게 나와야 합니다.


class NaverMap  
markCurrentPosition()  { … } 
createMarkers()   { … } 
subscribeInfoWindow() { … } 


class GoogleMap  
markCurrentPosition()  { … } 
createMarkers()   { … } 
subscribeInfoWindow() { … } 



class EasyMap
	constructor(obj) {  
… 
if(this.isValid(obj)) { … } 
this.createConcreteMap()
 }


markCurrentPosition() {
	this.MapImplement.markCurrentPosition() 
}
createMarkers() {
	this.MapImplement.createMarkers() 
}
	subscribeInfoWindow() {
	this.MapImplement.subscribeInfoWindow() 
}


createConcreteMap(){
switch(this.mapType)
	case “naver”:
		this.MapImplement = new NaverMap()
	case “google”:
		this.MapImplement = new GoogleMap()


}

이제 추상화 개념을 적용하여 EasyMap은 구체적 구현 코드에 영향을 받지 않습니다.


디자인 패턴으로 따지면 Adapter 패턴으로 형태를 잡은 것입니다.


또한 subscribeInfoWindow등 100줄 단위의 함수를 mapType별로 Class를 묶었으니 50줄 정도 됩니다.

50줄이면 더 쪼갤 필요는 있는데 여기서는 생략하겠습니다.




그리고 역시 switch 는 코드가 너저분 하니까  

createConcreteMap()을 좀더 수정하여 아래처럼 고칩니다.

createConcreteMap(){
	var type = {
 naver: NaverMap, 
google: Googlemap
	}
	constructor = type[this.mapType]
	if(constructor  == undefined) 
throw new Error(“Not Supported”)  
	this.MapImplement  = new constructor()
}

이정도 고치는데 5~10분 정도 들어갑니다.


그러나 변경 이후에는

Naver와 Google에 변동사항이 생겨도 각각의 Adapter Class에만 영향을 줍니다.

하나의 오류가 시스템 전체로 퍼지지 않게 보장됩니다.


전체적인 구조는 일관되게 동작할수 있으며. DaumMap 클래스를 구현하고 createConcreteMap 함수에 집어 넣기만 하면 루틴이 동작할수 있습니다.

유지보수 및 확장이 쉽다는 의미입니다.



아마 기존 소스에

DaumMap을 붙이려면, 모든 Switch를 찾아서, 100줄 짜리 함수들이 다 150줄이 되었을 것입니다.


그리고 구글 지도에 패치를 했을때 네이버 지도 기능에 영향을 안주는 것을 보장 할 수가 없습니다.

결국은 모든 지도를 다 테스트해야 출시할수 있게 됩니다.


코드 퀄리티는 이런것입니다.

굳이 표현하자면, 전산학에서 정립된 개념을 얼마나 반영했는가가 코드 퀄리티의 척도라고 말 할 수 있습니다.


그리고 효과는 엄청날 수 밖에 없습니다.

좋은 것을 만들기는 어렵지만,

좋은 것을 쓰기는 쉽습니다.


조직을 운영하는 분들은 느끼셨을것 같지만,

만드는데 품이 많이 들어가는 작업은 Advanced Beginner가 거의 하고, Competent는 그걸 정리해서 수준을 끌어 올립니다.

하지만 작업해서 나온 결과물의 사용성 / 안정성은 Competent가 모두 직접 만든 것에 비해서 크게 떨어지지 않습니다.

게다가 Advanced Beginner는 자신이 100% 작업한 코드보다도 Competent가 체계적으로 정리해둔 코드를 사용해서 개발할때,  오류도 훨씬 적고 속도도 빨라져 생산성이 올라갑니다.


그리고 Advanced Beginner레벨에 있는 분들은

어떻게든 능력있는 개발자를 찾아서  좋은거 많이 보고 모방해서 자기 것으로 하기 바랍니다.


흔히, 다른 사람이 작성한 좋은 코드를 보면 많이 배운다고 합니다.


하지만, 그것보다 더 빨리 배우는 방법은

자기가 작성한 코드가 좋은 코드로 변화하는 모습을 보는 것입니다.



왜냐면,  교과서적으로 좋은 코드를 볼 땐,  그 사람이 이미 잘하니까 이런게 가능하겠지라고 생각하게 됩니다. 하지만, 내 코드가  품질 개선이 되는 과정을 직접보고 이해하면, 나도 저렇게 할수 있다 라는 생각을 가지게 되기 때문입니다.



저는 여러분들이 단지 우리나라서 하던일만 잘해도 해외 개발사의 오퍼를 받는 것이 가능하다는 소식을 듣는 것만이 아니라, 코드 품질을 더욱 중요하게 생각해주셨으면 좋겠습니다.


해외 개발사에서는 코드 품질을 중요시하고, 그런 품질의 코드를 만들수 있는 사람을 대우하기 때문에, 저에게 제의를 했다고 생각합니다. 우리나라에서도 개발을 할때는 빨리 / 많이 만드는 것보다도 코드 품질을 더 중요하게 생각하는 문화가 생기길 바랍니다.


아울러 여러분들이 능력있는 개발자를 찾아 평생 동업자가 되거나 맨티를 자처하거나 또는 그 어떤 방향에서든지 생각하는 바를 얻을 수 있기 바랍니다.


원문 링크 : https://docs.google.com/document/d/1_phA5XUszSmN7Ta-QHs4DxRz9_iu8YlhxpVjSGEbWcg/edit

42
44
  • 댓글 29

  • kmksk
    883
    2017-01-18 16:12:31.0

    와 이거뭐야 정말 소름 돋게 좋은 글이네요!

    1
  • 진C
    1k
    2017-01-18 18:06:18.0

    길어요! 일단 선댓 후감상!

    오늘도 좋은(을?) 글 소개 고맙습니다!

    추워요 감기 조심하세요~

    1
  • 하마
    3k
    2017-01-18 20:00:40.0 작성 2017-01-19 14:09:05.0 수정됨

    주변에 좋은 개발자들과 함께 한다면 그보다 좋을것은 없을 것입니다. 이 시너지 효과가 상당하거든요. 그런 부분에 대해서는 공감이 됩니다. 그렇다고 좋은 개발자가 왜 내 주변에 없나 라고 푸념할 필요는 없습니다. SW 분야는 나름 축복받았다는게 오픈소스라는 훌륭한 스승이 너무 가깝게 있기 때문입니다.


    몇가지 코멘트를 남겨보자면 

    1. 능력있는 개발자를 선별하는것은 중요하지만, 더 중요한것은 능력있는 개발자를 찾을 필요가 있는가? 에 있습니다. 하지만 현재  대한민국의 SI 시장에서는 그럴 필요가 없어도 상관 없는게 문제라 그럴 필요가 있도록 만드는게 병행되야 할 거 같습니다. 

    2. 글쓴이가 수정한 코드는  어댑터 패턴과는 전혀 상관이 없으며  다른 GOF 패턴과도 별로 상관이 없습니다.( 즉 추상팩토리 패턴이나 팩토리 메소드 패턴과도 거리가 있습니다.) 굳이 말하자면 단순 팩토리 패턴이네요.

    3. 아래 코드가 과연 더 좋아 졌다고 말 할 수 있는지 잘 모르겠습니다.

    var type = {
    naver: NaverMap, 
    google: Googlemap
    	}
    	constructor = type[this.mapType]
    5
  • 송사리야
    34
    2017-01-19 10:09:26.0

    잘보았습니다!

    감사합니다.

    0
  • byeworld
    2k
    2017-01-19 12:25:43.0

    이 글이 돌고 돌아 여기도 오는군요. 

    역시 좋은 글은 많은 사람들이 알아보는 것 같습니다.

    0
  • inyl
    1k
    2017-01-19 16:23:55.0

    나만 그런가

    고친게 그닥 품질이 좋아보이지가 않는데..

    1
  • tale33
    24
    2017-01-19 19:00:22.0 작성 2017-01-19 19:04:00.0 수정됨

    맵을 공통인터페이스로 구현한것은.. 그냥 oop의 다형성이네요.

    어댑터라고 설명하신것은 인터페이스를 맞춘다의 의미로 설명하신것 같습니다.

    보통의 어탭터는 has a인 반면에 예문의 예제는 is a라 차이가 있기는 하네요.

    충분히 좋은 글인 것 같습니다 ^^

    0
  • kim2
    12
    2017-01-19 20:35:27.0

    단어 Competent 를 해석하지 않고 영어로 계속 쓰는 이유가 있나요?

    0
  • 말년개발
    1k
    2017-01-20 10:39:48.0

    아 좋은 글이네요....

     beginner에게는 많은걸 느끼게 할수 있을듯..

    0
  • Dive_Drink_Develope
    1k
    2017-01-20 13:56:38.0

    kim2 //Competent 를 어떤단어로 해석하는게 좋을까요?

    0
  • 서비스지향개발자
    5k
    2017-01-20 15:19:34.0

    잘 모르면서 잘하는 사람 뽑는건 신기에 가깝습니다.

    몇마디 나눠보면 들통이 나는데도 잘 모르면 알지 못합니다.

    개발 생활 하면서 아는척 가르치듯 아무말이나 코치하듯 하는사람들 엉뚱한 방향으로 가게 만드는 사람들이 겉으로 보기에 슈퍼개발자처럼 보입니다.

    그런사람을 어떻게 알아볼까요. 실력이 없으면 못알아보겠죠.


    2
  • 망한개발자
    1k
    2017-01-20 23:34:06.0

    노는개발자님 말씀에 공감합니다.

    인재를 알아보는 혜안이 있어야 합니다.

    단순히 이런저런 방식으로 인재를 알아본다는건 무리가 있습니다...

    선수는 선수를 알아본다는 말도 있습니다..

    0
  • Taetrees
    542
    2017-01-21 21:42:59.0

    어느 회사는 더 나은 개발자들만 추가로 뽑는다는데

    그 이유를 보면 팀 전체의 퍼포먼스가 떨어질 수 있기 때문이라고 하죠.

    어느 정도 공감하는게 좋은 개발자가 들어오면 팀 퍼포먼스가 올라가는걸 느껴지죠.

    그런데 한국 회사에서의 연차와 경력으로 누르면 잘못된 설계라도 바꾸지 못하고 진행해서 좋은 개발자가 있어도 팀 퍼포먼스가 떨어지는 사례도 많죠.

    0
  • 겸손합시다
    206
    2017-01-24 10:48:18.0

    맹신하지마세요

    때론 슈퍼클래스가 추상화 덕지덕지 된 코드보다 유지보수가 좋을때도 있습니다

    코드의 퀄리티는 개발자의 실력을 나타낼수 있는 척도가 될 수 있지만 그게 전부가 아닙니다.

    1
  • 율아빠
    4
    2017-01-24 13:58:50.0

    매우 좋은 글입니다.

    다만 위 방법만으로 좋은 개발자 채용을 기대할 수는 없다고 생각합니다.

    아래 링크도 한번 같이 읽어보시구요.

    https://blog.codinghorror.com/we-hire-the-best-just-like-everyone-else/

    개발자로서 일정 수준이 넘어서면 리팩토링과 튜닝을 선별적으로 하거나 의도적으로 안하는 수준이 되는데, 그런 수준의 개발자는 코딩/코드리뷰 테스트가 오히려 또 독이 됩니다. 제프 앳우드 표현처럼 코드리뷰도 '지극히 취약한 증거' 에 불과하니까요.

    코딩테스트/코드리뷰는 사실 C 급을 걸러내는 장치 중 하나로만 생각해야 합니다.

    OOP, Functional, Declarative 같은 트렌디한 형식에 갖혀 있지 않은 A급 개발자는 오히려 코딩테스트/코드리뷰 때문에 놓치게 될 수도 있습니다.

    능력 있는 개발자 채용은 '정말로' 어려운 난제 입니다.


    2
  • rapgod
    51
    2017-01-25 11:28:07.0
    너무 좋은글 감사합니다. 덕분에 많이 느끼고 생각하게되네요


    0
  • 동동아빠
    167
    2017-01-26 13:08:08.0

    너무나도 좋은 글 감사합니다.

    많은 것을 느끼고 생각할 수 있었습니다.

    감사합니다.

    0
  • 심심한사부
    622
    2017-01-31 16:13:58.0

    일반 개발자는 슈퍼 개발자를 알아보지 못할듯 합니다...

    세상은 자신이 아는 만큼만 보이니...



    0
  • 깨우침을주세요..
    592
    2017-02-02 21:57:06.0

    감사합니다...!

    0
  • 샬쿰
    17
    2017-02-06 14:40:01.0
    첫 직장에서 만났던 팀장님 competent 이상의 실력을 가지신 분이였네요 많이 배웠는데 좀더 배우지 못한게 아시워지게 하는 글 이네요 ㅜㅜ
    0
  • SupinanDateFormat
    24
    2017-02-08 22:48:28.0

    감사합니다

    잘 읽고 갑니다

    0
  • 양돌이
    199
    2017-02-09 13:36:19.0

    스킬업을 하고 싶은데 약간 정체기에 좋은글을 만난거 같아 도움이 되었습니다 감사합니다

    0
  • 냉초코
    107
    2017-02-10 14:35:58.0

    좋은 스승을 찾는건 어떻게 할 수 있나요. 사수는 정말 운이라고 생각하는데... 이게 노력으로 해결이 되는 문제는 아니라고 생각하거든요.....

    좋은 스승 밑에서 일하고 공부하고 싶네요 정말,.... 방법이 있다면 이것도 좀 공유좀 해주세요 ㅠㅠ

    0
  • 답이있소?
    84
    2017-02-18 15:39:27.0

    잘 읽었습니다.

    0
  • 지구촌아이
    252
    2017-02-22 10:04:17.0 작성 2017-02-22 10:05:23.0 수정됨

    코드품질 안좋아졌다고 하는분들은 그럼 저거보다 어떻게 해야 좋은 품질인가요?

    궁금해서 제가 생각하는게 틀릴수도 있다고 생각해서 드리는 질문입니다.

    일단 객체 지향에 맞게 객체단위로 나눠서 정규화하고 코드량을 줄일수 있는 좋은 리팩토링을 한거같은데

    뭐가 문제인가요?

    예제 소스가 짧아서 그렇지만 저기서 구글맵,네이버맵 외에 다음맵이라던가 다른 맵을 추가할시 단순 스위치문에 케이스 하나더만들고 그 밑에 나열하는것보다 메인소스는 최대한 건들지 않고 추가되는 맵종류만 클래스 단위로 추가해주면 다른 맵에 잘못된 소스로인해 에러가 전달되는현상도 막을수있는 효율성있는 코드같아서 하는말입니다. 궁금하네요

    0
  • 빨간악마
    2
    2017-03-24 20:34:37.0 작성 2017-03-24 21:24:56.0 수정됨

    좋은 내용이 많네.

    근데 코드 리뷰로만 개발자 역량이 판단 되는 부분이 많은데

    개인적인 생각으로 제대로된 코드리뷰는 설계문서를 기반으로 문서대로 만들어 졌는지를 파학하기 위한 과정이 선행되어야 제대로된 코드리뷰이지 않나 생각되는데요.

    즉 설계문서 없이 코드리뷰는 사실 해당 언어의 숙력도와 고급 기법 사용의 측면만 볼수있게 한정되어지지 않나 생각됩니다.

    사실 코드리뷰는 설계문서를 기반으로 [설계 문서가 존재하고] 문서 대로 잘 만들어졌는지를 파학하기 위한 한 부분이지 그걸로 개발자의 능력을 슈퍼개발자를 파악하기는 어렵다고 봅니다.

    집을 짔는다는 과정에서 정말 단순한 개집을 지을게 아니라면 기본적으로 설계도가 존재하고 설계도를 기반으로 작업인부들이 어떤 공법으로 어떻게 지을지 도면을 보고 작업을 한다면

    현재 한국에서 개발하는 개발 방법은 개집짓듯이 설계도도 없이 집을 짓는 어처구니 없이 비효율 적인 방법으로 개발을 하고 있지 않나 생각합니다.

    즉 여러 명의 작업자가 설계도를 보고 그것에 맞게 작업을 한다면 중간에 작업자가 교체 된다 하더라도 작업이 수월하게 진행 될것이고 도면이 있으니 유지보수가 수월해지고 SVN 같은 형상 관리 툴[설계문서 없이 형상관리툴 사용은 매우 비율적이라 생각합니다.] 사용에 문제가 생겨도 도면대로 다시 수정하면 되고 도면에 명시된대로 작업이 잘됬는지 코드리뷰를 통해 확인해서 수정하는 일원화된 시스템이 완성 된다고 봅니다.

    [사실 형상관리툴을 당연하게 쓰는 곳이 많은데 왜 쓰는지 이해하고 쓰는곳은 거의 못본듯 합니다.설계계념 없이 사용해서 발생하는 문제 라고 봅니다.]

    사실 이런 부분은 굉장이 서양적인 사고방식이 다분히 포함되어 있다고 봐야겠죠. 생상성,효율성, 그리고 합리성을 추구하는 민족이 만든 개발방식이니 그 문화가 담기는 것은 당연하고 보는 시각입니다.

    작업자는 하나의 부품이고 교체 가능하게 만들려면 설계문서가 반드시 있어야 하거든요. 

    이러면 유지보수 및 코드 질 향상과 생산성 증가 및 관리의 편의성이 한번에 해결된다고 봅니다. 물론 이런 시스템은 모바일이나 빠르고 새롭게 만들어지는 신기술분야에는 적용하긴 어렵죠. 그런 분야에선 애자일이나 익스트림 같이 설계개념보단 요구사항이 위주의 방법을 쓰긴 하죠.

    중요한건 설계문서를 만들수 있는 능력을 가진 사람이 거나 특정 프로젝트의 규모와 스팩을 보고 설계문서의 필요성을 판단해서 결정을 내리고 그에 어울리는 설계공법을 적용해서 진행할 수  있는사람이 수퍼개발자 혹은 아키텍처 가 된다고 보는 입장입니다.

    코드리뷰에 너무 집중해서 능력있는 개발자에 관해서 이야기하시는 것 같아 부족한 지식으로 몇자 적어보았습니다.

    0
  • benjK
    27
    2017-03-26 22:23:45.0

    좋은 글 정말 감사합니다.

    큰 충격을 받고 갑니다.


    0
  • 휴먼1
    300
    2017-03-27 15:38:59.0

    이런 기준이 있다는거에 놀라고 한가지 새로운 방향을 알게된거 같습니다.

    감사합니다.

    0
  • 원시크
    22
    2017-05-18 18:26:40.0
    좋은 글 감사합니다.
    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.