OOP 디자인을 만드는 데 어려움이 있음을 깨달았습니다. 이 속성이 X 클래스로 올바르게 설정되어 있는지 결정하는 데 많은 시간을 보냈습니다.
예를 들어, 며칠이 지난 게시물입니다. /codereview/8041/how-to-improve-my-factory-design
내 코드를 확신하지 못합니다. 따라서 디자인을 개선하고 시간을 덜 내고 싶습니다.
좋은 디자인을 만드는 법을 어떻게 배웠습니까? 저에게 추천 할만한 책이 있습니까?
OOP 디자인을 만드는 데 어려움이 있음을 깨달았습니다. 이 속성이 X 클래스로 올바르게 설정되어 있는지 결정하는 데 많은 시간을 보냈습니다.
예를 들어, 며칠이 지난 게시물입니다. /codereview/8041/how-to-improve-my-factory-design
내 코드를 확신하지 못합니다. 따라서 디자인을 개선하고 시간을 덜 내고 싶습니다.
좋은 디자인을 만드는 법을 어떻게 배웠습니까? 저에게 추천 할만한 책이 있습니까?
답변:
시스템 설계는 수행을 통해서만 더 나아질 수있는 것 중 하나입니다. 물론, 그것은 좋은 디자인에 대해 조금 읽는 데 도움이됩니다. 일반적인 객체 지향 디자인 책은 Gang of Four 's Design Patterns : Elements of Reusable Object-Oriented Software 입니다. 다른 유형의 시스템과 다른 영역의 디자인 패턴 및 원칙에 대한 다른 책들도 있습니다.
또한 다른 사람들을 참여시키는 것이 가장 좋습니다. 디자인을 만든 후에는 해결하려는 문제와 디자인을 다른 사람들에게 제시하여 중요한 검토를 받으십시오. 피드백을 듣고 결정을 내린 이유에 초점을 맞춘 대화를 나눕니다. 솔루션을 구현할 때 디자인과 관련된 다른 문제를 깨닫게됩니다. 이것들을 기록하고 그들로부터 배우십시오. 또한 다른 사람들과 함께 설계 및 요구 사항에 대한 구현을 검토하고 자신이 한 일을 한 이유에 대해 비판적으로 논의하는 것이 좋습니다.
일반적으로 다른 사람들과 직접 대면하는 것이 가장 좋지만 여기에서는 프로그래머에게 특정 디자인 질문을 할 수 있습니다. 코드 검토 및 구현 관련 질문을 위한 Stack Exchange 사이트도 있습니다 .
코드 검토 질문의 모양에서, 당신은 그것을 과장하는 단계에 있습니다. 좋은 디자인의 중요성을 발견 한 사람들에게는 이것이 일반적인 문제라고 생각합니다.
실제로 당신이 데려 오는 기술로는 자연스럽고 아마도 필요한 단계입니다. 무언가를 배우기 시작하면 기술에 대한 지식이 많이 발달할수록 더 많이 적용할수록 결과가 좋아지고 숙련도를 향한 것처럼 보입니다. 문제는 새로운 목표가 결과의 품질이 아니라 기술에 얼마나 많은 지식을 축적했는지입니다.
기술의 진정한 숙달은 사용시기와 사용하지 않을시기에 대한 이해를 포함합니다. 그러한 기술을 남용하는 것이 아마도 그러한 이해를 발전시키는 유일한 방법 일 것입니다. 물론 이것에 대해 읽을 수는 있지만 독서는 경험을 대신 할 수 없습니다.
우선, 디자인 패턴을 읽는 것은 나쁜 시작 IMHO입니다. SOLID 및 GRASP 와 같은 OO 설계 원칙에 대해 읽는 것이 좋습니다. 이에 익숙해지면 일반적인 디자인 패턴을 연구하는 것이 좋습니다. 구체적인 원리를 적용하기 위해 이러한 원리를 적용하는 방법을 알 수 있기 때문입니다.
언어를 사용할 때 패턴이 나타날 때 언어에는 실제로 기능이 없다고 주장됩니다. 이 진술은 매우 급진적이지만 그 안에는 많은 진실이 있습니다. 그러므로 저는 여러분이 사용하고자하는 개념을 더 잘 이해하고 새로운 개념에 대해 배우기 위해 다른 언어를보고 놀아 볼 것을 제안합니다. 스 퀴크, 루비, 리스프의 후보가 될 것입니다.
List의 경우, 개인적 권장 사항은 컴퓨터 프로그램의 구조 및 해석입니다 . 이는 명확한 추상화 및 구성 (de) 구성만으로 복잡한 문제에 대한 강력한 솔루션을 쉽게 만들 수있는 방법을 보여줌으로써 디자인에 대해 많은 것을 가르쳐주었습니다. 하향식 방식.
여기 내가 제안하는 것이 있습니다.
다른 사람들이 언급했듯이, 당신은 연습과 경험을 잘 얻을 것입니다. 당신이 취할 수있는 지름길은 실제로 많지 않습니다.
당신이 당신의 물건을 되돌아보고 당신이 쓴 것을 좋아하지 않는다는 사실은 이미 우리 직업의 다른 많은 사람들에 비해 곡선보다 앞서 있습니다. 당신이 자신을 개선하려고 노력하는 동안, 우리 중 나머지는 20 개의 매개 변수를 가진 500 줄 함수를 작성하는 사람들과 협력합니다. 그들은 그 엉망이 작동하기 때문에.
소프트웨어 디자인의 경우 흑백이 아니며 디자인이 좋거나 나쁩니다. 아무리 많은 경험이 있더라도 이전 코드 중 일부로 돌아가서 "내가 이것을 썼을 때 나는 무엇을 피웠 는가?" 핵심은 사물에 대한 지속적인 평가이며, 좋은 코드가 좋고 나쁜 코드가 나쁜 이유를 평가하기 위해 종종 사고 연습을 거치는 것입니다.
마지막으로, 연습을 대체 할 수있는 것은 없지만 다른 사람들이 고려하지 않은 다른 관점을 지적 할 수 있기 때문에 항상 블로그 / 책 /이 사이트를 계속 읽는 것이 좋습니다.
우선이 책들을 추천합니다 :