큰 변화를 제안 / 인턴으로 다시 쓰기 [닫기]

문맥:

• 내부 프로젝트입니다 (많은 사람들이 사용하지 않는다고 생각합니다)
• 오래 되었군요
• 우리는 그것을 업데이트하고 있습니다

문제 :

1. 그것은 mvc 프레임 워크를 남용합니다 (모델의 사용, 뷰의 비즈니스 로직 등)
2. 우리가 요구하는 것은 작지만 응집력이 낮기 때문에 두 가지 옵션이 있습니다.
   1. 물건을 계속 찌르다
   2. 큰 코드 덩어리를 옮기거나 물건을 다시 씁니다.

해결책 (내가 본다) :

1. 리팩토링 / 재 작성을 통해 새로운 버그를 도입하지 말고 조만간 작업을 진행하고 모범 사례를 무시하고 새로운 버그를 도입하지 마십시오.
2. 리 팩터 / 리 라이트

내 질문은 실제로 것 같아요 :이 프로젝트를 크게 변경하려면 누군가를 모욕하지 않고 어떻게 제안합니까? 아니면 때때로 (비유적인) 덕트 테이프를 의미하더라도 흐름을 따라가는 것이 더 좋을까요?

알았어

응용 프로그램이 잘못 구성되어 있고 잘못 작성되었다고 생각합니다.

고객은 그것이 일을하고 있다고 생각합니다.

당신은 "내부 아름다움"을 향상시키는 것 외에 다른 이유없이 그것을 다시 쓰고 싶다.

따라서 고객에게 애플리케이션이 현재하는 일을 정확히 수행하는 데 돈을 쓰도록 요구하고 있습니다. 사용자가 보거나 이해하지 못하는 부분 만 "더 나은"것입니다.

잘못 작성된 잘못 작성된 코드에 대한 주된 반대 의견은 이해하기 어렵다는 것입니다.

이 코드는 이해하기 어렵고 잘못 구조화 된 응용 프로그램에서만 쉽게 구현할 수있는 기능과 특징을 가지고 있습니다. 따라서 당신이 이것에 매우 능숙하지 않으면 새로운 응용 프로그램은 현재 응용 프로그램이하는 일을 정확하게 수행하지 않을 것입니다. 원래 코드가 무엇을했는지 완전히 이해하지 못했기 때문에 아마도 잘못했을 것입니다.

따라서 고객은 이제 원래 응용 프로그램보다 훨씬 나쁜 응용 프로그램을 얻는 데 많은 돈을 소비했습니다. 당신은 인기가 없을 것입니다!

운 좋게도 경험이 많은 대학은 당신을 유머러스하게 준비하고 있습니다.

그래서 제 조언은 오래된 코드베이스를 계속 실행하고 조용히하는 것입니다. 고객은 코드가 못 생겼다고 생각하더라도 실제로 신경 쓰지 않는 시스템을 원합니다.

변경 사항을 제안하십시오. 수 분명 각각의 비즈니스 사례에 : 왜 제안합니다 변화 도움말 시스템 전체? 그렇지 않은 경우 다시 밀어 넣으십시오. 왜 깨지지 않은 것을 고쳐 돈을 쓰나요? 이러한 시스템이 더욱 확장 만들기 등의 이유와 우려의 분리 할 수있다 유효하지만 (누가 말 하느냐에 따라) 99 %의 시간 만 "정확히 구현되지 않았다"고 말하면 아무데도 갈 수 없습니다. 코드를 정리하더라도 작업을 제안하는 것이 아니라 프로젝트에 가치를 더하고 있는지 확인하십시오.

불행히도, 전문 세계에서 무언가 잘못 구현되었다고해서 그것이 깨져서 고칠 필요가 없다는 것을 의미하지는 않습니다. 또한이를 수정하면 프로젝트의 다른 영역에 영향을 줄 수있는 예기치 않은 녹아웃 문제가 발생할 수 있습니다.

귀하의 질문을 읽고, 난 응용 프로그램을 다시 작성하는 것이 가치가 있다는 사실은 의심. 아마도 당신은 당신의 질문에 전체 사례를 귀찮게하지 않았을 것입니다. 그러나 오래되고 거의 사용되지 않는 내부 응용 프로그램 인 경우 재 작성의 이점이 비용 가치가 있습니까? 재 작성 비용은 모든 업데이트 및 패치의 합계보다 높을 수 있습니다.

그것이 사실이 아니라고 생각한다면 여기에서 한 것보다 더 많은 사례를 만들어야합니다.

응용 프로그램을 개선 할 때 업데이트 과정에서 자연스럽게 발생하는 약간의 리팩토링이 발생할 수 있습니다.

당신은 인턴입니다. 아마도 당신은 아주 새로운 사람 일 것입니다. 그들은 아마도 당신을 바보로 의심합니다.

따라서 제안을 할 때 가볍게 밟으십시오 . 겸손하고 가정하지 마십시오. 다른 회원이 코드베이스에 대한 자신의 아이디어와 그에 따른 압력에 대해 토론 할 수 있도록 아이디어를 대화식으로 전달하십시오 (물건을 정리하려는 노력을 기울이지 않은 이유가있을 수 있습니다).

당신은 그들의 신뢰를 얻고 싶습니다. 주어진 작업에 적합한 코드를 작성하여이를 수행합니다. 깨끗하게 작성하고 구현하고 싶은 모범 사례를 사용하지만 할당 된 작업에만 사용하십시오. 이것들은 아마도 작은 일이 될 것입니다. 팀의 나머지 사람들은 아마도 중요하지 않다고 생각합니다. 그 일을 잘하십시오. 당신이있는 곳을 밝게 비추고, 팀이 코드를 호의적으로 검토하게되면 아이디어도 점점 커질 것이다.

결국 , 역량과 지식을 입증 할 때 제안을 철회 할 수 있습니다.

나는이 제안을 전적으로 동료 개발자에게만 제안 할 것이다 . 나는 경영진이 어떤 유형의 경계를 넘어서는 것으로 생각할 것이기 때문에 경영진에게이를 제시하지 않을 것이다.

작업중인 개발자에게 제안한 후 코드베이스가 왜 그런지에 대한 몇 가지 이유가있을 수 있습니다. 그 이유는 "아니오, 실제로 코드는 괜찮습니다. MVC를 이해하지 못하는 것 (그리고 이것이 인턴 인 이유)"에서 "좋은 생각입니다. 새로운 응용 프로그램을 함께 설계합시다"까지 다양합니다.

이 응용 프로그램을 리팩토링하는 것에 대한 대답은 '아니오'일 것입니다. 인턴쉽이 내부 응용 프로그램을 다시 작성하는 것을 원하지 않습니다. .

그러나 동료에게 물어 보는 것은 결코 아프지 않으며, 그렇게하면 배우게됩니다. 그리고 7983879342는 인턴쉽의 모든 것입니다.

어떤 일이 있어도 다음 메시지를 제거하기를 바랍니다. 위의 응답 중 일부는 때때로 코드 재 작성을 지적 했으므로 최상의 기술적 이유로 비즈니스 / 비용 이유로 실현할 수없는 경우가 있습니다. 너무 많은 프로그래머가 기술 솔루션에 살고 있으며 기술적 우아함 / 가독성 / 모범 사례에 대한 그들의 개인적, 탐구는 업무 수행에 대한 비즈니스의 요구와 균형을 이루어야한다고 생각하지 않습니다. 내 개인적인 경험에서 (양 방향에서) 균형을 맞추지 않는 사람은 종종 팀 내에서 책임으로 간주됩니다.

넉백이 생기더라도 배우고 성장하는 방식에 대해 질문하는 것을 멈추지 마십시오.

다른 답변은 귀하의 상황의 정치에 대해 많이 말했으며 동의하는 경향이 있습니다. 매력적인 비즈니스 사례를 제시 할 수 없다면 카드에 다시 쓰지 않을 것입니다.

그러나 이것이 보이 스카우트 규칙을 잊어야한다는 의미는 아닙니다 .

항상 캠프장을 찾은 것보다 깨끗하게 두십시오.

이 코드베이스에서 무언가를 구현하는 동안 디자인이나 구현의 일부 측면을 정리하는 방법을 알아낼 수 있다면 고려해야합니다. MVC 모델을 더 잘 사용하기 위해 전체 애플리케이션을 다시 작성할 필요 가 없으며 특정 뷰에 대해 새로운 비즈니스 로직을 구현하는 경우 이전 뷰에서 로직을 모델로 이동하는 것을 고려할 수 있습니다. 새로운 논리를 추가합니다.

다른 사람들이 말했듯이 다른 개발자 (이 응용 프로그램에 익숙한 사람)에게 구현 방법 / 이유를 이해할 수 있도록 빠른 연습을하도록 요청하십시오. 기술적 측면을 이해할 수는 있지만 점을 비즈니스 요구 사항 (비즈니스 요구 사항보다 우선)에 연결할 수 있기를 원한다고 설명합니다.

이 정보가 있으면 평가를 수행 할 수 있습니다. 개인적으로 다시 작성해야한다고 생각하지만 다른 사람들이 시간을 잘 활용한다고 생각하지 않는다면 개인 프로젝트로 사용하십시오. 여기에 1 시간이 걸리거나 다운 타임이 발생하더라도 구현을 "올바로"수행하십시오. 작업을 마치면 다른 개발자에게 "이봐, 이것 좀 정리할 수있을 것 같아서 다운 타임 중에 부수적 인 일을했다고 생각합니다. 어떻게 생각하십니까?" 그들에게 변화를 누르지 말고 그냥 "이봐, 너희들 이래?" 거기에서 가십시오.

대부분의 변경은 일반적으로 점진적으로 발생합니다.

명심해야 할 몇 가지;

• 응용 프로그램의 역사는 무엇입니까?
• 오늘 왜 못 생겼어?
• 아키텍처 변경의 이점은 무엇입니까?

좋은 전략은 작은 일을하고 물건에 대해 많은 질문을하는 것입니다 (Google이나 소스에서 배울 수없고 사람들의 시간을 낭비하지 않는 질문). 코드베이스와 개발자에게 편안함을 느낀 후에는 코드가 왜 그런지 잘 알고 있어야합니다. 때때로, 그것은 단지 "그렇습니다, 우리는 무언가를 해킹하고 그것을 문 밖으로 밀어 내야했습니다". 정상적인 작업을 수행 할 때 발생하는 시스템의 작은 부분에 약간의 변경을 제안 할 수 있다면 급진적 재 작성보다 더 큰 견인력을 얻습니다.

멋지게 물어보고 논리적 인 사례를 만들면 (직감이나 더 나은 방법은 아님) 다시 쓰기를 제안해도 아무런 문제가 없습니다. 사용률이 낮은 응용 프로그램을 다시 작성할 가능성이 높으며 원래 시스템을 작성한 사람이 여전히 주변에 있고 (나보다 계층 구조가 높을 때) 비판을받지 않을 가능성이 높습니다.

"우리는 기본 MVC 원칙을 위반하는이 끔찍하게 설계된 시스템을 다시 작성해야합니다"라고 말하지 말고 적절한 상위 계층 (직접 사람)에게 공개 질문으로 요청하십시오. "MVC 모델로 시스템을 다시 작성하면 장기적으로 많은 시간을 절약 할 수 있을지 궁금합니다. 어떻게 생각하십니까? MVC 모델을 통합하고 TDD 등을 수행했으며 2 개월의 정기 유지 보수 후에도 고장날 수 있습니다. " 우리는 그럴 필요가 없다고 생각할 수도 있습니다. 귀하의 예상 시간과 새로운 시스템이 적절한 대체품이 될 가능성에 동의하지 않습니다. 또는 응답은 괜찮을 수도 있지만 새로운 시스템이 사람들이 당신을 비난 할 것이라고 제안한 시간 내에 새로운 시스템보다 좋은 / 더 나은 일을하지 마십시오. 그리고 시스템이 거의 사용되지 않더라도; 다시 쓰기 기간 동안 사소한 수정으로 업데이트를 중지하지 못할 수도 있습니다.