프로그래머로 산다는 것
유석문 이사 / 신규서비스개발실
NHN Technology Services
CONTENTS
1. 개발자???
2. 좋은 개발자???

3. 좋은 개발자!!!
0. 프로그래머로 산다는 것

2013년 문화체육관광부 우수학술도서

2012.09.26 로드북

황상철

하호진

이상민

김성박
0. 프로그래머로 산다는 것 FAQ

화장실에서도 일하란 말이냐??

필자 중 누구의 다리냐??
1. 개발자???
개발(놈)者
1.1 개발자??? or ??????
상황: Java 3 ~ 5년 경력 기술면접

응??

Class Stack() {
……
}

으응??

최근에는 개발보단 관리를 많이 하느라 …

이미지 출처: http...
1.2 개발(놈)者 Begins – 업무 할당

비극 또는 일상의 시작 ~!!

이 일을 언제까지 끝낼 수 있겠나?

참고로 시간이 없네.
이미지 출처: http://elderonamission.blogspot.kr/2...
1.2 개발(놈)者 Begins – 업무 수행

검색

복사 & 붙여넣기

이미지 출처: https://fisher.osu.edu/blogs/ftmba-admissions/tag/dead
line/
http://www....
1.3 개발(놈)者의 탄생 주역

나쁜 고객과 상사

이미지 출처: http://www.fanpop.com/clubs/kuzco/ima
ges/30859484/title/kuzco-3-photo
http://4reall...
1.4 개발자의 필수능력

깔끔한
코드

적절한
논리력

• 사람이 이해하기 쉬운 코드

• 원리 탐색 능력

• 변경이 용이한 코드

• 제약조건을 고려한 해법

• 유지보수 비용이 낮은 코드

• 단순한 디자인

이...
1.5 깔끔한 코드 작성법

개발자

ATDD

Acceptance Test
Driven Development
고객

TDD

Test Driven Development
이미지 출처: http://www.solution...
1.5 깔끔한 코드 작성법

이미지 출처: http://asynchrony.blogspot.kr/2008/12/hendrickson-on-atdd.html
1.5 깔끔한 코드 작성법

• 사용하는 코드만 만들기(Caller Create)
• 리팩토링(Refactoring)
• 코드 읽기(Code Review)

이미지 출처: http://diogoosorio.com/blo...
1.6 적절한 논리력

• 알고리즘과 데이타 구조(Don’t Reinvent The Wheel)

• 단순한 디자인(Simple Design)
• 진화적 디자인(Evolutionary Design)
• 협업(Cooper...
1.7 실천법

• 꾸준한 연습(Daily Practice)
• 매일 몸값 올리는 시간을 가져라

• 멀리 가고 싶다면 함께 가라

• 현재 필요한 만큼만 하
라
• 간단하게 하라

이미지 출처: http://www.m...
2. 좋은 개발자???
2.1 좋은 OO 개발자???

• 시간 변동성 없음

“좋은”

개발자
서버, 웹, 클라이언
트, 임베디드, 모바
일, 게임, …………

공유

협업

이미지 출처: http://uas.osu.edu/program/c...
2.2 공유하는 이유??

나는 관대하니까 ~ ????

이미지 출처: http://themostbeautifulfraudintheworld.blogspot.kr/2012_05_01_archive.html
2.2 공유하는 이유??

내가 최고니까 ~ ????

이미지 출처: http://www.spreadshirt.com/i-m-the-best-t-shirts-C3376A10929818
2.2 공유하는 매우 현실적인 이유

주변이 똑똑해져야 내가 편함
•

사고를 수습하는 일이 줄어듬

•

중요한 일을 할 여유를 가질수 있음

좋은 평판을 얻을 수 있음

주변의 덕을 볼 확률이 올라
감
이미지 출처:...
2.3 공유 대상

무엇이든

이미지 출처: http://emergingtech.tbr.edu/new-technologies
http://newstechnica.com/2008/11/28/portsmouth-gets-f...
2.4 공유 방법
기록

메일

조회
공유

교육
세미나

코드리뷰
* 주의: 재미있어야함!

이미지 출처: http://diginomica.com/2013/05/24/email-the-stepchild-digital-...
2.5 협업

이미지 출처: http://www.alleywatch.com/2013/06/10-tools-that-simplify-startup-collaboration/
2.5 협업의 전제조건: 상대를 이해하자

고슴도치도 제 새끼는 함함하다.
QA

• 산출물: 테스트케이스, 버그레포트
•

자주듣는 말: 그럴리가 없는데?
제자리에선 잘되요 ~!

기획자

개발자
• 산출물: 코드
•...
2.6 협업의 필수요소

자아존중감(自我尊重感)
• 자신이 존중 받을 가치가 있다고 믿음

• 있는 그대로의 자신을 인정함

• 타인의 부정적 견해에 크게 영향 받지 않음

본성은 바꿀 수 없지만 외부의 자극에
반응하는...
2.6 자아존중감을 높이는 방법

인문학(Liberal Arts)
• 스토아 철학
• 세네카, 에픽테토스
• 인지심리학(Cognitive Psychology)

• 행복에 걸려 비틀거리다
• 뱀의 뇌에게 말을 걸지 마라...
3. 좋은 개발자!!!
3.1 좋은 개발자!!!

도메인 지식
공유, 협업
실천력

논리력
이미지출처: http://ifather.tistory.com/categor
y/재밌는세상?page=2

피드백

좋은 코드 작성
능력
3.2 좋은 개발자!!!

연습이 완벽을 만든다!
(Practice makes perfect!)

이미지 출처: http://www.todayhumor.co.kr/board/view.php?no=100207&page=1...
Q&A
THANK YOU
Upcoming SlideShare
Loading in …5
×

Deview 2013 프로그래머로 산다는 것 유석문

4,048 views

Published on

2013년 문화관광부 선정 우수학술도서인 "프로그래머로 산다는 것"의 공동저자인 발표자의 경험을 공유합니다.
"좋은 프로그래머"가 되어야 한다는 충고는 흔하게 하지만 구체적인 방법을 제시하는 경우는 매우 드뭅니다. 단지 열심히 일하고 공부하라는 식의 피상적인 내용만 이야기하고 있습니다. 목표와 방법이 잘못된 경우라면 열심히 할 수록 빨리 실패하게 됩니다.
이에 "좋은 프로그래머"가 무엇인지 정의하고 이에 필요한 기술, 문화적 요소에 대한 발표자의 경험과 생각을 공유합니다.

본 발표는 다음의 내용을 다룹니다.
- 좋은 코드란 무엇인가?: "좋은 프로그래머"의 기초는 "좋은 코드"를 작성하는 전문가 입니다. 좋은 코드를 작성하기 위해 필요한 지식과 기술요소를 설명합니다.
- 공유: Silo를 개발자의 전형으로 오해하는 경우가 많습니다. 이와 반대로 공유를 통해 조직과 개인의 발전을 추구하는 방법을 발표자의 경험과 실 사례를 통해 공유합니다.
- 협업: 효과적으로 서비스를 개발하려면 서비스 개발에 참여하는 모든 참여자의 협업이 중요합니다. 하지만 많은 조직이 단방향의 일흐름을 유지하며 무수한 낭비와 실패를 경험합니다. 이러한 낭비와 실패를 예방하고 함께 성공할 수 있는 방법인 "효과적인 협업"에 필요한 기술요소와 방법을 설명합니다.

Published in: Education
3 Comments
25 Likes
Statistics
Notes
No Downloads
Views
Total views
4,048
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
115
Comments
3
Likes
25
Embeds 0
No embeds

No notes for slide
  • 말씀 드릴 내용은 도대체 개발자의 정의가 무엇인지 그리고 나아가 좋은 개발자가 되려면 어떻게 해야 하는지 입니다.이에 대한 현실의 흔한 오류와 이에 대한 해결법을 살펴 보겠습니다.
  • 본 발표의 제목은 2012년에 출간된 책의 제목에서 가져왔습니다.여기 계시는 네 분이 공동 저자입니다. 책에는 저름 포함한 이분들의 경험과 고민이 담겨 있습니다.자신의 솔직한 경험과 개발자에게 꼭 해주고 싶은 이야기를 적는 것에만 동의하고 작성하여 통일성이 없습니다.하지만 이는 현실의 다양한 고민을 담은 장점이기도 합니다.오늘 발표에서는 저의 이야기를 들려 드리겠습니다. 다른 저자의 이야기가 궁금하신 분께서는 책을 읽어 보시면 좋겠습니다.그리고 여기 계신 네분이 이번 행사에 참석하셔서 잘 찾으시면 행사장에서 만나실 수 있습니다. 컬렉션 모으듯이 한 번 찾아 보시는 것도 좋겠습니다.
  • 책이 출판되고 난 다음에 많이 받았던 질문에 대해 먼저 답변 드리겠습니다.표지가 강렬하다 보니 “화장실에서도 코딩하란 이야기냐?”란 분노를 표출해주신 분이 많습니다.이에 대한 답변은 상황에 따라 다르다입니다. 표지를 보고 분노를 느끼신 분이라면 아마도 매우 급박한 일정에 쫒겨 업무를 강요받고 계신 상황일 것입니다. 그런 상황이라면 개발이란 작업이 즐거움이 아닌 고통으로 느껴지실테니 화장실에 앉아 코딩하는 것은 끔찍한 일이겠지요. 그런 경우시라면 저의 답변은 절대 하지 마세요 입니다. 반면 개발이 너무 즐겁고 재미있어 밥 먹는 것 조차 귀찮게 느껴지고 화장실에서도 코딩하고 싶을 정도로 행복하신 경우라면 당연히 하셔도 좋습니다.보이는 현상이 아닌 의도가 무엇인지가 중요하니까요.그 다음으로 누구의 다리냐? 라는 질문을 많이 받았는데요. 단언컨데 제 다리는 아닙니다. 그리고 전 빨간색 팬티를 입지 않습니다.
  • 이제 개발자에 대한 이야기를 좀 해보겠습니다.현재 제가 느끼는 개발 분야의 문제점을 먼저 말씀 드리고 대안을 설명 드리겠습니다.
  • 많이 보신 그림일 거에요. 자료구조 중에 스택입니다. 푸시로 데이터를 넣고 팝으로 꺼내면 집어 넣은 역순으로 데이터를 얻게됩니다.기초 자료구조이므로 다들 익숙 하실 것입니다.저는 이걸 면접에 사용합니다. 상황은 다음과 같습니다. 개발 경력이 3~5년 정도 되시는 지원자에게 스택을 설명하고 스택 클래스를 손코딩으로 구현해보라고 요청합니다.실제 사례를 보여 드릴께요.뭔가 이상하죠? 클래스의 바디 부분은 거의 작성하지 못한 상태입니다.이쯤 되면 지원하신 분께서는 매우 불안한 눈빛으로 저를 보시며 “최근에는 개발보단 관리를 주로 하느라 기억이 안난다”고 말씀 하십니다.그때의 제 표정이죠. 슬픈 것은 이런 일이 아주 특별한 경우라 여러분께 말씀 드리는 것이 아니란 것입니다.지원자 중 10명에 8명 정도는 여기에서 면접이 종료됩니다.이력서 만으로는 거의 나라를 구하신 분들인데 실제 코드는 작성하지 못합니다. 이런 경우라면 개발자라고 호칭하기 어렵죠. 그래서 같은 한자를 사용하지만 음이 아닌 뜻으로 부르고 싶은 욕구가 들때가 많습니다.바로 개발자가 아닌 개발놈이죠. 하필 어감도 딱입니다.왜 이런 일이 벌어지는 걸까요? 현실에서 벌어지고 있는 일을 살펴 보겠습니다.
  • 멋진 복장으로 개발자가 업무를 시작하는 상황입니다.비극 또는 일상이라 표현한 이유는 이런 환경이 강요된 경우라면 비극이라 표현할 수 있고 이것을 개발자가 자신의 당연한 삶이라고 오해하고 바꿀 수 없다고 믿는 경우엔 일상이라고 표현한 것입니다.통상의 업무가 주어지는 환경은 다음과 같습니다.글씨의 크기가 다르듯 이런 표현에서는 업무 보단 데드라인이 더 중요합니다. 무조건 데드라인을 맞추란 의미이죠. 이런 상황에서 개발자는 어떤 선택을 할 수 있을까요?
  • 관리작는 시간만 강조하고 있는 상황이라면개발자는 기존의 코드 또는 인터넷 검색을 통해 유사한 해결책을 찾아 낼 것입니다. 최근 검색기술이 발달하여 샘플코드 구하기가 매우 쉬워진 것도 이런 현상에 한 몫을 한거죠.그 다음엔 그 코드를 복사해서 붙여넣습니다.그리곤 동작하는 것 처럼 느껴질때까지 이것 저것 뜯어 고쳐 봅니다. 저희가 흔히 이야기 하는 삽질을 하는 것이죠.이렇게 해서 제대로 일이 될리 없습니다. 당연히 산출물의 품질도 낮고 이런 과정을 반복하며 개발자가 성장할 수 없습니다.기초적인 언어 문법도 모르고 어디서 본 것은 같은데 라며 헷갈려 하는 개발자가 이런 과정의 반복에서 탄생합니다.
  • 이런 개발자를 만들어내는 주된 원인을 살펴 보겠습니다.먼저 일정을 강요하고 요구사항을 수시로 변경하며 협업할 줄 모르는 고객과 상사가 주요 원인입니다.시키면 시키는대로 하라고 강요하며 합리적인 대안을 제시하는 개발자의 이야기를 들어주지 않습니다.그 다음은 탐욕스러운 회사입니다. 개발자의 발전을 위한 투자에 인색하고 그저 번아웃 될 때까지 열심히 부려먹다 지치면 새로운 사람을 채용해 대체하면 된다고 생각하는 회사입니다.개발자는 쉽게 대체할 수 있는 소모성 자원이라 생각합니다. 또다른 예로 다단계 하청 문제를 들 수 있습니다. 하청 받은 것을 다시 하청으로 넘기는 과정에서 비용은 계속 감소하므로 개발자에게 제대로된 처우를 제공하거나 투자를 해줄 수가 없습니다.결국 이익을 극대화 하겠다는 탐욕스러운 회사가 발전의 근간인 개발자를 고사시킵니다.그 다음으로 현재의 문제를 개선하기 위해 노력하는 사람을 좌절시키는 비협조적인 동료 입니다. 기존 보다 나은 개선책을 찾아 적용하려고 할 때 “예전 부터 이렇게 해왔어. 동작하면 건드리지마, 원래 그래”라고 이야기 하며 기존의 악행을 답습하려는 사람이 많습니다. 이런 사람과 함께 일하면서 지속적인 발전을 하기는 매우 어렵습니다.이 외에도 여러 요소가 있습니다. 문제는 이런 항목이 독립적이지 않으며 상호 연관 되어 있어 현실에선 혼합된 형태로 나타난다는 것입니다. 정말 강력한 힘을 발휘하죠.이렇기에 개발자의 눈물이 마를 날이 없습니다. 그러니 이런 문제만 피하시면 됩니다 라고 설명할 수 있으면 좋겠지만 현실은 절대로 녹녹하지 않습니다.아주 단순한 방법으로 이것을 피하기가 어렵다는 것을 설명해 보겠습니다.고객 중에 반은 좋은 고객이고 반은 나쁜 고객이라고 가정해 보겠습니다. 그리고 다른 요인들도 같은 비율이라고 가정해 봅시다.4가지의 조건을 모두 만족할 확률은 0.5의 4제곱입니다. 대략 6% 정도 되겠네요. 아주 희망적으로 예측했음에도 말입니다. 게다가 동료나 상사의 경우는 한 명이 아닙니다. 이를 관련된 사람으로 모두로 계산 범위를 넓힌다면 확률은 더욱 낮아집니다.아마 오늘 이자리에 계신 분들의 대부분이 적어도 몇가지의 문제를 겪고 계신 이유가 바로 그것입니다 즉, 이것은 아주 보편적인 현실입니다. 게다가 저희가 통제할 수 없는 외부요인이기도합니다.문제가 있다고 고객이나 상사를 저희가 마음대로 교체할 수 없음은 설명 드릴 필요도 없겠죠. 회사와 동료도 마찬가지입니다.이게 프로그래머로 살아가는 환경이자 현실입니다. 그러니 여러분은 개발자를 그만두고 통닭집을 빨리 오픈 하시는 것이 좋습니다. 끝.농담이고요. 이는 비단 개발자만 겪는 문제가 아닙니다. 모든 업종에서 공통으로 나타납니다. 저희만 당하고 있는 것이 아니죠. 조금 위로가 되시나요?이런 상황에서 가장 먼저 해야할 일은 현실을 있는 그대로 인식하는 것입니다. 그렇지 않다면 모든 문제를 자신이 통제할 수 없는 외부 요인 탓으로 돌리게되고 결국 아무것도 할 수 ㅇ벗는 자신에 절망하게 됩니다.깨끗하게 인정해야 합니다. 이게 바로 현재 우리가 개발자로 살아가는 환경입니다.
  • 많은 분이 멘붕 상태이실텐데 먼저 위로주 한 잔 드리겠습니다. 미성년자 분들은 받으시면 안되고요.외부 환경이 열악할 수록 통제가 가능한 요인에 집중해야 합니다. 자신이 할 수 있는 일에 집중하고 역량을 키워 나가면 영향력이 커져 통제 불가능하다고 판단되었던 영역에 까지 영향력을 발휘할 수 있습니다.극단적으로 말해서 개발할 줄 모르는 개발자의 말을 동료나 회사가 들어 줄까요? 혹시라도 퇴사할까 회사나 상사가 전전긍긍하고 동료가 존경하는 사람이 된다면 이야기가 달라집니다.지금 부터 그 이야기를 해보겠습니다.개발자에게 갖추어야할 핵심역량 첫 번째는 깔끔한 코드를 작성하는 능력입니다. 깔끔한 코드란 …..혹시라도 남들이 볼까봐 창피한 코드를 작성하고 있다면 회사나 동료에게 피해를 주는 것도 문제이지만 가장 큰 문제는 바로 자신의 소중한 인생을 낭비하는 점입니다.극단적인 표현으로 쓰레기 같은 코드를 생산해 내고 있는 사람이 바로 자신이 되는 것이고 그런 사람이 존중 받을리 없을테니까요.그 다음으론 적절한 논리력이 필요합니다. 논리력은 좋은 것이니 최고의 논리력을 갖추어야 하는 것 아니냐라고 의문을 품는 분이 계실텐데요. 공학도인 개발자에겐 균형있는 논리력이 필요합니다.개발자가 과학자라면 단 하나의 진실이 있을 것이고 진실이 아닌 나머지는 모두 거짓이므로 아무리 많은 비용이 들더라도 진실을 추구해야 할 것입니다.하지만 공학도인 개발자에겐 현재 상황에 가장 적합한 해결책을 찾는 것이 목표입니다.DB에서 데이터를 한 번에 모두 가져오는 것이 좋을지 아니면 나누어 가져오는 것이 좋을지에 대한 정답이란 없습니다.현재 주어진 조건에 적합한 해법을 그때 그때 찾아서 적용해야합니다. 그리고 누가 봐도 이해할 수 있는 그리고 현재 사용가능한 가장 단순한 디자인을 적용해야 합니다.간단한 일을 복잡하게 처리하고 너희들은 이런 거 이해도 못하겠지? 라고 뽐내는 것은 병신력의 천재일 뿐입니다.그럼 깔끔한 코드를 작성하는 방법 부터 살펴 보겠습니다.
  • 깔끔한 코드를 작성하기 위해서는 소프트웨어의 완료 조건을 알아야합니다.무엇을 만족 시키면 다 만들었는지를 알수 있어야 필요한 만큼만 만들고 쓸데 없는 짓을 안할 수 있습니다.소프트웨어 개발에서 중요한 완료 조건은 두 가지 관점에서 나옵니다.첫 번째는 고객의 관점입니다. 고객이 원하는 소프트웨어가 무엇이고 그것이 어떻게 동작하는지를 정의하고 그에 맞추어 개발을 진행해 나가는 방식이 ATDD입니다.개발은 결국 소프트우어를 사용할 고객을 만족 시키는 작업입니다. 고객이 무엇을 원하는지 모르는 상태에서 개발한 코드는 아무리 뛰어난 기술을 활용한 경우라도 시장에서 살아남을 수 없습니다. 저희가 공학도임을 명심하셔야 합니다.두 번째는 코드를 작성하는 개발자의 관점에서 완료를 정의하는 것입니다. 내가 작성한 코드가 내 의도대로 동작하는지를 검증할 수 있어야합니다.로그인을 만든 것 같은데 이게 동작하는지 모르겠으니 QA에게 맡기자 라고 생각하는 것은 “저는 제가 무엇을 하였는지 모르겠나이다”라고 고백하는 결과입니다.고객과 개발자의 관점에서 완료를 정의하고 개발을 진행하면 필요한 만큼만 만들게 되어 오버엔지니어링을 피할 수 있어 유지보수가 용이하고 단순한 코드를 작성할 수 있습니다.
  • ATDD에 대해 조금 더 설명 드리겠습니다.ATDD는 먼저 개발자, 기획자,QA가 함께 모여 사용자 관점에서의 스토리를 협의하고 정의 합니다.이후 인수 테스트를 정제하고 개발에 들어가면 개발자 관점의 TDD를 수행하며 인수테스트를 통과할 때까지 개발합니다. 정의한 인수테스트를 모두 통과 시키면 개발이 완료된 것이며 이를 사용자에게 데모하고 피드백을 받아 필요할 경우 수정 및 개선을 진행합니다.이와 같이 사용자 관점의 테스트를 먼저 정의하고 이를 통과하도록 TDD를 이용해 개발을 진행하는 방법을 ATDD라 합니다.
  • 다시 강조하지만 개발자는 사용되는 코드만 작성해야 합니다.혹시나 모를 미래를 대비해 쓰지 않는 코드를 만드는 것은 개발자가 무당이 되겠다는 이야기와 동일합니다.미래에 요구사항이 어떻게 변경될지 예측하여 맞추기는 거의 불가능합니다.이에 도움이 되는 방법이 콜러 크리에이트 입니다.TDD와 ATDD를 이용하면 테스트에서 프로덕션 코드를 호출해서 사용하게 되어 사용하지 않는 코드를 생산 하지 않게 됩니다.이는 단순한 디자인을 유지하는데 매우 큰 도움이 됩니다.그리고 인지해야할 사실 하나가 깔끔한 코드를 다 한번에 작성하는 것은 불가능하다는 사실입니다. 간단한 메일을 작성하는 경우에도 발송 전에 여러번 읽고 문맥을 다듬고 오타를 고칩니다. 그처럼 코드도 동작하기 시작하면 읽기 좋고 이해하기 용이하고 유집보수가 쉽게 개선해야 합니다. 이것이 바로 리팩토링입니다. 리팩토링은 언제 날잡아서 하는 행사가 아닌 코드를 작성하는 동안 지속적으로 함께 수행하는 일입니다. 그리고 코드를 개선하는 것이므로 리팩토링 과정에서 사이드 이팩트가 발생하면 안됩니다. 리팩토링 과정에서 발생할 수 있는 사이트이팩트를 방지해 주는 것이 바로 테스트 입니다. 여러분이 ATDD, TDD 를 이용해 개발하였다면 깔끔한 코드를 만들기 위한 리팩토링을 위험 부담 없이 진행할 수 있습니다. 그렇지 못하다면 여러분은 리팩토링을 하는 것이 아니라 위험 속에서 새로운 코드를 개발하고 있는 것입니다.코드는 작성한 사람 뿐만 아니라 유지보수에 참여하는 사람이 지속적으로 관리하게 됩니다. 그러므로 타인이 이해할 수 있는지 확인하여야 하며 이 작업이 코드리뷰입니다.코드리뷰를 통해 누구나 쉽게 이해할 수 있는 코드로 만들어야 합니다.
  • 적절한 논리력을 필요한 만큼만 하는 균형잡힌 개발자의 능력입니다.아주 특이한 경우를 제외하고는 대부분의 경우 개발자가 해결하는 문제에 적합한 해결책이 공개되어 있습니다.그것이 바로 알고리즘과 데이타 구조입니다. 좋은 해법이 있는데 새로운 해법을 만드는 것은 낭비입니다.그리고 여러 해결책 중에서 가장 단순한 것을 선택하여야 합니다. 개발자는 새로운 것을 좋아하고 남들은 하지 못하는 나만의 것을 추구하는 경향이 있습니다.이는 그저 허영심과 자만심일 뿐입니다.복잡한 문제를 풀려면 우선 단순화 하고 쉬운 부분 부터 단계적으로 발전 시켜 나가는 것이 좋습니다. 이때 활용하는 기법이 단순한 디자인과 진화적 디자인입니다.사칙 연산을 배운뒤에야 삼각함수, 미적분등의 단계로 나아갈 수 있는 것과 마찬가지로 문제를 해결하고 싶다면 차근차근 단계를 밟아가야 합니다.그러면서 주변과 협업하여 좋은 결과를 만들어야 합니다 협업을 통해 자신이 바라보지 못한 부분을 다른 사람의 관점에서 바라보고 정보를 얻을 수 있으며 자신만의 세계에 갖히지 않을 수 있습니다.그리고 다른 해법을 살펴보고 이해하고 장단점을 분석해야 합니다. 이과정을 통해 문제에 적합한 해결책을 찾을 수 있습니다.지금까지 말씀 드린 내용이 기술과 지식으로 느껴지신다면 오해입니다. 이는 습관입니다. 지식으로 익혔다고 자유자재로 활용할 수 없습니다. 자꾸 사용하고 시행착오를 거쳐 자신의 습관으로 만들어야만 합니다.
  • 그러기 위해서 매일 꾸준히 연습해야 합니다. 한 번 배웠다고 끝나지 않습니다. 계속 사용하면서 자신의 것으로 만들 어야 합니다.제가 사용했던 방법으로 “몸 값 올리기”라는 실천법이 있습니다.회사에서 제공하는 연봉은 제가 그만큼의 일을 해줄 것이라는 기대에 대한 표현입니다. 그럼로 연봉이 올라가려면 기존보다 더 발전해야 합니다.이런 발전은 통상의 근무시간에 획득하기 어렵습니다. 그래서 저는 매일 오전 시간을 정해 놓고 새로운 기술을 살피거나, 책을 읽거나, 관심은 있지만 현업에 사용할 일이 없어 써보지 못한 기술을 시험해 봅니다.
  • Deview 2013 프로그래머로 산다는 것 유석문

    1. 1. 프로그래머로 산다는 것 유석문 이사 / 신규서비스개발실 NHN Technology Services
    2. 2. CONTENTS 1. 개발자??? 2. 좋은 개발자??? 3. 좋은 개발자!!!
    3. 3. 0. 프로그래머로 산다는 것 2013년 문화체육관광부 우수학술도서 2012.09.26 로드북 황상철 하호진 이상민 김성박
    4. 4. 0. 프로그래머로 산다는 것 FAQ 화장실에서도 일하란 말이냐?? 필자 중 누구의 다리냐??
    5. 5. 1. 개발자???
    6. 6. 개발(놈)者 1.1 개발자??? or ?????? 상황: Java 3 ~ 5년 경력 기술면접 응?? Class Stack() { …… } 으응?? 최근에는 개발보단 관리를 많이 하느라 … 이미지 출처: http://www.leda-tut orial.org/en/official/ch02s04.html 읭???
    7. 7. 1.2 개발(놈)者 Begins – 업무 할당 비극 또는 일상의 시작 ~!! 이 일을 언제까지 끝낼 수 있겠나? 참고로 시간이 없네. 이미지 출처: http://elderonamission.blogspot.kr/2011/06/our-call-to-duty.html
    8. 8. 1.2 개발(놈)者 Begins – 업무 수행 검색 복사 & 붙여넣기 이미지 출처: https://fisher.osu.edu/blogs/ftmba-admissions/tag/dead line/ http://www.3waylinks.com http://withalways.tistory.com/120 http://backreaction.blogspot.kr/2012/02/updated-science-symbol.htm l 되는 것 처럼 보일때 까지 ~!!!
    9. 9. 1.3 개발(놈)者의 탄생 주역 나쁜 고객과 상사 이미지 출처: http://www.fanpop.com/clubs/kuzco/ima ges/30859484/title/kuzco-3-photo http://4realleaders.com/2011/11/the-good-bad-and-ug ly-part-3/ http://www.seattlejusticeblog.com/2010/10/mike-withe y-joins-public-justice-to-fight-health-insurance-greed/ http://i-sight.com/investigation/managing-an-uncooper ative-complainant-or-witness-in-a-workplace-investiga tion/ http://thedevilsdoor.org 탐욕스러운 회사 비협조적인 동료 통제할 수 없는 외부요인
    10. 10. 1.4 개발자의 필수능력 깔끔한 코드 적절한 논리력 • 사람이 이해하기 쉬운 코드 • 원리 탐색 능력 • 변경이 용이한 코드 • 제약조건을 고려한 해법 • 유지보수 비용이 낮은 코드 • 단순한 디자인 이미지 출처: http://www.redbubble.com/people/yossirb9/works/9288761-keep-calm-for-inner-peace?p=sticker http://blog.naver.com/ryo132?Redirect=Log&logNo=100195221848
    11. 11. 1.5 깔끔한 코드 작성법 개발자 ATDD Acceptance Test Driven Development 고객 TDD Test Driven Development 이미지 출처: http://www.solutionsiq.com/resources/agileiq-blog/bid/64395/What-is-the-Definition-of-Done-DoD-in-Agile http://www.iconarchive.com/show/people-icons-by-aha-soft/user-icon.html http://www.lunched.com.au/features
    12. 12. 1.5 깔끔한 코드 작성법 이미지 출처: http://asynchrony.blogspot.kr/2008/12/hendrickson-on-atdd.html
    13. 13. 1.5 깔끔한 코드 작성법 • 사용하는 코드만 만들기(Caller Create) • 리팩토링(Refactoring) • 코드 읽기(Code Review) 이미지 출처: http://diogoosorio.com/blog/entry/test-driven-development-tdd-using-phpunit
    14. 14. 1.6 적절한 논리력 • 알고리즘과 데이타 구조(Don’t Reinvent The Wheel) • 단순한 디자인(Simple Design) • 진화적 디자인(Evolutionary Design) • 협업(Cooperative Design, Design Review) • 기술 벤치마킹(Benchmarking) 이미지 출처: http://teamdicky.blogspot.kr/2012/09/the-whining-and-bitching-part.html http://tommythematerialgirl.blogspot.kr/2012/05/easy-street.html
    15. 15. 1.7 실천법 • 꾸준한 연습(Daily Practice) • 매일 몸값 올리는 시간을 가져라 • 멀리 가고 싶다면 함께 가라 • 현재 필요한 만큼만 하 라 • 간단하게 하라 이미지 출처: http://www.mymodernmet.com/profiles/blogs/cute-yoga-kittens http://24.media.tumblr.com/tumblr_lzfa17ANA01qzo3c9o1_1280.jpg, http://ahmad.baitalmal.com/?cat=1
    16. 16. 2. 좋은 개발자???
    17. 17. 2.1 좋은 OO 개발자??? • 시간 변동성 없음 “좋은” 개발자 서버, 웹, 클라이언 트, 임베디드, 모바 일, 게임, ………… 공유 협업 이미지 출처: http://uas.osu.edu/program/collaborative-art-making-intensive http://www.jdsmitproductions.co.nz • 분야가 다 양 • 시간 변동
    18. 18. 2.2 공유하는 이유?? 나는 관대하니까 ~ ???? 이미지 출처: http://themostbeautifulfraudintheworld.blogspot.kr/2012_05_01_archive.html
    19. 19. 2.2 공유하는 이유?? 내가 최고니까 ~ ???? 이미지 출처: http://www.spreadshirt.com/i-m-the-best-t-shirts-C3376A10929818
    20. 20. 2.2 공유하는 매우 현실적인 이유 주변이 똑똑해져야 내가 편함 • 사고를 수습하는 일이 줄어듬 • 중요한 일을 할 여유를 가질수 있음 좋은 평판을 얻을 수 있음 주변의 덕을 볼 확률이 올라 감 이미지 출처: http://www.beeskneesdance.com/lindy-hop-pet-peeves/homer-simpson-doh/ http://www.bubblews.com/news/294553-hall-of-fame http://www.123rf.com/photo_20283635_man-receiving-award-trophy-medal-reward-prize-knighted-honour-honor-ceremony-event-stick-figure-pict. html
    21. 21. 2.3 공유 대상 무엇이든 이미지 출처: http://emergingtech.tbr.edu/new-technologies http://newstechnica.com/2008/11/28/portsmouth-gets-future-crime-predicting-cctv-cameras/cctv-epic-fail/ http://www.careerminds.com/blog/are-you-a-team-player-or-a-group-player.html http://tippingback.com/fun-is-yours-to-decide/
    22. 22. 2.4 공유 방법 기록 메일 조회 공유 교육 세미나 코드리뷰 * 주의: 재미있어야함! 이미지 출처: http://diginomica.com/2013/05/24/email-the-stepchild-digital-forgot/ http://www.nuget.org/packages/Hellang.Repository/ http://www.weblinkinternational.com/chambers http://gallery.orchardproject.net/List/Search?searchTerm=author%3A%20Piotr%20Szmyd * 주의: 쌈박질 조심!
    23. 23. 2.5 협업 이미지 출처: http://www.alleywatch.com/2013/06/10-tools-that-simplify-startup-collaboration/
    24. 24. 2.5 협업의 전제조건: 상대를 이해하자 고슴도치도 제 새끼는 함함하다. QA • 산출물: 테스트케이스, 버그레포트 • 자주듣는 말: 그럴리가 없는데? 제자리에선 잘되요 ~! 기획자 개발자 • 산출물: 코드 • 자주듣는 말: 이거 이상해요! • 산출물: 기획문서 • 자주듣는 말: 이걸 왜 해야 하는데요? 이미지 출처: http://www.telegraph.co.uk/news/picturegalleries/picturesoftheday/7735918/Pictures-of-the-day-18-May-2010.html?image=6
    25. 25. 2.6 협업의 필수요소 자아존중감(自我尊重感) • 자신이 존중 받을 가치가 있다고 믿음 • 있는 그대로의 자신을 인정함 • 타인의 부정적 견해에 크게 영향 받지 않음 본성은 바꿀 수 없지만 외부의 자극에 반응하는 방식은 바꿀 수 있다. 이미지 출처: http://www.psychologytoday.com/blog/death-love-sex-magic/201005/the-secrets-meaningful-life-part-iii-the-importance-self-esteem
    26. 26. 2.6 자아존중감을 높이는 방법 인문학(Liberal Arts) • 스토아 철학 • 세네카, 에픽테토스 • 인지심리학(Cognitive Psychology) • 행복에 걸려 비틀거리다 • 뱀의 뇌에게 말을 걸지 마라 • 설득의 심리학
    27. 27. 3. 좋은 개발자!!!
    28. 28. 3.1 좋은 개발자!!! 도메인 지식 공유, 협업 실천력 논리력 이미지출처: http://ifather.tistory.com/categor y/재밌는세상?page=2 피드백 좋은 코드 작성 능력
    29. 29. 3.2 좋은 개발자!!! 연습이 완벽을 만든다! (Practice makes perfect!) 이미지 출처: http://www.todayhumor.co.kr/board/view.php?no=100207&page=1&s_no=100207&table=bestofbest
    30. 30. Q&A
    31. 31. THANK YOU

    ×