낡은 방식으로 PHP를 사용하고 있는 조직의 개발환경 개선 방안 구상
2010/02/08 19:00
다음 글은 현재 속한 팀에서 공감과 개선을 이끌어 내고자 공유했던 내용이다. 비슷한 상황을 가지고 있는 사람에게 참고가 될 수 있을까해서 포스팅 해본다.
나누어 일하기
돌아보기
이상적인 개발자의 일상
- 출근 후 코드를 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 가 쌓임.
- 앞으로를 예측 가능하게 해준다.
도구들
실행 방안
당장 할 수 있는 것들은?읽을 거리
- Headfirst Software Development
- 애자일 프랙티스
댓글을 달아 주세요
잘 읽고 갑니다. Trac은 설치가 크게 어렵진 않았던 걸로 -_-;;
trac에서 redmine으로 넘어왔는데 뭐.. 만족스러워요
좋은 도구 알려주셔서 감사합니다. eclipse mylin 연동도 되고 아주 쓸만하네요.
다행이네요 ^^ trac like한걸 개발하다가 걍 redmine 쓰게되었어요.. ㅋㅋㅋ 지인분들 소개해드렸더니 trac보다는 만족하시던데..
trac은 그럭저럭 만족스러운데, wiki editor가 간지나는(..) 문서를 꾸미기엔 많이 부족한거 같아서 아쉽더라고요. 멀티 repository지원도 안되고 -ㅁ-;