생각대로 살지 않으면 사는대로 생각한다.

프로그래머의 리더십 국내도서 저자 : 정영훈 출판 : 한빛미디어 2015.01.05 상세보기

프로그래머의 리더십 (어느날 갑자기 프로젝트 관리자가 되었다. 뜨~아악!)-정영훈

+어느정도 개발년차가(3년이상~) 된 개발자에게 꼭 권하고 싶은 책중에 하나다.

하나 하나 챕터들 모두 그냥 넘기기 아깝다. 5년차를 넘어서 서서히 중간관리자로 넘어가는 사람에게는 특히 도움이 많이 된다.이 책을 읽으면서 저자에게 고마운 마음이 많이 들었다. 저자는 단순히 책을 내서 금전적인 이득도 생각했겠지만 책을 읽다보면 그런 의도보다 선배 개발자로써 후배 개발자들에게 친형처럼 조언을 해주는 느낌을 많이 받았다. 진심으로 본인이 경험과 노하우를 전달해주려는 마음이 많이 보였다.

[핵심적인 내용들]

1.같은 업종이나 회사에서 일한 지 3년 정도가 되면 기술자로서 알아야 하는 지식 중 98%를 습득할 수 있게 된다.3년차 프로그래머와 10년차 프로그래머가 와성한 소프트웨어의 품질은 외관상으로는 쉽게 느낄 수 없다. 하지만 소프트웨어를 운영해 보면 안정성과 유지보수의 편리함에서 크게 다른 것을 알 수 있다. 전문가와 기술자를 구분하는 2%의 기술 차이는 7년 이상의 경험으로 채울 수 밖에 없다. 전문가는 다 채우지 못한 2%를 위해 최소 7년이상을 자신만의 노하우를 만들고 실력을 갈고 닦으며 보낸다. 

2.프로그래머의 일반적 요구사항

  2-1.금전적 요소 : 적절한 연봉, 업무 강도, 시간의 적설함, 근무환경과 처우

  2-2.지적 요소 : 기술, 노하우 습득 환경, 성정을 느낄 수 있는 프로젝트, 회사에 기여하고 인정받을 수 있는 업무

기술과 노하우 전수를 통해 프로그래머의 만족도를 높이는 것이 더욱 효과적인 전략이다.프로그래머는 지적 욕구와 성장에 대한 기대가 많아서 기술에 대한 갈망이 상당히 크다. 

3.매슬로우 욕구 5단계

 -1단계/2단계/4단계는 회사  경영층에서 관리하는 요소로 중간관리자인 리더가 할 수 있는 권한이 적은 경우가 많다. 하지만 이런 부분까지 개선할 수 있다면 더 쉽게 리더십을 발휘할수있다.

 -리더로써 좀 더 집중할 부분은 3단계의 사회적 욕구와 5단계의 자기 발전의 욕구다. 사회적 욕구에는 소속감이 있는데 팀원들이 잘 조화롭게 팀에 동화될 수 있게 역할이 필요하다. +마지막 단계인 자아실현에서도 끊임없이 자기 계발을 할 수있는 환경을 조성해주고 외부교육 및 내부교육을 통해서 지속적인 자기 계발을 할 수 있도록 해야한다.

4.리더는 점점 성장하는 팀원이 자신의 자리를 위협하는 것을 크게 두려워 할 필요가 없다. 팀원이 리더를 뛰어 넘을 확률은 10%에 지나지 않는다. 팀원이 치고 올라오는 것을 두려워해서 앞길을 막는 전략은 하책이다. 

5.리더는 새로운 업무에 대한 정보가 확실해질 때까지 프로그래머에게 통보하지 않고 지금 프로그래머가 한창 진행하는 작업이 완료될 때까지 기다려야한다. Context Switching이 발생하기 때문이며, 해당 정보가 나중에 취소나 변경이 될 가능성이 있기 때문이다. +또한 실제 개발자들이 외부 고객사로 부터 전화대응을 직접적으로 하지 않게 해야한다. 중소 기업의 경우에는 DevOps를 하는경우가 많은데, 개발중에 전화대응을 하게 되면 아무리 사소한 일이라도 업무가 중단이 되고 다시 코드베이스로 돌아가서 작업이 바로 진행이 되지 않는경우가 많다. 최소한 외부의 전화를 받아서 전달해주는 직원이 필요하며 개발자는 긴급한 내용이 아니라면 나중에 몰아서 처리하는것이 좋다.

6.리더가 담당해야 할 중요한 임무 중 하나는 인재 양성이다. 프로그래머의 업무능력을 키우기 위해서는 실전을 자주 접할 수 있게 해주는 것이 필요하다. 그러니 주니어 프로그래머에게 개발만 시키지 말고 고객의 요구사항을 직접듣게 하고, 유관부서와 협의 미팅에 참석하게 하자. 

7.Pair Programming:모니터 하나를 두고 직접 코딩하는 프로그래머와 코딩하는 프로그래머 뒤에서 검토해주는 프로그래머가 한팀이 되어 프로그래밍 하는것. 생산성이 40%증대 된다. 또한 주니어를 시니어가 교육하기에 좋으며 부담감도 줄어들게 된다. 

8.프로젝트 문제가 발생시  대안없이 팀원들과 위기 상황을 공유하지 말고, 정답은 아니지만 대안을 먼저 제시한다. 

9.프로그래머가 기술적 어려움을 호소할 때 대처방법

   9-1.답을 모를때 : 가이드 제시 , 브레인 스토밍 , 위임(좋지 않음)

   9-2.답을 알때 : 단서를 제시(시니어),정답을 알려줌(주니어),직접 해결(좋지 않음, 납기가 촉박할 때만 사용)

10.프로그래머는 원인과 과정이 확실한 논리적인 말을 중요시한다. 프로그래머는 단답식으로 짧게 중요한 포인트만 들어 있는 대화를 좋아한다. 일과 크게 관련 없는 구구절절한 대화를 좋아하지 않는다. 

11.팀원이 언제나 좋아하고 편히 여기는 리더는 이 세상에 없다. 회식에 참석하여 계산만 하고 바로 가는 것이 정답.

12.론다번의 저서 '시크릿'을 보고 깨어나게 되었는데, 한줄로 요약하면 상상한 것은 현실화 되어 돌아온다.  또한 꿈꾸는 다락방 책도 좋음. +역시 NLP의 힘을 여기에서도 느끼네요.

13.내 밥그릇을 깨 뜨리자.훗날 도태된 기술이 됨, 혼자 보수하기 번거로움,문제 발생시 대신 해줄 사람이 없음.

  뒤처지기 전에 자신의 새로운 기술을 빨리 익히고 경쟁하면 된다.

14.프로페셔녈 프로그래밍에 보면 10년 이상의 프로그래머는 글을 써야 한다고 나와있다. 노하우나 경험을 담아서 후배 프로그래머에게 전해주자.

15.을의 처지에서 무시를 당하는 것이 패배가 아니다. 무시를 당하고도 고난을 통한 인성의 발전과 실력 향상이 없는 것이 진정한 패배다. 

팟캐스트 나는 프로그래머다 2탄 국내도서 저자 : 임백준,정도현 출판 : 한빛미디어 2016.07.01 상세보기

나는 프로그래머다 -2편

+나는 프로그래머다의 후속편이다. 다시 읽어 볼 만한 내용을 정리했다.

[핵심적인 내용들]

1.개발자 컨퍼런스를 즐기는 방법

   열정 ->예습->철판->정리(반드시 1시간 안쪽 분량으로 정리)->발표

2.Node.js는 생산성의 높다. 적합한 서비스는 채팅처럼 아주 간단한 연산이 필요한 애플리케이션이다. I/O가 큰작업들, 예를 들면 DBMS의 트랜잭션이 되게 긴 쿼리를 처리하는 그런일에는 완전 쥐약이다. 또한 컴파일하고 실행시키는 과정이 없기 때문에 개발한 로직이 실제로 수행되어야만 에러를 발견할 수 있어서 죽는 경우가 많다.

3.Fake it till you make it  그렇게 될 때까지 그렇게 된 것처럼 행동하라. 개발자가 성장하기 위해서 반드시 필요한 심리적 덕목.자기가 벌여놓은 'fake'를 구체적인 실천을 통해서 뒷바침하지 못하는 경우가 문제다.

4.프로그래밍 대회 준비 사이트 : 알고스팟(https://algospot.com),코드셰프(Codechef),프로젝트오일러(ProjectEuler),리트코드(LeetCode),구글 코드잼( Google Code Jam)등을 통해서 꾸준히 머리를 풀면 좋다.

5.C#과 타입스크립트를 개발한 앤더스 하일스버그의 말

 =>가장 중요한 것은 항상 직접 코딩해보는 것입니다. 지금은 설계에 상당 시간을 쓰고 있지만, 나는 아직도 많은 코드를 쓰고 있습니다. 왜냐하면, 직접 코딩을 해봤을때만이, 무엇이 동작하고 무엇이 동작하지 않는지 느낄 수 있기 때문이죠, 개발자가 일단 코딩을 멈추게 되면, 굉장히 빨리 높이 올라가서 어느덧 아키텍트 혹은 뭐 우주비행사 같은 게 되어서 지꺼링게 되죠, '뭐든지 가능하다','사람 더 쓰면 된다'등등...하지만 정말 실상은 그렇지 않습니다.

6.A급 개발자들은 A급 실력을 유지하기 위해서 20~30%의 시간을 자기계발에 쓰는 사람들이다. 개인 프로젝트를 진행하거나, 세미나를 하거나, 책읅 읽거나 커뮤니티 활동을 하거나, 그게 뭐든 자기 실력을 키우고 가다듬기 위해서 시간을 할애한다. 

7.프로그래밍 언어도 언어의 일종이기 때문에 어린 나이일수록 배우기가 유리하다는게 언어 학자들이 밝혀낸 사실이다.

8."IT 엔지니어의 제로부터 시작하는 영어 공부법"에 소개된 영어 공부의 다섯가지 원칙

 8-1.사운드 퍼스트(Sound First) : 먼저 귀가 뚫려야 한다. 외국어에 대해서 언어가 아닌 노이즈로 인식한다. 원어민의 발음에 최대한 가깝게 소리를 낼 수 있게 발음과 억양을 연습하는 것이 맨 처음 이뤄져야함.

 8-2.다이렌트 이해의 원칙(Direct Understanding) : 영어를 번역해서 생각하지 말고 영어 그대로 이해한다.

 8-3.스피킹중심의 원칙(Speaking Centered):네이티비의 발음과 역양을 흉내 내어 음독하는 것은 영어를 유창하게 말하기 위한 초필살기. 한국식 발음으로는 아무 소용이 없다. 음독시에는 녹음기 기능을 이용해서 발음 체크.

 8-4.문맥 이해의 원칙(Contextual Experienced) : 자잘한 단어나 문법이 아닌 전체적인 문맥으로서 문장을 이해.

 8-5.선택과 집중의 원칙(Choice and Focus):미국식 또는 영국식 둘중에 선택. 자신이 주로 사용하고 싶은 쪽으로 타켓팅해서 그쪽 분야의 영어를 집중적으로 공략.

읽기 좋은 코드가 좋은 코드다 국내도서 저자 : 더스틴 보즈웰,트레버 파우커 / 임백준역 출판 : 한빛미디어 2012.04.10 상세보기

The Art of Readable Code ( 읽기 좋은 코드가 좋은 코드다 ) -Dustin Boswell and Trevor Foucher

+정말이지 프로그래머라면 반드시 읽어야 되는 책중에 하나라고 생각합니다.

코드는 읽기가 좋아야 나중에 유지보수도 쉽고 개발중에도 더 빠른속도로 파악이 가능하며 생산성도 높습니다.

가독성 향상을 위한 작명법,주석, 빈줄 삽입등 간단한 규칙만 지키면 코드를 더 읽기 쉽고 유지보수가 쉽게 만들수가 있다. 아래는 간단히 정리하였지만 꼭 1독 이상을 권장합니다.

[핵심적인 내용들]

1.tmp나 rtval 같은 보편적인 이름을 사용하지 말고 변수값을 설명하는 이름을 사용하라.

  보편적인 이름을 사용하려면 꼭 그렇게 해야하는 이유가 있어야한다.

2.명확한 변수명을 사용하면 가독성도 좋을 뿐만 아니라 버그도 줄일수 있다.(변수명에 sum 인데 -를 하는경우등)

3.변수명에 단위를 포함하거나 중요한 속성을 포함해서 작성한다.

   dealy->delay_secs , size->size_mb / html_utf8

4.변수명의 약어를 정할 때는 팀에 새로 합류한 사람이 변수가 의미하는 바를 이해할 수 있다면 좋은 작명이다.

5.클래스 표기법 

  -클래스명은 Camel 표기법

  -클래스 member 변수는 _로 끝남

  -클래스 메소드는 대문자로 시작(? 소문자 아닌가?)해서 Camel표기법

6.변수명은 부정어 보단 긍정어를 사용하라 ( isNotExist => isExist )

7.메서드명은 해당 작업이 어떤식으로 진행되는지 표현이 가능해야 한다. 보통 get으로 시작하는 메소드는 가벼운 접근자로 생각한다.그런데 이러한 메소드에 상당히 시간이 걸리는 작업을 하게 되면 문제가 발생할 수 있다.

8.비슷한 코드는 비슷하게 보여야 한다. 일관성과 간결성을 위해서 줄 바꿈이나 공백등을 도입하라. 필요하다면 헬퍼 메소드를 이용해서 간결하게 처리하라. 빈줄을 이용해서 커다란 블록을 논리적인 문단으로 나눠라.

9.일관성있는 스타일은 '올바른'스타일 보다 더 중요하다.

10.코드의 한곳에서 A,B,C가 순서대로 언급이 되면 다른곳에서도 동일한 순서를 지켜라

11.코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 마라

12.좋은 코드 > 나쁜 코드 + 좋은 주석

13. 코드에 주석 달 때 프로그래머 사이에서 널리 사용되는 표시

  -TODO: 아직 하지 않은 일

  -FIXME:오동작을 일으킨다고 알려진 코드

  -HACK:아름답지 않은 해결책

  -XXX:위험! 여기 큰 문제가 있다.

  -TextMate :ESC

14.조건문에서 왼쪽 : 유동적인 '질문을 받는'표현 , 오른쪽 : 더 고정적인 값으로, 비교대상으로 사용되는 표현

   if(bytes_received > bytes_expected)  vs  if(bytes_expected > bytes_received) 

15.기본적으로 if/else를 사용하고 ?:를 이용하는 삼항연산은 매우 간단할 때만 사용하라

16.중첩을 최소화 하고, 함수 중간에서 반환하여 중첩을 제거하라.

17.변수는 함수의 시작 상단에서 모두 정의하지 말고 필요한 시점 바로 전에 정의해서 사용하라

18.할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다. - 알버트 아인슈타인

19.매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라. 이미 존재하는 라이브러리로 자신의 문제를 풀 수있는 상황이 많다는것을 잘 모른다. Don't reinvent the Wheel