버전 관리
팀에서 일하고 있기 때문에 배포 된 것을 사용하는 것이 가장 좋습니다. 후보자는 Git과 Mercurial입니다. 즉, 팀은 프로젝트를 중단하지 않고 로컬로 커밋 할 수 있지만 작업을 추적 한 다음 이러한 커밋을 중앙 서버로 푸시 할 수 있습니다. 코드가 개정이 아닌 변경 세트로 추적되므로 훨씬 빠르며 병합 충돌이 적습니다. hginit 안내서 (스택 오버플로 공동 창립자가 작성)를 읽으면 DVCS가 무엇인지 조금 더 이해할 수 있습니다. http://hginit.com/

rsync 또는 ftp 대신 배포를 위해 리포지토리를 사용해야합니다.

테스트 주도 개발 테스트
중인 작업에 따라 많은 시간이 소요될 수 있습니다. 작은 프로젝트의 경우 오버 헤드이므로 완전히 건너 뛰라고 말하지 않습니다. 라이브러리 또는 대규모 장기 프로젝트를 작성하는 경우 반드시 테스트를 작성하십시오. 테스트는 유지 보수 단계에서 도움이됩니다. TDD가 모든 버그를 찾을 수는 없습니다. 사용자 경험 문제, 레이아웃 문제, 성능 문제 등이 있습니다.

Xdebug 디버깅 은 기본적으로 유일한 선택입니다. Netbeans과 잘 통합됩니다. 변수를 인쇄해야 할 필요가 있다고 생각되면 로그 파일을 사용해야합니다. 프레임 워크 로그 기능을 사용하면 프로덕션 환경에서 훨씬 안전합니다.

계획 / 다이어그램
만약 좋은 프레임 워크를 사용한다면 상세한 다이어그램을 너무 많이 만들 필요는 없습니다. 간단하게 유지하고 더 짧은 릴리스 주기로 작업 할 수 있으므로 과도하게 계획하기 쉽습니다. 프로젝트의 요구 사항과 사양은 변경 될 수밖에 없기 때문에 모든 시간을 투자하지는 않을 것입니다. 코드는 가장 세부적인 수준의 사양임을 기억하십시오.

버그 추적 도구 (아래 참조)를 사용하여 사양을 팀 구성원에게 할당 할 수있는 작업으로 나눕니다. 중앙 도구를 사용하여 프로젝트를 문서화하면 버그 추적기에 위키가있을 수 있습니다.

Mysql Workbench와 같은 도구를 사용하여 다이어그램에서 데이터베이스 스키마를 디자인하고이를 SQL로 내보낼 수 있습니다.

프레임 워크와 OOP
아마도 가장 중요한 부분 일 것입니다. 빠른 개발 및 코드 재사용을 지원하는 대중적인 프레임 워크를 찾으십시오. 어떤 사람들은 이런 말을 좋아하지 않지만, 틀이 당신의 작업 방식을 지시해야합니다. 한 개발자가 프로젝트를 전환하고 특정 페이지의 컨트롤러가 어디에 있는지, 템플릿 변수가 무엇인지, 모델을 쿼리하는 방법을 정확히 알 수 있도록 구조를 제공해야합니다. 일부 프레임 워크는 여기서 너무 많은 유연성을 허용하므로 개발자가 항상 같은 방식으로 프레임 워크를 사용하지는 않습니다. 나는 파이썬 철학을 좋아한다. 모든 것을 할 수있는 확실한 방법이 있어야합니다. 이것이 내가 장고와 레일을 좋아하는 이유이며, 그들은 매우 의견이 많으며 다른 사람의 코드를보고 그것이 무엇을하는지 이해할 수 있음을 의미합니다. Symfony는 여기서 가장 좋은 옵션처럼 보입니다.

다음과 같이 스택 오버플로에 대한 많은 ‘어떤 프레임 워크’질문이 있습니다 : https :
//.com/questions/2648/what-php-framework-would-you-choose-for-a-new-application-and-why

버그 추적
귀하의 팀에게 개발자를위한 좋은 버그 추적기를 만드십시오. 베이스 캠프처럼 단순화 된 것을 사용하지 마십시오. Redmine과 Unfuddle은 훌륭한 버그 추적기의 두 가지 예이며 시간을 추적하고 리포지토리와 통합 할 수도 있습니다. 팀은이 도구를 사용하여 전자 메일 또는 IM이 아닌 문제를 전달해야합니다. 기존 버그 및 문서 기록이있을 때 새로운 개발자가 더 쉽게 만들 수 있습니다. 이 기사에서는 좋은 버그 추적기의 역할과 그 이유를 정확하게 설명합니다. http://www.joelonsoftware.com/articles/fog0000000029.html