Seminar/소스리딩 워크샵

소스리딩 - 이민석

MB Brad KWON 2012. 8. 4. 22:01



!!소스리딩의 결과를 통계를 내면 소프트웨어의 품질을 높이는 툴!!

 

예전의 개발 방식은 순차적 폭포수 개발 방식!!

계획 -> 설계 -> 개발 -> 테스트 -> 유지/보수

 

최근의 개발 방식은반복적 점진적 개발 방식!!

Iteration을 아주 짧게 돌려서 기능 부분별로 개발한다.

개발과 테스트를 동시에 진핸한다.

단계별로 Small Release를 한다.

사이사이에 코드 리뷰를 하고 분석을 한다.

 

CI 서버를 이용하여 개발자들이 COMMIT을 하고 통합빌드 -> 릴리즈빌드를 진행한다. => 피드백을 팀장에게 메시지를 보낸다.

 

 

 

무엇이 문제인가??

 

-소스코드는 관리하기 힘들다.

-아무도 있던 소스로 일하기를 원하지 않는다.

-자주 수정하다보니 걸레 수준이다.

-소스를 작성한 엔지니어가 이미 회사를 떠났다.

-프로그래머의 개성이 강하다.

 

 

소스를 보면…..

표준함수가 있는데 안 쓰고 자기가 만든다.

설명이 없는 상수가 많다.

함수의 길이가 길다.

함수, 변수의 이름에 일관성이 없다.

약어, 상징어를 자기 맘대로 쓰는 것

 

 

안전하고 좋은 코드!!

오류 발생 가능성이 적은 코드

테스트가 가능한 코드

보기 좋은 코드

 

 

좋은 코드를 만드는 습관!!

-설계를 미리 고민한다.

-구현 전에 문서를 만든다.

-소스를 반드시 읽자!!

-모든 문제를 분석하자!!

-나만의 문제란 생각을 버리자!!

-비효율적인 답최적의 답, 중간의 답 => 모두가 정답이다!!

-최적화는 뒤로 미루자 깨끗한 코드를 작성하는 것이 먼저 => 구조적인 최적화를 고민

-성능 최적화는 프로파일링 툴로 성능을 평가한 후에 가장 큰 놈만 팬다.

-읽기 어려운 코드는 reuse도 하지 말자

-디버거를 꼭 사용해야 한다.

-warning은 미래의 버그이다.

-코딩의 생산성을 생각하자!!

-문법의 오류가 없어도 오해의 소지가 있다면 쓰지 말자!!

-‘핫 키를 사용해야 한다 => 마우스를 사용하면 손가락 5개를 뺏기게 된다.

 

 

도구를 이용하자!!

에디터, 검사도구, 이슈 트래킹, 버전관리 등등

 

바둑 : 기보를 보며 공부하고 복기를 한다.

코딩 : 남이 만든 코드를 읽고 내가 작성해 본다.

 

 

신뢰성 있는 코드를 만드는 것!!

아주 잘 테스트가 되어있는 소스들은 프로들이 짜도 하루에 10~40줄 정도!!