정말 나쁜 시스템을 개선합니다
https://stackoverflow.com/questions/192464
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
정말 나쁜 시스템에서 어떻게 개선을 시작 하시겠습니까?
단위 테스트 및 리팩토링을 권장하기 전에 내가 의미하는 바를 설명하겠습니다. 나는 그 기술을 사용할 수 있지만이 경우 무의미 할 것입니다.
실제로 시스템이 너무 깨져서해야 할 일을하지 않습니다.
예를 들어 시스템은 보내는 메시지 수를 계산해야합니다. 대부분은 작동하지만 경우에 따라 메시지 카운터의 값을 높이는 것을 "잊어 버린다". 문제는 자체 해결 방법이있는 다른 많은 모듈 이이 카운터를 구축하여 카운터를 수정하면 시스템 전체가 현재보다 나빠질 것입니다. 솔루션은 모든 모듈을 수정하고 자체 보정을 제거하는 것이지만, 150 개 이상의 모듈로 너무 많은 조정이 필요할 정도로 감당할 수 없습니다.
더 나쁜 것은 시스템 자체가 아니라 사람들의 머리에 해결 방법이있는 문제가 있습니다. 예를 들어 시스템은 한 메시지 그룹에서 4 개 이상의 관련 메시지를 나타낼 수 없습니다. 일부 서비스에는 5 개의 메시지가 함께 그룹화되어야합니다. 회계 부서는이 제한에 대해 알고 있으며 이러한 서비스의 메시지를 계산할 때마다 메시지 그룹을 계산하고 5/4로 곱하여 올바른 수의 메시지를 얻습니다. 이러한 편차에 대한 문서는 전혀 없으며 현재 시스템에 얼마나 많은 것들이 존재하는지 아무도 모릅니다.
그렇다면이 시스템 개선을 어떻게 시작 하시겠습니까? 어떤 전략을 따르겠습니까?
몇 가지 추가 사항 : 저는 이것에 대해 일하는 한 명의 무장 중이므로 충분한 남성을 고용하고 시스템을 재 설계/리팩토링하는 데 허용되는 대답이 아닙니다. 그리고 몇 주 또는 몇 달 안에 나는 실제로 눈에 띄는 진행을 보여 주어야하므로 몇 년 안에 리팩토링을 수행하는 것이 옵션이 아닙니다.
몇 가지 기술적 세부 사항 : 시스템은 Java와 PHP로 작성되었지만 실제로는 중요하지 않다고 생각합니다. 그 뒤에는 오라클과 PostgreSQL이 뒤에 두 개의 데이터베이스가 있습니다. 코드 자체가 냄새가 나기 전에 언급 된 결함 외에도 실제로는 잘못 쓰여지고 문서화되어 있습니다.
추가 정보:
카운터 문제는 동기화 문제가 아닙니다. 카운터 ++ 문은 일부 모듈에 추가되며 다른 모듈에 추가되지 않습니다. 빠르고 더러운 수정은 누락 된 곳에 추가하는 것입니다. 긴 해결책은 필요한 모듈의 측면으로 만들어 나중에 잊을 수 없습니다. 나는 이런 것들을 고치는 데 아무런 문제가 없지만,이 변경을 할 경우 10 개 이상의 다른 모듈을 깨뜨릴 것입니다.
업데이트:
나는 Greg D의 대답을 받아 들였다. 내가 Adam Bellaire가 더 좋아하더라도, 알아야 할 이상의 것이 무엇인지 아는 데 도움이되지 않을 것입니다. 답변 해주셔서 감사합니다.
해결책
- 화재를 꺼내십시오. 중요한 우선 순위의 문제가 있으면 무엇이든간에 먼저 처리해야합니다. 냄새가 나는 코드베이스를 사용하면 괜찮습니다. 괜찮습니다. 당신은 앞으로 그것을 향상시킬 것임을 알고 있습니다. 이것은 당신이보고하는 사람을 대상으로하는 당신의 판매 기술입니다.
- 저지른 과일을 선택하십시오. 나는 당신 이이 특정 소프트웨어를 비교적 새롭고 당신이 그것을 처리하기 위해 다시 태워 졌다고 생각합니다. 코드의 관련 서브 시스템에서 하루나 이틀 이상 걸리지 않아야하는 코드의 관련 쉬운 문제를 찾아서 해결하고 고정하십시오. 여기에는 리팩토링이 포함될 수 있습니다. 목표는 시스템과 원래 저자의 스타일에 익숙해지는 것입니다. 당신은 정말로 운이 좋지 않을 수 있습니다 (내 시스템에서 일한 두 명의 무능한 자 중 한 명이 항상 1 개 대신 4 개의 구두점 마크로 그의 의견을 포스트 고정하여 특정 코드의 세그먼트를 작성하는 사람을 매우 쉽게 구별 할 수있었습니다.) 그러나 저자의 약점에 대한 통찰력을 개발하여 무엇을 찾아야하는지 알 수 있습니다. 예를 들어, 글로벌 상태와의 광범위하고 단단한 결합과 예를 들어 언어 도구에 대한 이해가 좋지 않습니다.
- 큰 목표를 설정하십시오. 귀하의 경험이 내 평행과 평행을 이루면, 이전 단계를 수행 할 때 특정 약간의 스파게티 코드에서 더 자주 자신을 찾을 수 있습니다. 이것은 당신이 풀어야 할 첫 번째 매듭입니다. 원래 저자가 잘못한 것에 대한 구성 요소와 지식을 이해 한 경험을 통해 (따라서 조심 해야하는지) 시스템의 하위 집합에 대한 더 나은 모델을 구상 할 수 있습니다. 기능을 유지하기 위해 지저분한 인터페이스를 유지 해야하는지 걱정하지 마십시오. 한 번에 한 단계 씩 가져 가십시오.
거품, 린스, 반복! :)
시간이 주어지면 나머지 시스템과의 인터페이스 아래에서 새로운 모델에 대한 단위 테스트를 추가하는 것을 고려하십시오. 사용하는 테스트를 통해 코드에서 나쁜 인터페이스를 조각하지 마십시오. 향후 반복에서 변경할 것입니다.
언급 한 특정 문제 해결 :
사용자가 수동으로 작업하는 상황에 빠지면 사용자와 대화하십시오 그것을 바꾸는 것에 대해. 시간을 가라 앉히기 전에 변경을 제공하면 변경 사항을 수락 할 것인지 확인하십시오. 그들이 변화를 원하지 않는다면, 당신의 임무는 깨진 행동을 유지하는 것입니다.
여러 다른 구성 요소가 작업 한 버기 구성 요소를 사용하면 병렬 구성 요소 기술을 뒷받침합니다. 기존의 방식으로 작동하는 카운터를 만듭니다 ~해야 한다 일하다. 유사한 (또는 실용적이고 동일한 경우) 인터페이스를 제공하고 새 구성 요소를 코드베이스로 밀어 넣습니다. 깨진 구성 요소를 둘러싼 외부 구성 요소를 만지면 이전 구성 요소를 새 구성 요소로 교체하십시오. 비슷한 인터페이스가 코드의 포팅을 용이하게하고 새로운 구성 요소가 실패하면 이전 구성 요소가 여전히 주변에 있습니다. 가능할 때까지 이전 구성 요소를 제거하지 마십시오.
다른 팁
지금 당신에게 무엇을 요구하고 있습니까? 기능을 구현하거나 버그를 수정하라는 요청을 받고 있습니까? 그들은 심지어 그들이 당신이 원하는 것을 알고 있습니까?
시스템 전체를 "고정"하는 인력, 시간 또는 자원이 없다면, 당신이 할 수있는 모든 것은 보석 물뿐입니다. 몇 달 안에 "눈에 보이는 진보"를 만들 수 있어야한다고 말하고 있습니다. 글쎄, 당신이 설명한 것처럼 시스템이 나쁘기 때문에 실제로 시스템을 악화시킬 수 있습니다. 눈에 띄는 일을하라는 압력으로 단순히 코드를 추가하고 시스템을 더욱 복잡하게 만듭니다.
결국 리팩터가 필요합니다. 주위에 방법이 없습니다. 최종 사용자가 볼 수있는 리팩터를위한 방법을 찾을 수 있다면 그것은 이상적입니다, "몇 달"대신 6-9 개월 또는 1 년이 걸더라도. 그러나 할 수 없다면 선택할 수 있습니다.
- 리팩터, 그리고 당신의 노력에도 불구하고 "아무것도 성취하지 못한다"고 생각할 위험이 있습니다.
- 리팩터를 리팩터링하지 말고 "가시적 인"목표를 달성하고 시스템을 더 복잡하고 언젠가 리팩터링하기가 어렵습니다. (아마도 당신이 더 나은 직업을 찾은 후에, 다음 개발자가 당신이 사는 곳을 결코 알 수 없기를 바랍니다.)
당신에게 가장 유익한 것은 개인적으로 회사의 문화에 달려 있습니다. 언젠가는 더 많은 개발자를 고용 하거나이 시스템을 다른 제품으로 완전히 대체하기로 결정합니까?
반대로, "사물을 고치기위한"노력이 실제로 다른 것들을 깨뜨리려고한다면, 그들은 당신이 한 손으로 다루도록 요청받는 괴물에 대해 이해하고 있습니까?
여기서 쉬운 답변이 없습니다. 죄송합니다. 독특한 개별 상황에 따라 평가해야합니다.
이 책은 기본적으로 단위 테스트와 리팩터라고 말하지만이를 수행하는 방법에 대한 더 실용적인 조언을 제공하는 전체 책입니다.
http://ecx.images-amazon.com/images/i/51rcxgpxq8l._sl500_aa240_.jpg
http://www.amazon.com/working-effectally-legacy-robert-martin/dp/0131177052
Windows 탐색기가있는이 시스템이 포함 된 디렉토리를 엽니 다. 그런 다음 Ctrl-A를 누른 다음 Shift-Delete를 누릅니다. 그것은 당신의 경우 개선 된 것 같습니다.
진지하게 : 그 카운터는 스레드 안전 문제가있는 것처럼 들립니다. 나는 증가하는 기능을 잠금시켰다.
그리고 시스템의 나머지 부분과 관련하여, 당신은 불가능한 일을 할 수 없으므로 가능한 일을 시도하십시오. 두 전선에서 시스템을 공격해야합니다. 더 눈에 띄게 문제가되는 문제를 먼저 처리하여 진행 상황을 보여줄 수 있습니다. 동시에, 당신은 더 많은 인프라 문제를 다루어야하므로 실제로이 일을 언젠가 고칠 수있는 기회가 있습니다.
행운을 빕니다. 그리고 출처가 당신과 함께 있기를 바랍니다.
리팩터에 중간 정도 어려운 영역을 선택하십시오. 기존 코드의 메소드 서명만으로 원래 코드의 골격을 만듭니다. 어쩌면 인터페이스를 사용해도 가능합니다. 그런 다음 해킹을 시작하십시오. 당신은 그들에게 도착할 때까지 "새로운"방법을 오래된 방법에 지적 할 수도 있습니다.
그런 다음 테스트, 테스트, 테스트. 단위 테스트가 없기 때문에 좋은 구식 음성 활성화 단위 테스트 (사람)를 사용합니까? 또는 갈 때 자신의 테스트를 작성하십시오.
좌절과 질문을 포함하여 어떤 종류의 저장소에 갈 때 진행 상황을 문서화하십시오. 따라서이 프로젝트를받는 다음 가난한 슈 머크가 당신이있는 곳이 아닐 때 :).
첫 번째 부분이 끝나면 다음 부분으로 이동하십시오. 핵심은 점진적인 진전을 기반으로하는 것이므로 가장 어려운 부분부터 시작해서는 안된 것입니다. 민주화하기가 너무 쉬울 것입니다.
Joel은 다시 쓰기/리팩토링에 관한 몇 가지 기사를 가지고 있습니다.
나는 거의 3 년 동안 동일한 특성을 가진 레거시 시스템으로 작업 해 왔으며, 내가 알고있는 지름길은 없습니다.
우리의 레거시 시스템에서 가장 귀찮게하는 것은 버그를 고칠 수 없다는 것입니다. 왜냐하면 다른 많은 기능은 내가 고치면 깨질 수 있기 때문입니다. 이것은 못생긴 해결 방법을 요구하거나 새로운 버전의 오래된 기능을 작성해야합니다. 이전 기능에 대한 호출은 한 번에 새로운 기능으로 대체 될 수 있습니다 (테스트 중).
당신의 임무의 목표가 무엇인지 잘 모르겠지만, 가능한 한 코드를 거의 만지라고 강력히 조언합니다. 당신이해야 할 일만하십시오.
사람들을 인터뷰하여 최대한 많이 문서화하고 싶을 수도 있습니다. 어떤 질문을 해야하는지 알지 못하고 사람들이 많은 세부 사항을 잊어 버렸기 때문에 이것은 큰 일입니다.
그 외에 : 돈을 받고 충분한 도덕적 지원을 받으십시오. 이빨이 울고 gnashing 할 것입니다 ...
어딘가에서 시작해야하며 고정이 필요한 버그가있는 것처럼 들립니다. 나는 그 버그를 통해 일하면서 빠른 승리 리팩토링을 만들고 그 과정에서 가능한 단위 테스트를 작성합니다. 나는 또한 같은 도구를 사용합니다 Sourcemonitor 시스템에서 가장 '복잡한'코드 부분을 식별하고 어떤 식 으로든 디자인을 단순화 할 수 있는지 확인합니다. 궁극적으로, 당신은 그것이 느린 과정이 될 것이라는 것을 받아들이고 더 나은 시스템을 향해 작은 단계를 만들어야한다는 것을 받아 들여야합니다.
나는 상당히 빨리 격리하여 추출하고 다시 작성할 수있는 시스템의 일부를 선택하려고 노력할 것입니다. 많이하지 않더라도 진행 상황을 꽤 빨리 보여줄 수 있으며 레거시 코드와 직접 인터페이스하는 문제가 없습니다.
바라건대, 그러한 몇 가지 작업을 선택할 수 있다면, 그들은 당신이 눈에 띄는 진전을 보이고, 더 큰 모듈을 다시 작성하도록 더 많은 사람들을 고용하는 것에 대한 주장을 제시 할 수 있기를 바랍니다. 시스템의 일부가 깨진 동작에 의존 할 때, 당신은 선택의 여지가 많지 않고 무엇이든 수정하기 전에 분리 할 것입니다.
바라건대, 당신은 전체를 다시 작성할 수있는 팀을 점차적으로 구축 할 수 있기를 바랍니다.
이 모든 것은 괜찮은 훈련과 함께 갈 것입니다. 그렇지 않으면 사람들의 오래된 습관이 붙어있을 것이며, 예상대로 일이 작동하지 않으면 당신의 작업이 비난을받을 것입니다.
행운을 빕니다!
문제가있는 현재 존재하는 모든 것을 사용하지 말고 올바르게 작동하는 새로운 것을 쓰십시오. 이 문서를 가리키는 곳 전체에 큰 빨간 깜박이는 표지판을 변경하고 큰 빨간 깜박이는 표지판을 바꾸는 것에 대해 가능한 한 많이 문서화하십시오.
그렇게함으로써 실제 작업 시스템을 얻기 위해 진행 상황을 늦추지 않고 기존 버그 (다른 곳에서 보상받는 버그)를 유지할 수 있습니다.
