나에게 할당 된 3 개 이상의 버그를 머릿속에 유지할 수없고, 수천 줄의 스파게티 코드를 이해할 수없는 것이 정상입니까?

나는 오래 되지 않은 코드베이스에서 일하고 있습니다 ... 완벽하지 않은 환경에서도 완벽 하지 않습니다. 내 인생에서 본 최악의 코드베이스는 아니지만 여전히 많은 문제가 있습니다 : 제로 단위 테스트; 수천 줄의 코드가있는 메소드; 기본 객체 지향 원칙에 대한 오해; 기타

코드를 유지하기가 아프다.

1. 변수를 완전히 재사용하여 잘못 작성된 수천 줄을 디버깅해야 할 때마다 완전히 사라집니다.
2. 일부 수정 또는 리팩토링 응용 프로그램의 다른 위치에 버그가 도입되었습니다.
3. 문서, 테스트 또는 관찰 가능한 아키텍처가없고 이름이 잘못된 메소드와 결합되어 사용 가능한 모든 작업 메모리를 채우고 있다고 생각합니다. 내가 수정해야 할 코드를 이해하기 위해 기억해야 할 다른 모든 것들에 대한 여지가 남아 있지 않습니다.
4. 직장에서의 끊임없는 중단은 나를 방해하고 속도를 늦 춥니 다.
5. 버그 추적 시스템이 없으면 한 번에 2 ~ 3 개 이상의 작업을 기억할 수 없으며 주말 동안 모든 작업을 잊어 버립니다.

동료들도 비슷한 문제가없는 것 같습니다.

1. 그들은 나보다 훨씬 빨리 잘못 작성된 메소드를 디버깅 할 수 있습니다.
2. 코드베이스를 변경할 때보 다 버그가 적습니다.
3. 그들은 20 개의 다른 파일에서 수천 줄의 코드를 읽어야 할 때에도 코드를 변경하기 위해 필요한 모든 것을 잘 기억하는 것 같습니다.
4. 그들은 이메일, 전화벨, 주위 사람들과 대화하거나 다른 사람들에게 질문을하는 것으로 방해받지 않습니다.
5. 그들은 TFS를 사용한 이후로 이미 가지고있는 버그 추적 시스템을 사용하고 싶지 않습니다. 그들은해야 할 모든 작업을 기억하는 것을 선호합니다.

왜 이런 일이 발생합니까? 잘못 작성된 코드로 오랫동안 작업 할 때 개발자가 얻는 특별한 기술입니까? 나쁜 코드에 대한 상대적인 경험 부족이 이러한 문제 / 감정에 기여합니까? 메모리에 문제가 있습니까?

그렇습니다. 구조화 된 사람들이 구조화되지 않은 코드 / 환경의 영향을받는 것은 정상입니다. 동료들은 아마도 모든 배경 소음을 걸러내는 것이 좋습니다. 편두통 환자는 편두통이 시작될 때 내 환경을 걸러내는 능력이 크게 떨어진다는 것을 알고 있습니다. 사람들은 다양합니다.

코드에서도 마찬가지입니다. 동료들은 단일 방법으로 여러 수준의 추상화에서 발생하는 "코드 노이즈"를 걸러 내고 코드를 더 큰 영역의 기능으로 "청크"하는 데 능숙했을 것입니다.

설명하는 것과 같은 코드 기반에 적응하는 데 시간이 걸립니다. 동료들은 아마도 더 많은 시간을 투자했을 것이며 아마도 "코드베이스 초보자"에 빠지지 않는 컨벤션, 패턴 및 구성을 선택했을 것입니다. 당신이 상상할 수있는 것보다 혼란에 더 많은 구조가있을 수 있습니다. 동료와 대화하고 시간을내어 동료에게 당신에게 할당 된 버그 중 하나를 해결하는 방법에 대한 두뇌를 고르라고 요청하십시오. 그들이 당신에게 X, Y 또는 Z 단위를 열라고 요청할 때, 왜 그 중 하나인지, 그것이 관련이 있다고 말하는 것이 무엇인지 물어보십시오.

천 줄의 방법으로 길을 잃는 것은 정상입니다. 좋은 접는 편집기로 공격하고 주석을 추가하여 실제로 그렇게하지 않고 다양한 부분을 기능 및 / 또는 절차에 청크하십시오. 물건을 인쇄하고 구식 형광펜을 사용하는 것도 도움이 될 수 있습니다.

단위 테스트의 안전망없이 리팩토링을하면 발을 쏠 수 있습니다. 하지마 하지마

아무도 당신이 모든 것을 기억하도록 요구하지 않습니다. 동료들이 버그 시스템을 원하지 않거나 필요로하지 않는다면, 할 일 목록에 자신에게 할당 된 작업을 작성하고 작업 세부 사항에 대해 누군가와 이야기 할 때 / 후에 메모를 작성하십시오.

내가 볼 수있는 3 가지 주요 사항이 있습니다.

포인트 1, 2 및 3은 동료가 코드베이스에 대해 더 많은 경험을 가지고 있다는 사실에서 비롯됩니다. 즉, 디버그 프로세스에 장기 메모리를 사용하며 doXYZ가 실제로 UVW를 수행하지만 역사적인 이유로 이름이 바뀌지 않았다는 것을 기억할 수 있습니다. 그러나 코딩하는 데 몇 개월이 걸리면 통증을 느끼기 시작할 것입니다.

포인트 4의 경우 중단에 저항하기 위해, 긴급하지 않은 비즈니스가 사용자를 영역 에서 벗어나게하지 마십시오 . 중단 후에 다시 시작하는 데 시간이 오래 걸립니다. 회사의 메신저를 바쁘게 설정하고 코딩만으로 긴 블록 (전체 오후)으로 일정을 잡으십시오.

포인트 5 초 동안 현재 개인 작업 목록으로 작업중 인 버그가 포함 된 Excel 시트를 작성하거나 IDE에서 작업 관리 기능을 사용하면 동료 중 일부가 동일한 작업을 수행 할 수 있습니다.

나에게 메모리 문제처럼 들리지 않습니다. 그것은 당신이 당신의 작업 습관 / 경향이 당신이 겪고있는 것에 적합하지 않은 것처럼 들리며, 당신은 동료가 아닌 자신에 대해 너무 많은 생각을하고 있습니다.

1. 천 줄의 방법-그들이 그 일을하지 않으면 모든 사람들이 그 길을 잃게 될 것입니다. 집어 올리거나 다시 가져 오는 것이 더 빠를 수 있습니다. 당신은 경험을 통해서를 제외하고는 바꿀 수 없으며 심지어는 그렇지 않을 수도 있습니다.

2. 버그를 도입하는 리팩토링은 항상 위험합니다. 변경하기 전에 변경 사항을 다루기 위해 단위 테스트를 개발할 수 있지만 관리에서 허용하지 않을 수도 있습니다 (아직 수행하지 않았거나 이미 수행되었을 수도 있음). 그리고 단위 테스트는 여전히 사실을 놓칠 수있는 마법이 아니며 버그를 도입 할 수 있습니다. 그들은 단지 리팩토링하지 않을 가능성이 있습니다. 이것은 (1)으로 돌아가서 수정해야 할 부분에만 집중하려고 시도합니다. 즉, 더 빨리 요점을 얻지 만 더 큰 그림을 그리워하고 다음 라인 엉망으로 다음 항목을 수정하는 데 시간이 더 오래 걸립니다.

3. 작업을 완료하는 데 필요한 것을 만듭니다. 이것이 순서도 나 다른 문서를 만드는 것을 의미한다면 그렇게하십시오. 필요 여부와 생성 후 사용 여부는 관계가 없습니다.

4. 중단으로 인해 모든 사람이 느려집니다. 그것에 집중하면 속도가 더 느려질 것입니다. 그것을 받아들이고 가능한 빨리 그루브로 돌아 오십시오.

5. 2 개 또는 3 개의 버그를 염두에 두는 것은 나쁘지 않습니다. 3 개 또는 4 개가 더 나을 것입니다. 종이, 화이트 보드, tfs, 엑셀, 단어 또는 메모장-그냥 적어 두십시오. 나는 그것이 당신 동료들이하는 일이라고 확신합니다. 그 중 하나라도 무작위로 고치십시오.

프로그래밍은 완벽한 기억에 관한 것이 아니며 방해 요소를 무시할 수있는 것이 아닙니다. 이것에 초점을 맞추는 것은 여러분이 만드는 방해 요소입니다.

CAVEAT / UPDATE : 아래 답변을 읽은 후, 너무 가혹하다고 느꼈습니다. 내 의도가 아니라, 당신이 묘사하는 환경은 끔찍하며 대부분의 사람들에게 영향을 줄 것입니다 (아마도 더 나은 프로그래머가 고통을 겪지 만 같은 환경에서 다른 사람들과 비교하면 더 낫습니다). 내 대답은 환경이 변하지 않는다고 가정 할 때 귀하의 질문에 포인트별로 반영됩니다 (필요한 경우에도).

완전히 적절한 답변 :

1) 그것은 기술의 경험, 응용 프로그램 유지 관리 (디자인이 좋지 않은 경우 더 많음) 및 응용 프로그램의 특정 부분에 달려 있습니다. 또한 집중력 문제에 따라 다릅니다 (4 번)

2) 1과 동일하지만 다른 메트릭을 사용합니다. 같은 대답입니다.

3) 노트 블록과 펜. 또는 단어 / 엑셀 문서. 그렇게 어렵지 않습니다.

4) 그것은 개인적인 집중 문제입니다. 그래도 스스로 향상시킬 수 있는지 확실하지 않습니다.

5) 티켓 시스템 사용 여부는 프로그래머가 아닌 프로젝트 관리자가 결정해야합니다. 그의 의견을 말하거나 요점을 제시하십시오. 그가 반대하는 경우, 메모 블록과 펜을 다시하십시오.

나는 그 경험을 바탕으로 이전과 같은 상황을 겪어 왔으며 당신의 문제는 기억과 관련이 없으며 당신의 스트레스를 유발하고 집중하는 것을 방해하는 무언가가 당신의 마음에 (아마도 일과 관련이 없음) 있다고 말할 수 있습니다. 진행중인 작업에 대한 %.

따라서 첫 번째 단계는 책상에있을 때 그 물건에서 마음을 비우는 것입니다.

생산성 측면에서 뒤쳐져 있다고 느끼기 때문에 스트레스가 증가 할 수도 있으므로 동료들과 이야기하고 리팩토링에 대한 접근 방식에 대한 팁을 요청하십시오.

마지막으로 해결하거나 지금 당장 문제를 작성해야하는 경우 당황하지 마십시오 (정교한 버그 추적 시스템 일 필요는 없음). 100 % 확실하지 않은 상태에서 머리 위로 메모하는 것보다 메모