레거시 코드를 전달할 때 자신의 코딩 편향을 어떻게 극복합니까? [닫은]

프로그래머로서 우리는 종종 우리의 기술에 대한 자부심을 갖고 '좋은'코드와 '나쁜'코드가 무엇인지에 대해 매우 강한 의견을 가지고 있습니다.

우리 경력의 어느 시점에서, 우리는 아마도 일부 레거시 시스템을 무릎에 떨어 뜨렸을 것입니다. 그리고 '나의 신,이 코드는 짜증나!' 코드가 완벽하게 기능하고 유지 보수가 가능한 코드 임에도 불구하고 좋은 코드의 개념에 맞지 않기 때문입니다.

다른 프로그래머의 작업에 집중할 때 어떻게 정신적으로 준비합니까?

모든 레거시 코드 기반의 경우이를 처리하기 위해 정신적으로 자신을 준비하는 올바른 방법은 단위 테스트를 작성하는 것 입니다.

짜증이 나지 않든, 먼저 물건을 깰 필요없이 바꿀 수 있다는 자신감이 필요합니다!

나는 "아, 이건 완전히 틀렸다"고 몇 번이나 말한 후 다시 쓴 다음 그 코드가 왜 그렇게 쓰여 졌는지 어려운 방법을 알아 냈습니다. 일반적으로 명백하지 않은 서면 / 문서화되지 않은 요구 사항입니다. 적어도 현재 작업중 인 레거시 코드에서는 마찬가지입니다.

당신은 당신의 자신의 엉터리 레거시 코드를 실행할 수있을 정도로 오래있을 때까지 기다립니다. 그것은 겸손한 경험이며 학습 과정의 일부입니다. 나는 모든 것을 알았던 시간을 갈망합니다.

Fosco는 잠재적 인 시간 및 기능 제한의 상황에이를 수있는 좋은 점이 있다고 생각합니다. 때때로 당신은 뭔가 일을하도록 강요받습니다.

그리고 마지막으로, 이것이 당신이 직업을 갖는 이유라는 것을 이해하십시오.

웃으면 서 너무 많이 판단하지 말고 그냥 지나치십시오. 실제 코드 나치가되는 것은 좋지 않습니다 ... '충분히 좋은 것'또는 '당시 충분히 좋은 것'과 같은 것이 있습니다. 위기를 해결하기 위해 무언가를 개발하거나 붕대를 감아 서 다시는 방문하지 않는 경우가 많습니다.

그것이 정말로 나쁘다면, 그것을 다시 쓸 수 있는지 확인하십시오. 중요하지 않다면, 그냥 나가십시오.

전투를 선택하십시오. "이런 식으로 쓰지 않겠다"와 "이것은 심각한 유지 관리 또는 지원 문제를 일으킨다"의 차이점을 아십시오.

나는 종종 원래의 개발자들이 좋았다고 생각한 것에 대한 느낌을 얻는 것이 유용하다고 생각합니다.

그들이 한 일에 대한 패턴과 주제를 찾아보십시오. 처음에 이상한 결정에 대한 이유가 있다는 것을 알게되었습니다.

때때로 당신은 원래 개발자가 실제로 나빴다는 것을 알지만, 당시에 그들이 어떤 종류의 나쁜 것을 팔았는지에 대한 아이디어가 있습니다.

어느 쪽이든, 이렇게 한 후에는 다시 쓰기를 시작할 수있는 곳이나 모든 것을 리팩터링하지 않고도 빠른 수정이 어떤 모습인지 더 잘 이해할 수 있습니다.

가장 중요한 것은 그것이 추악하기 때문에 그것이 나쁘다는 것을 즉시 가정하지 마십시오. 원본보다 능력이 떨어지는 것을 발견하기 위해 무언가를 현대화하는 데 시간을 투자한다는 것은 어리석은 것처럼 보이지 않습니다.

시간이 있으면 공격 하고 잘못 작성된 코드를 죽입니다.

전쟁이다.

나는 추악한 코드가 많은 디버깅을 보인 코드이고, 커서 검사로는 분명하지 않은 많은 미묘함을 항상 추론합니다. 그것을 대체하거나 깊이 다시 디자인하면 코드의 모든 측면을 절대적으로 이해해야합니다. 바닥에 갈 시간이 없다면, 최소한의 위험에 접근하여 목표를 달성하기 위해 가능한 한 작은 변화를 가져와야합니다.

일반적으로 나는 작은 수정 / 변경을하고, 사물의 최후에 도달하고 전체를 리팩토링하는 것을 막을 추후 개발을위한 기능을 제안 할 것이다. 그런 다음 로드맵에서 기능이 끝날 때까지 코드를 무시하도록 최선을 다합니다.

레거시 코드가 2 년 이상 된 경우 코드 작성 당시 존재했던 언어 나 운영 체제 등의 제한으로 인해 코드가 작성되었을 수 있습니다. 이봐 지금은 안 좋아 보이지만 그때 나빴어? 개발자가 자신이 한 일에 대한 이유가 있다고 가정합니다. 그 이유는 더 이상 적용되지 않을 수도 있지만 일반적인 무능력 대신 하나가 있다고 가정하면 (젊은 프로그래머는 5 년 안에 코드에 대해 같은 것을 생각할 것입니다) 훨씬 덜 화를냅니다. 그것이 작동하고 관련된 문제가 없다면, 더 흥미로운 문제를 해결할 수 있기 때문에 추악한 레거시 코드를 소중히 간직하십시오.

과거에 다른 사람의 코드를 보지 못하고 "내"스타일로 이길 시간이 없었을 때, 나는 매우 업무 중심적인 태도를 취해야했습니다.

이 코드 / 수정 / 제작에 추가하려고하는 것은 무엇입니까?

내가 그 목표를 향해 노력하고 있습니까? 그렇지 않은 경우 작업을 중지하고 마지막으로 작업 중심 변경을 한 시점으로 되돌립니다.

이 작업을 마쳤습니까? 그렇다면 코드가 아닌 Martian 금형에 의해 작성된 것처럼 보이지만 코드 땜질을 중지하십시오.

나중에 코드와 필요한 수정 프로그램을 소유 할 준비가되지 않은 경우, 코드를 만지지 마십시오. 글을 쓰지 않았을 때 충분히 공부하지 않았기 때문에 작성하지 않은 것을 깰 때 무언가를 고치려는 경향을 극복하게되며, 2 일이 걸리고 재 훈련되어 다시 작동하게됩니다. .

잘못 이해하지 마십시오 ... 코드를 리팩터링 해야하는 합법적 인 이유가 있지만 비즈니스에서 코드 작동을 요구하고 뛰어 들기 전에 결과를 모른 채 "고정"하면 상처의 세계를 요구하고 있습니다. .

한 번에 조금씩 리팩토링하는 것이 유용 할 수 있지만, 그 동작이 왜 존재하는지와 그 영향이 무엇인지 이해하지 않는 한 코드가 실제로 동작하는 방식의 작은 측면을 변경하는 데 특히주의하십시오. 불행히도, 최악의 코드는 동작을 건드리지 않고 변경하기가 가장 어려운 경우가 있지만 일반적으로 코드의 일부를 똑 바르게하거나 최소한 주석을 달 수 있습니다.

요즘 레거시 코드에서 거의 독점적으로 일하고 있으며 항상 "오, % t, 그들은 무엇을 생각하고 있었습니까?"라고 생각합니다. . 그런 다음 코드에 대한 단위 테스트 작성을 시작 합니다. 이것이 제어 흐름과 종속성을 분석해야하는 시점입니다.

때로는 단위 테스트를 쉽게 작성할 수 없습니다. 그러나 시도하는 동안 코드에 대한 정보를 얻고 코드가 작성된 방식을 이해할 수 있습니다. 때로는 코드가 실제로 엉망이라는 것을 증명할 수 있습니다. 때로는 원래 개발자의 사고 과정을 이해하고 새로운 기능을 추가하려고 할 때 유용한 문서를 추가하거나 코드를 다시 작성할 수 있습니다.

저에게 12 개월 후에 다시 돌아 왔을 때 제 코드는 저에게 동일하게 보일 것이라고 생각하는 것이 도움이됩니다 .

경험이 있으면 코드가 실제로 나쁜시기와 다른 스타일로 작성된시기를 아는 판단이옵니다. 완벽하게 작동하고 유지 보수가 가능 하고 자동화 된 테스트 범위가 좋은 경우 나쁘지 않으며 마음을 열면됩니다. 당신은 아마 무언가를 배울 것입니다. 잘못된 코드는 작동하지 않으며 유지 관리 할 수 ​​없습니다.

다음은 정말 잘못된 코드의 마커입니다.

• 리팩토링 대신 큰 논리 블록이 복제되었습니다.
• 클래스 또는 패키지 간의 순환 종속성
• 높은 커플 링; 낮은 응집력
• 사용하지 않는 변수, 읽을 수없는 변수에 쓰기 불가능한 코드.
• 날짜 형식과 같은 표준 라이브러리 기능의 재 구현.
• 불필요하게 복잡한 논리; 즉, 10 줄이 잘되는 50 줄의 코드.
• 클래스 또는 메소드의 목적을 설명하는 주석이 없습니다.
• 오해의 소지가있는 의견.

자동화 된 테스트가 없다고해서 코드가 잘못되었다는 의미는 아니지만 프로젝트가 잘못되었음을 의미합니다.

이것들은 맛의 문제가 아닙니다. 이러한 관행은 프로그램 유지 관리를 훨씬 더 비싸게 만듭니다.

당신은 어떻게 자신을 준비합니까?

새로운 코드 기반에서 성공적으로 작업하려면 시간이 걸린다는 사실을 받아들이십시오. "완벽하게 유지 관리 가능"하고 높은 테스트 범위가있는 경우 시간이 덜 걸리지 만 여전히 즉시 발생하지는 않습니다. 코드가 나쁜 경우, 내가하는 첫 번째 일은 이해 관계자에게 코드의 모양이 좋지 않으며 초기 진행이 느리다는 것을 경고하는 것입니다. 그들이 회의적이라면, 실제 코드의 문제 샘플을 보여주고 업계 모범 사례와 어떻게 다른지 설명함으로써 주장을 뒷받침합니다.