코드를 작성한 후 얼마 후에“더 나은 글을 썼을 것”이라고 생각하는 이유는 무엇입니까? [닫은]


12

저는 2 년 이상 C ++에서 취미 프로젝트를 진행해 왔습니다. 모듈 / 함수를 작성할 때마다 많은 생각으로 코딩합니다. 이제 문제를보십시오

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

다음 'X'은 모든 모듈입니다 (소형 / 대형 / 중형). 나는 코딩하는 동안 얼마나 많은 노력을 기울이든지 상관없이 이것이 발생한다는 것을 관찰하고 있습니다. 따라서 대부분 작업 코드를 보지 않습니다. :)

이것은 많은 사람들에게 공통된 느낌입니까? 이 언어는 특정 현상입니까? (C ++에서는 동일한 방식으로 다른 방식으로 작성할 수 있습니다).

실제 코드를 리팩토링하는 느낌을 받으면 어떻게해야합니까? 워킹 코드를 변경해도 많은 찬사를 얻지 못하고 오히려 실패하면 문제를 일으킬 수 있습니다.


14
이전 코드에서 문제를 찾지 못하면 더 걱정할 것입니다. 이것은 당신의 기술이 발전하고 있음을 보여줍니다.
대런 영

1
당신은 당신의 예전의 코드를보고 않으면 하지 "나는 그것을하지 않았다 왜 이놈 생각 코드를 쓴 이후 다음 돌아 오는 길에이?!", 당신은 충분히 배운하지 않았습니다.
sbi

답변:


17

이 현상은 매우 일반적이며 프로그래머에게 한정되지 않습니다. - 당신이 지적 작업을 수행 할 때마다, 당신은 당신이 향상 수있는 장소 수십 알 수 일부 거리를 가지고 있습니다. 지금까지 논문을 쓴 어떤 현명한 (WO-) 사람을 물어, 그들은 당신에게 한 가지를 말해주지 ". 그것을 보지 말라 당신은 첫 눈에 오류를 찾을 수 있습니다."

리팩토링 루프를 피하기 위해 기본적으로 두 가지가 있습니다.

  1. 글을 쓰고 디자인하는 동안 가능한 한 멀리 먼 시각을 얻으십시오. 동료에게 디자인 / 코드를 살펴 보도록하십시오. 주말 후에 다시보십시오. 취하거나 높을 때 살펴보십시오 (그러나주의하십시오 : 냉정 할 때까지 아무것도 바꾸지 마십시오 ).
  2. 불완전한 삶. 그것이 예쁘지 않지만 잘 작동하는 경우 (읽기 : 확장 성 및 가독성을 포함한 모든 요구 사항을 충족시키는 데 훌륭한 역할을 함) 완벽한 작업을 위해 노력하지 말고 자신이 한 좋은 일에 만족하십시오.

이것을 읽으십시오. en.wikipedia.org/wiki/Buyer's_remorse 매우 유용합니다.
S.Lott

3

지속적인 리팩토링은 갈 길입니다. 작업 코드를 변경해도 문제가 발생하지 않으며 올바르게 수행하면 권장해야합니다. 코드가 완전히 단위 테스트 된 경우 자신있게 코드를 리팩터링 할 수 있습니다.

실제 프로덕션 코드에 대해 예측할 수있는 유일한 것은 변경입니다. 그것이 어떻게 변할 것인지, 내일 어떤 새로운 기술을 배울 것인지 추측하지 마십시오. 간단히 말해, 코드를 "완벽하게"만들려고하지 마십시오. 현재 지식을 최대한 활용하십시오. 또한 코드가 철저히 테스트되고 확장 가능한지 확인하십시오.

기존 코드를 리팩토링하는 데 20 % -30 %의 시간이 소요됩니다. 저는 기술 회사에서 일하고 있으며 "관리"는 기존 코드 변경에 대해 불평 한 적이 없습니다. 그러나 일부 회사에서는 이것이 문제가 될 수 있음을 알고 있습니다. 마틴 파울러 (Martin Fowler)는 리팩토링 책 에 섹션을 가지고있다 .

요약하면, 그것은 내 경험에서 일반적인 느낌이지만 부정적인 것은 아닙니다.


2

모든 모듈 / 기능은 우선 순위의 세계에서 태어나고 진화합니다. 일단 외부 세계 목표를 달성하기에 충분하면 종종 정체 상태로 남아 있습니다. 그 모든 것이 궁극적으로 더 높은 목적을 위해 서비스를 제공합니다. 그렇습니다. 우리는 코드에 대해 강박 관념이 있어야합니다. 어쩌면 초점을 코드 자체에서 조금 벗어나서 코드 제작자 인 내부에서 진행되는 프로세스에 대해 더 깊이 생각해 보는 것이 좋을 것입니다.


2

이것이 많은 사람들에게 공통적 인 느낌입니까? 이 언어는 특정한 현상입니까?

그것은 당신이 지식과 ​​견해를 넓히고 있음을 의미합니다.

우선 순위가 높은 작업이없는 경우 항상 돌아가서 코드를 개선해야합니다.


"... 돌아가서 코드를 개선하십시오." -누가 당신에게 이것을 지불합니까? 코드가 작동하면 계속 진행하십시오. 프로그래머로서 배우고 성장함에 따라 항상 더 나은 일을하는 방법을 찾고 이전의 노력을 향상시킬 수 있다고 생각할 것입니다. 이전 코드를 되돌아 가고 개선하는 것은 대부분 시간 낭비입니다.
Dawood ibn Kareem

1
@David Wallace-아무도 이전 코드로 돌아 가지 않았다면, 우리는 그것에 대해 소란스럽지 않을 것입니다.
JeffO

1
"코드가 작동하고 나면 계속 진행"-코드가 작동하기 때문에 프로덕션 코드에서 어떤 종류의 버그가 발생했는지는 믿지 못할 것입니다.)
BЈовић

@ Jeff O-그건 사실입니다. 오래된 코드를 유지하려면 내 코드이든 다른 사람이든 코드를 수정하는 것이 좋습니다. 그러나 코드를 유지 해야하는 달러가있는 프로젝트가 없다면 코드 정리에 소요되는 시간을 정당화 할 수있는 방법이 없습니다. 물론 버그가 아닌 한.
Dawood ibn Kareem

@VJovic-프로덕션에 버그가 있으면 코드 DIDN이 작동하지 않기 때문입니다. OP가 올바르게 작동하지만 못생긴 코드에 대해 이야기하고 있다고 생각합니다.
Dawood ibn Kareem

2

나는 항상 사람이 수학 수업을 들으면서 이전 수업의 기술을 강화합니다. 대수학 II를 가져갈 때까지 대수학은 힘들어 보였다. 그런 다음 대수에서 배운 기술이 유용 해졌습니다. 프로그래밍, 작문, 목공 또는 다른 것에서도 마찬가지입니다.

프로그래밍 과정을 밟으면 If-then-else에 대해 배웠습니다. 스위치에 대해 배울 때까지 많은 일을했습니다. 당신이 새로운 것을 배우고있을 때, 여러분은이 진보를 겪습니다.


2

과거에 내가 직접 작성한 대부분의 코드를 읽을 때마다 같은 느낌이 듭니다. 이것은 좋은 것입니다, 그것은 당신의 지식과 코딩 스타일이 수년에 걸쳐 개선되었음을 의미합니다.

작동하는 프로덕션 코드를 변경하는 경우 명백한 버그를 발견하지 않으면 큰 문제가되지 않습니다. 시간 낭비 일뿐만 아니라 생성 된 대부분의 소프트웨어 버그가 릴리스 된 프로그램을 변경할 때 발생하는 버그이기 때문에 더욱 중요합니다. 통계적으로 예기치 않은 버그가 발생할 수 있습니다. 고장 나지 않았다면 고치지 마십시오.


1

응용 프로그램을 개발한다는 것은 응용 프로그램을 개선하고 개선하는 것을 의미합니다. 이것은 지속적인 프로세스이므로 프로그래밍하는 동안 더 많은 경험과 지식을 얻습니다. 또한 개발 중임을 의미하므로 이전 코드를 다시 살펴보면 개선 될 수 있음을 알 수 있습니다.

이 느낌이 없으면 다음 두 가지 중 하나를 의미합니다.

  1. 당신은 여전히 ​​같은 수준의 기술에 있습니다.
  2. 귀하의 코드는 이미 완벽합니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.