돌아보기

이상적인 개발자의 일상

출근 후 코드를 SVN으로부터 업데이트 받는다.
CI 의 리포트 확인.
CI 리포트에 오류가 있을 (빌드가 깨져있을) 경우

수정할 수 있다면 직접 수정후 테스트 한 뒤 commit
담당자가 수정하도록 ticket 발급

Stand up meeting 을 가지고 어제 일을 반성하고 할 일에 대해 구성원간 공유를 한다.
Issue Tracker에 등록된 ticket이 있는 지 확인하고 처리한다.
Story에 기반하여 자신이 할 일을 정의해 eclipse 의 task 목록에 등록한다. (Issue Tracker에 자동으로 등록된다.)
등록한 task 에 대한 test case 를 만든다.
test case가 성공하도록 구현한다.
더 이상 task에 대한 구현 사항이 없다면 코드를 commit 한다.
구현 과정에서 특기할 만한 것이 있다면 wiki 에 공유.
오늘 할 일이 끝나면 퇴근.

조엘 테스트

1. Source Control(소스 컨트롤)을 사용하십니까? 예

2. 한번에 빌드를 만들어낼 수 있습니까? 아니오

3. daily build(일별 빌드)를 만드십니까? 아니오

4. 버그 데이타베이스를 가지고 있습니까? 아니오

5. 새로운 코드를 작성하기 전에 버그들을 잡습니까? 아니오

6. up-to-date(최신) 스케줄을 가지고 있습니까? 아니오

7. spec(설계서)를 가지고 있습니까? 아니오

8. 프로그래머들이 조용한 작업환경을 가지고 있습니까? 아니오

9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까? 예

10. 테스터들을 고용하고 있습니까? 아니오

11. 신입사원들은 면접 때 코드를 직접 짜는 실기시험을 봅니까? 아니오

12. hallway usability testing(무작위 사용성 테스팅)을 하십니까? 아니오

2점. 2005년 기준의 테스트인데 우리는 과거에 있나 현재에 있나. IT에서 5년은 영겁의 세월.

현재의 상황 - 어쩔 수 없었을 것입니다.

기존 방식을 고수 하는 이유

가장 빨리 할 수 있다.
가장 안전해 보인다.

젠가, 폭탄 돌리기
땀이 베어있는 코드
view 와 logic 이 분리 되어 있지 않음.
controller 와 persistence layer 가 분리되어 있지 않음.
단위테스트 가 없음.
빌드 가 소스 코드에 통합되어 있지 않음.
각각 다른 개발 환경 - editplus, vi, eclipse 등.
서로 다른 코딩 스타일.

왜 변화해야 하는가

테스트가 잘되어 있어야 개발 비용을 줄일 수 있다.
웹사이트는 계속 변경되지만, 변경 비용은 뒤로 갈 수록 비싸진다.
일이 재미있습니까? -> "재미" 를 먼저 찾기 위해 노력해야 하지만, 결국 개발주기를 반복하다보면 재미가 나오는 것이지, 그 전에 재미가 무엇인지를 알고 그것만 개발하기는 힘들다. 그러니까 변화를 수용해라.
기술은 끊임 없이 변화한다. 조금씩 계속해서 변화에 적응해야 살아 남을 수 있다.

코드 공동 소유

Truck Number

우리의 Truck Number 는 1에 가깝다.

리팩터링

지속적으로 코드의 품질을 유지하려면 리팩터링이 필수 이지만, 남의 코드를 건드릴 수 없다면 리팩터링을 할 수 없다.

리팩터링은 성숙한 실천법으로 코드를 항상 변화가 용이하도록 유지해준다.

선결과제

배경 지식의 공유
Framework

코드 중복 제거
일관된 코드 구조
메인 비즈니스에 집중 (폼 검증 등은 framework 에 위임)

TDD
SVN Notifier : 다른 사람의 commit 을 감지하고 Code Review를 도와준다.
Conflict : 다른 사람이 작성한 코드와 수정중인 코드의 충돌을 미리 감지한다.
짝프로그래밍

TDD

90년대에 OOP가 대두됐다면 21세기는 TDD가 대세
TDD는 테스트 기법이 아닌 설계 기법
단위 테스트는 보너스 (조엘테스트 5)
꼭 필요한 기능만 구현하게 되므로 , Feature Creep 를 막을 수 있다.
작성된 테스트는 문서로서의 역할도 수행한다.
품질을 올릴 수 있으므로, 버그가 크게 줄어든다.
리팩터링의 필수 도구. (외부 동작은 같으며 내부구조를 변경)
자동 테스트를 도입하려면 강력한 리더쉽, 분명한 비전, 용기가 필요.

Crytec GDC'09 에서

질문자 : 어떤 사람들은 단위 테스트를 잘 이해하지 못해서 테스트를 작성하게 하는데 어려움이 있는데 너네는 어떻게 했냐?
Tech Director : 억지로 시키면 안 되고, 개발자들에게 단위 테스트(자동 테스트) 의 중요함을 이해시켜야 한다.
질문자 : 그래도 잘 안 된다면?
Tech Director : 그럼 나가게 했다. 그마나 우리 뿐만 아니라 유비소프트나 EA 에서도 개발자 면접 볼 때 단위테스트를 해 봤는지 물어본다고 하더라. 이제 단위 테스트는 피할 수 없는 거라고 생각한다.
질문자 : 좋은 테스트를 만드는 건 참 어렵다. PT 에서는 멘토링이 필요하다고 했는데 너네는 어떻게 했냐?
Tech Director : 컨설팅을 받는 것도 좋은 생각이지만, 우리는 그냥 팀원들끼리 pair programming 을 하게 했다.

Continuous Integration

"자주 커밋하고 자주 통합하라" 애자일의 원칙
HUDSON을 통해 Auto Build, Deploy, UNIT TEST를 수행하여 매일 아침마다 그날 집중해야 할 일을 찾음
정적 테스트가 가능할 경우 효과가 극대화

나누어 일하기

직군 세분화

Frontend Engineer
Web QA Tester (조엘테스트 10)
Persistence Layer Developer
Web Service (API) Developer

Go MVC

직군을 세분화 하기 위해서는 필수이다.
패턴을 적용할 수 있다.
본연의 업무에 집중 가능.
좀 더 독립적인 컴퍼넌트들.

=> 협업에 대해 좀 더 깊은 고민을 해야 한다.

PHP 개선

PHP MVC Framework

다음과 같은 MVC Framework 들이 많이 쓰인다.

ZendFramework
Code Igniter
Cake PHP
Sympony
Agavi
qphp
Fuse

여러 종류의 MVC framework 이 있지만 전혀 표준화 되어 있지 않음.
PHP MVC Framework는 필요없다. -> Rasmus

PHP 개발도구

Editplus

가볍고 단순.
리팩터링이 어렵다.
build 환경을 가지고 있지 않다.

Eclipse

PDT 를 사용하여 PHP 개발을 지원.
Xdebug, Zend Server CE를 사용하여 Debug를 통합하고 Profiling 이 가능.
Java 개발 도구에 비하여 현저히 부족한 features.
Unit Test가 IDE에 통합되어 있지 않다.

Zend Studio

현재로서는 가장 완벽한 PHP 개발도구.
Zend Server와 통합되어 좀 더 세밀한 Debug와 Profiling 이 가능.
Unit Test 가 JUnit 처럼 IDE에 통합되어 있다.
copy 당 $400 은 너무나 부담스럽다.
Eclipse 의 Java 개발 도구 ($0) 보다는 만족스럽지 못한 환경

PHP의 한계

인터프리트 언어.
build 환경의 부재.
PHP의 코드 무결성은 runtime 에서 확정 되므로, 실행(url 을 열어보기) 전까지 무결성을 장담할 수 없음.
Test 가 IDE에 통합 되지 않음
PHP5 로의 전환 -> 곧 PHP6가 나온다. 다시 한 번 패러다임의 전환이 필요.

비슷한 경험을 가진 NHN (Non-confidential, 채용·세미나등에서 공개)

2006년까지 문제에 대한 반성
2007년 중반 부터 PHP MVC Framework 을 도입하기로 함. Mojavi 등 검토 하고 최종 ZendFramework을 사용하기로 함.
2개의 파일럿 프로젝트만에 ZendFramework 사용을 중단하기로 함. (본인이 이 중 1개 프로젝트 전담자)

언어의 한계로 확장이 힘들다. (모듈 재사용, 세션 공유 등)
IDE에 통합된 Unit testing framework의 부재.
전문 인력 부재. 기존 개발자들이 관련 지식을 습득하는 데 어려움을 겪음.
사세 확장에 따라 신규 인력 채용에 박차를 가했으나 관련 인력을 구할 수 없음

정규 교육기관의 커리큘럼에 PHP 는 찾아보기 힘듬.
사설 교육기관에서 PHP Framework 에 대한 내용이 없음.

미들 티어등 엔터프라이즈영역의 library 부재.
결국 유연한 PHP언어의 장점을 버리기로 함.

2년의 cooltime 을 가지고 Java 계열 Framework (Lucy) 로 전환하기로 결정.
2009년 현재 모든 프로젝트 Java로 전환하였거나, old 프로젝트 버림.

왜 JavaEE 인가

모든 방면에서 검증된 플랫폼.
숙련된 인력을 구하기 쉬움.
표준화된 spec, library 들
강력한 확장성.
컴퍼넌트 모델이 확립되어 협업이 용이하다.
이미 성숙된 환경. PHP6에서 Enterprise 영역에 대해 적극적 지원(이로 인해 이전의 PHP보다 급격히 복잡해진 spec) 을 언급하나, JavaEE에서는 이미 완성.

PHP in JavaEE

quercus - 100% Java Code로 PHP를 구현 (Jython, JRuby 등과 대비)

별다른 노력을 들이지 않고 기존 코드 사용가능
PHP 를 Java 바이트 코드로 변환 가능 (인터프리트 언어의 단점 극복)
mod_php 보다 최대 4배 빠른 속도
기존 PHP 코드를 유지하면서 Java 환경의 개발을 할 수 있음.
개선된 환경으로 나아가기 위한 완충작용

Glassfish - 다양한 스크립팅 지원. quercus와 함께 사용가능.

Ruby (Jruby)
Python (Jython)
Groovy/Grails
Scala/Lift
Phobos (Server side Javascript for Ajax)

우리의 프로젝트

단순히 quercus library만 사용한다고 동작 하지는 않음.
mysql 모듈에서 몇가지 문제가 발생

JDBC에서 허용되지 않는 쿼리 실행시 (SET NAMES ...) -> SET NAMES를 사용하지 않는다. JDBC parameter 수정으로 가능.
빈 문자열을 Boolean type으로 사용시 (JDBC의 한계) -> 비교 구문의 수정
Zend Guard 로 인코딩 된 php 파일은 실행하지 못함 -> 사실상 Zend Guard는 아무런 역할을 하지 못하고 수많은 decompiler 앞에 무력하므로 plain 으로 되돌린다.

그러나 어렵지 않은 노력으로 실행 가능.

PHP는 유연성이 아주 뛰어난 훌륭한 개발 환경 이므로 이를 받아들여, 다른 스크립팅 언어까지 지원가능한 Glassfish 환경에서 운용한다면 최상의 조합이 될 것.

Java 로...

JavaEE의 모든 것을 다룰 수 있는 언어.
Eclipse, Netbeans 등 무료로 가장 최상의 개발도구를 활용할 수 있다.
개발자의 미래를 위하여

연봉 통계 (indeed.com)

Java EE : $103,000
PHP : $74,000

구인 통계

Java : 10,395 개
PHP : 1,602 개

Issue Tracking

당신은 어디서 무슨 일이 일어나고 있는 지 알고 있습니까?

스탠드업 미팅

이해가 어긋나기 전에 바로잡을 수 있는 기회
더 많은 회의를 줄이기 위한 짧은 시간의 만남

이슈 트래커

실무자의 일정 관리.
한눈에 어떻게 돌아가는 지 알 수 있다.
보고성 회의를 크게 줄일 수 있다.
프로젝트의 교훈들에 대한 DB 가 쌓임.
앞으로를 예측 가능하게 해준다.

도구들

Trac

개발자에게 이상적인 도구.
SVN 과 완전히 통합.
Eclipse에 쉽게 통합. (ticket status, commit 로그 등)
설치가 어렵다.

Mantis

쉬운 설치
쉬운 사용
단순한 기능
비 프로그래머에게 편리함
강력한 통계 기능
Eclipse에 통합 가능하나 번거롭다. (할일 목록, SVN 과의 통합)

Jira

유료
Eclipse와 유기적 통합.
Atlassian의 다른 제품들(Confluence, Fisheye 등)과 연동
더욱 강력한 통계

실행 방안

당장 할 수 있는 것들은?

읽을 거리

Headfirst Software Development
애자일 프랙티스

티스토리 툴바