어두운면으로 가라는 압박을 받고

어두운면으로 가라는 압박을 받고

---

레거시 (코어)에서 작업하는 개발자가 이미 스파게티 코드에 감염된 기존 코드에 새 기능을 추가 할 때 GOTO 문을 사용하는 시스템을 실행하는 상황이 있습니다.

이제 더 유지 보수가 가능한 솔루션으로 리팩토링하는 데 시간을 소비하는 대신 '단지 하나의 GOTO'를 사용하는 것이 가능하다는 것을 이해합니다. 문제는있는 것이 '단지 하나의 작은 GOTO'가 그렇게되어 있지 않다입니다. 클릭 매주 한 번 정도 추가 할 새로운 '하나의 작은 GOTO'가 있습니다. 이 코드베이스는 많은 Pastafarians 가 플라잉 스파게티 괴물 자체에서 영감을 받았다고 믿게 만드는 GOTO로 인해 1984 년 이전으로 거슬러 올라가는 코드로 인해 작업하고 이미 공포 입니다.

불행히도 오류가 있다는 언어에는 준비된 리팩토링 도구가 없기 때문에 단기적 승리가 여기서 주목할 유일한 승리이기 때문에 '나중에 생산성을 높이기 리 위해 팩터링'을 추진하기가 더 어려워집니다 ...

다른 사람이 새로운 GOTO를 추가하여 임의의 섹션으로 2000 줄을 사용하는 데 모두 동의하는 문제를 경험 한 사람이 있습니까? 그러나 Anaylsts 가이 작업을 한 번만 고집하고 승인 이메일로 요청합니까?

tldr;

개발자가 계속해서 GOTO 문을 추가 압박 (강제)되는 문제를 해결하는 방법은 무엇입니까? ( 추가하여 여러 해당 기능 의 섹션으로 건너 뛰도록 추가하는 것) ' 더 빨리 기능을 가져 오기'때문입니다.

이 문제로 인해 랩터들에게 귀중한 개발자를 잃을지도 모른다는 두려움이 시작됩니다 ...

설명 :

이동 here

alsoThere:아니요, 한 서브 루틴에서 1000 개 라인을 루프의 중간에 다른 서브 루틴으로 점프하는 종류의 이야기하고 있습니다. 이동 somewhereClose

there:나는 당신이 합리적으로 읽을 수있는 프로그램이 무엇을하고 어떤 수있는 종류의 고토에 대해 이야기하지 않았다. 이동 alsoThere

somewhereClose:이 미트볼을 만드는 코드입니다. midpoint: 처음 여기에 고토 nextpoint detail: (각각 거의 완전히 다른) 고토 pointlessReturn

here:이 질문에서 나는 가끔 괜찮은 고토 사용에 대해 이야기하지 않습니다. 이동there

tacoBell:그리고 그것은 단지 드로잉 보드로 돌아옵니다. 이동 Jail

elsewhere:분석가가 프로그램이 터치 될 때마다 수행하는 작업을 해독하는 데 몇 가지 주가 걸리면 코드베이스 심각한 문제가있는 것입니다. 사실, 실제로 최신 버전 나는이 hell:아니더라도 4 사양 고토 고토의 연주에 달려 있습니다.detail pointlessReturn: tacoBell

Jail:사실, 작은 승리로 작은 업데이트입니다. 이 특정 프로그램의 일부를 한 번에 하나의 레이블로 리팩토링하는 데 4 시간을 보냈고, svn에 각 반복을 저장했습니다. (그 중 약 20) 각 단계에, 논리적이고 쉽게 자그마한 충분했다 고토가 bypass nextpoint: 자발적으로 식사 밖으로 뛰어 당신이 스파게티 미트볼 자기의 이상한 종류의를 통해 화면에. Goto elseWhere bypass: 는 논리 변경을 도입하지 않습니다. 좀 더 읽기 쉬운이 새 버전을 사용하여 분석가와 함께 앉아 거의 모든 변경 사항을 완료했습니다. 이동 end

4:첫 번째 * 처음 여기에 goto hell, 두 번째 가 여기에 goto hell , 세 번째 가 여기에 goto hell 네 번째 지금 최신 goto hell

end:

---

잘못되었습니다 GOTO로 인해 얼마나 많은 버그가 발생했는지 발생합니까? 회사에 비용이 얼마나 들었습니까? "이건 기분이 나쁘다"라기보다는 문제를 구체적인 바꾸십시오. 담당자가 문제로 인식 할 수있게 "함수에 대한 새로운 논리를 단순화하는 것 외에는 GOTO 없음"또는 "그렇지 않은 기능에 대해 새로운 GOTO 없음"과 같은 정책으로 전환하십시오. 100 % 단위 테스트 범위를 갖습니다. " 시간이 지남에 따라 정책을 강화하십시오.

---

GOTO는 좋은 코드 스파게티를 만들지 못합니다. 다른 많은 요소가 관련되어 있습니다. 이 리눅스 메일 링리스트 토론 은 몇 가지 관점을 고려하는 데 도움이 될 수 있습니다 (사용에 대한 더 큰 그림에 대한 Linus Torvalds의 의견).

"no goto 정책"을 시도하려고 시도하는 것은 정책적으로 더 유지 관리 할 수있게 만들지 않을 것입니다. 변경 사항은 더 미묘하고 코드의 전반적인 품질을 높이는 데 시스템을 두어야하며 플랫폼 / 언어, 단위 테스트 범위, 정적 분석의 모범 사례를 사용하는 라인을 따라 생각해야합니다.

---

개발의 현실은 올바른 방법에 대한 모든 꽃말에도 불구하고 고객이 빠른 방법으로 수행하는 데 더 관심이 대부분의 것입니다. 코드베이스의 개념이 파열 지점으로 신속하게 이동하고 결과적으로 비즈니스에 대한 낙진이 발생하는 것입니다.

당신이 가진 것은 단지 하나의 예입니다. 이에 대한 입장은 개발 방식을 결정합니다. 네 가지 옵션이 생각합니다.

1. 요청을 수락하고 항상 작업을 수행 할 것임을 수락합니다.

2. 요청을 수락하고 즉시 새 일자리를 찾기 시작하십시오.

3. 할 일을 거부하고 엉망진창을 고치기 위해 싸울 준비를하십시오.

4. 사임하세요.

당신이 선택하는 옵션은 당신이 당신의 직업과 자존감을 얼마나 소중히 여기는가에 달려 있습니다.

---

보이 스카우트 패턴을 사용할 수있을 것입니다. 조금 것보다 조금 더 높은 곳을 두십시오. 새로운 기능을 도입하지 말고 제거하십시오.

이렇게하면 개선에 너무 많은 시간을 소비하지 않고 새로 도입 된 버그를 찾는 데 더 많은 시간을 할애 할 수 있습니다. 부품에서 goto를 제거하면 추가 시간이 많이 들지 않을 것입니다. 부품을 이해하고 새로운 기능을 가져 오는 데 시간을 소비해야했습니다.

2 시간의 리팩토링은 15 분의 20 배를 절약하고 더 빠르게 심층적 인 개선을 할 수 있다고 주장합니다.

---

원칙으로 돌아 가기 :

• 읽을 수 있습니까?
• 작동?
• 유지 보수가 가능한가요?

---

이것은 고전적인 "관리"대 "기술자"갈등입니다.

"기술자"팀에 있음 굳건에도 불구하고 수년 동안 나는이 논쟁의 "관리"측면을 굳건히 긍정습니다.

여기에는 여러 가지 이유가 있습니다.

1. gotos를 사용하여 적절하게 구조화 된 프로그램을 읽기 쉽고 잘 작성하는 것이 가능합니다! 어셈블러 프로그래머에게 물어보십시오. 조건부 분기와 기본 do 루프 만 사용하면됩니다. "스타일"이 최신이 아니며 잘 쓰여지지 않았 음을 의미하지 않기 때문입니다.

2. 그것이 엉망이라면 완전한 재 작성을 할 때 필요한 비즈니스 규칙을 추출하는 것이 정말 고통 스러울 것입니다. 또는 프로그램의 기술적 인 리팩토링을 수행하는 경우에는 리팩토링 된 프로그램의 동작은 "올 바릅니다". 즉, 이전 프로그램이하는 일을 정확히 수행합니다.

3. 투자 수익-원래 프로그래밍 스타일을 고수하고 최소한의 변경 만하면 최소한의 노력으로 고객의 요청을 신속하게 충족 할 수 있습니다. 많은 시간과 노력을 들여 리팩토링하는 것은 더 비싸고 더 오래 걸립니다.

4. 위험-재 작성 및 리팩토링은 제대로하기 어렵고 리팩토링 된 코드에 대한 광범위한 테스트가 필요하며 "버그"처럼 보이는 것은 고객이 우려하는 한 "기능"일 수 있습니다. 레거시 코드를 "개선"하는 데있어 특별한 문제는 비즈니스 사용자가 버그에 의존하는 해결 방법을 잘 확립했거나 버그의 존재를 악용하여 IT 부서에 알리지 않고 비즈니스 절차를 변경할 수 있다는 것입니다.

따라서 모든 경영진은 변경 사항을 테스트하고 위험을 최소화하면서 두 배의 빠른 시간에 생산에 들어가는 결정에 직면하게됩니다. 또는 대규모 프로그래밍 작업을 수행하고 비즈니스를 비명을 지르도록합니다. 새로운 벌레가 생기면 그들에게.

그리고 당신이 5 년 안에 리팩토링하기로 결정한다면, 어떤 콧물을 가진 대학 졸업생들은 당신의 리팩토링 된 프로그램이 더 이상 유행어를 준수하지 않는다고 신음 할 것이고 그가 그것을 재 작성하는 데 몇 주를 소비하도록 요구할 것입니다.

고장 나지 않았다면 고치지 마십시오!

PS : 심지어 조엘이 나쁜 생각이라고 생각 : 당신이 할해서는 안 것들

최신 정보!-

리팩토링하고 코드를 개선하려면 적절하게 진행해야합니다.

기본적인 문제는 당신이 클라이언트에게 "나는이 프로그램에 대해 n 주를 보내고 싶다. 모든 것이 잘되면 지금하고있는 것과 똑같이 할 것이다"라는 것이다. -이것은 최소한으로 말하기 어려운 판매입니다.

충돌 및 중단 횟수, 겉보기에 작은 변경 사항을 분석하고 프로그래밍하는 데 소요 된 시간, 너무 힘들어서 수행되지 않은 변경 요청 수, 시스템이 빠르게 변경되지 않아 비즈니스 운영 손실에 대한 장기 데이터를 수집해야합니다. 충분히. 또한 잘 구조화 된 프로그램을 유지하는 비용과 가라 앉히는 비용에 대한 전염병 데이터를 수집하십시오.

빈 카운터에 제시 할 방수 케이스가 없으면 예산을 얻을 수 없습니다. 당신은 이것을 직속 상사가 아닌 경영자에게 팔아야합니다.

---

나는 최근에 그 자체로 레거시가 아닌 일부 코드를 작업해야 했지만 이전 개발자의 습관은 확실히 있었으므로 GOTO는 어디에나있었습니다. 나는 GOTO를 좋아하지 않는다. 그들은 끔찍한 일을 만들고 디버깅을 악몽으로 만듭니다. 더 나쁜 것은 그것들을 일반 코드로 대체하는 것이 항상 쉬운 것은 아닙니다.

GOTO를 풀 수 없다면 더 이상 사용하지 않는 것이 좋습니다.

---

불행히도 이것이 작성된 언어에는 준비된 리팩토링 도구가 없습니다.

매크로 기능이있는 편집기가 없습니까? 쉘 스크립트가 없습니까? 저는 수년에 걸쳐 수많은 리팩토링을 수행했지만 리팩토링 브라우저로는 거의 수행하지 않았습니다.

---

여기서 근본적인 문제는 일부 코드에 goto를 추가하는 측면에서 아마도 필요한 기능적 변경을 설명하는 '분석가'가 있다는 것입니다. 그리고 그 변경 사항을 입력하고 이에 대해 불평하는 것으로 보이는 '프로그래머'가 있습니다.

다른 것을 만들려면, 그 사람들 사이의 책임의 역기능 할당을 변경해야합니다. 작업을 분할하는 방법에는 여러 가지가 있습니다. 고전적이고 일반적인 방법 (공식적이지만 무시 된 정책)은 분석가가 구현에 독립적 인 사양 문서를 작성하고 프로그래머가이를 다음과 같이 구현하도록하는 것입니다. 유지할 수 있습니다.

그 이론적 접근 방식의 문제는 실제로 많은 일반적인 상황에서 비현실적이라는 것입니다. 특히, '적절하게'그렇게하기 위해서는 후배로 보이는 직원들이 더 선배이고, 사무실에서 더 나은 사회적 관계를 갖고, 더 비즈니스에 정통한 동료들과 논쟁을 이기기 위해 필요합니다. 'goto'가 구현에 독립적이지 않기 때문에 분석가로서 단순히 그 단어를 말할 수 없다는 주장이 작업 공간에서 날아 오지 않는다면 아마도 이것이 사실 일 것입니다.

많은 상황에서 다음과 같은 대안이 훨씬 좋습니다.

1. 분석가는 클라이언트 용 코드를 작성하고 개발자는 인프라를 작성합니다.
2. 분석가는 단위 테스트를위한 참조 구현으로 사용되는 실행 가능한 사양을 작성합니다.
3. 개발자는 분석가가 프로그래밍하는 특정 도메인 언어를 만듭니다.
4. 당신은 하이브리드만을 가지고 하나와 다른 것 사이의 구별을 뜨립니다.

---

프로그램을 변경하기 위해 "단지 한 번만 제공"이 필요하다면 코드는 매우 유지 보수가 가능할 것입니다.

이 레거시 코드를 다룰 때 발생하는 문제입니다. 코드를 "현대화"하십시오. 저에게 대답은 일반적으로 완전한 재 작성을 제안 화 할 수있는 정말 큰 변화가 존재하는 스타일을 고수하는 것입니다.

또한 Java의 "throw"문이나 SQL "ON ERROR"와 같은 여러 "현대"언어 기능이 실제로 "GO TO"라는 점을 알아 두십시오.

참고 URL : https://stackoverflow.com/questions/2910017/being-pressured-to-goto-the-dark-side