우연의 일치로 프로그래밍을 극복하는 방법? [닫은]

The Pragmatic Programmer 책 에서 작가 는 우연의 개념에 의한 프로그래밍을 언급합니다 . 그것은 그것이 무엇인지, 왜 발생했는지, 당신이 겪을 수있는 위험이 무엇인지 설명하고 전쟁에서 지뢰밭과 비교합니다.

오래된 흑백 전쟁 영화를 본 적이 있습니까? 피곤한 병사는 솔에서 조심스럽게 전진합니다. 지뢰가 있습니까? 지뢰가 있습니까, 아니면 교차해도 안전합니까? 표지판, 철조망 또는 분화구가없는 지뢰밭이라는 징후는 없습니다. 군인은 총검과 함께 승리를 앞두고 땅을 찌르며 폭발을 예상했다. 없어요 그래서 그는 잠시 동안 들판을 헤쳐나 가며 뛰면서 찌르고 찌르는 소리를냅니다. 결국, 그는 현장이 안전하다는 것을 확신하고 똑바로 펴고 자랑스럽게 앞으로 나아갔습니다.

군인의 초기 광산 조사는 아무 것도 공개하지 않았지만 이것은 운이 좋았습니다. 그는 비참한 결과와 함께 잘못된 결론을 내 렸습니다.

개발자로서 우리는 지뢰밭에서도 일합니다. 매일 우리를 잡기 위해 기다리는 수백 개의 함정이 있습니다. 군인의 이야기를 기억하면서 우리는 잘못된 결론을 이끌어내는 것에주의해야합니다. 우연히 프로그래밍에 찬성하여 운과 우연한 성공에 의존하는 우연의 일치로 프로그래밍을 피해야합니다 ...

그러나 나는 그들이 "어떻게 극복 하는가"문제를 묘사하는 방식에 대해 정말로 만족하지 않습니다. 예, 코드를 작성하기 전에 미리 생각해야하지만 어떻게 연습해야합니까? 내가 생각할 수있는 유일한 것은 기존의 오픈 소스 프로젝트에 기능을 추가하는 것입니다. "지금하고있는 작업"과 "다른 코드가 어떻게 작동하는지"에 대한 지식이 있어야합니다. 자신의 프로젝트를 작성할 때

편집하다:

귀하의 게시물 요약 :

• 다음 행동을 추측하지 말고 그것이 올바른지 증명하십시오
• 필요한 경우 단위 테스트 및 리팩토링
• 기능 추가 – 컴파일 – 테스트
• 코드를 멍청한 짓으로 설명 할 수 없다면 우연의 일치로 프로그래밍했을 것입니다.

BTW, 대답을 받아들이 기가 어렵습니다. 정말 어렵습니다. 모든 답변은 정말 좋습니다 :)

미리 생각할 필요는없고, 수행 한 작업에 대해 매우 명확하고, 현재하고있는 작업에 대해 매우 명확해야합니다.

서브 루틴은 자신이하는 일을 말하고 행동을하고 숨겨진 의존성을 갖지 않아야합니다. 그런 다음 누군가 전화하면 자신이 무엇을하는지 더 쉽게 추론 할 수 있습니다.

글로벌 상태를 피하십시오. (변수, 싱글 톤 등) 상황을 이해하기 위해 머릿속에 있어야 할 상태가 많을수록 발생하는 상황을 이해하고 가장 중요한 사례를 찾는 것이 더 어렵습니다.

단위 테스트를 작성하십시오. 단위 테스트는 찾고자하는 이상적인 동작이 아니라 방금 작성한 코드의 실제 동작을 캡처하는 데 유용합니다.

편집 / 컴파일 / 테스트주기를 단축하십시오. 큰 코드를 추가하고 테스트를 제대로 수행하지 않으면 생각과 다르게 동작 할 가능성이 있습니다. 그런 다음 임의의 변경 사항으로 "수정"하면 현재 정답을 얻었지만 실제로 어떻게 발생했는지 전혀 모릅니다. 우연의 일치로 프로그래밍하고 있습니다. 그러나 5 줄을 추가하고 테스트 할 때 그것이 효과가 있다고 생각하는 것처럼 작동하기 때문에 정답을 얻을 확률이 훨씬 좋습니다. 경험을 통해 개별적으로 테스트 한 10 줄의 5 덩어리는 한 번에 50 줄의 코드와 매우 다른 짐승이라고 말할 수 있습니다.

무자비하게 리팩터링하십시오. 여러 번 나는 코드를 다소 단순하게 만들고 싶지 않은 많은 일을하는 리 팩터를 발견했다. 이러한 리 팩터를 고의적으로 우선적으로 다루기 시작한 후, 보통 한 달 안에 그 자체로 보상을 받는다는 것을 알게되었습니다. 그러나 핵심에 초점을 둔 리 팩터는 일상 생활을 더 단순하게 만드는 요소이며, 더 나은 또는 더 일반적인 임의의 미학을 충족시키는 것은 아닙니다. 내가 배운 그 리 팩터는 훨씬 더 조심 스러웠다.

이 중 어느 것도 사전 계획이 필요하지 않습니다. 그러나 모두 기존 코드를 이해하기 쉽기 때문에 의도적으로 다음 작은 청크를 쉽게 구현할 수 있습니다.

그것은 추측하지 않기 위해 거의 비등합니다 . 대부분의 새로운 프로그래머가 그렇게하지만, 재향 군인이 연구 시간을 절약한다고 생각하기 때문에 베테랑도 그렇게합니다. 당신이 추가, 그래서 뭔가,하지 작업을 수행 +1하거나를 -1하는 변경 trueA를 false, 일부 문장의 순서를 변경하거나 그 반대의 경우도 마찬가지 추가하거나 작동 할 때까지 변경 지연, 변경 스레드 우선 순위 및 기타 소형 변환은 기본적으로 무작위 순열을 테스트.

이는 기존 코드 변경에 주로 적용되지만, 처음부터 시작하는 사람이 없기 때문에 새로운 코드의 요소이기도합니다. 항상 표준 라이브러리, 운영 체제 또는 최소한 프로세서 아키텍처를 기반으로 구축하고 있습니다.

다시 말해, 수정이 작동하는 이유 를 알 때까지는 완료되지 않습니다 . 가는 길은 그리 중요하지 않습니다. 임의 순열조차도 나중에 "자신을 거짓으로 변경하면 문제를 해결하는 데 시간이 걸리지 만 진단하기 어려운 버그를 좁히는 데 도움이 될 수 있습니다. 왜 그렇습니까?"

내가 프로그램에서 만난 가장 무서운 의견은

만지지 마십시오. 작동합니다. 우리는 방법과 이유를 모르지만 작동합니다. ¹

그리고 코드 조각이 우연의 일치에 의한 프로그래밍 의 결과라는 것을 인정하기 때문에 무섭습니다 .

우연에 의한 프로그래밍을 피하려면 코드가 무엇을 하고 왜 작동 하는지 정확히 동료 (자신 또는 고무 오리에게 ) 설명 해야합니다. 프로그래밍을위한 총알은 의도적으로 코드를 설명 할 수있는 목표를 향해 나아가는 데 도움이됩니다.

¹ 컨텍스트의 경우이 주석은 기본 OS에서 컨텍스트 전환을 처리하는 코드에 나타납니다. 내가 만났을 때 코드는 이미 몇 년 동안 생산되었습니다.

새로운 프로그래머에게는이를 극복하는 데있어 가장 중요한 부분은 그들이하는 일을 실제로 이해하는 것입니다.

많은 영역에서 무언가를하는 방법을 모른다면 시행 착오를 겪습니다. 무언가를 시도하십시오; 그것이 작동한다면, 그렇지 않으면, 다른 것을 시도하십시오.

프로그래밍에서, 특히 C 또는 C ++와 같이 정의되지 않은 동작 개념이있는 언어를 사용하는 경우 성공은 더 이상 부울 결정이 아니기 때문에이 방법은 효과가 없습니다. "일종의"작동, 때로는 작동하는 입력, 일부 입력에는 작동하지만 다른 입력에는 작동하지 않는 것을 가질 수 있습니다.

나는 때때로 새로운 프로그래머들을지도했고, 무작위로 입력하는 것이 일반적인지 알아보기 위해 노력했다. 그들은 줄을 입력 한 다음 나에게 물었습니다. "이런 식으로 작동할까요?" 그들이 할 수 있는지 전혀 단서가 없다는 것이 분명했습니다.

테이크 아웃은 새로운 프로그래머로서 코드의 기능을 설명 할 수 있어야한다는 것입니다. 코드를 작성하는 것만이 아니라 코드를 읽는 법을 배워야합니다.

(물론 이는 노련한 프로그래머에게도 적용되지만, 여기에서의 나의 경험은 대부분 새로운 초보자들에게있었습니다.)

"레이싱 라인에서"코딩, 테스트 및 수정이 너무 쉽습니다. X & Y를 제공하고 Z를 생성하는 기능이 있습니다. 그러나 X가 손상되어 Y를 사용할 수 없으면 어떻게됩니까? Z를 출력 할 수 없으면 어떻게합니까? 무엇이 잘못 될 수 있는지 지속적으로 염두에두고 테스트주기 동안이를 기록하십시오.

최고의 코드는 주석이 거의 필요하지 않습니다.

의미있는 메소드, 클래스 및 변수 이름은 가독성을 높이는 데 큰 도움이됩니다.

코드 냄새가 나면 STOP. 그 냄새는 사라질 것 같지 않으며 조금만 노력하면 나중에 큰 슬픔을 덜 수 있습니다.

개발 프로세스 내에 테스트를 포함시킵니다. 나는 TDD 대신 BDD 의 사용을 옹호합니다. 왜냐하면 당신에게 잘못된 보안 감각을 줄 수있는 테스트 뗏목에 맹목적으로 의존하기보다는 달성하려는 목표를 설명하도록 강요하기 때문입니다.

더 멋진 기능을 추가하려는 충동을 물 리치십시오 (자신의 애완 동물 프로젝트가 아닌 한). 추가 코드는 설계, 작성, 테스트 및 유지 관리해야합니다. 클라이언트 / 비즈니스에 필요하지 않은 경우 리소스가 크게 소모 될 위험이 있습니다.