나는이 통찰력있는 기사를 발견했다.
나는 종종 매년 덜 빠는 것이 겸손한 프로그래머가 향상하는 것이라고 생각했습니다. 1 년 전에 작성한 코드가 마음에 들지 않아야합니다. 그렇지 않은 경우 A) 1 년 동안 아무것도 배우지 않았거나 B) 코드를 개선 할 수 없거나 C) 이전 코드를 다시 방문하지 않는 것입니다. 이 모든 것은 소프트웨어 개발자의 죽음의 키스입니다.
- 얼마나 자주 이런 일이 발생합니까?
- 코딩이 실제로 개선되기까지 얼마나 걸립니까? 월, 년?
- 혹시 다시 방문 마십시오 당신의 오래된 코드를?
- 이전 코드는 얼마나 자주 당신을 괴롭히는가? 또는 기술 부채를 얼마나 자주 처리해야합니까?
기한과 빠른 수정 사항을 신속하게 충족시키기 위해 수행했던 오래된 버그와 더티 코드를 수정하는 것은 확실히 고통 스럽습니다. 경우에 따라 대부분의 응용 프로그램 / 코드를 다시 작성해야 할 수도 있습니다. 그것에 대한 논쟁이 없습니다.
내가 만난 개발자 중 일부는 이미 코딩이 개선 될 필요가 없거나 더 이상 개선 될 수없는 진화 된 단계에 있다고 주장했다 .
- 이런 일이 발생합니까?
- 그렇다면 특정 언어로 몇 년 동안 코딩을했을까요?
관련 :
예전의 코드와 얼굴을 찡그린 고통을 되돌아 본 적이 있습니까?
코드에서 스타 워즈 순간 “루크! 나는 당신의 코드입니다!” “아니요! 불가능합니다! 할 수 없습니다!”
답변
> Sucking Less Every Year ?
아니 , 매년 다른 빨기 🙂
몇 년 전에 첫 리뷰를 한 후 나는 이름 풀림이 없어졌습니다.
그런 다음 코드가 (필수) 가능한 한 일반적으로 구현되었지만 코드를 이해하고 유지하기가 어려워졌습니다.
그런 다음 테스트 중심 개발 인 InversionOfControl을 뛰어 넘었습니다.
결론
오래된 나쁜 habbits의 고통은 줄어 들었지만 내가 더 많이 배웠기 때문에 내가 얻은 새로운 고통으로 과잉 보상되었습니다.
답변
흥미롭게도, 내가 함께 일한 모든 “락스타”프로그래머들은 매우 겸손하고 배우고 싶어했으며 모든 것을 알지 못한다는 것을 인정할 준비가되어있었습니다. 도대체, 많은 사람들은 적어도 마음이 가벼워지는 순간에 실제로 완전히 자멸을 거부했습니다.
코딩을 “향상시킬 수 없다”고 생각하는 개발자를 만난 적이 없다고 생각하지만,이 사람들은 당신이 얻을 수있는 한 록 스타와는 거리가 멀다는 것을 알 수 있습니다.
답변
다음은 조언이 아니라 개인 로그입니다.
- 더 적은 전역 변수 사용
- 변수 또는 함수 이름에 약어를 사용하지 마십시오
- [일부] 테스트 코드 작성
- 벤치마킹없이 코드를 느리거나 느리게 판단하지 마십시오
- 앱로드 테스트 방법 알아보기
- 고장 나지 않으면 고치지 마십시오.
- 소스 코드 관리 도구 (git / hg) 사용
- 리팩토링은 시원하며, 테스트 비용을 과소 평가하지 마십시오.
- 보안이 어렵 기 때문에 가능한 빨리 이것을 조심하십시오
- 일부 오픈 소스 프로젝트 버그 패치
- 새로운 블로그
- 유용성은 기능 요청이 아닐 수 있지만 중요합니다.
나는 1 년 안에 모든 것을 배우지 못했습니다. 모든 시간이 걸립니다 …
답변
종종 사람들은 좋은 코드가 갑자기 발생한다고 생각하지만 대부분의 사람들은 단지 필사자들에게 좋은 코드가 코드베이스에서 자랍니다. 요구 사항이 끊임없이 변하고 완벽한 프로그래머가 아니기 때문에 처음부터 완벽한 소프트웨어를 작성하는 것은 매우 어렵습니다. 따라서 관리자와 프로그래머로부터 바보 같은 결정을 내리지 않습니다. 그런 다음 각 요구 사항이 이전 코드 중 일부를 더 나은 코드로 리팩터링하고 지불해야하는 좋은 기회를 얻는다는 것을 알았습니다. “코드를 커밋 할 때마다 코드 리포지토리를 조금 더 나은 상태로 두십시오”라고 말합니다. 그러면 시스템이 이상적인 시스템으로 발전 할 것입니다.
그의 소프트웨어를 자랑스럽게 생각하지만 좋은 프로그래머는 전혀 없습니다. Than은 프로그래머가 프로세스에서 배운 것을 의미합니다.
또한 “Clean Code”책을 읽으면 자신의 코드 “흡인 계수”를 여러 번 늘릴 수 있습니다. :디
답변
나는 실제로 이것을 위해 동전의 양면을 가지고 있습니다.
한편으로, 오래된 코드를 살펴보면 당시에는 모르는 기술과 언어 기능을 활용하여 간단하게 수행 할 수있는 버그와 복잡한 방법으로 가득하다는 것을 알 수 있습니다.
다른 한편으로, 당신은 문제에 대한 특히 우아한 해결책을 발견하고 당신이 얼마나 영리한 지에 잘난 척하는 미소를 풀어 줄 수 없습니다.
그런 다음 C에서 GOTO를 사용한 사실에 따라 두 줄 아래로 스크롤하고 끔찍한 얼굴을 찌푸립니다.
답변
흠 … 내 오래된 코드가 얼마나 좋은지에 대해 종종 상당히 즐겁게 놀랍니다.
내가 오늘하고 있다면, 종종 다르게 써야 했지만 시간의 한계에 따라 살아야한다면 확실하지 않을 것입니다. 최소 몇 기가의 RAM을 가진 일반적인 컴퓨터를 믿을 수 있다면 큰 하드 드라이브가 100MB 일 때와는 조금 다르게 코드를 작성할 수 있습니다.
답변
얼마나 자주 이런 일이 발생합니까?
코딩이 실제로 개선되기까지 얼마나 걸립니까? 월, 년?
이전 코드를 다시 방문한 적이 있습니까?
이전 코드는 얼마나 자주 당신을 괴롭히는가? 또는 기술 부채를 얼마나 자주 처리해야합니까?
-
새로운 것을 배울 때마다 매일 희망이 있습니다.
-
내가 배운 것을 구현하면 구현 할 때부터 즉시 구현됩니다.
-
예, (1) 새로운 기능, (2) 버그 수정, (3) 향수, (4) 무언가를 해결 한 방법을 살펴보면 유용 할 수 있습니다.
-
1과 관련하여, 내가 더 나은 일을하는 방법을 배울 때, 일부 오래된 프로젝트가 더 잘 수행 될 수 있다는 것을 알고 있습니다. 나는 그들을 떠난다. 다음 프로젝트가 더 나은 방법으로 완료되었는지 확인하십시오. 실제 버그가 아니라면 걱정하지 않아도됩니다.