학생에서 현업 개발자로..

2013/04 하광성(kwangswei@gmail.com)

CTO SWP(연) webOS platform task

Web app manager / WebKit

AWARDS

2011 일등SW신입과정 사전테스트 전체 1등

2011 일등SW신입과정 6기(우수자과정) Project 최우수상

2012 Coding Expert 1기

2012 SW College 사내 우수 강사

Intensive C(Advanced) Programming

개발자가 모자라요

"취업난" VS "인력난”

2013년 SW전공 년 6,500명 배출

1) 소프트웨어 인력 양성 전략, 2013, 한국소프트웨어기술진흥협회 2) 학위 생산과 일자리의 비교(미국, 2002~2013, CACM 2008, August)

1)

2)

개발자는 모자라지 않습니다.

단지 당장 투입할 수 있는,

기본기를 갖춘 개발자

가 매우 부족할 뿐 입니다.

기업의 문제

학교의 문제

NHN "대학교육 못믿어… SW인재 직접 키운다"

‎국내 기업의 신입사원 SW 교육 VS 해외 기업의 1일 오리엔테이션. Coursera “Algorithm Part I” – Princeton Univ.

학생의 문제 취업 준비 대학생 ‘8대 스펙 중 토익이 가장 중요’

총체적 난국!!!

But,

학교에서의 코딩과 현업에서의 코딩 간의 차이는?

학교에서 가르쳐주지 않지만 현업에서 중요한 지식들은?

※주의. 학교에서 배운 지식들이 중요하지 않다는 것은 결코 아님.

동작이 최우선!

과제 제출하면 땡!

다른 사람 코드 참조 X

아마도 학교에서는,

Clean code 동작’만’이 최우선이 아니다. (하지만, 현실에서는 최우선이다 아직.. ㅠ.ㅠ)

Readability

새로운 코드를 작성하는 시간 < 기존 코드를 수정 또는 추가하는 시간

Code Review 책을 많이 읽어야 좋은 글을 쓸 수 있듯이,

좋은 코드를 많이 읽어야 좋은 코드를 만들 수 있다.

Google 의 Code Review

Linux Community

Truck 지수

학습효과

지금부터는,

public static String testableHtml(

PageData pageData,

boolean includeSuiteSetup

) throws Exception {

WikiPage wikiPage = pageData.getWikiPage();

StringBuffer buffer = new StringBuffer();

if (pageData.hasAttribute("Test")) {

if (includeSuiteSetup) {

WikiPage suiteSetup =PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_SETUP_NAME, wikiPage);

if (suiteSetup != null) {

WikiPagePath pagePath = suiteSetup.getPageCrawler().getFullPath(suiteSetup);

String pagePathName = PathParser.render(pagePath);

buffer.append("!include -setup .").append(pagePathName).append("\n");

}

}

WikiPage setup = PageCrawlerImpl.getInheritedPage("SetUp", wikiPage);

if (setup != null) {

WikiPagePath setupPath = wikiPage.getPageCrawler().getFullPath(setup);

String setupPathName = PathParser.render(setupPath);

buffer.append("!include -setup .").append(setupPathName).append("\n");

}

}

buffer.append(pageData.getContent());

if (pageData.hasAttribute("Test")) {

WikiPage teardown = PageCrawlerImpl.getInheritedPage("TearDown", wikiPage);

if (teardown != null) {

WikiPagePath tearDownPath = wikiPage.getPageCrawler().getFullPath(teardown);

String tearDownPathName = PathParser.render(tearDownPath);

buffer.append("\n").append("!include -teardown .").append(tearDownPathName).append("\n");

}

if (includeSuiteSetup) {

WikiPage suiteTeardown =PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_TEARDOWN_NAME, wikiPage);

if (suiteTeardown != null) {

WikiPagePath pagePath = suiteTeardown.getPageCrawler().getFullPath (suiteTeardown);

String pagePathName = PathParser.render(pagePath);

buffer.append("!include -teardown .").append(pagePathName).append("\n");

}

}

}

pageData.setContent(buffer.toString());

return pageData.getHtml();

}

Clean code

함수는 왜 분리하고, 또 언제 분리하는가?

그 밖에,

Coding style, 일관성, 주석, 관용구의 사용, 의미 있는 이름 부여하기 등등.

추천 도서

Clean code, The practice of programming, 읽기 좋은 코드가 좋은 코드다

함수(function)의 분리와 활용 – Abstraction levels of function

Clean code : Meaningful Names

public static String renderPageWithSetupsAndTeardowns(

PageData pageData, boolean isSuite) throws Exception

{

if (isTestPage(pageData))

includeSetupAndTeardownPages(pageData, isSuite);

return pageData.getHtml();

}

설계(Design)가 중요하다고 배운 당신!

엘레강스한 설계와 UML문서가 없이는 코딩 하지 않겠어!

아마도 학교에서는,

설계는 중요하다!

But, 개발 초기에 완벽한 설계는 불가능하다!

SW 설계는 경험의 산물.

Agile

십중팔구 여러분의 설계는 예상치 못한 이슈들로 계속 변한다.

그럼? 변화에 빠르게 적응하자!

점진적 개발방법론 (Scrum, TDD 등)

확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다

(open-closed principle)

지금부터는,

OPTIMIZATION! 여러분의 프로젝트에서 사용할 A라는 프로그램을 받았다고 합시다.

A의 수행시간은 30분이 걸리는데 코드를 보니 하루 정도 투자하면 수행 시간을

5분으로 단축할 수 있을 것 같습니다.

당신이라면 최적화를 하겠습니까?

최적화의 첫 번째 법칙은?

아마도 학교에서는,

글쎄요? 예/아니오 로 대답을 하기 이전에 여러분은 프로젝트 기간 동안

A를 몇 번이나 사용할 것인지 물으셔야 합니다.

First Rule of Optimization : Don’t Optimization matters only when it matters.

Done is better than perfect - Facebook

프로그램이 어떤 환경에서 돌아갈지를 감안할 때 더 빨리 만들면 어떤 이익이 있는가?

최적화는 측정된 데이터를 기반으로!

지금부터는,

참고자료. Optimization - Your worst enemy (http://www.flounder.com/optimization.htm)

최적화는 측정된 데이터를 기반으로!

LG SI 최적화 이슈 문의 사례

Assembly로 최적화를 했는데 Debug Mode 에서는 40% 나 성능 개선이 되는데,

Release Mode 에서는 오히려 나빠져요!

“스타트업은 데이터를 어떻게 바라봐야 하는가?”

(http://www.slideshare.net/yongho/ss-32267675)

청바지 브랜드 사례 – 우리는 우리 생각보다 세상을 모르고 있다.

사례,

백문이 불여일RUN

아마도 학교에서는,

각종 툴들은 분명 유용하다!

But, 어디까지나 ‘보조 도구’

IDE, Debugger 에 의존하여 일단 해보고 안되면 그 때가서 생각해보고 하는 방식은

개발자의 실력에는 도움이 안됨.

도구의 도움 없이 스스로 하는 ‘의도적 수련’이 필요.

“손코딩뇌컴파일눈디버깅”

손코딩뇌컴파일눈디버깅 – 매주 (수) 서초R&D센터 저녁 6시20분

당신이 제자리인 이유 - 지루하거나 불안하거나 (http://agile.egloos.com/5749946)

지금부터는,

손코딩뇌컴파일눈디버깅이 과연 효과적일까?

Interview Process

Google, Microsoft, Apple, Yahoo, Facebook, Amazon, Netflix

그들이 평가하는 것

문제를 잘 이해하는가? 필요한 조건 및 가정을 잘 도출하는 가?

어떤 과정을 통해 문제를 접근하고 풀어나가는가?

그 과정에서 의사소통을 잘 하는가?

깔끔하게 코딩을 잘 하는가?

자신의 풀이에서 버그나 예외 상황은 없는 지 검증하고 디버깅을 잘 하는가?

그들의 인터뷰 목표

“잘하는 사람을 놓치더라도 자질이 부족한 엔지니어를 채용하는 일은 없도록 하자”

홍보,

테스트??

돌아가는 코드 만들기도 바쁜데…

평가에도 반영 안되고…

아마도 학교에서는,

개발자 단계에서의 테스트는 중요하지만

현업에서도 아직까지 부족한 실정

개발자의 테스트 활동이 필요한 이유

초기 단계에서 발견된 결함은 수정이 용이, 수정 비용/시간 감소

버그를 찾는 시간 >>>>> 버그를 수정하는 시간.

수정에 대한 검증 : Side effect 방지

HW 자원으로 인한 개발 지연, 다른 모듈의 의존성 등으로 인한 개발 지연 방지

테스트를 추가하는 것이 SW를 더 나은 디자인 방향으로 유도한다.

지금부터는,

Light Scheduler 를 Design 해봅시다

예제,

class LightScheduler {

public:

LightScheduler();

void addTurnOn();

void wakeup();

private:

TimeService time;

LightController lights;

};

사용자는 32개의 전등(HW)을 켜고 끄는 작업을 light scheduler 에게 등록. 작업을 수행할 전등, 수행되는 시간, On 또는 Off 를 설정할 수 있음. 최대 128개의 작업을 Scheduling 할 수 있음. 지정된 시간이 되면 light controller 는 전등을 조작해야 함.

TimeService 시스템 타이머를 이용하여 LightScheduler를 깨워주고 시간을 받아오는 부분 LightController 전등을 직접적으로 제어하는 모듈.

초기 디자인

요구사항

Light Scheduler 를 Design 해봅시다

예제,

Light Scheduler를 개발&테스트 하려고 보니...

TimeService 는 OS 의존적인 모듈인데다가 시간은 계속해서 흐르므로 테스트가 어렵습니다.

LightController 는 HW를 직접적으로 제어하는 모듈로 자동화 테스트가 어렵습니다.

class LightScheduler {

public:

LightScheduler(TimeService&,

LightController&);

~LightScheduler();

void addTurnOn();

void wakeup();

private:

TimeService& time;

LightController& lights;

};

출처. 임베디드C를 위한 TDD

설령 Design Principle을 위반하더라도

테스트하기 좋은 코드

가 좋은 코드다!

참고자료

임베디드 C를 위한 TDD by James Grenning

TDD : 어떻게 테스트 할 지를 고민합시다.

지금부터는,

협업 및 의사소통

programming skill, communication skill, domain knowledge

Problem Solving

우리가 미적분을 배우는 이유

Problem Solving 을 통해 키워지는 역량

(남의 코드를 빨리 읽고 이해하는 능력. 예외 상황이나 오류를 찾아내는 능력.기본 코딩 스킬의 향상, 문제를 모델링 하는 능력)

TopCoder, Code jam, Hacker cup, ACM ICPC, code forces

추천 도서 : "알고리즘 문제 해결 전략", "코딩 인터뷰 완전분석”

Open Source Contribution

취미 = 일 = Global career

양질의 코드 + 전세계 뛰어난 개발자들의 Feedback

그 외에도 이런 것들을 준비했으면 좋겠습니다.

열심히'만' 하는 것보다는 '잘'해야 한다.

개발자에게 있어서 Code Quality 는 타협의 대상이 아닙니다.

기준을 높게 잡으세요. 주변의 실력자들을 보면 대부분 '이만하면 됐어...' 의 기준이 굉장히 높습니다.

함께 더불어 성장합시다.

지식은 공유되어야 하고, 여러분은 움직이셔야 합니다.

영어

......아 눈물이...ㅠ.ㅠ

오늘 이야기 한 내용에 정답은 없습니다.

Open mind~!

마지막으로,

강연 후기 및 피드백