내 코드의 대부분에는 주요 디자인 결함이 있습니다. 끝내거나 지금 고치세요? [닫은]

저는 저와 같은 기술 수준을 가진 제 친구와 함께 C # 프로젝트를 진행하는 고등학생입니다. 지금까지 100 개의 커밋 범위에서 약 3,000 줄의 코드와 250 줄의 테스트 코드를 작성했습니다. 학교 때문에 몇 달 동안 프로젝트를 연기했으며 최근에 다시 프로젝트를 다시 시작할 수있었습니다.

내가 그것을 백업 할 때, 내가 작성한 코드는 렌더러에 과도한 스레드 포함, 에뮬레이트 된 CPU, GPU 및 게임 카트리지 간의 상호 작용에서 경쟁 조건 방지와 같은 잘못 설계되었습니다. 중복되고 혼동되는 코드뿐만 아니라

문제는 프로그램의 주요 기능조차 끝내지 못했기 때문에 진정으로 리팩터링 할 수 없으며 코드 디자인에 결함이 있음을 완벽하게 인식하지 않는 것입니다. 동시에 나는 프로젝트를 포기하고 싶지 않다. 상당한 진전이 있었으며 작업은 낭비되지 않아야합니다.

나는 두 가지 선택이있는 것처럼 느낍니다. 열악한 디자인을 해결하고 모든 것이 작동하면 리팩토링하여 기능을 끝내고 나머지 기능을 완료하기 전에 모든 기능을 중지하고 모든 것을 풀기 위해 노력하여 프로젝트를 시작하는 것처럼 느낍니다. 내 마음에 다시 신선하거나 과도한 크기로 인해 프로젝트를 완전히 버립니다 (본질적으로 "드로잉 보드로 돌아 가기").

그러한 프로젝트에 대한 다른 사람들의 경험을 바탕으로 올바른 길로 되돌아가는 데 어떤 도움이 필요합니까? 이 사이트의 답변에서 일반적인 합의는 재 작성은 일반적으로 불필요 하지만 과도한 비용없이 코드를 유지할 수없는 경우 사용 가능한 옵션이라는 것입니다. 나는이 프로젝트를 진심으로 추구하고 싶지만, 제 코드는 계속 진행하기에 충분하게 설계되지 않았고, 낙담 감이 계속되지 않습니다.

내가 너의 신발에 있다면 아마 이런 식으로 시도 할 것이다.

• 먼저 현재 프로젝트를 최소한 부분적으로는 가능한 빨리 완료하지만 작업 상태에서 완료하십시오 . 아마도 당신은 원래 목표를 줄여야 할 것입니다. "버전 1.0"에서 볼 수있는 최소한의 기능을 생각하십시오.

• 그런 다음에 만 처음부터 다시 작성하는 것을 생각해야합니다 ( "버전 2.0"이라고 함). V1.0의 일부 코드를 재사용 할 수 있습니다. 어쩌면 상황에 대해 다시 잠을 자고 나서 V1.0을 리팩터링하고 대부분을 저장할 수 있다는 결정을 내릴 수 있습니다. 그러나 "개념 증명 V1.0"을 갖지 않기 전에이 결정을 내리지 마십시오.

작업 프로그램 "1.0"은 코드가 나쁜 경우에도 다른 사람에게 보여줄 수있는 것입니다. V2.0을 작성하는 도중에 시간이 부족하다는 것을 알고도 여전히 V1.0을 부분적으로 성공시키는 것은 사기에 훨씬 유리합니다. 그러나 V1.0을 먼저 완료하지 않으면 V2.0을 완료하지 못할 가능성이 큽니다. 반쯤 진행할 때 설계에 다시 만족하지 못하는 시점이 있기 때문입니다. V2.0을 다시 포기하고 V3.0에서 작업 하시겠습니까? 이 끝나지 않는 서클에 빠질 위험이 높으며 결코 끝나지 않습니다.

프로젝트를 미완성 상태로 남겨 두는 방법을 배우는 대신 중간 목표 달성 방법을 배우는 기회로 활용하십시오.

완성 된 IT 프로젝트, 심지어 결함이있는 프로젝트는 완료되지 않은 프로젝트보다 훨씬 좋습니다.

미완성 된 사람들은 당신에게 많은 것을 가르쳐 줄 수 있지만 완성 된 것만 큼 많지는 않습니다.

당신은 지금 그것을 볼 수는 없지만 결함이있는 코드로 작업하면 엄청난 양의 가치를 얻습니다.

필자의 투표는 마무리를 한 다음 리팩토링을해야한다. 더 많은 프로젝트로 작업을 시작하면 놀랍게도 종종 "리팩토링되어야하는"부분이 수년간 그대로 유지되고 다른 부분은 확장되는 것을 볼 수 있습니다.

대부분의 경우 고용 관점에서 완성 된 프로젝트에 대한 더 많은 명성을 얻게됩니다.

나는 행복하게 프로젝트를 시작합니다.

당신은 학생이고 여전히 배우고 있습니다. 이것은 당신이 연결 한 질문과는 매우 다른 입장에있게됩니다.

• 코드에 대한 전문적인 책임은 없습니다. 지금 전체 프로젝트를 삭제하고 멀리 가면 영향을받지 않습니다. 이것은 개발자에게 큰 이점입니다. 당신이 연결 한 질문에서, 개발자들은 사람들이 돈을 지불하는 소프트웨어를 유지하려고 노력하고 있으며 작은 버그조차도 고객에게 큰 문제를 일으킬 수 있으므로 처음부터 작성하는 것이 위험합니다. 당신은 그 문제가 없습니다.

• 개인 프로젝트로서, 이것은 새로운 것을 시도하고 실수로부터 배울 수있는 완벽한 기회입니다. 이전 코드에 문제가 있음을 인식하는 것이 좋습니다. 이는 더 나은 방법을 배웠기 때문입니다. 시행 착오를 통한 경험은 초보 프로그래머에게 매우 귀중 할 수 있습니다.

• 프로젝트는 상대적으로 작으며 기본적으로 테스트가 없습니다. 다음 번에 더 잘할 일에 대한 아이디어가 이미 있기 때문에 처음부터 3000 줄을 작성하는 것은 몇 밤이 될 수 있습니다.

• 깨진 코드베이스에서 작업하는 것은 다시 쓰는 것보다 사기가 훨씬 더 커질 것입니다.

제쳐두고 이것은 단위 테스트로 더 모듈 식 프로그램을 작성해 볼 수있는 좋은 기회 일 수 있습니다. 그렇게하면 오랜 휴식 후 코드를 다시 찾게되면 코드를 이해하기가 훨씬 쉬워지고 잊어 버림으로 인해 실수로 발생할 수있는 오류를 방지 할 수 있습니다.

마지막으로, 여기에 때때로 앞으로 더 큰 조치를 취할 것을 뒤로 조치를 취할의 지혜에 하나 개의 의견이다.

아마도 개발의 "빠른 학습"부분에있을 것입니다. 몇 달 후, 새롭고 멋진 디자인이 시작했을 때조차 알지 못했던 방식으로 끔찍하게 손상되었을 가능성이 큽니다.

일을 끝내십시오 -이것이 배우는 데 가장 중요한 것입니다. "이 프로젝트를 시작하기 전에 많은 것을 배웠기 때문에 처음부터 다시 시작하십시오"루프에 갇혀있는 많은 사람들 (프로그래머 만이 아니라)을 알고 있습니다. 문제는 끝나지 않는다는 것입니다. 새로운 것을 배우지 않을 때까지는 좋은 곳이 아닙니다. :)

실제로 무엇이든 마무리 할 수 ​​있어야합니다. 처음부터 시작하는 것은 흥미롭고 시원하며 재미 있지만, 그 내용 만 배우면 아무 것도 마칠 수 없습니다. 다시 말하지만, 그것은 매우 유용한 능력이 아니며, 실제로 유용한 것을 만드는 것만큼이나 기분이 좋지 않습니다. 인생은 짧고 시간은 제한되어 있으며 확실한 결과없이 계속 연습 할 수는 없습니다. 어떤 접근 방식을 결정할 수 없어서 일을 시작할 수 없다면 이미 위험 지대에있는 것입니다.

다시 시작할 충동이 항상있을 것입니다. 학습 환경 에서조차도 나쁜 생각 일 가능성이 높습니다. 그렇다고해서 모든 프로토 타입을 프로덕션 준비가 된 응용 프로그램으로 멀리 옮겨야한다는 의미는 아닙니다. 그러나 최소한 실제 프로토 타입 단계에 도달해야합니다. 이는 사기에 도움이되며, 모든 종류의 개발자에게 매우 유용한 특성입니다. 일을 끝내십시오 . 재미있는 부분은 프로토 타입을 사용하여 "처음부터 다시 작성"하는 것보다 많은 재미 있고 유용한 것들이 있다는 사실을 곧 알게 될 것입니다. 당신이하는 모든 일은 비용이 든다. 최소한 그 동안 다른 일을했을 수도있다.

저는 소프트웨어 개발에서 "작동하게하고, 올바르게 만들고, 빠르게 만들어" 이념을 따릅니다 .

1. 작동 시키십시오 : 프로젝트를 사용할 수 있도록 핵심 기능을 작성하십시오. 추악한 코드를 의미하더라도 모든 것이 작동하게하려면 필요한 작업을 수행하십시오.
2. 올바르게 만들기 : 버그를 수정하고 코드를 리팩토링하여 쉽게 읽고 이해하고 유지 보수 할 수 있습니다.
3. 속도 향상 : 속도, 리소스 사용량 및 유지 관리 성 간의 균형이 잘 맞도록 프로그램을 최적화하십시오.

지금은 1 단계를 마치지 않았습니다. 먼저 작동하게 한 다음 코드가 얼마나 추한지 걱정할 수 있습니다. 실제로 작동하는 제품을 만드는 것은 새로운 개발자가 가장 어려운 일 중 하나입니다. 처음으로 코드를 완벽하게 만들기 위해 싸워서 최적화 지옥에 갇히고 실제로 마무리 작업을하지 않기 때문입니다. 모든 기능을 구현합니다. 소프트웨어 작동에 집중할 수 있도록 리팩토링 및 최적화에 대한 모든 걱정을 제거하는 방법을 배워야합니다. 더 많은 경험을 얻으면 처음에는 자연스럽게 더 많은 일을 할 것이므로 리팩토링이 덜 필요합니다.

명심하십시오 : 조기 최적화는 모든 악의 근원입니다 ( 좋은 토론을 위해서는 이 우수한 프로그래머 .SE 질문 참조 ). 코드를 개선하는 방법에 대해 너무 많은 시간을 소비한다면 분석 마비에 빠지게 됩니다. 이것은 프로젝트를 죽입니다. 프로젝트 최적화를 시작하기 전에 프로젝트를 완료하는 것이 좋습니다.

훌륭한 동기 부여 연사를 인용하려면 다음 과 같이하십시오 .

언제나 그렇듯이 관련 xkcd가 있습니다 :

다시 작성하십시오. 작동하지 않는 코드는 가치가 거의 없으며 3 천 줄은 많은 코드가 아닙니다. 현재 가지고있는 코드를 작성하는 데 걸리는 시간이 거의 걸리지 않으며 훨씬 좋습니다. 나는 종종 5 백 또는 수천 줄의 불쌍한 코드를 버렸으며, 종종 재 작성 길이는 1/5입니다.

"다시 쓰지 않는다"에 대한 대부분의 개념은 중요한 작업을 수행하고 진화하는 요구 사항을 충족시키기 위해 지속적으로 변경되는 대규모 시스템과 관련이 있습니다. 사용중인 복잡한 시스템의 재 작성은 거의 성공하지 못합니다.

당신의 상황은 완전히 반대입니다. 사용자가없는 작은 응용 프로그램이 있으며 구현하기 위해 필요한 유일한 요구 사항입니다. 계속해서 다시 작성하십시오.

처음부터 다시 시작하는 실제 프로젝트가 newcoming 개발자가 인식하지 버그 수정을 축적 주로하기 때문에, 일반적으로 실제 프로젝트에 나쁜 움직임이다 (예를 들면, 볼 당신이 할해서는 안 것들 에서, 소프트웨어에 조엘 의 블로그.)

그럼에도 불구하고, 학교 프로젝트는 그러한 역사를 물려받지 않으며 일반적으로 컴퓨팅에 대한 부분적인 지식과 경험 부족으로 코딩과 디자인으로 시작합니다. 나는 첫 번째 버전을 프로토 타입으로 간주하고 실패한 개념 증명으로 사용하고 행복하게 버릴 것입니다 (버려 내기 와 진화 프로토 타이핑 에 대한 논의 는 버리기 와 프로토 타입의 차이점 은 무엇입니까? 참조).

올바른 디자인은 머릿속에서 성숙해 왔으며 코드로 작성하는 데 많은 시간이 걸리지 않습니다.

나는 재 작성이 나쁜 아이디어라는 제안에 정중하게 동의하지 않을 것이다.

소프트웨어 수명주기의 영역에서, 일반적으로 에러를 수정하는데 필요한 시간과 노력이 수명주기에서 각 계층의 크기만큼 증가한다는 것이 인정된다. 즉, 요구 사항 수준에서 오류를 수정하는 데 1 시간이 걸리면 디자인에서 10 시간, 코딩 테스트에서 100 시간, 버그 수정으로 1000 시간이 소요됩니다. 그 수치는 터무니없는 것처럼 들릴지 모르지만 대략적으로 정확한 것으로 업계에서 인정됩니다. 분명히 작은 프로젝트에서는 덜하지만 일반적인 아이디어는 남아 있습니다. 프로젝트에 기본 설계 결함이있는 경우 학습 경험을 호출하고 되돌아 가서 초기 요구 사항을 검토하고 재 설계하는 것이 더 적절합니다.

또한 구조화 된 단위 테스트를 사용하여 테스트 중심 개발 모델을 고려하는 것이 좋습니다. 그것들은 고통스럽고 처음에는 시간 낭비처럼 보이지만, 특히 다른 사람의 코드와 통합 할 때 오류를 발견하는 능력은 과장 될 수 없습니다.

이 문장에서 나를 잃었다.

문제는 프로그램의 주요 기능조차 끝내지 못했기 때문에 진정으로 리팩터링 할 수 없으며 코드 디자인에 결함이 있음을 완벽하게 인식하지 않는 것입니다.

나는 ( Systemantics에 명시된 ) 원칙을 믿습니다.

• 작동하는 복잡한 시스템은 작동하는 간단한 시스템에서 진화 한 것으로 밝혀졌습니다.
• 처음부터 설계된 복잡한 시스템은 작동하지 않으며 작동하도록 패치 할 수 없습니다. 작동하는 간단한 시스템부터 시작하여 다시 시작해야합니다.

복잡한 시스템을 작성하는 것은

• 간단한 시스템 작성
• 작동하는지 확인

... 예 : 다음 단계 :

1. 약간의 코드 작성
2. 작동하는지 테스트
3. 조금 더 코드를 작성
4. 다시 테스트
5. 기타.

3 단계에는 다음이 포함될 수 있습니다.

3. 조금 더 코드를 작성
   1. 기존 코드를 리 팩터하여 새로 추가 할 수 있도록 준비
   2. 리팩토링을 테스트하여 여전히 작동하는지 확인하십시오.
   3. 새로운 기능 추가

또한 2 단계 "작동하는지 테스트하여"그렇지 않은 경우 다시 작성해야 할 수도 있습니다.

썩은 코드 기반을 구축하고 있다면 더 많은 기능을 추가하지 않을 것입니다. 따라서 다음 구현할 작업으로 "기존 스레딩 구현 단순화"와 같은 일정을 세우는 경향이 있습니다. 테스트를 진행하면서이를 리팩토링 연습으로 취급 할 수 있어야합니다. 이 작업 단계의 성공 / 종료 기준은 다음과 같습니다.

• 소스 코드가 더 간단합니다
• 그리고 새로운 버그가 도입되지 않았습니다
• (그리고 몇 가지 오래된 버그가 제거되었습니다)

부수적으로, "작동하는지 확인하기위한 테스트"가 반드시 "단위 테스트"를 의미하는 것은 아닙니다. 팀 구조가 단순 할 때 (단순한) 시스템 테스트 (단위 테스트 대신)를 사용하여 (단순한) 시스템을 테스트 할 수 있습니다 .

이와 같은 문제가 발생할 때 직면하는 문제 중 하나는 지금까지 작성한 코드에 어떤 식 으로든 감정적으로 붙어 있다는 것입니다.

한 동료가 대학에서 유명한 교수의 수업을받는 동안 프로그램을 작성하고 있다고 말했습니다 (Dijkstra라고 생각합니다). 그는 교수에게 한 달 넘게 작업 한 코드를 살펴 보라고 요청했다. 교수는 백업을했는지 물었다. 그 후 교수는 자신의 코드를 모두 삭제하고 다시 작성하라고 말했습니다.

그는 화를 냈지만 3 일 후에 더 깨끗한 코드와 적은 버그, 적은 코드 줄로 프로그램을 마쳤습니다.

프로젝트에 가장 적합한 옵션을 정직하게 추정하십시오.

3 가지 선택은

• 삭제 (완전히 되돌아 보지 않음)
• 기존 디자인 작업 계속
• 가는 동안 코드를 리팩터링하십시오.

저는 10 년 넘게 프로페셔널 프로그래머였으며, 업무 라인에서 마지막 옵션이 가장 많이 선택되었지만 항상 최선의 옵션은 아니라는 결론을 내 렸습니다.

그 기간 동안 당신의 기술이 크게 성장한 것 같습니다. 아마도 그 프로젝트에서 일한 것이 그 프로젝트에 기여했을 것입니다. 유익한 학습 경험으로 다시 설계하면 유익 할 것입니다.

이것은 고객을위한 작업 프로그램으로 제공 할 필요는 없음을 기억하십시오. 연습을 위해 특별히 작성되었습니다. 따라서 배송 문제와 결함이있는 배송을 연습하고 싶지 않다면 현재 "디자인 근육"을 사용하는 것이 유익한 개발 단계에 있다고 생각합니다.

그렇게 할 때는 디자인 프로세스와 계획에 중점을두고 기존의 내용을 묵상하고 이해하고있는 내용을 반영하십시오.

리 팩터 리 팩터 리팩터링! 냉장고 !!!!

솔직히, 당신이 아무리 경험이 있더라도 이것은 일반적인 문제입니다. 코드를 작성하고 무언가를 배웠으며 이전 코드에 대한 새로운 지식을 사용하려고합니다. 새로운 지식에 대해 이전 코드를 측정하려고합니다.

그것은 작동하지 않습니다. 그렇게하면 응용 프로그램 / 게임이 완료되지 않습니다. 대신, 프로젝트에 시간을 할당하여 일부 "작업"이 잘못된 코드를 리팩터링하도록하십시오. 예를 들어 게임을 저장하는 끔찍한 방법이 있다고 가정 해 봅시다. 게임 자체를 계속 연구하되 그 무시 무시한 방법을 리팩터링 (교체) 할 시간을 찾으십시오. 리 팩터를 작게 유지하면 문제가되지 않습니다.

리 팩터가 필요한 응용 프로그램의 주요 부분에 도달하면 심각하게 잘못하고 있습니다. 리팩토링을 더 작은 부분으로 나누십시오. 코드 작성에 7 시간, 리팩토링에 1 시간을 투자하십시오.

프로젝트를 마치고 기능 정지를 누르면 리팩토링에 많은 시간을 할애 할 수 있습니다. 지금은 게임을 끝내야하지만 여전히 일부 리팩토링을 시도하십시오. 그것이 당신이 할 수있는 최선입니다.

항상 리팩터링 할 것이 있습니다.

나는 그것이 현재 어떤 종류의 코드를 가지고 있으며 정확히 어디에 문제가 있는지에 달려 있다고 말합니다. 즉, 당신의 기초가 좋으면 (대부분 적절한 클래스 디자인, 좋은 분리 / 응집 등, 언급 한 스레드와 같은 몇 가지 나쁜 선택), 맨손으로 1.0을 가져 와서 리팩토링하십시오. 내일은 없어

다른 한편으로, 만약 그것이 실제로 식별 할 수있는 구조 등 (어떻게 든 개념 증명 학습시 작업 프로토 타입)없이, 컴파일러를 통과하는 못생긴 텍스트 파일들만 있다면, 차라리 삭제하고 다시 시작하겠습니다.

다음 버전에서는 민첩한 접근 방식을 사용하십시오. 2 주 또는 일정에 맞는 고정 반복 일정을 설정하십시오. 각 청크가 시작될 때 (스프린트라고하자), 2 주 동안 달성 할 수있는 목표를 설정하십시오. 계속해서 해보고, 최선을 다해 작동 시키십시오. 매 2 주마다 추상적 인 내부 작업뿐만 아니라 친구에게 보여줄 수있는 것을 갖도록 목표를 설정하십시오. 구글 "스크럼"과 "스마트 목표". 혼자있는 경우 몇 가지 빠르게 정리 된 글 머리 기호가있는 종이 조각 만 있으면됩니다.

그렇게 할 수 있다면 다시 시작하는 것이 좋습니다. 당신이 시작한 후에 그 내부를 깊이 알고 있다면 어쨌든 현재의 위치에있게 될 것입니다. 그런 다음 코드를 고수하고 작동하게하십시오.

당신은 고용주 신발에 자신을 넣어야합니다.

대부분의 신입 사원에게는 다음과 같은 방법으로 가장 가치있는 사람이 될 것입니다.-작성한 새 코드에 대해 100 % 테스트로 마무리하십시오. -기존 (잘못된 설계) 코드에 대한 테스트를 추가하십시오. -원하는 디자인을 달성하기 위해 리팩토링합니다.

좋은 버전 관리 프로세스, 브랜치 및 태그를 사용하여 모든 작업을 수행하십시오.

재 작성은 종종 섹시한 아이디어이지만, 신입생들이 실제로는 다소 위험한 아이디어입니다. 처음부터 시작하는 것이 이미 작업 품질을 향상시킬 의사가 있음을 보여 주면 진지한 사람이라는 좋은 신호입니다.

분명히 다시 쓸 수는 있지만 다른 프로젝트로 만들 수 있습니다.

내 과거 경험을 믹스에 추가하기 만하면됩니다. 나는 여분의 몇 분을 얻을 때마다 1 년 이상 동안 사이드 프로젝트를 진행해 왔습니다. 이 프로젝트는 간단한 테스트 베드에서 정적 클래스로, 객체 지향의 슬림형 디자인으로 바뀌 었습니다.

이러한 모든 변경 사항을 통해 버그 수정 및 성능 이점을 제외하고 코드의 동일한 기능을 유지했습니다 (가능한 한 빨리 필요). 리팩토링되었지만 동일한 코드베이스는 동일하게 유지되므로 코드를 처음부터 낭비하지 않고 다시 작성하지 않고도 크게 개선했습니다.

이것은 내가 할 수 있었던 것보다 빠른 속도로 코드를 향상시킬 수 있음을 의미했습니다. 또한 내가 갈 때 제거해야 할 것, 즉 불필요한 클래스, 그리고 내 생각에 여전히 오래된 아이디어를 다시 쓰는 것보다 더 쉬울 수있는 것을 말하기가 더 쉬웠다는 것을 의미했습니다.

따라서 내 조언은 코드를 리팩터링하고 필요에 따라 개선하는 것입니다. 처음부터 다시 작성하기로 결정했다면 이전 프로젝트의 좋은 아이디어를 취하여 결함이있는 부분을 면밀히 검토해야합니다. 즉, 이전 코드를 새 프로젝트에 복사하지 마십시오.

대답은 내가 "복잡성 한도"라고 부르는 것에 달려 있습니다. 코드베이스에 점점 더 많이 추가할수록 코드베이스가 점점 더 복잡해지고 구성이 줄어드는 경향이 있습니다. 어느 시점에서, 당신은 "복잡성 상한선"에 도달하게되는데,이 시점에서 앞으로 진행이 매우 어려워집니다. 무차별적인 힘으로 계속 움직이려고하는 대신 백업, 재구성 / 다시 쓰기를 계속 한 다음 계속 진행하는 것이 좋습니다.

코드베이스가 너무 나빠서 복잡도 한도에 가까워지고 있습니까? 그럴 것 같으면 진행하기 전에 정리하고 단순화하는 데 시간이 걸립니다. 정리하는 가장 쉬운 방법은 일부 부품을 다시 작성하는 것입니다.

둘 다요? 양자 모두?

계속해서 기존 디자인을 수정하고 새로운 기능을 추가하는 데 시간을 투자하십시오.

만약 당신이 엉뚱한 인터랙션을 가지고 있다면, 시작하기에 좋은 곳이 될 수 있습니다 ( "렌더러의 과도한 스레드"는 정확성 문제를 일으키는 것이 아니라 비효율적 인 것처럼 들립니다). 레이스에서 벗어나는 일반적인 방법 (또는 교착 상태)을 파악할 수 있는지 또는 최소한 여러 가지 구체적인 방법을 알아낼 수 있는지 확인하십시오.

교착 상태 및 경주 감지기와 같은 것들이 C #에서 사용할 수있는 정도는 모르겠지만 존재하는 경우 어떤 문제가 있는지 확인하고 수정 프로그램이 작동하는지 확인하는 데 유용 할 수 있습니다.

나는 일반적으로 코드를 버리고 처음부터 다시 시작하는 대신 유용한 코드로 문제를 해결하는 데 더 많은 동기가 있음을 알았습니다. 스코치 필드 (그린 필드 및 브라운 필드와 유사하게) 개발이 더 만족스러운 경우가 있지만, 일반적으로 기존 접근법이 더 이상 잘못되지 않아야하는 곳에서 벗어나는 경우에 해당됩니다.

코드가 모듈 식인 경우 잘못 작성된 구성 요소 주위의 나머지 코드를 완료 한 다음 나머지 코드에 영향을주지 않고 잘못 작성된 구성 요소를 다시 작성해야합니다.

이 경우 잘못 작성된 구성 요소를 다시 작성할 때는 사용자에게 달려 있습니다. 잘못 작성된 구성 요소가 잘못 작성되어 완성 된 코드가 그대로 작동하지 않으면 나머지 코드를 완성하기 전에 다시 작성해야합니다.

가장 먼저 물어보아야 할 질문은 "결함이 얼마나 나쁜가?"입니다.

정확히 무엇을 잘못 했습니까?

문제가 너무 심해서 문제를 해결하는 데 많은 시간을 허비하거나 민감한 데이터 (암호 / 신용 카드)를 노출 시키거나 나쁜 취약점을 일으키는 경우 편집해야하지만 대부분의 경우 가지고있는 것을 가지고 끝내고 나중에 문제를 해결하십시오.

프로그래머는 응용 프로그램 개선을 좋아하고 "최고의 상태"를 원하지만 올바른 접근 방식은 아닙니다.

응용 프로그램이 100 %가 아니더라도 버그를 모두 제거한 후 가능한 빨리 응용 프로그램을 릴리스 하면 버그 및 버그 1.1을 수정하는 데 시간 이 걸리면서 다른 사람들로부터 피드백 을받습니다 . 다른 사람들이 응용 프로그램을 훨씬 더 좋게 만들도록 도울 수 있으며 사람들이 싫어하는 일을하는 데 시간 을 낭비했을 수 있습니다.

따라서 귀하의 경우에는 그것을 꺼내어 피드백을 얻은 다음 모든 변경 사항으로 버전 2.0을 구성하고 결함을 수정하십시오.

기억해야 할 또 다른 사항은 지속적으로 개선되고 있다는 것입니다. 1 년 전에 작성한 코드를 볼 수 있고 코드가 나쁘다는 것을 알면 여전히 개선 중이라는 것을 알 수 있습니다.

코드가 얼마나 엉망인지에 달려 있습니다.

• 코드를 지나치게 복잡하거나 장황하게 만드는 실제 n00b 오류를 만든 경우 해당 부분을 다시 작성하는 것이 좋습니다.

• 어쨌든 수정해야 할 심각한 버그가 있다고 생각되면 버그를 수정했는지 여부를 확인할 수있는 단위 테스트를 작성하십시오 (아직 프로그램을 시작할 수 없기 때문에). 버그를 조기에 수정하는 것이 좋으며 코드가 수행하는 작업을 계속 기억하면서 버그를 수정하는 것이 좋습니다.

• 메소드가 호출되거나 클래스가 속하는 클래스 또는 그와 비슷한 것이 마음에 들지 않으면 IDE를 사용하십시오. (이것은 일부 자바 스크립트, 파이썬, 펄, PHP 등이 아닌 C #입니다.) 영향을받는 구성 요소를 사용하는 코드를 작업 할 때 해당 구성 요소가 수행해야 할 작업에 대한 명확한 그림을 볼 수 있습니다. IDE가 고통스럽지 않으면 리팩터링하십시오.

그렇지 않으면, 그것을 작동시키고 다음 프로젝트에서 당신의 기술을 연마하십시오.

다른 사람들이 제안했듯이, 이것은 전문 프로젝트가 아닌 개인 프로젝트이므로 재 작성을 진지하게 고려할 것입니다.

그러나 실험을 수행하여 과학적 방법을 활용할 수 있습니다. 먼저 가설을 생각해보십시오. 내 생각 엔 "다시 쓸 시간이다" 더 많은 프로그래밍을 수행하기 전에 시간을 절약하고 실패 비용을 줄이며 선험적 편향을 어느 정도 제한하십시오 ( "시간 상자"). 아마도 4 시간의 시계 시간을 제안 할 것입니다. 또한 가설을 평가하는 방법론을 결정하십시오. 말뚝이 적기 때문에 방법론으로 제안하고 싶을뿐입니다. "내가 이것을 기뻐?" 이제 실험을 시작하십시오. 선택한 타임 박스 후 가설의 평가는 무엇입니까? 예를 들어, 제 예제에서, 4 시간을 보냈으므로 다시 쓰기 시작 했습니까? 그렇다면 아마도 올바른 선택 일 것입니다.

세계의 모든 조언을 구할 수 있지만, 가설을 실험적으로 테스트하는 것만 큼 좋은 것은 없습니다.

실험으로 다시 쓰기를 선택해야하는 몇 가지 이유는 다음과 같습니다.

• 내 경험상, 보통 더 재미있다. 재 작성이 전문적인 상황에서 종종 선택되지 않는 큰 이유는 재미가 유일한 기준과 거리가 멀기 때문입니다. 그러나 여전히 코딩에 익숙하지 않기 때문에 재미는 아마도 매우 중요한 기준일뿐 아니라이 초기 단계에서 당신에게 무형이 될 수있는 다른 요소의 지표이기도합니다 (재미는 더 배우게 될 것 등을 제안합니다).
• 당신의 경험과 아마도 잔인한 양심은 재 작성이 고려할 가치가 있다고 말하고있는 것 같습니다. 그 목소리가 있다면 들으십시오. 당신이 따르지 않더라도 적어도 조언을 들으십시오. 앞으로는 더 많은 외부 목소리가있을 것이며, 자신의 선의의 소리를 듣는 연습이 필요합니다.
• 다시 작성하면 코드를 더 모듈화 할 가능성이 높습니다. 모듈을 만들면 다른 프로젝트에 활용할 수있는 더 재사용 가능하고 안정적인 구성 요소가 있습니다. 결국, 주요 프로젝트의 단순한 모듈처럼 보이는 것이 가장 흥미롭고 가치있는 코드 조각으로 판명되었습니다.

무언가를 마무리하는 것은 좋은 생각이지만 진공 상태에서는 아닙니다. 다시 쓰기를 시작하면 특정 하위 모듈을 완성하여 무언가를 끝내도록 선택할 수 있습니다. 위 실험 후 첫 번째 목표로 설정할 수 있습니다. 마무리는 초기 메인 프로젝트를 아직 완료하지 않아도됩니다. 모듈을 완료 한 후 원하는 경우 원래 프로젝트 전체 범위를 다시 작성할 때까지 다른 모듈 등을 완료하십시오.