코드를 작성할 수는 있지만 잘 디자인 할 수는 없습니다. 어떤 제안? [닫은]

나는 비트와 조각으로 코드를 작성하는 데 능숙하다고 생각하지만 내 디자인은 정말 짜증납니다. 문제는 디자인을 어떻게 개선하고 더 나은 디자이너가 되는가입니다.

학교와 대학은 수학적 문제 해결에 능숙 해지는 방법을 사람들에게 가르치는 데 많은 도움이되지만 학교에서 만든 대부분의 응용 프로그램은 일반적으로 약 1000-2000 줄 정도의 길이라는 사실을 인정합니다. 실제 소프트웨어의 복잡성은 수십만에서 수백만 줄의 코드로 반영되지 않습니다.

이것은 topcoder / project euler와 같은 프로젝트조차도 큰 도움이되지 않을 것이라고 생각합니다. 수학적 문제 해결 능력을 향상시킬 수는 있지만 학업 프로그래머가 될 수 있습니다. 멋지고 깨끗한 물건에 더 관심이 있고 대부분의 응용 프로그램 프로그래머가 다루는 일상적인 평범하고 털이 많은 물건에 전혀 관심이없는 사람.

제 질문은 디자인 기술을 어떻게 향상 시키는가입니다. 즉, 수천 줄의 코드로 들어가는 중소 규모의 응용 프로그램을 설계 할 수 있습니까? 더 나은 HTML 편집기 키트 또는 김프와 같은 일부 그래픽 프로그램을 빌드하는 데 도움이되는 디자인 기술을 어떻게 배울 수 있습니까?

무언가를 정말로 잘하는 유일한 방법은 시도, 눈부신 실패, 다시 시도, 이전보다 조금 덜 실패한 후 시간이 지남에 따라 실패의 원인을 인식하여 나중에 실패 가능성을 관리 할 수있는 경험을 개발하는 것입니다. 소프트웨어 개발의 모든 측면을 배우기 때문에 좋아하는 1 인칭 슈팅 게임에서 악기 연주, 자동차 운전 또는 심각한 PWN 나이를 배우는 것도 마찬가지입니다.

실제 지름길은 없지만 경험을 쌓는 동안 문제가 발생하지 않도록 할 수있는 방법이 있습니다.

• 좋은 멘토를 찾으십시오 . 이미 회비를 지불 한 사람과 문제에 대해 이야기하는 것보다 더 좋은 것은 없습니다. 지도는 빠른 학습을 돕는 훌륭한 방법입니다.
• 읽고 , 더 읽고 , 읽고있는 것을 연습하고, 경력 전체에 걸쳐 반복하십시오. 나는 20 년 이상이 일을 해왔으며, 매일 새로운 것을 배우기 시작합니다. 초기 설계뿐만 아니라 새로운 설계, 테스트, 모범 사례, 프로세스 및 방법론에 대해서도 배우십시오. 모두 디자인이 어떻게 등장하고, 형태를 취하며, 시간이 지남에 따라 지속되는 방식에 다양한 영향을 미칩니다.
• 어설프게 시간을 찾으십시오 . 직장을 통해 스 unk 크 워크 프로젝트에 참여 하거나 자신의 시간에 연습하십시오. 이것은 새로운 지식을 실천하고 그러한 것들이 어떻게 작동 하는지를 보며 독서와 함께 진행됩니다. 이것은 또한 멘토와 좋은 대화를 나누는 것들입니다.
• 가져 뭔가 기술과 관련된 외부 직장의. 이것은 프로젝트 또는 포럼 일 수 있습니다. 사물에 대한 새로운 관점을 유지하기 위해 즉각적인 동료 집단 밖에서 이론과 아이디어를 테스트 할 수있는 것.
• 인내심을 가지십시오 . 경력을 쌓는 데 시간이 걸린다는 점을 인식하고 실패한 이유와 장소를 배우기 위해 잠시 물러서야한다는 것을 배우십시오.
• 작업, 생각, 실패 및 성공에 대한 일기 또는 블로그 를 유지하십시오 . 이것은 꼭 필요한 것은 아니지만, 시간이 지남에 따라 어떻게 발전해 왔는지, 기술이 어떻게 발전하고 생각이 바뀌 었는지 보는 것이 큰 도움이 될 수 있다는 것을 알게되었습니다. 몇 달에 한 번씩 자신의 일지로 돌아가서 4-5 년 전에 쓴 내용을 살펴 봅니다. 그 당시에 내가 얼마나 배웠는지 발견하는 것은 진정한 눈을 뜨는 것입니다. 또한 때때로 문제가 있음을 상기시킵니다. 건강 개선에 도움이됩니다.

글쎄요, 이런 종류의 질문에 대한 황금 사과는 없으며, 아마도 이것이 모든 코더 자신이 자신에게 맞는 것을 찾는 것입니다. 어쨌든 여기에 내 테이크가 있습니다.

당신은 수있는 주제에 대한 책을 읽고. 훌륭한 책. 환상적인 책. 그러나이 책은 응용 프로그램을 빌드하고 디자인하려고했지만 실패한 경우에만 도움이됩니다.

나를 위해, 그것은 경험에 관한 모든 것입니다. 신인으로 시작했을 때 디자인 방법에 관한 책을 읽었습니다. 당시에는 내용을 많이 이해하지 못했습니다. 작업을 시작하고 응용 프로그램을 직접 디자인해야 할 때 매우 지저분한 응용 프로그램을 만들었습니다. 그들은 일했지만 유지하기가 힘들었습니다. 그런 다음 그 책들을 다시 읽었습니다. 이번에는 더 잘 이해했습니다.

이제 저는 계속해서 새로운 실수를하고 옛 실수를 배웁니다.

설계를 중단하고 코드 리팩토링을 배우십시오. 지속적이고 공격적인 리팩토링을 통한 증분 ​​개발은 초기 설계보다 훨씬 최종 제품이 더 깨끗합니다.

패턴에 대해 읽으십시오. 그러나 가장 먼저 안티 패턴에 대해 읽으십시오. 안티 패턴을 인식하는 것이 중요하며, 왜 그렇게해야하지 않는지 왜 그렇게하지 않아야 하는지를 이해하는 것이 더 쉽습니다.

예를 들어 http://sourcemaking.com/antipatterns/software-development-antipatterns 를 참조 하십시오 .

요구 사항이 변경되면 프로덕션 환경에서 매우 일반적으로 빠르게 조정할 수 있도록 코드를 작성하십시오.

"단지 하나의 작은 핵"을 추가하는 것에 대해 회의적입니다. 하나 더, 하나 더, 코드는 유지 보수가 불가능 해집니다.

가치 폐쇄 / 개방 원칙을 .

테스트를 작성하십시오 (TDD에서와 같이). 실제로 구현하기 전에도 디자인을 생각하게합니다.

오픈 소스 프로젝트의 코드를 찾아보십시오 (합리적인 규모의 프로젝트). 나는 일반적으로 너무 많은 추상화 수준을보고 놀랐습니다. 나는 그것이 예술을위한 예술이 아니라는 것을 이해합니다. 그것이 이런 식으로 이루어진 이유가 있습니다.

좋은 디자인에 매우 중요하다고 생각하는 한 가지 원칙은 분해입니다. 클래스가 너무 큰 경우 (300-400 줄 이상의 코드) 작은 클래스로 나눕니다. 메소드가 너무 큰 경우 (예 : 50 줄 이상의 코드) 분해합니다. 프로젝트에 50 개 이상의 클래스가 포함되어 있으면 분해하십시오.

핵심은 시스템의 크기를 추정하고 몇 가지 추상화 계층 (예 : 서브 시스템, 응용 프로그램, 프로젝트, 모듈, 클래스, 방법)을 구성하여 코드를 이해하기 쉬운 단위로 분해하고 소수의 종속성을 갖는 이해 가능한 단위로 분해 할 수 있도록하는 것입니다.

힘든 것은, 우리가 실제로 이야기하는 것은 더 나은 코드를 만드는 것이 아니라 추상화하는 능력이지만, 두 가지가 더 나아지고 한 가지가 더 행복해집니다.

"보다 나은"

A) 당신이 할 수있는 최고의 디자이너를 찾고 프로그램을 함께 디자인하고 디자인을하십시오. 그들이 문제를 해결할 때 생각하고있는 것을 설명하고, "정확하다고 느낀다"는 말을하지 말고 계속 파십시오. 그 과정은 "멘토링"파티에도 도움이 될 것입니다

B) 모든 것을 개별 배우와 그들 간의 대화로 생각하십시오. 각 액터는 단일 역할 / 책임을 가져야하며 각 그룹은 다른 시스템을 처리합니다. 그 대화가 효과가 있고 각 배우가 일관되고 응집력이 있다면 당신은 가고 있습니다.

그리고 "행복한"

C) 최선을 다 했는데도 여전히 일어나지 않는다면 어떤 사람들은 어떤 일을 할 수 없다는 것을 받아들이는 데 아무런 문제가 없습니다. 타이트하고 화려한 코드를 작성할 수는 있지만 디자인하거나 설계 할 수는 없습니다. 그래서 무엇? 나는 토피를 위해 육체적 스포츠를 할 수없고, 잘 보이지 않으며 내 차 운전이 평균보다 더 나을 수 없습니다. 당신이 잘하는 것을보고 활용하십시오.

내 개인적인 경험에서 다른 사람의 코드를 읽는 것은 "영감"의 좋은 원천입니다. 다른 사람들의 디자인을 이해하고 왜 그런 식으로 일을하는지 스스로에게 물어보십시오.

연구를위한 많은 오픈 소스 프로젝트를 찾을 수 있습니다.

어쨌든 연습이 필요합니다.

두려워하지 마십시오

단순성을 위해 노력하십시오

사용자의 의견을 경청하십시오

많은 아이디어를 시도하십시오

무언가를 만든 다음 더 나아지십시오

가치를 더하는 일을하고, 그렇지 않은 것을 버린다

올바른 질문을하는 법을 배우십시오. 종종 다른 각도에서 문제를 살펴봄으로써 디자인을 향상시킬 수 있습니다. 특히, 이는 현재 문제를 해결하는 데 주력하지 않고 여러 관련 문제를 해결하는 솔루션을 더 많이 찾는 데 도움이됩니다.