나는 모든 알려진 코딩 표준을 무시하는 것으로 보이는 여러 PHP/MySQL 웹 응용 프로그램을 지원하고 유지 관리해야한다는 과제를 썼다.무엇을 할 것인가 PHP의 프로 시저 코드, 비즈니스 로직 및 쿼리
PHP 코드에는 루틴, 프로 시저, 비즈니스 로직 및 쿼리가 포함되어 있습니다.이 코드는 모두 코드에 포함되어 있습니다. MVC조차도 객체 지향 프로그래밍이 없으며 프리젠 테이션 레이어와 애플리케이션 레이어가 분리되어 있지 않습니다. 이 응용 프로그램을 만드는 데 사용 된 프레임 워크가 없으며 새로운 프로젝트에 Yii Framework를 사용하고 있습니다.
이러한 애플리케이션을 다시 작성해야합니까? 적어도 반주는 그들을 수정해야하고, 새로운 일을하면서 기존 애플 리케이션을 업데이트해야한다.
누구든지 이에 대해 조언이 있습니까?
제품을 장시간 사용할 수 있습니까? 다른 사용자가 코드를보고 당신이 그것을했다고 생각합니까? 이러한 경우 예를 들어, 코드를 다시 작성할 수도 있습니다. 귀하의 회사에서 도움을 얻을 수있는 기회를 얻으십시오. 어쩌면 당신도 알게 될 것입니다.
많이 묻는 질문입니다. 이 망가을 일하고 경우 How do you stop yourself from refactoring working but awful code?
은 기본적으로 '그것을 깰. 당신이 그것에 종사하고 그것을 깨뜨리지 않고 코드를 수정하기 위해 변경할 수 있다면 그렇게하십시오. 코드를 다시 작성 하시겠습니까? 나는 투자의 수익은 얼마인지, 얼마나 많은 시간이 걸릴지, 새로운 버전을 도입하지 않고 이전 버전의 버그를 피할 수 있는지에 대한 아이디어를 가지고 갈 것입니다. 그런 것들.
프로젝트에 도움이되기를 바랍니다.
전적 재 작성에주의해야합니다. 응용 프로그램이 작동하고 사용자가있는 경우 경로는 기존 코드베이스를 수정하는 것입니다.
예, 기존 프레임 워크리스 코드베이스에 프레임 워크를 구현할 수 있습니다. 그것은 많은 노력을 필요로하지만 가능합니다 (나는 이것을 여러 번했습니다). 다시 시작하면 귀중한 시간을 잃을 것입니다. 그동안 입증 된 시간이었습니다. (Netscape 기억해?)
분명히 문제가 있음을 알고, 프레임 워크를 구현하고 응용 프로그램을 개선하여 응용 프로그램을 향상시키는 것이 해결책임을 알고 있습니다. 그것은 당신을 게임보다 앞서 가게합니다.
단계별로 새 프레임 워크를 구현하십시오. MVC 프레임 워크로 시작 - 코드베이스로 가져 오되, 아직 레이어가 분리되어 있지 않다는 사실에 대해 걱정하지 마십시오. 새로운 버전을 얻으려면 MVC 프레임 워크 위에 구축되었지만 실제로 MVC 규칙을 따르지는 않습니다. 시작입니다. 그런 다음 비즈니스 로직을 모델 계층으로 이동하십시오. 또는 그대로두면되지만 OO로 설정하십시오.
귀하의 직업은 사용자가 사용할 수있는 제품을 생산하는 것입니다. 당신의 일은 모범 사례를 따르지 않아야합니다. 의미 - 예, 모범 사례가 올바른 행동 과정입니다. 하지만 사용자가 앱을 사용할 수 없거나 앱이 경쟁 업체와 경쟁 할 수 없다면 쪼그리고 앉아서 상관 없습니다. 그걸 놓치지 마라. 앱을 개선하여 멋진 제품으로 만들 수 있지만 앱의 완성도를 좋게하지 마세요.
감사합니다. Mike, 나는 완전히 완벽하다는 데 동의하지 않습니다. 내가해야 할 일을 수행하고 다음 사람이 따라 다니고 지원하기 쉽도록 단단하고 잘 문서화 된 코드 이후입니다. 나는 할 수있을 때 할 수있는 일에 대해 당신의 생각을 좋아하지만 여전히 건전한 원칙을 따른다. –
프리젠 테이션 레이어와 bussiness 레이어가 분리되지 않은 것은 분명히 나쁘지만 다른 선택 사항과 함께 몇 가지 장점이 있습니다. 코드를 유지 관리하는 것이 어려울 경우 코드를 리팩토링하십시오. 당신이 좋은 디자인 패턴에 익숙하기 때문에, 당신은 그것을 상당히 쉽게 할 수 있어야합니다. 또한이 방법은 코드의 버그를 줄이는데도 도움이됩니다. 그러나 코드를 리팩토링하는 동안 상황이 나아지기 전에 상황이 악화된다는 것을 기억하십시오. 너무 빨리 포기하지 마세요.
리팩터링 코드와 관련해서는 결코 그런 생각을하지는 못했지만 그 이유 중 하나는 완전한 재 작성을 선택하는 이유였습니다. 나는 좋은 충고와 나보다 앞선 독서를 많이 가지고있다. 답장을 보내 주셔서 감사합니다. –
내 경험에 따르면, 이는 일반적으로 비즈니스 결정이었습니다. 상사가 이러한 시스템을 유지 보수하는 데 얼마나 많은 시간을 소비하는지 알고 있습니까? 얼마나 많은 사용자가 실제로이 시스템을 사용합니까? 비즈니스에 얼마나 비판적입니까? 재 작성으로 경영진을 파면 할 수 있습니까? 그리고 유용하고 유익하다는 것을 증명할 수 있습니까?
일상적인 유지 관리에서 이미 몇 가지 기본 리팩터링을 시작할 수 있습니다. 업데이트가 필요할 때마다 약간의 시간이 걸릴 수도 있지만 일종의 OOP 솔루션을 사용하거나 처리하기 쉬운 코드를 정리하는 방법을 찾으십시오. 전면적 인 재 작성은 일반적으로 좋은 아이디어가 아니며 판매가 어렵지만 이미 새로운 기능을 유지 관리하고 추가하는 경우 새로운 코드 또는 수정 사항을 사용하여 이미 존재하는 것을 개선 할 이유가 없습니다.
나는이 앱에 사용자로드가 얼마나 많은지에 달려있다. 라이브 시나리오에서 실제로 어지럽 혀지는 지, 그리고 얼마나 많은 시간을 이들 픽스처와 모든 것에 낭비하고 있는지에 달려있다.
완전히 지저분한 무언가에 브레이크 헤드보다 항상 재 작성하는 것이 좋습니다.
예 이러한 제품은 우리 회사의 업무 방식을 결정합니다. 그러나 나중에 수정 될 수있는 "그냥 완료했습니다"명령으로 구축되었습니다. 대부분의 오리지널 프로그래머들은 오래 전에 사라졌고이 앱들은 나중에 수정되지 않았습니다. 내 앞에있는 팀원 중 몇 명은 보고서를 마사지하고 일정한 사냥을하기보다는 (심지어 똑같은 문제를 일주일 내내 꺼내서도) 지속적으로 버그를 조사하고 그에 대한 조치를 취하는 것이 좋습니다. 내가 여기있는 곳을 더 읽을수록 내 상황이 독특하지 않다는 것을 알게된다. –