크리에이티브 코딩에있어 나쁜 점은 무엇입니까? [닫은]


42

나는 Bob Ross가 오늘 밤에 "행복한 나무"를 그리는 것을보고 있었고 , 최근에 내 코드에 대해 스트레스를 받고있는 것이 무엇인지 알아 냈습니다.

여기와 스택 오버플로에있는 사람들의 커뮤니티는 불완전 함을 거부하는 것처럼 보입니다. 저의 목표는 저의 기술을 향상 시켜서 존경 할만한 (따라서 유지 보수가 가능하고 기능적인) 코드를 작성하는 것입니다. 그러나 나는 창의적으로 코딩합니다.

"크리에이티브 코딩"의 의미를 설명하겠습니다.

  • 프로젝트의 첫 번째 단계는 종종 앉아서 코드를 강타하는 것입니다. 더 큰 것들을 위해, 나는 여기저기서 조금 계획하지만 대부분은 그냥 뛰어 들었습니다.
  • 프로젝트에서 다른 작품을 만드는 다른 사람들과 함께 작업하지 않는 한 수업을 도표로 작성하지 않습니다. 그럼에도 불구하고 그것은 확실히 내가하는 첫 번째 일은 아닙니다. 나는 일반적으로 거대한 프로젝트에서 일하지 않으며 비주얼이 매우 유용하지 않습니다.
  • 내가 작성한 첫 번째 코드는 테스트, 단순화, 재실행 및 원래의 핵을 재사용 가능하고 논리적이며 효율적인 것으로 변환하면서 여러 번 다시 작성됩니다.

이 과정에서 나는 항상 청소하고 있습니다. 사용하지 않는 코드를 제거하고 명확하지 않은 내용은 주석 처리합니다. 나는 끊임없이 테스트합니다.

내 프로세스는 전문 개발자 커뮤니티에서 수용 가능한 것의 결정에 반하는 것으로 보이며 그 이유를 이해하고 싶습니다.

잘못된 코드에 대한 불만은 대부분 전 직원의 혼란에 빠졌으며 해결하는 데 많은 시간과 비용이 소요된다는 것입니다. 이해합니다. 내가 이해하지 못하는 것은 최종 결과가 처음부터 모든 것을 계획 할 때 얻는 것과 비슷하다는 점을 감안할 때 내 프로세스가 어떻게 잘못되었는지입니다. (또는 적어도 내가 찾은 것입니다.)

이 문제에 대한 나의 불안감은 최근에 너무 나빠서 내가 작업하고있는 특정 문제를 해결하기위한 모든 방법에 대한 모든 것이 있다는 것을 알 때까지 코딩을 중단했습니다. 다시 말해서, 나는 대부분 코딩을 중단했습니다.

문제에 대한 의견이 무엇이든 관계없이 의견을 보내 주셔서 감사합니다.

편집 : 답변 주셔서 감사합니다. 나는 그들 각각에게서 무언가를 배웠습니다. 당신은 모두 가장 도움이되었습니다.


6
당신이 일하는 방식에 아무런 문제가 없으며, 최종 결과에서 중요한 것이 무엇인지 알고, 그것이 정말로 중요한 것입니다. 그런 식으로 큰 팀과 일하는 데 어려움을 겪을 수도 있지만, 그럴 경우 적응할 것입니다. 그것은 당신이 분석 마비로 곧장 가고있는 것처럼 들립니다 : sourcemaking.com/antipatterns/analysis-paralysis
Bjarke Freund-Hansen

39
몇 달 동안 다시 작성하면 계획 일수를 절약 할 수 있습니다!
Jonas

3
@ 조나스 : 좋은 하나. 그러나 분석 마비를 과소 평가해서는 안됩니다. 요즘에는 방법론, 디자인 패턴 등에 대한 모든 "좋은 조언"을 통해 한 줄의 코드를 만지기 전에 며칠 동안 며칠 동안 계획, 분석 및 디자인해야한다는 인상을 쉽게 얻을 수 있습니다. . 그리고 그것은 매우 비생산적 일 수 있습니다. 내가 믿는 현실은 계획과 설계가 장기적으로 도움이 될 수있는 것을 이해하고, 작업중인 것에 대해 어떤 느낌을 느끼고 실제로 무언가를하기 위해 언제 뛰어 들어야하는지 이해하는 것입니다.
Bjarke Freund-Hansen

4
애자일 선언문 : "작업 소프트웨어는 진행의 주요 척도입니다."
Gary Rowe

2
마치 프로그래밍 세계가 프리 마돈나로 가득 차있는 것 같습니다. 사용자가 완벽한 영어로 글을 쓰지 않거나 코드가 엘리트가 다루기에는 "너무 초보자"로 간주되기 때문에 SO로 가서 5 번 다운 된 질문을 볼 수 없다는 것이 얼마나 실망 스럽습니다.
Scottie

답변:


29

code-test-refactor-repeat에는 아무런 문제가 없습니다. 프로토 타이핑을 사람들에게 알려주십시오.

다른 한편으로, 더 큰 프로젝트의 경우, 디자인에 대해 약간의 생각을하면 오해의 여지가없는 루프에서 많은 시간을 절약 할 수 있습니다!

추신 : 다이어그램 기술은 시각적 사고 능력을 배우는 데 도움이됩니다.


4
"code-test-refactor-repeat"(또는 일부 순열)는 코드를 작성하는 방법입니다. 어쩌면 슈퍼맨은 "코드 완료"일 수도 있지만 필사자는 반복해야합니다.
Martin Wickman

5
@Martin : 그 루프에서 약간의 솔직한 생각이 ;-) 종종 유리하다
스티븐 A. 로우

4
"일부"가 얼마인지 아는 한!
Frank Shearar

당신의 답변에 감사드립니다. 나는 내가하고있는 일이 프로토 타이핑이라고 생각한 적이 없었지만, 그것이 바로 내가하는 일입니다. 귀하의 답변으로 새로운 것을 볼 수있는 방법을 알려 주었으며 귀하의 답변에 크게 감사드립니다.
Brad

7
@Brad, 때때로 프로토 타입이 진화하는 대신 죽어야한다는 것을 기억하십시오.

21

클래스 / 인터페이스에 "ItemVisitor"(?!)와 같은 패턴 이름이 포함 된 시각적으로 표현 된 UMLed 디자인 패턴 코드에 대해 명확하고 읽기 쉽고 간단한 코드를 항상 선호합니다. 디자인 패턴, OO 기술 및 기타 모든 것은 규칙을 공식화하는 것입니다. 그 규칙은 상식에서 비롯됩니다.

자신의 프로젝트에서 혼자 작업하지 않는 한 공식화없이 작업하는 것은 불가능하며, 과도한 형식화로 인해 프로젝트 비용이 증가합니다. 코드를 이해해야하는 다른 사람의 요구를 무시하지 마십시오. 가장 좋은 코드는 가장 간단한 코드입니다.

주저하지 말고 코드를 다시 작성하십시오. 나는 이것을 위해 X downvotes (X> = 10)를 얻을 것이지만, 대담하게 만들 것입니다 : 코드 재사용은 가장 중요한 것이 아닙니다 .

코딩시작하기 전에 코드가 구현할 사용 사례고려해야합니다 . 소프트웨어를 사용하고 개발하지 않기 때문입니다. 유용성, 유용성 은 가장 중요한 두 가지 목표이며, 누가 소프트웨어를 사용할 것인지는 중요하지 않습니다. 프로젝트의 종속 부분의 다른 개발자 또는 최종 사용자.


4
"코드 재사용이 가장 중요하지 않다"는 +1 때로는 스위스 군용 칼이 필요하고 때로는 메스가 필요합니다.
mu는

귀하의 의견에 감사드립니다. 결과 소프트웨어가 무엇을 사용할 것인지에 관해서는 전체 프로세스에서 분명히 명심해야합니다. 나는 그것이 가장 중요한 부분이라는 데 동의합니다. 코드 재사용성에 대해 언급했습니다.
Brad

"코드 재사용이 가장 중요하지 않다"고 다시 한 번 +1이 아닌 단일 다운 보트
Gary Rowe

"재사용 성"에 중점을 두는 것은 반복하지 말고 중복을 제거하는 초창기 버전이라고 생각합니다.
Rob K

"재사용 전 사용"도 멋진 작은 책으로 만들었습니다 : 97things.oreilly.com/wiki/index.php/…
Lovis

14

나는 거의 같은 방법입니다. 다른 사람들이 자신에게 도움이 된 일에 대해 이야기 할 때 들어주십시오. 그러나 도덕적 명령이 필요한 것처럼 "해야 할 일"을 말하는 사람은 무시하십시오. 당신에게 맞는 것을 찾으면 함께 가십시오. 내말은, 최종 결과가 중요하지 않은가? 당신이가는 길에 누가 정말로 관심이 있습니까?

사람들이 다르다는 것을 기억하십시오 . 좋은 일입니다. 당신을 좋아하게 만드는 사람들의 말을 듣지 말고 다른 사람들을 당신과 같은 사람으로 만들고자하는 충동에 저항하십시오.


무언가를해야한다고 말하는 사람은 그것을 제시 할 충분한 이유가 있어야합니다. 그들이 명확하고 논리적이고 합리적인 이유를 제시 할 수 없다면, 그들의 "해야한다"는 "해야 할 것"이된다.
Tin Man

1
@ 그레그 (Greg)-그래도 여전히 명확하고 논리적 인 이유는 나에게 완전히 비논리적 일 수 있습니다.
Jason Baker

1
+1. 당신이 절대적 으로이 일을해야한다고 말하는 사람은 분명히 잘못입니다. 물론, 다른 사람들 (특히 위대하고 경험이 많은 사람들)을 연구하고 경청해야하며, 열심히 생각하고, 대안적인 접근법 등을 시도하고 비교해야하지만, 결국에는 올바른 것을 찾으십시오. 평범한 사람이 되려면 디자인 프로세스를 따르십시오.하지만 가치가있는 것은 스스로를 신뢰해야합니다.
Joonas Pulakka

+1-나는 개인적으로 다이어그램으로 시작하거나 공식적인 방식으로 할 수 있지만, 공식적인 방식이 나를 위해 일하기 때문입니다. 당신은 사람들에게 더 똑똑하거나 창의적이되도록 가르 칠 수는 없습니다. 그들은 자신의 방식으로 설정된 성인입니다. 당신은 그들을 고용하거나하지 않습니다.
Job

6

당신이 보인다 :

  1. 최상의 접근 방식을 찾기 위해 노력 (실험, 점진적 설계)
  2. 더 깔끔하게 코드를 다시 작성 (리팩토링)
  3. 지속적으로 테스트 작성 (테스트 중심 개발)

당신이하고있는 것은 굉장합니다! 특히 자신이 알아서 (애자일) 프로그래밍 책에서 배우지 않은 경우 완벽하게 올바르게하는 것처럼 보입니다. 이것에는 분명히 더 많은 것이 있지만 가치를 얻었습니다. 코드를 추가하는 동안 디자인을 리팩토링하고 개선하는 것을 잊지 마십시오 . BDUF 가 필요하지 않습니다 .

한 번하나의 작은 기능에 집중하고 각 기능이 완료된 후 릴리스 하는 것을 고려 했습니까 ? 그렇게하면 어려움을 겪고있는 분석 문제에서 벗어날 수 있고 고용주에게 실질적인 진전을 보여줄 수 있습니다.

또한, 당신이 무슨 "전문 개발 공동체"에 대해 이야기하는지 모르겠지만, 만약 당신이 있다면, 그들에게 상아탑으로 돌아가서 작업을 계속할 수 있도록 지시 할 것입니다!


나는 이것에 관해 당신과 완전히 함께합니다.
Eric O Lebigot

4

브래드, 당신은 혼자가 아닙니다. 나는 당신이 묘사 한 것과 똑같은 방식으로 일하는 아주 좋은 프로그래머를 알고 있습니다. :)

코드를 정리하고 효율적이고 읽을 수있게 만드는 방법을 알고 있다면 깨끗하고 효율적인 코드를 미리 작성하는 방법에 대한 감각을 확실히 개발 한 것입니다.

또한 사전에 계획을 세울 수있는 것이 없으며, 미묘한 부분을 발견하는 가장 짧은 경로는 종종 코드를 실행하고 간과 된 세부 사항을 이해하는 것입니다.

나는 당신이 완벽하게 잘하고 있고 당신이 묘사하는 프로그래밍 스타일이 완벽하게 유효하다고 생각합니다.


4

잘 알려진 MIT 책 "컴퓨터 프로그램의 구조와 해석"(일반적으로 "SICP")의 머리말에서 Alan J. Perlis의 인용문으로 위의 답변을 완성 할 가치가 있다고 생각합니다.

모든 컴퓨터 프로그램은 실제 또는 정신적 과정의 모델입니다. 인간의 경험과 사고로 인해 발생하는 이러한 과정은 그 수가 많고, 복잡하며, 부분적으로 만 이해됩니다. 그것들은 우리의 컴퓨터 프로그램에 의해 드물게 우리의 영원한 만족으로 모델화됩니다. 따라서 우리의 프로그램은 신중하게 수작업으로 분리 된 기호 모음, 연동 기능의 모자이크로 구성되어 있지만 계속 진화합니다. 모델에 대한 인식이 깊어지고 확대되고 일반화 될 때까지 변경합니다. 우리는 어려움을 겪습니다. "


잘 넣어. 그것들은 원시적 모델, 휴머니즘 모델, 그리고 프로그래머가 코드 내에서 일어나는 행동에 점점 더 많은 생각을 쏟아 붓는 초인간적 모델입니다.
easymoden00b

3

Good Clever와 Bad Clever가 있습니다.

Good Clever-영리한 코드 라인과 비영리 한 대안 라인의 비율이 높습니다. 20000을 작성하는 데 도움이되는 20 줄의 코드는 매우 우수합니다. 좋은 영리함은 자신을 구하는 일입니다.

Bad Clever-작성된 코드 라인과 코드 라인 간 비율이 낮습니다. 5 줄의 코드를 작성하지 않아도되는 한 줄의 영리한 코드는 Bad Clever입니다. 나쁜 영리는 "구문 자위"에 관한 것입니다.

참고 : 나쁜 영리한 사람은 거의 "나쁜 영리한 사람"이라고 불리지 않습니다. 그것은 종종 "아름다운", "우아한", "간결한"또는 "간결한"이라는 별칭으로 여행 할 것입니다.


1
"아름다운", "우아한", "간결한"또는 "간결한" ..... Ruby on Rails 홈페이지에서 한 번에 이것을 본 것 같습니다. :-D
Brad

1
어쩌면 나일지도 모르지만 LOC를 80 % 줄이면 영리한 가치가 있다고 생각합니다.
재귀

나는 "구문 적 자위"라고 라벨을 붙인 많은 것을 발견했다. 실제로 그것이 그들이 사용하는 언어를 실제로 배우기에는 너무 게으른 것이 문제 일 때 ...
Svish

3

나는 당신이 당신의 작업 흐름을 설명하는 방식으로 자신을 분명히 알 수 있습니다. 그룹 환경에서 작업을 시작했을 때 거의 모든 것이 바뀌 었습니다.

내가 약 8 개월 동안 근무했던 것은 실제로 하나의 프로젝트에서 개발자 팀에서 일한 첫 경험이었습니다. 지금까지 말 그대로 내 전체 경력은 팀워크와 함께 제공되는 모든 것을 처리 할 필요가없는 고독한 늑대 코더였습니다. 그룹에서 일할 때조차도 항상 상당히 사일로 작업했습니다. 저는 MINE 인 프로젝트 나 MINE 인 섹션을 가지고있었습니다. 진정한 협업 팀 작업 환경.

내가 깨달은 주요 내용은 다음과 같습니다. 현재하고있는 일이 피투성이가 아니라면 동료의 다음 두통을 썼을 것입니다. 여기서 볼 수있는 대부분의 "프로세스 지향"불쾌감은 우리 중 많은 사람들이 두통을 가진 동료가 된 사실과 관련이 있습니다. 그리고 대부분의 소프트웨어 프로세스 관리 이론은 그러한 두통을 최소화하는 것과 관련이 있습니다.

따라서 사전에 합의 된 계획을 세우는 것과 같은 것들은 ... 팀을 구성하고 동기화하는 것입니다. 당신이 팀이라면, 당신은 이미 자신과 동기화되어 있기 때문에 실제로는 필요하지 않습니다.


2

창의적인 예술 형식으로 접근하는 데 아무런 문제가 없습니다. 개인적인 이익을 위해 개발하고 있고 당신이하고있는 일이 당신을 위해 일하고 있으며, 즐겁다는 것이 제품 자체만큼이나 최종 결과만큼이나 중요 할 것입니다.

전문적인 작업 환경에서 프로젝트 시간 규모가 약 2-3 주 이하로 짧으면 접근 방식을 빠른 프로토 타이핑이라고하며 향후 작업에 매우 적합합니다.

그러나 더 긴 프로젝트, 심지어 혼자서 작업하는 프로젝트에서도 그러한 접근 방식은 고용주에게 비싼 사치입니다. 초기 아키텍처 설계에 며칠간의 프로젝트 예산을 지출 한 다음 경영진이 사양을 변경하기로 결정한 경우와 비교하여 아키텍처를 테스트하는 것은 일반적으로 시간이 많이 걸리며보다 가치있는 프로그래머 / 아키텍트가되기위한 기술을 개발할 것입니다. 당신의 경력에.


2

두 가지 관점 :

  1. 아무도 그림을 유지할 필요가 없습니다.

  2. Bob Ross가 그림을 그리는 것을 본 사람은 그림이 구조적이라는 것을 알고 있습니다. Bob Ross로부터 한 가지 교훈을 얻으려면 미리 계획하고 체계적인 방식으로 작업하면 프로세스가 매끄럽고 단순 해집니다.


1
밥 로스는 행복한 나무를 그렸다.
Rob K

1

나는 거의 같은 방식으로 코딩합니다. 글을 쓰기 시작하고 패턴이 떠오르는 것을 보면서 리팩터링합니다. 그런 식으로 구석에 자신을 페인트 할 수 있습니다. 앉아서 앉아서 문제를 생각할 때를 알아야하지만 때로는 문제 를 실제로 이해 하기 위해 찌르기 만하면됩니다 .

그러나 나는 이것에 대해 궁금합니다.

여기와 스택 오버플로에있는 사람들의 커뮤니티는 불완전 함을 거부하는 것처럼 보입니다. [..] 저의 프로세스는 전문 개발자 커뮤니티에서 수용 할 수있는 수준에 반하는 것으로 보입니다. 이유를 이해하고 싶습니다.

Stack Overflow의 누군가가 프로세스를 어떻게 수 있습니까? 그리고 "거부"란 무엇을 의미합니까? 당연히, 프로그래밍 커뮤니티에 게시 된 코드는 비판적으로 검토 될 것입니다. 그러나 누군가 코드를 개선 할 수있는 영역을 발견하면 좋은 것일 수 있습니다.

다행히 Stackframe에 질문을 게시 할 때 독자를 존중하지 않고 코드를 정리하고 가능한 가장 간단한 형태로 줄이려고합니다. 모든 의견이 좋은 경우. 당신은 당신이 우편 번호 경우 아는 것은 나쁜, 당신은 알고 당신이 그것을 게시하기 전에 그것의 나쁜, 당신이 그것을 가지고 가면 안된다 사람들이 개인적으로하는 경우 주의 가 그것의 나쁜.


개인적으로 물어 본 질문이나 답변은 언급하지 않았습니다. 질문을 게시하면 가능한 가장 간단한 사례로 분류되며 답변과 동일합니다. 다른 사람들이 질문에 완전하지 않은 코드를 게시하거나 올바른 질문을하는 방법을 잘 모를 때 반복적으로 격추되는 것을 발견했습니다. 질문이 좋은 질문에 가까운 경계선의 경우, 종종 질문을 편집하거나 의견을 추가하여 OP를 올바른 방향으로 밉니다. 나는 그것이 보통 일어나는 일이라고 생각하지 않습니다. [다음 코멘트에서 더 많은 것]
Brad

어쨌든 여기에서 내 질문에 대한 답변을 읽은 후에 커뮤니티를 잘못 읽었으며 완전한 프로젝트에 대한 비판에 대한 비판에 대한 비판이 예상된다고 생각합니다.
Brad

1

나는 또한 당신의 접근 방식을 사용합니다. 오버 엔지니어링의 위험이 줄어들 기 때문에 더 잘 작동합니다.

내가 자주하는 일은 아마도 가능한 최소한의 코드로 문제를 해결하는 것입니다. 이는 대개 불필요하게 종속성이나 다른 디자인 문제를 유발합니다. 그런 다음 작업 코드를 아름다운 코드로 리팩터링합니다.
예를 들어 인터페이스를 간결하게하기 위해 다른 모듈 간의 종속성을 줄이고 모든 모듈이 다른 모듈의 매우 최소한의 추상화에만 의존 할 때까지 어떤 데이터를 보관해야하는지에 대한 생각을합니다. 최종 결정을 연기하고 어떤 모듈이 어떤 책임을 져야하는지 말할 수 있습니다. 추상화를 연기했습니다.
문제를 별개의 책임, 별개의 추상화로 분리하는 데 너무 많은 생각을하는 것은 좋지 않습니다. 그것은 당신이 만든 추상화에 맞게 구현을 구부리 게 할 것입니다. 원하는 결과를 생성하고 유지할 수있는 경우 코드가 작동합니다. 좋은 코드를 통해 구현할 수 있다면 디자인이 작동합니다. 코드가 작동하지 않으면 코드를 변경하십시오. Ergo, 디자인이 작동하지 않으면 디자인도 변경해야합니다. 디자인을 구현 한 후에 만 ​​디자인이 작동하는지 확인할 수 있습니다.

따라서 간단한 스케치를 염두에두면 디자인을 시작하기에 충분합니다. 필요에 따라 재 설계, 추상화 및 리팩터링 합니다 .


1

당신이 프로그래밍에 능숙하다면, 때로는 재미 있어야한다고 생각합니다. 그것은 창조적 인 것을 의미합니다.

분명히 그룹으로 프로그래밍 할 때는 "도덕적"이유가 아니라 적용 할 때 실제적인 표준을 따라야하는 최소한의 표준이 있습니다.

그 외에도, 경계를 조사하여 거기에서 무엇을 찾을 수 있는지 보는 것은 흥미롭고 재미 있습니다. 어셈블리 언어로 Mini를 작업 할 때 한 번의 명령으로 서로 전환 할 수있는 공동 루틴을 만들 수 있다는 것을 알게되었습니다. 그런 다음 2 단계 앞으로, 1 단계 뒤로 이동할 수있는 자체 공동 루틴을 만드는 방법을 알아 냈습니다. 유용 했습니까? 나는 그것을 의심한다. 요점은 그것이 아니다.

Edsger Dijkstra가 프로그래밍의 창의성에 대해 이야기하는 것을 들었습니다. 그는 한 학생이 n + m 비트 단어의 n 비트 회전을 수행하는 방법을 어떻게 찾았는지 언급했습니다. 3 비트 스왑으로 완료되었습니다. 먼저 n 비트를 교환 한 다음 m 비트를 교환 한 다음 전체 n + m 비트를 교환합니다. 유능한? 아뇨, 영리합니까? 예.

올바른 마음으로 아무도 할 수없는 일을 자유롭게 시도하는 것이 좋습니다.


1

"하나의 크기가 모두 맞지 않는"경우 일 수 있습니다. 당신은 당신의 프로젝트를 위해 당신의 스타일 작업을 만들었습니다. 그래서 누가 그것을 논쟁해야합니까? 그러나 여기서 읽고있는 비평가들은 더 큰 프로젝트 나 팀 구성원 간의 복잡한 조정이 필요한 프로젝트에서 작업하고있을 수 있습니다.

여러 개발자 간의 협력이 포함 된 대규모 프로젝트에 참여한 경우 개발 스타일이 문제가 될 수 있습니다. 일정을 세우는 것은 어렵고, 진행 상황을 추적하기도 어렵고, 동료 프로그래머가 자신의 작업이 무엇인지 아는 것에 의존하는 작업의 비트를 계획 할 방법이 없습니다.

큰 프로젝트가 자신과 비슷한 개발 스타일을 채택 할 때 발생할 수있는 일을 알아 보려면 Dreaming in Code 를 읽으십시오 .


1
당신의 답변에 감사드립니다. 귀하의 의견은 저에게 도움이됩니다.
Brad

1

귀하의 방법이 잘못되지 않았다는 많은 확신이 있지만 개인적인 경험을 추가하겠습니다. 나는 당신의 길을 시작했지만 그 동안 나는 일반적인 구조의 적어도 일부를 미리 계획의 이점을 배웠습니다.

  • 가장 큰 장점은 약간의 코드 작업을 통해 재사용 할 수있는 코드를 쉽게 확인할 수 있다는 것입니다. 필자는 종종 글을 쓰는 동안 화면 옆에 매달려있는 일반적인 구성표의 다른 부분에 갑자기 유용하게 보이는 코드 조각을 작성합니다 (종이에 읽기 전용 스타일로 그려 짐).

  • 체계가 있으면 코드뿐만 아니라 체계도 리팩토링 할 수 있습니다. 때때로 나는 계획의 다른 부분에도 갑자기 유용한 클래스를 작성하는 데 바쁩니다. 결과적으로 프로젝트가 실행될 때 계획이 더 단순 해집니다.

  • 필요한 입력 및 주어진 함수 / 메소드 출력 및 클래스의 사용 가능한 슬롯으로 해당 구성표를 업데이트 할 때마다. 이것은 비트를 재사용하기 위해 더 빠릅니다. 코드가 정확히 들어가고 나가는 것을 확인할 때마다 코드에서 다이빙 할 필요가 없습니다. 댓글에 있어도 댓글을 올리려면 찾아봐야합니다.

실제로, 나는 당신의 방법도 사용합니다. 나는 시작하고, 시도하고, 리팩토링하고, 다시 시도하고, 다른 비트를 변경하는 등의 작업을 수행하지만 사이클에는 구성표도 포함됩니다. 그리고 완료되면 해당 코드에서 작동하는 다음 정보를 추가합니다.

내가 혼자 일하는 프로젝트를위한 것입니다. 동일한 코드에서 더 많은 사람들과 함께 일하는 경우 미리 계획하는 것이 논리 일뿐만 아니라 필수적입니다. 하지만 이미 알고 계신 것 같습니다.

그리고 다른 사람들이 말했듯이 : 이것은 나의 길이며, 마일리지는 다를 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.