코딩 및 유지 보수 중 메모, 생각, 알고리즘, 결정 사항을 기록하는 것이 정상적 / 허용 가능한가? [닫은]

22

휴무 . 이 질문은 의견 기반 입니다. 현재 답변을받지 않습니다.

이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 사실과 인용으로 답변 할 수 있도록 질문을 업데이트하십시오 .

휴일 삼년 전에 .

어떤 사람들은 말 없이는 생각할 수없는이 문제가 있습니다. 그리고 그들의 생각과 결정을 적는 것이 가장 효과적인 방법입니다.

따라서 코딩하는 동안 메모장 ++ 파일에 생각과 결정을 적어 두는 것이 일반적이며 수용 가능합니까?

예를 들어 기술 문서를 다시 작성하거나 더 복잡한 알고리즘에 대한 추론을 할 때 허용되는 경우도 있지만 설계 옵션을 고려하고 판단하려고 할 때 이상 할 수 있습니다.

이 관행이 생산성에 미치는 영향은 명확하지 않습니다. 한편으로는 내면의 단어를 사용한 추론이 글을 쓰는 단어보다 빠를 수 있습니다. 다른 측면에서-더 복잡한 문제는 쓰기가 필요합니다. 게다가, 더 많은 디자인 옵션을 고수하면 결정이 내려 질 때 느낌이 좋아져 사기가 높아집니다.

— 씨에게
소스

5

나는 또한 이것을하는 경향이 있으며, 그렇지 않으면 일반적으로 후회합니다. 나중에 어떤 방법으로 무언가를했는지 기억하거나 나중에 터널 비전으로 팔꿈치에 닿지 않을 때 결정을 내릴 수 있도록 나중에 다시 살펴 보는 것이 도움이됩니다. 내가 적어 놓은 것을 잊었을 때 나는 보통 이유를 잊어 버린 다음 단계를 다시 추적하는 데 더 많은 시간을 보냅니다.

— PseudoPsyche

21

문맥의 일부가 빠진 것 같은 느낌이 드나요? 이 관찰은 효율성에 대한 불만에 관한 것이 었습니까? 종종 비판에는 관련이 있거나 없을 수있는 근본 원인에 대한 제안이 있습니다.

— Jim Rush

9

"코멘트 및 문서"는 소스 코드에 기록하여 보관해야합니다. 디자인 옵션을 고려 하는 것에 대한 당신의 생각은 기록 될 수 있지만 일반적으로 유지되지는 않습니다. 나중에 도움이되지 않을 것입니다. (소스 코드 자체에서 명확하지 않은 경우, 그 사고 과정의 결과에 대해 기록 할 수 있지만 그것은 당신이 요구 한 것이 아닙니다). 전자 양식, 연필 및 종이 양식을 선호하거나 머리 속 에서이 작업을 수행 할 수 있다면 다른 사람이 아니라 자신에게 가장 적합한 것을 말할 수 있습니다.

— Doc Brown

4

... PS : 저는 일반적으로 연필과 종이, 또는 화이트 보드를 선호하며,이 모든 것을 머리에하려고하면 더 좋은 프로그래머가되지 않을 것이라고 생각합니다.

— Doc Brown

7

왜 허용되지 않습니까? 누구에게 허용됩니까?

— Paul D. Waite

62

정상일뿐만 아니라 좋은 생각입니다.

유명한 인용문이 있습니다

"나무를 자르려면 6 시간을 줘라. 그러면 도끼를 깎는 첫 4 시간을 보내겠다."

코딩하기 전에 시간을내어 생각을 정리하고 작업을 계획하는 데 많은 시간이 소요됩니다. 이러한 생각을 종이에 적어두면 계획을 숙고하고 비평하며 "머리 만"하면 매우 어려운 방식으로 계획을 정리할 시간을 갖게됩니다.

— 댄 피첼 먼
소스

8

잘못된 속성을 제거하지만 좋은 인용입니다. quoteinvestigator.com/tag/abraham-lincoln

— Paul Draper

1

분명히 진정한 진술과 좋은 인용이지만, 이해하기에는 그 질문에 다른 초점이 있습니다. 내가 이해하는 한 OP는 미리 계획의 중요성에 대해 의심의 여지가 없습니다. 그는 이러한 생각 / 계획을 작성하는 것이 더 효율적인지 아니면 모든 것을 그의 머리 속에 만 두는 것이 더 효율적인지 묻고 있습니다.

— Doc Brown

2

한 시간 동안 선명하게하는 것만으로 충분합니다. 이 작업은 최대 3 시간으로 추정 되었으나 이완은 무의미한 과잉 준비에 소비되었습니다. 다시 도덕이 무엇입니까? ;-)

— Steve Jessop

26

예, 이것은 완벽하게 허용되며 정상입니다.

의사 결정 프로세스를 문서화하면 코드를 다시 방문 할 때 코드가 특정 방식으로 작성된 이유를 파악하는 데 도움이되는 경우가 종종 있습니다.

이 메모는 코드에 주석으로 직접 포함될 수 있습니다. 확장 된 주석은 종종 외부 기술 설계 문서의 일부로 유지됩니다.

— mcknz
소스

4

디자인 옵션을 고려 하고 소스 코드에서 주석으로 판단하려고하는 것에 대한 메모를 포함 하지 않는 것이 좋습니다 . 그 사고 과정의 최종 결과 만 있지만 OP가 요구 한 것과는 상당히 다릅니다.

— Doc Brown

3

나는 종종 "우리가 왜이 결정을 내렸는가"에 따라 토론을합니다. 우리가 논의한 대안을 포함하여 컨텍스트를 제공하기 위해 일일 프로젝트 노트로 돌아가는 것이 매우 도움이됩니다. 나는 내가 좋은 회사에 있다고 생각합니다. The Everything Store 에 따르면 Jeff Bezos도 마찬가지입니다.

— kdgregory

8

@DocBrown-때로는 다른 가능한 방법 / 알고리즘을 사용 하지 않은 이유를 포함하는 것이 좋습니다. 따라서 미래 개발자가 수행 한 작업을 대체하지 않을 것입니다.

— HorusKol

1

@HorusKol : 드문 경우이지만 사소한 상식입니다. 그러나 그것은 "의사 결정 과정 문서화" 와는 상당히 다릅니다 .

— Doc Brown

1

@DocBrown 오른쪽, 아무도 소스 코드에 메모 페이지를 원한다고 생각하지 않습니다. :)

— mcknz

20

좋은 생각이야 미루는 방법이 될 때까지

열쇠는 균형입니다. 나는 내 자신을 상자에 넣지 않고 그들이 올 때 아이디어를 포착하면 가장 생산적이라고 생각합니다.

낮은 수준에서 연삭하고 높은 수준의 아이디어가 나오면 그냥 적어두고 나중에 다시 돌아옵니다.

일을 계획하는 것은 좋은 생각이지만 관중들 앞에서 의사 소통을하거나 발표하지 않으면 최고의 도구는 펜과 냅킨입니다. 아이디어를 포착하십시오. 예쁘게 만드는 데 시간을 낭비하지 마십시오.

— 설탕에 절인 _ 오렌지
소스

마크 다운은 이러한 메모를 작성하는 또 다른 좋은 방법입니다. 키보드에 손을 대면 사고 과정에 방해가되지 않습니다.

— RubberDuck

1

에디터를 시작하거나 펜과 냅킨을 잡는 것이 더 나은 대안은 전적으로 개인의 터치 타이핑 및 필기 기술에 달려 있습니다. 나를 위해 더 나은 해결책은 분명히 편집기입니다.

— cmaster

9

모든 전문적인 상황에서, 그것은 "정상적이고 수용 가능"할뿐만 아니라 필수입니다. 일반적인 개발주기는 코딩이 시작되기 전에 두 가지 문서화 단계로 구성됩니다.

기능 요구 사항 문서 : 일반적으로 비즈니스 분석가가 작성하고 구현할 기능을 지정합니다.
상세 설계 문서 : 꽤 많이 당신이, 알고리즘 등 내 (매우) 오래된 것들의 일부를 시스템의 기능 분해 (인수)를 지정, 단지 형식적인, 무슨 말을하는지입니다, 온라인 예이다 이 .

덜 공식적인 문서의 경우, 110 %는 인라인 주석에 대한 이전의 언급에 동의합니다. 이것이 유일한 길입니다. 어떤 식 으로든 다른 모든 것은 결국 없어집니다. 그러나 깔끔하고 사려 깊은 인라인 주석은 다른 기술과 마찬가지로 노력과 연습을 통해 개발 된 별도의 코딩 기술입니다. 예를 들어 this 에서 내 (매우) 오래된 것들을 볼 수 있습니다 . 그 스타일은 당신에게 호소력이 있거나 그렇지 않을 수 있습니다. 먼저 원하는 스타일로 잘 작성된 코드를 찾아서 자신의 코드로 에뮬레이션하는 것이 좋습니다. 잠시 후, 적합하다고 생각되는대로 조정하십시오.

— 존 포코 쉬
소스

4

이러한 종류의 정보를 넣을 수있는 좋은 장소는 버전 제어 시스템 (SVN, git 등)의 커밋 메시지에 직접 있습니다. 이렇게하면 같은 장소에서 변경 사항과 추론을 볼 수 있습니다.

— 데릭
소스

1

또한 검색 가능합니다. 예를 들어 커맨드 라인 git 및 sourcetree에서 커밋 메시지를 검색 할 수 있습니다. 메모장을 사용하는 경우 파일을 다시 열지 않으며 광범위한 bash를 모르고 모든 관련 장소를 검색하는 스크립트를 작성하지 않으면 검색하기가 어렵습니다.

— 희망적으로도 도움이 됨

커밋 문과 커밋 링크가있는 버그 또는 기능 요청 에서이 작업을 수행하려고합니다. 또한 코드를 변경 한 이유와 함께 코드에 날짜가 표시된 인라인 주석을 작성합니다. 이것은 주석이 거의 알려지지 않은 삐걱 거리는 오래된 코드베이스에서 극적으로 도움이됩니다.

— delliottg

아니요, 이것은 다른 것입니다. 커밋 메시지는 이유가 아니라 수행 된 내용을 설명해야합니다. 그 이유는 문서화 코드 주석, 함께 제공되는 문서 및 문제 추적기 해결에 포함됩니다. 커밋 메시지에 5 페이지의 노트와 디자인 작업을 넣거나 할 수 없습니다.

— Monica와의 가벼움 경주

버전 관리 시스템에 두는 것이 좋습니다. 더 좋은 곳은 내부에 일반 텍스트 파일입니다. 커밋 메시지보다 사용하기 쉽습니다.

— Thorbjørn Ravn Andersen 님이

2

다른 좋은 답변 외에도, 내가하려는 일에 대한 생각을 자주 적어 놓는다.

내가하려는 일을 명확하게 표현하면 필연적으로 요구되지 않는 가정, 가정 및 / 또는 요구 사항을 실현할 수 있습니다.

그런 다음 대안을 암시하고 차례로 대안을 제시합니다. 다른 글을 생각하면 저의 자리를 구하는 데 도움이되는 글입니다.

호흡과 심도를 탐색하기 위해 빠른 메모를 작성하므로 재귀 적으로 작동하여 솔루션 트리를 정교화하고 탐색하고 평가하여 백업, 탐색, 발견, 실현 및 결정을 도와줍니다.

— 에릭 아이 트
소스

1

당신 / / (새로운) 팀원의 시간을 절약 할 수있는 모든 것을 적어 두는 것은 시간이 잘 소요됩니다. 누군가가 나중에 필요할 수도 있고 실제 장기 프로젝트가 아니라면 지나치게 생각하지 않아야합니다.

또한 시간이 걸리지 않아야합니다. 생각하는 데 시간을 투자하면 생각을 1 대 1로 적을 수 있습니다 (사람에게 유용 할 수있는 한).

실제 문제는 당신이 쓰는 것을 지나치게 생각할 수 있습니다. 당신이 글을 쓰고 있다고해서 이미 존재하는 형식을 고수해야하거나 완전한 문서를 작성해야하는 것은 아닙니다.

아무 것도 쓰지 않고 메모장에 비공식 메모를 쓰는 것 중에서 선택하는 경우 비공식 메모를 작성하십시오.

— 희망적으로
소스

1

"어떤 사람들은 말 없이는 생각할 수없는이 문제가 있습니다. 그리고 그들의 생각과 결정을 적는 것이 가장 효과적인 방법입니다."

당신의 생각과 결정을 기록하는 것이 가장 효과적인 방법이라면, 왜 가장 효과적인 방법으로 진행하는 것이 일반적이지 않습니까? 당신은 당신에게 가장 잘 맞는 일을합니다. 다른 사람에게 가장 적합한 것이 아닐 수도 있습니다. 이 경우 다른 사람이 자신에게 가장 적합한 것을 말하지 못하게하고 자신에게 가장 적합한 것을 말하지 않습니다. 모든 사람이 최선을 다합니다.

— gnasher729
소스

1

인간은 머리에 한 번에 약 7 개의 "사물"만 담을 수 있습니다. 이것이 7 자리 전화 번호의 이유입니다. 프로그래머가 효율적으로 작업하려면 메모리에서 항목을 오프로드하고 필요에 따라 나중에 신속하게 검색 할 수있는 시스템을 찾아야합니다. 메모를하는 것은 분명하고 직접적인 방법이지만, 어느 정도 복잡한 작업을하는 모든 사람은 어떻게 든 해야합니다 . 프로그램을 다른 사람과 페어링 할 때는 해당 방법을 찾아야합니다.

일반적인 방법 중 하나는 테스트 중심 개발입니다. 이 방법론에서는 하나의 실패한 테스트를 작성하고, 실패한 테스트를 통과하기에 충분한 코드 만 작성한 다음, 기존의 모든 테스트를 계속 통과하면서 코드를 더 멋지게 보이도록 리팩토링합니다. 이 방법론은 모든 "노트"를 테스트 내에서 인코딩 된 상태로 유지합니다. 사람들은 다음 시험에 중점을두기 때문에 메모를하지 않고이 방법으로 매우 빠르게 작업 할 수 있습니다.

또 다른 일반적인 방법은 코드에 의사 코드 주석 또는 스텁으로 메모를 작성한 다음 점진적으로 실제 항목으로 대체하는 것입니다. 이것이 내가 보통 알고리즘을 쓰는 방법입니다. 첫 번째 초안은 의사 코드의 주요 기능 일뿐 아니라 점차적으로 더 깊이있는 추상화 수준으로 채워집니다.

어떤 방법을 사용하든 나쁘지 않지만 "효율적인"동료들이 어떤 방법을 사용하는지 알아보십시오. 그들은 당신과 같은 인간의 한계가 있습니다.

— 칼 빌레펠트
소스

1

TDD는 필기 운동입니까? 나는 그렇게 생각하지 않습니다.

— Robert Harvey