대규모 PHP 프로젝트의 재 작성 계획에 대한 팁?

나는 몇 년 동안 내가 일해 왔던 PHP 프레임 워크 (MVC 사용)를 완전히 다시 작성하기로 결정했습니다. 지금까지 내 문제는 프레임 워크 자체의 디자인에 대해 걱정하지 않고 아이디어를 생각해 내고 Trac에 티켓으로 던져서 나중에 추가한다는 것입니다. 시간이 지남에 따라 몇 가지 문제가 발생하여 재 작성이 도움이 될 것이라고 생각하지만 계획의 시작 부분을 잘 모르겠습니다. Trac을 사용하고 싶지 않다는 것을 알고 있습니다. 티켓과 이정표-그러나 무엇이 더 필요할까요?

나는이 재 작성을 철저히 계획하고 싶고, 내가 원하는 모든 기능, 어디로 갈 것인지, 그리고 다른 부분과 어떻게 연결될 것인지를 자세하게 설명하고 싶지만이 수준의 계획에 대한 경험은 없다. 어떤 충고? 도움이 될만한 프로그램이 있습니까? 나는 Trac에 질려있다. 나는 그것을 정말로 좋아하지 않았다.

디자인 문서가 필요하다는 것을 알고 있지만 따라야 할 특정 레이아웃이 있습니까? 버그 추적, 티켓, 이정표 등도 필요하지만 Trac 너머에도 그 점이 무엇인지 잘 모르겠습니다. 더 많이 필요하다고 확신하지만 무엇을 알지 못하므로 도움을 주시면 감사하겠습니다.

큰 프로젝트를 개발할 때 내가하는 일을 아래에서보십시오.

1-OpenProj와 같은 계획 도구를 사용하고 작업에 포함하려는 모든 기능을 추가합니다. 예를 들어, 현재 사용자가 내 사이트에 등록한 후 자동으로 로그온 할 수있는 기능을 개발 중입니다. 계획에 "feature-autologin"과 같은 작업이 있습니다.

2-저는 일인 개발 상점이므로 일반적으로 한 기능에서 다음 기능으로 이동합니다. 내 계획은 모든 기능이 순차적 인 방식으로 만들어졌습니다. 각 기능에 얼마나 많은 시간이 필요한지 추정하는 데 너무 많은 시간을 투자하지 않습니다. 나는 보통 각자 개발에 하루가 걸릴 것이라고 생각합니다. 더 많은 것을 취하면 계획을 간단히 업데이트하면 모든 향후 작업이 그에 따라 움직입니다.

3-나는 자식을 광범위하게 사용합니다. 각 기능은 지점입니다. 각 기능을 완료하면 개발 지점으로 다시 병합하고 다음 기능을위한 새 지점을 만듭니다.

4-소프트웨어에서 버그를 발견하면 작은 자식 분기를 만들어서 수정하고 해결되면 다시 병합합니다. 작업중인 개발 지점과 현재 기능 지점을 모두 업데이트해야합니다. 그건 그렇고 버그는 OpenProj 계획에서 또 다른 작업이됩니다. "버그-잘못된 주소"와 같은 것. 그리고 삽입하면 다른 모든 기능이 타임 라인으로 돌아갑니다.

5-개발 중에 새로운 기능에 대해 생각하면 계획에 가장 적합하고 타임 라인을 다시 조정하는 계획에 포함시키기 만하면됩니다.

이게 도움이 되길 바란다. 흥미로운 프로젝트가있는 것 같습니다. 행운을 빕니다!

완전한 재 작성을 원한다면, PHP를 전혀 사용해야하는지 고려해 보지 않겠습니까? 기술의 변경 / 업그레이드는 설계 / 확장 성 / 유지 보수성 등을 향상시키려는 촉매 제일 수 있습니다.

대신 크게 리팩토링하는 것이 좋습니다.

여기서 예상되는 문제 :

나는이 재 작성을 철저히 계획하고 싶고, 내가 원하는 모든 기능, 어디로 갈 것인지, 그리고 다른 부분과 어떻게 연결될 것인지를 자세하게 설명하고 싶지만이 수준의 계획에 대한 경험은 없다. 어떤 충고? 도움이 될만한 프로그램이 있습니까? 나는 Trac에 질려있다. 나는 그것을 정말로 좋아하지 않았다.

정말 힘든 것입니다. 기본적으로 모든 추악한 폭포 모델 입니다. 다음 은 '위대한 재 작성'접근 방식의 문제에 대한 일화적인 증거 입니다. 결론에 이르렀을 것입니다. 아마도 문제를 올바르게 예상하지 못하고 처음부터 다시 작성하려는 또 다른 혼란으로 끝날 것입니다. 당신이 나쁘기 때문이 아니라 한 번에 큰 것을 얻을 수 없기 때문에.

대신 리팩토링 시작하면, 당신은 할 수 있습니다 개별 티켓을 작성하고 프로젝트를 계속 사용할 수 있습니다. 여기에서의 트릭은 전체적으로 더 나은 디자인으로 이어지는 작은 변화를 식별하는 것입니다.

예를 들어 MVC가 없지만 원하는 것을 언급합니다. 첫 번째 단계로 단일 PHP 파일을 가져 와서 일반적인 믹스 업을 가정하여 정렬하면 맨 위에 모든 db-access, 계산 등이 있고 맨 아래에는 "템플릿"( 각 파일에 대한 첫 번째 티켓). 두 번째 단계에서는 이러한 모든 템플릿 부분을 함수로 캡슐화하여 매개 변수를 전달할 수 있습니다. (더 많은 티켓). 끝난? 축하합니다. MVC에서 V를 마쳤습니다.

기존 프레임 워크 사용을 고려하십시오. CakePHP, Zend Framework, CodeIgniter 및 Symfony는 PHP에서 알려진 것들입니다. 그들이 수백 또는 수천 명의 사용자의 요구를 충족 시키면 그들이 당신의 요구를 충족시킬 수 있다고 확신합니다.

PHP 이외의 것을 배우거나 사용하려는 경우 Django (Python) 및 Rails (Ruby)는 일반적인 웹 응용 프로그램의 주요 프레임 워크입니다.

물론 프레임 워크를 만드는 경험을 원치 않는 한, 기존의 지원되는 프레임 워크를 잘 사용하는 방법을 알기보다는 시장에서 훨씬 가치가 낮습니다.

내가 사용 하는 것은 스케줄 추적기로 Redmine 입니다. IT는 trac보다 훨씬 사용자 친화적 인 (제 의견으로는) 각 항목을 매우 잘 처리합니다.

다시 쓰기와 관련하여, 모든 기능 / 새로운 확장 기능이 제공 될 것으로 예상하지 않으므로 가능한 한 유연하게 응용 프로그램을 작성하고 작성하는 것을 이해해야합니다. PHP가 가지고있는 많은 MVC 프레임 워크를 사용하면이를 활용할 수 있습니다. 그러나 DB 프레임 워크가 처음부터 유연하지 않으면 이러한 프레임 워크 중 일부에 문제가 생길 수 있습니다 (Cake). 나는 당신이 할 수있는 한 추상적 인 것을 만드는 데 정말로 집중할 것입니다. 하드 코딩 된 것을 볼 때마다 그것이 무엇인지, 왜 DB에 저장할 수 없는지 스스로에게 물어보십시오.

실제로 DB 디자인은 수많은 질문과 문제에 대한 답변을 제공하며, 애플리케이션과의 상호 작용 방식이 가장 중요합니다. 따라서 데이터 저장 방식과 DB 구성 방식을 분석하는 데 많은 시간을 할애하는 것이 좋습니다.

이슈 추적 소프트웨어로서 JIRA는 훌륭하지만 비용이 많이 듭니다. 내가 사용하는 또 다른 좋은 도구는 Eventum입니다. 무료입니다.

그러나 가장 중요한 부분은 필요한 것을 잘 이해하는 것입니다. 먼저, 어플리케이션에 대한 요구 사항을 수집하고, 원하는 것에 대해 가능한 한 완전한 느낌을 갖도록해야합니다.

이를 바탕으로 소프트웨어 요구 사항을 만들 수 있습니다. 이는 응용 프로그램의 일부가 될 모듈, 해당 기능 및 하위 기능, 객체, 클래스, 인터페이스 등 모든 것을 설명하는보다 기술적 인 접근 방식입니다.

애플리케이션의 복잡성과 필요한 코드 라인에 대해 잘 알고 있으므로 추정하고 일정을 만들 수 있습니다. 일정과 마감일을 정하는 것이 중요합니다. 그렇지 않으면 마감하지 않을 수 있습니다.

그것이 도움이되기를 바랍니다.