매년 덜 빠는가? [닫은]

매년 덜 빠는 -Jeff Atwood

나는이 통찰력있는 기사를 발견했다.

나는 종종 매년 덜 빠는 것이 겸손한 프로그래머가 향상하는 것이라고 생각했습니다. 1 년 전에 작성한 코드가 마음에 들지 않아야합니다. 그렇지 않은 경우 A) 1 년 동안 아무것도 배우지 않았거나 B) 코드를 개선 할 수 없거나 C) 이전 코드를 다시 방문하지 않는 것입니다. 이 모든 것은 소프트웨어 개발자의 죽음의 키스입니다.

1. 얼마나 자주 이런 일이 발생합니까?
2. 코딩이 실제로 개선되기까지 얼마나 걸립니까? 월, 년?
3. 혹시 다시 방문 마십시오 당신의 오래된 코드를?
4. 이전 코드는 얼마나 자주 당신을 괴롭히는가? 또는 기술 부채를 얼마나 자주 처리해야합니까?

기한과 빠른 수정 사항을 신속하게 충족시키기 위해 수행했던 오래된 버그와 더티 코드를 수정하는 것은 확실히 고통 스럽습니다. 경우에 따라 대부분의 응용 프로그램 / 코드를 다시 작성해야 할 수도 있습니다. 그것에 대한 논쟁이 없습니다.

내가 만난 개발자 중 일부는 이미 코딩이 개선 될 필요가 없거나 더 이상 개선 될 수없는 진화 된 단계에 있다고 주장했다 .

• 이런 일이 발생합니까?
• 그렇다면 특정 언어로 몇 년 동안 코딩을했을까요?

관련 :

예전의 코드와 얼굴을 찡그린 고통을 되돌아 본 적이 있습니까?

코드에서 스타 워즈 순간 "루크! 나는 당신의 코드입니다!" "아니요! 불가능합니다! 할 수 없습니다!"

  > Sucking Less Every Year ?

아니 , 매년 다른 빨기 :-)

몇 년 전에 첫 리뷰를 한 후 나는 이름 풀림이 없어졌습니다.

그런 다음 코드가 (필수) 가능한 한 일반적으로 구현되었지만 코드를 이해하고 유지하기가 어려워졌습니다.

그런 다음 테스트 중심 개발 인 InversionOfControl을 뛰어 넘었습니다.

결론

오래된 나쁜 habbits의 고통은 줄어 들었지만 내가 더 많이 배웠기 때문에 내가 얻은 새로운 고통으로 과잉 보상되었습니다.

흥미롭게도, 내가 함께 일한 모든 "락스타"프로그래머들은 매우 겸손하고 배우고 싶어했으며 모든 것을 알지 못한다는 것을 인정할 준비가되어있었습니다. 도대체, 많은 사람들은 적어도 마음이 가벼워지는 순간에 실제로 완전히 자멸을 거부했습니다.

코딩을 "향상시킬 수 없다"고 생각하는 개발자를 만난 적이 없다고 생각하지만,이 사람들은 당신이 얻을 수있는 한 록 스타와는 거리가 멀다는 것을 알 수 있습니다.

다음은 조언이 아니라 개인 로그입니다.

• 더 적은 전역 변수 사용
• 변수 또는 함수 이름에 약어를 사용하지 마십시오
• [일부] 테스트 코드 작성
• 벤치마킹없이 코드를 느리거나 느리게 판단하지 마십시오
• 앱로드 테스트 방법 알아보기
• 고장 나지 않으면 고치지 마십시오.
• 소스 코드 관리 도구 (git / hg) 사용
• 리팩토링은 시원하며, 테스트 비용을 과소 평가하지 마십시오.
• 보안이 어렵 기 때문에 가능한 빨리 이것을 조심하십시오
• 일부 오픈 소스 프로젝트 버그 패치
• 새로운 블로그
• 유용성은 기능 요청이 아닐 수 있지만 중요합니다.

나는 1 년 안에 모든 것을 배우지 못했습니다. 모든 시간이 걸립니다 ...

종종 사람들은 좋은 코드가 갑자기 발생한다고 생각하지만 대부분의 사람들은 단지 필사자들에게 좋은 코드가 코드베이스에서 자랍니다. 요구 사항이 끊임없이 변하고 완벽한 프로그래머가 아니기 때문에 처음부터 완벽한 소프트웨어를 작성하는 것은 매우 어렵습니다. 따라서 관리자와 프로그래머로부터 바보 같은 결정을 내리지 않습니다. 그런 다음 각 요구 사항이 이전 코드 중 일부를 더 나은 코드로 리팩터링하고 지불해야하는 좋은 기회를 얻는다는 것을 알았습니다. "코드를 커밋 할 때마다 코드 리포지토리를 조금 더 나은 상태로 두십시오"라고 말합니다. 그러면 시스템이 이상적인 시스템으로 발전 할 것입니다.

그의 소프트웨어를 자랑스럽게 생각하지만 좋은 프로그래머는 전혀 없습니다. Than은 프로그래머가 프로세스에서 배운 것을 의미합니다.

또한 "Clean Code"책을 읽으면 자신의 코드 "흡인 계수"를 여러 번 늘릴 수 있습니다. :디

나는 실제로 이것을 위해 동전의 양면을 가지고 있습니다.

한편으로, 오래된 코드를 살펴보면 당시에는 모르는 기술과 언어 기능을 활용하여 간단하게 수행 할 수있는 버그와 복잡한 방법으로 가득하다는 것을 알 수 있습니다.

다른 한편으로, 당신은 문제에 대한 특히 우아한 해결책을 발견하고 당신이 얼마나 영리한 지에 잘난 척하는 미소를 풀어 줄 수 없습니다.

그런 다음 C에서 GOTO를 사용한 사실에 따라 두 줄 아래로 스크롤하고 끔찍한 얼굴을 찌푸립니다.

흠 ... 내 오래된 코드가 얼마나 좋은지에 대해 종종 상당히 즐겁게 놀랍니다.

내가 오늘하고 있다면, 종종 다르게 써야 했지만 시간의 한계에 따라 살아야한다면 확실하지 않을 것입니다. 최소 몇 기가의 RAM을 가진 일반적인 컴퓨터를 믿을 수 있다면 큰 하드 드라이브가 100MB 일 때와는 조금 다르게 코드를 작성할 수 있습니다.

1. 얼마나 자주 이런 일이 발생합니까?

2. 코딩이 실제로 개선되기까지 얼마나 걸립니까? 월, 년?

3. 이전 코드를 다시 방문한 적이 있습니까?

4. 이전 코드는 얼마나 자주 당신을 괴롭히는가? 또는 기술 부채를 얼마나 자주 처리해야합니까?

1. 새로운 것을 배울 때마다 매일 희망이 있습니다.

2. 내가 배운 것을 구현하면 구현 할 때부터 즉시 구현됩니다.

3. 예, (1) 새로운 기능, (2) 버그 수정, (3) 향수, (4) 무언가를 해결 한 방법을 살펴보면 유용 할 수 있습니다.

4. 1과 관련하여, 내가 더 나은 일을하는 방법을 배울 때, 일부 오래된 프로젝트가 더 잘 수행 될 수 있다는 것을 알고 있습니다. 나는 그들을 떠난다. 다음 프로젝트가 더 나은 방법으로 완료되었는지 확인하십시오. 실제 버그가 아니라면 걱정하지 않아도됩니다.

또 다른 질문 에서, 주제는 자신의 코드의 품질을 평가하는 방법에 관한 것이 었습니다. 내 제안 중 하나는 코드를 작성할 때보 다 경험이 훨씬 높은 몇 년 안에 그것을 검토하는 것이 었습니다. 이 다른 질문에 대한 나의 대답 은 귀하의 질문과 직접 ​​관련이 있습니다.

"제 경우에는 수명이 1 년입니다. 즉, 6 개월 전에 작성한 코드를 수정할 수 있지만 2 년 전에 작성된 코드 인 경우 코드가 던져 질 가능성이 높습니다. 너무 빨라요. "

실제로, 내가 작성한 모든 코드 는 일년 내 관점에서 견딜 수 없게됩니다. 그리고 나는 버리기 코드뿐만 아니라 품질, 유지 보수성 및 가독성을 염두에두고 작성한 코드에 대해서도 이야기하고 있습니다. 현재로서는 예외는 없었습니다.

수명에 대한 두 번째 질문에 대답하기 위해, 그것은 많이 다릅니다. 버리기 코드의 수명은 0 초입니다 . 코드를 작성한 직후에 빠지지만 중요하지 않습니다. 필자가 작성한 일부 코드는 2 년 후에 견딜 수 있었지만 약간의 리팩토링, StyleCop 규칙 적용 등과 같은 약간의 외관상의 변화가 필요했습니다. 평균적으로 정확한 경우 평균 수명 은 8 개월에서 1 년 사이 입니다. C # 및 PHP의 경우 6 개월 사이

이전 코드를 다시 방문합니까? 물론 DRY에 신경 쓰지 않고 자신의 바퀴를 다시 발명하지 않는 한 모든 개발자는 물론입니다. 또한 많은 프로젝트에서 사용 하는 공통 코드베이스 가있는 경우 코드를 자주 검토하고 개선 할 수 있습니다 . 또 다른 요점은 거대한 프로젝트에서 작업하는 경우 몇 년이 걸릴 수 있으므로 이전 코드를 다시 방문해야한다는 것입니다.

내가 만난 개발자 중 일부는 이미 코딩이 개선 될 필요가 없거나 더 이상 개선 될 수없는 진화 된 단계에 있다고 주장했다.

어떤 사람이 자신이 아무 것도 배울 필요가 없을 정도로 완벽하다고 말하면, 그녀가 얼마나 멍청한 지 이해할 수조차 없다는 것을 의미합니다.

컴퓨터 / 프로그래밍 분야에서 20 년의 경험이 있어도 상황이 너무 빨리 변하기 때문에 항상 배울 것이 많고 코드를 개선 할 수있는 새로운 기술이 있습니다. 예를 들어, .NET Framework 3.0이 없을 때 작성된 C # 코드는 오늘날의 새로운 기능 (Linq, Code contracts 등)을 통해 더 읽기 쉽고 개선 될 수 있습니다. 가장 똑똑한 개발자가 작성했습니다.

코드를보고 "내가 이것을 작성할 때 무엇을 생각하고 있 었는가?"

때때로 코드를 구성하고, 코드를 꾸미거나 다른 것을 만들어내는 새로운 아이디어가 나에게 올 때마다 항상 개선이 이루어지고 있습니다.

작업 환경에 따라 동일한 코드 기반으로 계속 작업하고 거기에 무엇이 있고 관리해야 할 내용에 대해 잘 알고 있기 때문에 몇 년 전부터 코드가 표시 될 수 있습니다.

오래된 코드는 대개 기존 시스템을 변경하거나 시스템을 교체 할 때 거의 항상 괴롭 힙니다. 두 경우 모두 기존 시스템의 단점을 알아야 새 시스템에 있는지 확인해야합니다.

Jon Skeet과 같이 완벽한 코드를 생각할 수있는 사람들이 있다고 확신하지만 코드를 개선 할 수 없다고 말하는 대부분의 다른 사람들은 자아 시점에서 매력적이지 않을 수 있다고 말합니다. 동시에, 항상 그렇지는 않을 때마다 큰 개선을 찾는 관점에서.

1. 얼마나 자주 이런 일이 발생합니까?

이전 코드에 얼마나 자주 불만이 있습니까? 거의 언제나. 내가 정말 자랑스럽게 생각하는 코드가있는 경우는 드물지만 예외는 있습니다. 몇 년 전에 쓴 코드가 좋았다는 말을 들었습니다. 나는 울부 짖으며 "내가 쓴 쓰레기보다 열등한 가난한 사람을 보았습니다."

2. 코딩이 실제로 개선되기까지 얼마나 걸립니까? 월, 년?

그것은 일반적으로 단계에 있습니다 ... 나는 실제로 스타일이나 방법론에 들어갑니다 (예를 들어 유창한 인터페이스를 취하십시오 ... 마지막으로 젖은 스타일을 가진 마지막 스타일이었습니다). . 그러면 더 좋아 보이기 시작합니다.

3. 오래된 코드를 다시 방문한 적이 있습니까?

내가 원하는만큼 자주 내 이전 코드의 대부분은 이전 고용주가 소유하고 있습니다. 개인 코드는 너무 자주 씻겨집니다.

4. 오래된 코드는 얼마나 자주 당신을 괴롭히는가? 또는 기술 부채를 얼마나 자주 처리해야합니까?

이전 고용주가 이전 코드를 대부분 사용하고 있기 때문에 개인 코드를 대부분 흰색으로 씻습니다.