낡은 방식으로 PHP를 사용하고 있는 조직의 개발환경 개선 방안 구상

다음 글은 현재 속한 팀에서 공감과 개선을 이끌어 내고자 공유했던 내용이다. 비슷한 상황을 가지고 있는 사람에게 참고가 될 수 있을까해서 포스팅 해본다.

돌아보기

이상적인 개발자의 일상

• 출근 후 코드를 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
• 애자일 프랙티스