물러서서 신선한 눈으로 코드를 보는 방법? [닫은]

작년에 리치 클라이언트 애플리케이션 (35,000+ LoC, 가치있는 것)을 개발하는 1 인 팀으로 보냈습니다. 현재 안정적이며 생산 중입니다. 그러나 나는 프로젝트가 시작될 때 내 기술이 녹슬 었다는 것을 알고 있으므로 의심 할 여지없이 코드에 큰 문제가 있습니다. 이 시점에서 대부분의 문제는 아키텍처, 구조 및 상호 작용에 있습니다. 쉬운 문제, 심지어 아키텍처 / 디자인 문제도 이미 해결되었습니다.

불행히도, 나는이 프로젝트에 너무 많은 시간을 투자하여 외부에서 생각하는 데 어려움을 겪었습니다. 새로운 관점에서 접근하여 디자인에 내재 된 결함을 발견했습니다.

머리 모양과 코드 바깥을 어떻게 밟아서 깔끔하게 보이고 더 좋게 만들 수 있습니까?

이것에 접근하는 방법 :

• 기술 및 비즈니스 문제에 익숙한 사람을 찾아서 대화하십시오. 이것은 한 사람으로 구성된 팀에서는 어려울 수 있지만 일반적으로 최선의 선택입니다.
• 잠시 동안 다른 프로젝트를 수행하십시오. 이것은 또한 어려울 수 있지만 일주일의 휴식을 취해도 새로운 관점을 얻을 수 있습니다.
• 오픈 소스 제품과 같은 유사한 프로젝트 나 제품을 살펴보십시오. 코드를 복사하지 않도록주의하지만 아이디어와 완전히 다른 방식으로 접근했을 수 있습니다.
• 새로운 언어, 라이브러리 또는 프레임 워크를 배우십시오. 관련된 기술을 통해 동일한 문제에 다르게 접근하는 방법에 대한 통찰력을 얻을 수 있습니다.
• 디자인이나 언어 / 프레임 워크에 관한 좋은 책 / 블로그 / 잡지를 읽으십시오. 본인의 기술 수준이 확실하지 않지만이 사이트의 다른 답변에는 다양한 대안이 있습니다.

해결하려는 특정 예가있는 경우 여기에 게시하십시오.

고무 오리 디버깅 : 코드 조각이나 모듈 또는 기능으로 앉아 크게 설명하십시오. 잘못 들리거나 어리석은 말이나 평범하지 않은 말을 발견하면 조사 할 문제로 적어 두십시오.

계속 배우고 기술을 확장하십시오. 당신이 모르는 것을 아는 것은 어렵지만, 그것을 볼 때 그 "aha"순간이 당신을 때릴 것입니다. 다른 언어 나 디자인 패턴을 배워서 올 수도 있습니다.

변경하라는 메시지가 표시됩니다. 유연성이 떨어지고 많은 재 작업이 필요한 코드 부분을 찾을 수 있습니다. 처음에는 모든 것을 생각할 수 없기 때문에 반드시 실패는 아닙니다.

사용자가 불평을 시작합니다. 모든 것이 훌륭하다고 생각할 때 ...

짧은 기억이 도움이됩니다. 나는 일주일 전에 무언가를 바꾼 "멍청이"에 ​​대해 불평하는 것으로 알려져 있습니다.

좋은 첫 번째 단계는 개선 될 수있는 코드를 식별하는 것입니다. 소스 컨트롤에서 가장 자주 변경되는 파일을 찾으십시오. 어떤 코드를 다루기가 가장 어려운가요? 어떤 코드가 가장 많은 버그를 생성합니까? 코드 전체에서 어떤 종류의 변경으로 인해 파급 효과가 발생합니까? 이 단계에서, 당신은 알 필요가 없습니다 이유 코드가 골칫거리 그냥 있다는 것이 귀찮은.

작업 할 영역을 식별 한 후 문제가 실제로 무엇인지 알아 봅니다. 디자인 문제를 분류하기 위해 체계적으로 접근하는 책이 있습니다. Martin Fowler의 리팩토링 , Herb Sutter의 C ++ 코딩 표준 , Robert Martin의 Clean Code 등을 살펴보십시오.이 코드에는 객관적인 방식으로 코드를 볼 수있는 "규칙"이 있습니다.

문제가 무엇인지 확인한 후에는 다른 방법으로 문제를 해결해보십시오. 예를 들어, 위반 한 규칙이 "상속보다 컴포지션 선호"인 경우 컴포지션으로 변경하고 느낌을 확인하십시오.

분명히, 다른 사람이 코드를 보도록하는 것이 도움이 될 수 있지만 , 코드가 다른 사람보다 발생하는 문제의 종류와 디자인의 이유에 대해 훨씬 더 잘 알고 있기 때문에 항상 생각만큼 도움이되지는 않습니다. . 자신의 디자인을 객관적으로 평가하는 몇 가지 방법을 배우면 큰 배당금을 지불하게됩니다.

다른 사람이 귀하의 코드를 보도록하십시오. 다른 사람을 찾을 수 없으면 다른 사람에게 보여줄 것처럼 상호 작용에 대한 완전한 설명을 작성하십시오. 다른 사람에게 의사 결정을 설명하려고 시도하는 과정 (실제를 위해서라도)은 왜 특정 방식으로 일을하고 있는지에 대해 실제로 생각하고 논리의 허점을 보는 데 도움이 될 수 있습니다.

나는이 상황을 매우 잘 알고있다. 그런 식으로 막히면 프로젝트에서 다른 관점을 취하려고합니다.

1.) 사용자 / 고객 관점-피드백 사용

불행히도 우리는 코드를 작성하는 방식으로 응용 프로그램을 사용하기 때문에 자체 결함을 볼 수없는 방식으로 코드에 걸렸습니다. 사람들이 어떻게 그것을 사용하는지 살펴보고 가장 직관적 인 사용자 지침이 무엇인지 알아 내려고 노력하십시오. UI 프로토 타입을 사용해보십시오. 이것은 재미있을 것 같지만 재 설계주기를 시작하는 시간보다 사용 논리를 변경하여 코드의 많은 부분을 다시 코딩해야한다는 것을 알게되면.

2.) 코드의 기능 분석을 수행하고 시각화

일부 IDE 및 프레임 워크는 UI 및 백엔드 코드 혼합과 같은 기능을 제공합니다. 이런 일이 생기면 언젠가는 의존성이 깨지기 쉽고 어려워서 코드베이스를 거의 유지할 수없는 상황에 직면하게됩니다. 특히 UI 코드를 다른 코드와 혼합하면 스파게티 코드 및 중복 기능이 발생할 수 있습니다. 데이터베이스 클래스, 통신 클래스, UI 클래스, 코어 클래스 등과 같은 기능 블록으로 코드를 나누고 함수 블록에 이름을 말하십시오. 그런 다음 그래픽 도구 (마인드 매핑 도구 사용)로 기능을 시각화하여 구조가 다른 프로젝트에 거대한 코드 블록을 재사용 할 수있을만큼 논리적이고 모듈화되어 있는지 확인하십시오. 큰 고통.

내 경험 에서이 작업을 수행하는 가장 좋은 방법은 클래스와 코드 호출 간의 모든 종속성을 시각화하는 문서를 만드는 것입니다. 결과적으로 인터페이스 디자인이 시각화됩니다. 이 코드 맵이 행동 할 때보 다 완전한 clusterf ***처럼 보인다면. 아직 발생하지 않은 경우 코드 구조를 나타내는 적절한 명명 규칙을 호출하는 방법과 수행 방식에 대해 생각할 필요가없는 방식으로 생각해야합니다.

3.) 품질 보증에 대한 일반적인 접근법을 사용

내가 가장 좋아하는 것은 FMEA입니다. 코딩 측면에서 이것은 과거에 무엇이 잘못되었는지 분석 할뿐만 아니라 무엇이 잘못 될 수 있는지에 대한 생각을 의미합니다. 매우 일반적인 예는 갑자기 네트워크 연결이 끊어진 것입니다. 이 작업을 수행 한 후 데이터 손실, 충돌, 잘못된 계산과 같은 결과로 오류 조건을 분류하고 사용자에게 미치는 영향을 판단 할 수 있습니다. 아직 완료되지 않은 경우 간소화 된 오류 및 예외 클래스 및 루틴을 정의하면 코드를 깨끗하고 직선적으로 유지할 수 있습니다. 가장 좋은 방법은 다른 코드를 작성하기 전에 새로운 코드의 평화를 구현하는 것입니다. (저는 항상이 조언을 따르지 않는 것은 유죄입니다.)

또한 자체 코드에 대한 "개선 제안 목록"을 생성하고 자주 업데이트하는 데 도움이되었습니다. (솔직히 말해서 내 프로젝트에는 여전히 자랑스럽지 않은 많은 코드가 있습니다.) 또한 API 문서, 개발자 회의 또는 개발자 잡지에서 모범 사례 코드를 수집하고 살펴 보는 데 시간을 투자합니다.

이 시점까지는 코드를 만질 필요가 없습니다. 단순히 무엇이 잘못되었는지 인식하고 코드를 개선하는 방법을 정의하는 방법을 찾는 것입니다.

마지막으로 오래된 방귀에서 일상적인 작업에 대한 몇 가지 팁. 먹을 수있는 것보다 더 많이 물지 않도록하십시오. 이로 인해 깨끗한 코딩에 너무 많은 압력이 발생합니다. 당신은 그것을 올바르게 할 시간을 거의 얻지 못하지만 나중에 결함을 수정하는 데 시간이 걸릴 것입니다.

임시 솔루션만큼 오래 지속되는 것은 없지만, 문제가 해결 될 때 종종 문제를 해결하는 데 시간이 오래 걸립니다. 예를 들어 기본 프레임 워크 나 OS의 결함에도 불구하고 무언가를 작동시키는 데 사용되는 불쾌한 해킹이나 이상한 예외가 있습니다. 그런 다음 결함이 해결되거나 새 버전이 단순히 API를 삭제합니다…

문제가 발생하여 의견을 작성하고 수시로 검토해야하는 메모를 작성하는 것보다 해결 방법을 찾아야하는 경우 일반적으로 우리는 새로운 것을 배우기 때문에 점점 좋아집니다. 더 좋은 방법을 찾으면 최대한 빨리 구현하십시오. 그렇지 않으면 해결 방법 및 예외 예외에 대한 해결 방법을 언젠가 코딩 할 수 있습니다. (너희 가운데 죄가없는 사람이 내게 첫 바이트를 던져 보자.)

작은 물건을 땀 흘리지 마십시오.

누구나 더 잘 코딩 할 수있었습니다. 우리는 일을 빠르게하고 몇 주 후에 더 효율적으로 수행 할 수 있음을 깨닫습니다. 요점은 코드의 90 %가 충분할 것입니다.

버그 로그를 살펴보고 문제를 일으킬 수있는 루틴을 찾으십시오. 버그를 발견하면 코드를 검토하고 코드를보다 효율적으로 만드는 방법에 대해 생각할 수도 있습니다. 대부분의 경우 버그 자체를 수정하는 것 외에는 눈에 띄게 개선 할 수 없지만 때로는 무언가를 수행하는 더 좋은 방법이 있다는 것을 알게 될 것입니다.

사용자와 대화하고 UX 또는 속도 문제와 같은 문제를 식별하는 위치를 확인하십시오. 코드를 개선하기 위해 이러한 문제를 해결하십시오.

어느 시점에서 코드가 너무 취약 해져서 변경해야 할 방법이 없다는 것을 알게 될 것입니다. 그런 다음 API 또는 테스트 중심 개발을 통해 시스템을 어떻게 더 유연하게 만들 수 있었는지 생각해보십시오. 많은 경우에, 큰 변화없이이 API를 코드에 삽입하기 시작할 수 있다는 것을 알게 될 것입니다. 다른 경우에는 코드를 개선하려는 노력이 가치가 없다는 것을 알게 될 것입니다.

증분 변경이 어려울 수 있습니다. 필요하지 않은 경우 코드베이스를 완전히 다시 작성하지 않는 것이 목표입니다. 물론, 당신은 1 년 전보다 지금은 더 나은 프로그래머이지만, 지금 당장해야 할 일이 있습니다. 5 년 후, 주니어 프로그래머가 레거시 코드에 대해 불평 할 때, 그들은 고치려고 노력하고, 미소 짓고 끄덕이며, 자신이 작성한 것을 인정하지 않습니다.

팀에 합류 할 수있는 회사를 떠나고 찾는 것을 고려 했습니까? 나는 고립되거나 정체 된 팀에서 개발자가 직업이 제공하는 많은 것을 놓친다는 것을 매우 강하게 느낍니다.

동료 리뷰를 통해 이미 머리 밖에있는 사람이 조언을 할 수 있습니다. 스택 교환 코드 검토는 귀사에서 특별히 소유하지 않은 일부 코드를 검토 할 수있는 좋은 장소입니다. 아마도 거대한 블록을 처리 할 수는 없지만 많은 프로그램은 많은 간단한 코드와 간단하지 않고 많은 문제를 일으키는 다른 코드로 만들어집니다. 일반적인 코드의 예가 있지만 반복되고 많은 위치가 변경되는 경우 좋은 검토 후보가 될 수 있습니다. 예를 들어, 메시지를 형식화하는 경우 모든 메시지 전달을 검토하도록 요청하지 말고 상당히 복잡한 예제 메시지 하나만 요청하십시오.

자신의 코드에 대해 더 객관적으로 만들고 싶다면 코드를 코딩 표준과 비교하거나 정적 또는 동적 코드 검사기를 실행하거나 드물게 문서화 된 경우 주석을 추가하면 도움이 될 수 있습니다.

자신의 코드를 테스트하기 어렵게 만드는 테스트 심리학이 있지만 단위 테스트 중에는 최선을 다할 것입니다. 자신의 코드를 읽는 것은 비슷하거나 더 나쁜 문제 일 수 있습니다. 많은 분야에서 멘토, 경쟁사 심사, 코치 등을 사용합니다. 건축가, 시스템 엔지니어 및 테스터를 세는 경우에도 마찬가지입니다. 버그보고 도구 또는 고객 지원 부서에 액세스 할 수있는 고객은 제품이 현장에 도착하면 헤드 외부로부터 피드백을 제공합니다. 이것이 애자일의 접근 방식이 조기에 자주 출시되는 또 다른 큰 이유입니다. 회사의 유일한 개발자 일 수도 있지만 코드의 영향을받는 사람들이있을 수 있습니다.

"이것이 생각보다 작은 문제입니까, 아니면 다른 사람들이 경험 한 문제입니까?"

esh. 이미 충분합니다. 코드가 프로덕션 환경에서 버그가없고 수행해야 할 작업을 수행하는 경우 아키텍처는 중요하지 않습니다. 적어도 지금은.

우리 모두가 가면서 희망적으로 배웁니다. 나는 내가 그것을 쓸 당시에 자랑 스러웠던 코드를 많이 썼는데, 단지 1 년 또는 2 년 후에 그것이 끔찍하다고 결정했다. 지금은 엄청나게 무자비한 코드로 가득 찬 다년간 프로젝트를 진행하고 있지만 코드는 작동합니다. 나는 그것을 만지기 위해 매우 보수적 인 접근법을 취하고 있습니다.

그리고 당신도 그래야합니다. 1 년 간의 작업 후에 현재 주요 건축 문제가 보이지 않는다면 중요한 문제가 없다고 가정하는 것이 안전하다고 생각합니다. 이것은 나쁜 장인 정신이 아닙니다. 앞으로 나아가고 있습니다.

다른 답변 외에도 개발자 회의에 참석하는 것이 좋습니다.

이를 통해 많은 주제와 사람들에게 자신의 앱과 직장을 생각하게 할 수 있습니다. 특히 그들은 그 당시에는 효과가없는 것과 앞으로 일어날 문제에 대해 이야기 할 것입니다. 앱과 일부 겹칠 가능성이 큽니다.

바람직하게는 이것을 위해 3 일이 걸린다. 나는 내 자신의 일에 필요한 정신적 거리를 얻고 내 자신이 아닌 더 큰 공동체의 눈을 통해 그것을 볼 수있을만큼 길다는 것을 발견했다.

덧붙여서 이것은 그룹 사고가 어디에서나 발생할 수 있기 때문에 사람들의 팀에도 적용됩니다.

마지막으로, 만약 당신이 이것에 대한 승인을받지 못하면, 일년에 한 번, 직업을 바꾸십시오.

• 실습 디자인 패턴 및 모범 사례
• 앱 요구 사항 및 요구 사항에 따라 프레임 워크, 도구, 패키지 등을 선택하십시오.이를 위해서는 많은 에칭 블로그를 읽고 각 개별 기술 문제에 대한 솔루션을 찾아야합니다.
• 설계 / 건축 초안을 작성하고 기술 / 건축 분야에 능숙한 사람과 논의하십시오. 피드백 및 의견을 사용하여이 초안을 개선하십시오. 안정적인 상태가 될 때까지 계속하십시오.

• 앱에 필요한 모든 것을 구성하고 유지 관리 할 수 ​​있도록 코드 구현

  프로젝트를 재구성하고 다시 구현하면 앱의 일관성, 성능 등이 향상됩니다.

나는 몇몇 똑똑한 사람들과 함께 문제를 '발산'하는 것이 도움이된다고 생각합니다. 구체적인 정보가 필요합니다. 24x7x365 웹 사이트입니까? LoB 앱? 어디에서 실행되거나 호스팅됩니까?

핵심 목표와 원하는 결과에 도달하면 다른 사람들이 집중하고 집중하도록 도울 수 있습니다. 코드는 하나의 특정 작업에 대해 작성된 최고의 코드이거나 최악의 코드 일 수 있습니다. 실제로 중요하지 않습니다. 원하는 목표에 어떤 영향을 미칩니 까?