안정적인 시스템 대 더 나은 디자인

Question

5 월 매일 직장에서 나는이 딜레마를 만난다 :

"안정적인 시스템 대 더 나은 디자인"

일부 모듈을 수정할 때 일상적인 작업에서 잘못된 디자인을 볼 때

-> 잘못 쓰여진 코드

-> 잘못 작성된 알고리즘

-> 최적화 가능

나는 문제와 함께 문제를 해결하는 것을 선호합니다.

그러나 많은 사람들이 내 변화에 반대하는 몇 가지 지원에 반대합니다. 반대하는 사람들은 말할 것입니다.

"시스템이 안정적이면 비즈니스 지향이 있어야합니다. 어떤 것이 회귀를 유발할 수 있으므로 비즈니스를 선호하지 않습니다."

시간 :

6 개월 후에 자신의 서면 코드를 볼 수 있습니다.

누가 지원하는 동안 :

이것은 지속적인 개선이며 시스템은 더 안정적입니다.

그래서 사람들이 어떻게 생각하는지 알고 싶습니다.

Answer 1

적용 가능한 경우 단위 테스트 (또는 여러 가지 에지 케이스를 덮기 위해)를 작성하십시오. 이것은 당신에게 리팩터에 대한 자신감을 부여하고 당신이 아무것도 깨지 않았다는 것을 알고 있습니다.

물론 코드가 엄격하게 결합 된 경우 (또는 스파게티!) 문제가 될 것입니다.

Answer 2

깨지지 않으면 고치지 마십시오. 포장하십시오. 구현을 변경하지 않고 모듈을 최대한 분리하십시오. 실제 필요가 발생할 때 / 고정, 개선)를 만져야합니다.

Answer 3

내 의견은 이전 코드가 현재 작업을 방해하지 않는 한 완벽하지 않은 경우 이전 코드를 수정하지 않는 것입니다.

코드의 대부분은 심하게 작성되었습니다. 사실의 문제입니다. 품질 가치에 대한 완벽한 이해 와이 품질 수준을 달성하고 유지하기위한 접근 방식에 대한 합의를 통해 완벽한 팀에 있지 않다면 최적화가 큰 그림을 바꾸지 않습니다. 당신은 지금 무언가를 고칠 수 있지만 다음 사람은 다시 물건을 엉망으로 만들 것입니다.

Answer 4

나는이 산업에서 깨지지 않았다면, 좋은 이유가 없다면 그것을 고치지 마십시오.

Answer 5

응용 프로그램을 내부에 알거나 비생산적인 환경에서 응용 프로그램을 테스트 할 포괄적 인 단위 테스트 및 시간이있는 경우이를 위해 이동하십시오. 그렇지 않으면 필요할 때만하십시오.

Answer 6

둘 다 정확하고 쉬운 방법이 없습니다.

문제가 발생할 때 문제를 해결하지 않으면 모든 문제가 해결되지는 않습니다.

현재 진행중인 문제와 관련하여 100%가 아닌 수정으로 무언가를 깨뜨리면 사람들이 당신을 미워할 것입니다.

반면에, 무고한 코드 (또는 무고한 것처럼 보이는 코드)를 수정하고 예상치 못한 방식으로 깨지면 가치있는 것을 발견했습니다 : 부서지기 쉬운 코드. 부서지기 쉬운 코드는 일반적으로 아무도 감히 만지지 않는 것입니다. 그러나 제품을보다 안정적으로 만들려면 그러한 코드를 제거해야합니다. 이 도로의 첫 번째 단계는 그것을 찾는 것입니다.

나는 그러한 수정이 팀에서 많은 "불필요한"마찰을 일으킨다는 것을 인정해야한다. 부서지기 쉬운 코드를 터치하면 사람들이 당신에게 소리를 지르며 두려워합니다. 종종이 코드는 고객의 얼굴에 날려 버리므로 모든 종류의 방향에서 열이 나옵니다.

따라서 그것은 당신이 얼마나 많은 고통을 원인하고 당신이 기꺼이 견뎌 낼 것인지에 달려 있습니다. 만날 때 모든 것을 고정하면 연말까지 코드가 더 나을 것입니다. 그러나 종종 하루가 끝날 무렵 더 나빠집니다.

Answer 7

두 번째로 "파산하지 않았다면 고치지 마십시오"라고 답하지만 관련 링크가 있습니다 ...

절대하지 말아야 할 일, 1 부 -Joel Spolsky

본질적으로 - 때때로 이해할 수없는 코드는 실제로 이해할 기회가없는 필요한 버그 픽스입니다.

Answer 8

한편으로, 이미 더 많이 작동하지 않는 코드를 변경하면 물건을 깨는 위험이 있으며 쉽게 모든 소비하는 작업이 될 수 있습니다.

반면에, 나쁜 코드를 유지 해야하는 부담으로 인해 사물을 깨는 것에 대한 두려움 때문에 나쁜 코드를 혼자 남겨두면 새로운 발전을 방해 할 수 있습니다.

때때로 코드는 복잡한 코너 케이스를 처리해야하기 때문에 나쁘게 보입니다. Joel Spolsky가 지적합니다, 다시 작성하면 코너 케이스를 다루지 않아 버그가 발생합니다. 때로는 코드가 실제로 나쁘기 때문에 코드가 나빠 보이며, 다시 작성하면 알지 못했던 버그를 수정할 수 있습니다. 코드베이스에 대한 경험은 어떤 코드를 결정하는 데 도움이됩니다.

~ 안에 보이 스카우트 체크인, Jeff Moser는 "항상 캠프장을 찾은 것보다 캠프장을 깨끗하게 떠나는 것"이라는 아이디어에 대해 논의합니다. 모든 것을 고칠 수 없더라도 항상 코드베이스를 깨끗하게 두십시오. 이러한 작은 개선 사항은 시간이 지남에 따라 추가됩니다.

말했듯이 이 답변, 단위 테스트는 좋은 것입니다. 레거시 코드로 효과적으로 작동합니다, Michael Feathers는이 주제에 대한 훌륭한 자료입니다.

Answer 9

나는 개인적으로 필요한 작업을 수행하기보다는 물건을 고치는 데 시간을 소비하는 경향이 있습니다. 불행히도 쉬운 문제처럼 보이는 것을 고치고 당신이 원하지 않았던 큰 혼란을 풀기가 너무 쉽습니다.

나는 또한 다른 방법으로 다가오는 사람들과 함께 일했으며, 일을 끝내는 한 나쁜 비트로 살 수 있습니다.

종종, 당신은 미래에 더 쉽게 작업 할 수 있도록 '올바른 것을 얻는'나이를 소비 할 수 있으며, 앞으로 코드가 재사용되지 않는다는 것을 알게 될 것입니다.

가장 중요한 것은 팀에 대한 견해의 균형을 잡고, 다른 사람들과 정기적으로 논의하고, 궁극적으로 고객이 청구서를 지불하는 고객이기 때문에 프로젝트 요구 사항을 충족시키는 것입니다.

당신이 찾은 문제에 대해 건설적으로하십시오 - 그것을 위해 구멍을 선택하지 마십시오! 팀 코드 리뷰는 가난한 코더가 좋은 코드를 만드는 방법을 이해하기 시작하기 때문에 시간이 지남에 따라 나쁜 코드를 개선하는 데 도움이됩니다.

나는 'todo'댓글로 나쁜 코드를 표시 한 다음 나중에 시간/예산을 수정하기 위해 돌아 오는 것이 좋습니다. 적어도 당신은 잠재적 인 문제 영역에 대한 깃발을 얻었으므로, 필요하지 않은 수정에 시간을 낭비하지 않고도 (아마도) 시간을 낭비하지 않아도됩니다.