객체 지향 디자인에서 수행해야 할 작업을 실제로 찾는 방법은 무엇입니까?


12

먼저 면책 조항 :이 질문 이이 웹 사이트에 적합한 지 잘 모르겠지만 초보자뿐만 아니라 다른 사람들에게도 여전히 관련 질문이 있습니다. 여기에 맞게 질문을 개선 할 수 있다면 int 의견을 지적하십시오. 그것이 맞지 않는다면, 나에게도 알려주십시오. 가능한 경우 이것에 대한 좋은 포럼을 찾지 못했기 때문에 이것이 논의 될 수있는 곳을 알려주십시오.

PHP를 공부하면서 2009 년에 프로그래밍하는 법을 배웠습니다. 2012 년 후, 나는 C #과 .NET으로 옮겼습니다. 어쨌든 코딩은 문제가 아니며 알고리즘을 쓰는 것은 내 문제가 아닙니다. 내 실제 문제는 알고있다 어떤 요구 사항을 달성하기 위해 코딩해야하고 어디에서 코딩하는 것이있다.

웹에서 사용할 수 거기 대부분의 과정이 해결 방법을 -하는 방법을 쓰기 코드에 특정 언어 등의 API의 일부 세트를 사용하는 방법을 여기에서의 나의 가리.

이 몇 년 동안 나는 객체 지향 분석 및 디자인, 디자인 패턴, 도메인 기반 디자인 등 많은 것들에 대해 많이 읽었습니다. 예를 들어 SOLID 원칙, 도메인 전문가의 참여 필요성, 유비쿼터스 언어 개발 등과 같은 DDD의 주요 아이디어 중 일부를 이해합니다. 나는 이론적 배경이 적어도 합리적 이라고 감히 말할 것이다 .

그러나 연습을 할 때 나는 재난 인 것 같습니다. 얼마 전에 나는 이미 다른 사람에 의해 개발되고있는 금융 시스템의 개발을 계속해야했습니다. C # 및 WinForms로 개발 된 "이전 시스템"입니다. 도메인 규칙이 복잡하고 비즈니스 규칙이 많은 프로젝트를 처음 선택한 것은 처음이었습니다.

나는 요구 사항을 대부분받을 때 "어떻게 지구상에서이 작업을 수행 할 수 있습니까?"라고 생각한다고 고백합니다. -수행해야 할 작업을 파악하기 위해 요구 사항에 대한 작업을 시작하는 방법조차 모릅니다. 필자의 주요 혼동은 내가 코딩해야 할 것, 클래스, 인터페이스 및 각 논리 부분이 어디인지, 각각의 클래스가 무엇인지에 대한 것입니다. 문제는 어디서부터 시작 해야할지 모르겠다는 것입니다.

대부분의 경우 꽤 많은 생각으로 아이디어를 얻었지만 아이디어가 올바른지 판단하는 방법을 결코 알지 못합니다.

필자가 권장 한 소프트웨어 아키텍처 및 객체 지향에 대해 많은 것을 읽었지만 실제로 수행해야 할 작업을 식별하는 데별로 도움이되지 않았다고 말했기 때문에 이것이 이론의 부족이라고 생각하지 않습니다. .

그래서 어떻게 배울 수 정말 객체 지향 설계를? 내가 배우고 싶은 것은 : 주어진 요구 사항은 수행해야 할 작업과 각 코드가 속한 위치를 찾는 프로세스에서 요구 사항을 시작하는 방법을 알고 있다는 것입니다. 내 생각이 올바른지 판단하는 법을 어떻게 배울 수 있습니까?

나는 이것을 대답으로 완전히 설명하는 것이 불가능하다고 생각합니다. 그러나 내가 찾고있는 것은 사이트 스타일에 따라 개요를 제시하고 아이디어를 확장하고 실제로 배우는 데 사용할 수있는 참고 자료 (도서, 온라인 코스 등)를 가리키는 대답입니다.


1. 연산자 오버로드와 연산자 재정의의 차이점, 추상 클래스가 무엇인지, 인터페이스, 캡슐화, 다형성 등의 차이점과 같은 C #의 모든 기본 개념을 이미 이해하고 있습니까? C #에서 OO를 완전히 이해하려면 먼저 이러한 사항을 알아야합니다. c-sharpcorner.com/technologies/oop-ood를 참조하십시오 .
Robert Harvey

2
2. Winforms로 작성된 오래된 응용 프로그램은 제대로 설계되지 않으면 큰 진흙 공으로 변하는 경향이 있습니다. 우려의 분리가 가장 중요합니다. winformsmvp.codeplex.com
Robert Harvey

1
실제로 과정이 없습니다. 디자인은 주로 구성 방법을 알고 있으며 경험과 함께 제공됩니다. SOLID 원칙은 좋은 시작이지만 충분하지 않으며 사람들은 SOLID에서 길을 잃고 원칙이 존재하는 이유를 잊어 버리는 경향이 있습니다.
Robert Harvey

1
조금 시작하십시오. 요구 사항은 문제입니다. 한 가지 문제는 "다음 Stackexchange 사이트를 개발하고 싶습니다"또는 "다음 Stackexchange에 로그인을 원합니다"만큼 거대 할 수 있습니다. 큰 문제를 많지만 작은 것으로 바꾸십시오. 전반적으로, "잘못된"일을 먼저하고 시간이 지남에 따라 개선 할 기회를 가지십시오.
Laiv

1
나는 동시에 upvote하고 vtc하고 싶습니다 ...
svidgen

답변:


21

그렇다면 객체 지향 디자인을 실제로 배우는 방법을 배울 수 있습니까? 내가 배우고 싶은 것은 : 주어진 요구 사항은 수행해야 할 작업과 각 코드가 속한 위치를 찾는 프로세스에서 요구 사항을 시작하는 방법을 알고 있습니다. 내 생각이 올바른지 판단하는 법을 어떻게 배울 수 있습니까?

우선, 객체 지향 디자인을 올바른 것으로 생각하지 마십시오. 그것은 영어를 올바른 것으로 생각하는 것과 같습니다.

객체 지향 패러다임이 올바르지 않습니다. 특정 장단점이 있습니다. 이상적입니다. 우리의 유일한 것이 아닙니다. 아무것도 아닌 것보다 낫지 만 모든 것이 아닙니다.

저는 수십 년 동안 코딩을 해왔습니다. 나는 아이디어가 존재하는 한 거의이 물건을 연구했습니다. 나는 아직도 그것이 무엇을 의미하는지 배우고 있습니다. 전문가들은 여전히 ​​그 의미를 배우고 있습니다. 우리의 전 분야는 100 세 미만입니다.

따라서 요구 사항 더미를 가져 와서 요구 사항을 충족시키는 코드를 밝혀도 작성한 코드가 비극적 인 혼란은 당신이 혼자가 아닙니다. 작업 코드는 단순히 훌륭한 코드의 첫 번째 단계입니다. 작동 할뿐만 아니라 다른 사람이 쉽게 읽고 이해할 수있는 코드. 요구 사항이 변경 될 때 신속하게 조정할 수있는 코드. 앉아서 "와우, 너무 간단하다"고 말하는 코드.

문제는 우리가 그 모든 일을하기 위해 돈을받지 못한다는 것입니다. 우리는 전문가이기 때문에 모든 것을합니다. 우리는 항상 마감일이 있기 때문에 상사가 보이지 않을 때 모든 것을해야합니다. 그러나 우리는 5 년 후에 다시 와서 초보자들에게 다음과 같이 말하고 싶다. "아, 그래. 내가 썼어.

어떻게 가나 요? 연습. 믿음에 대한 디자인 아이디어를 받아들이지 마십시오. 이벤트 중심 디자인이 어떻게이 디자인을 단순화 할 수 있을지에 대해 누군가는 말하지 않습니까? 그들이 옳은지 확실하지 않습니까? 관찰자 패턴을 사용하는 집에서 장난감 프로젝트를 만드십시오. 그것으로 혼란. 도움이되지 않는 것을 찾으십시오.

읽다. 질문. 테스트. 반복.

당신이 당신 삶의 80 %를 위해 그것을하고 있다는 점에 도달하면, 당신은 나처럼 혼란 스러울 것입니다.

나는 요구 사항을 대부분받을 때 "어떻게 지구상에서이 작업을 수행 할 수 있습니까?"라고 생각한다고 고백합니다. -수행해야 할 작업을 파악하기 위해 요구 사항에 대한 작업을 시작하는 방법조차 모릅니다. 필자의 주요 혼동은 내가 코딩해야 할 것, 클래스, 인터페이스 및 각 논리 부분이 어디인지, 각각의 클래스가 무엇인지에 대한 것입니다. 문제는 어디서부터 시작 해야할지 모르겠다는 것입니다.

나는 같은 느낌이었습니다. 그런 다음 리팩토링의 기쁨을 발견했습니다. 코딩 할 때 디자인을 기꺼이 조정하십시오. 미리 종이에 모든 것을 해결하려고 시도하는 것은 어려운 일입니다. 잘못 될 수있는 코드를 작성하고 잘못 증명 한 후 수정하십시오.


2
이것은 좋은 대답입니다. 저는 15 년 동안 프로그래밍을 해왔으며 소프트웨어 엔지니어링 (직업)의 전 분야가 "퍼지"라고 덧붙입니다. 그것은 예술과 기능이 혼합되어 있으며 개발자에 따라 다른 것보다 더 중요합니다. 종이에 아키텍처에 대한 아이디어를 생각 해낼 수는 있지만 먼지에 흠집이 나고 엉망이되고 작동하지 않는 것을 찾을 때까지 OO 디자인의 세부 사항을 해결할 수 없습니다.
jropella

답변 해주셔서 감사합니다! 요점은 요구 사항을 구현할 솔루션이 하나 이상 있고 제대로 작동하면 구현 한 다음 다른 코드 및 기타 요구 사항과 어떻게 관련되는지 알면 리팩터링하여 더 잘 만드는 것입니까? 그러나 여전히 몇 가지 요구 사항이 있으며 시작 방법을 모릅니다. 이 경우 시작하는 방법에 대한 조언이 있습니까? 때로는 요구 사항과 가능한 구현에 대해 논의하는 것이 최선이라고 생각하지만 혼자 일합니다. 이런 종류의 토론을 환영하는 포럼이 있습니까?
user1620696

2
우선, 혼자 일하는 것을 그만두십시오. 실마리를 모르는 초보자라도 당신을 늦추어 설명하는 것이 그것보다 낫습니다. 둘째, 요구 사항을 여러 부분으로 나누는 법을 배웁니다. 견인력을 얻을 수있는 관리 가능한 물건이 생길 때까지 계속하십시오. 필요한 경우 완전히 다른 환경에서 개념 증명 코드를 작성하십시오. 필요한 것에 대한 이해를 나타내는 무언가를하십시오. 그런 다음 해당 표현을 테스트하십시오. 당신은 내가 당신이 나쁜 가정을했다는 것을 알았습니다. 잘 됐네요 기꺼이 바꾸십시오.
candied_orange

1

소프트웨어 개발은 ​​모든 수락 기준을 충족시키면서 예산에 맞춰 작동하는 소프트웨어를 제 시간에 맞춰 제공합니다. 그렇게했다고 가정하면, 코드 나 그 구조의 품질은 부차적 인 관심사입니다.

물론 새로운 그린 필드 코드를 작성하는 것은 레거시 코드를 유지하는 것보다 훨씬 저렴하고 쉬운 경향이 있으므로 코드 품질이나 아키텍처에 너무 매달리지 않고 실제 문제는 유지 관리 성이라는 점을 기억하십시오.

일반적으로 코드 변경과 관련된 비용, 시간 및 위험이 버그를 수정하거나 요구 사항에 대한 변경 사항을 구현하는 것이 여전히 비용 효율적이고 이러한 변경 사항을 구현함으로써 "죽음의 나선 코드 엔트로피

반대로, 코드가 손상되지 않도록하기 위해 무언가를 깨거나 과도한 시간 / 돈을 소비 할 위험이없이 자신있게 변경하거나 리팩토링 할 수없는 경우, 즉 코드 작업에 관련된 시간, 비용 및 위험이 발생할 때 코드는 유지 불가능한 것으로 간주 됩니다 변경의 이점과 비교할 때 불균형 적으로 높음 (예 : 고용주 또는 고객이 새로운 기능을 추가하거나 버그를 수정하는 등의 비용을 잃지 않음)

혼란스러운 변화를 막기 위해 엉망 주위에 충분한 규정이있는 경우 가장 사악한 스파게티 엉망조차도 잠재적으로 유지 관리가 가능합니다 (이런 경우는 드 rare니다). 스파게티 엉망의 문제점은 변경 사항을 깨는 것을 방지하는 것이 비용이 많이 들고 비효율적 인 경향이 있다는 것입니다.

유지 관리 가능한 코드를 작성하는 가장 신뢰할 수있는 방법은 적절한 자동화 테스트 모음을 동시에 작성하는 것입니다 (사용 가능한 경우 다른 정적 분석 도구를 최대한 활용하는 것).

리팩토링 할 수있는 충분한 자동화 테스트를 받기 위해 TDD / BDD와 같은 엄격한 개발 방법론을 따를 필요는 없습니다. 나중에 실수로 변경되는 변경으로부터 코드를 보호하기에 충분 해야합니다 .

코드에 자동화 된 테스트가 포함 된 경우 해당 테스트가 적용된다는 것을 알고 코드의 디자인과 구조를 완화 할 수 있습니다. 나중에 적극적으로 리팩터링하거나 버리고 다시 시작할 수 있습니다.

이것은 쉽게 테스트 가능한 코드를 작성하는 방법에 대한 의문을 제기합니다. 이것은 일반적으로 SOLID 원칙을 따르는 주요 주장입니다. 실제로 SOLID 원칙을 준수하는 코드의 특징은 단위 테스트를 작성하는 것이 쉽고 시간 / 비용 효율적이라는 것입니다.

물론 단위 테스트를 작성할 시간이없는 경우도 있습니다. 그러나 "이 코드에 대한 자동 테스트는 어떻게 작성합니까?"라는 질문을 명심하면서 모든 코드를 작성했다면 (실제로 이러한 테스트를 구현하지 않았더라도) 합리적으로 유지 관리 가능한 디자인을 찾은 것 같습니다.


1
우리는 자동화 된 테스트를 작성할 시간이 없지만 항상 수동 테스트를 반복해서 반복해서 실행합니다 ...
Nick Keighley

마찬가지로, 우리는 처음으로 "정확하게"그리고 "깨끗하게"코드를 작성할 시간이 없지만, 잘못 안내되었지만 널리 퍼진 사고 방식으로 인해 계속 반복해서 코드를 계속해서 수정하는 데 끝없는 시간이있는 것 같습니다. 이 게시물.
Dunk

@ 덩크 나는 코드가 절대로 변경되거나 다시 방문해서는 안된다고 생각하는 것이 현실적이라고 생각하지 않습니다. 단위 테스트 사례 및 SOLID 지침은 불가피한 상황에서 변경하기 쉽고 비용이 많이 드는 코드를 생성하는 사례를 장려하는 것에 관한 것입니다. 예를 들어 누군가가 개발자가 당시 고려하지 않았던 정말 이상한 모호한 버그를 발견하거나 고객이 솔루션은 요구 사항을 변경하거나 개발자가 인간이기 때문에 원래 코드에도 실수가 포함되어 있습니다. 또는 개발자가 요구 사항을 이해하지 못했거나 이전에 알려지지 않은 기술적 제한 사항을 발견했을 수도 있습니다.
Ben Cottrell

1
@ BenCottrell-전적으로 동의합니다. 코드는 항상 다시 방문해야합니다. 그러나, 그로 인해 사람들은 "선불 설계"에 시간을내어 일종의 실패로 다소 "깨끗한 코드"를 작성하도록 지시합니다. 그들은 "on-time"과 "on-budget"만트라를 사용하여 열악한 코드 / 디자인을 정당화합니다. 원하는 모든 "연습"을 사용할 수 있지만 좋은 디자인과 상대적으로 "깨끗한 코드"가 없으면 "변경하기 쉽고 저렴한 코드"를 구입하지는 않습니다. 좋은 디자인과 "깨끗한 코드"는 실제로 정시 목표와 예산 목표를 달성하는 부산물이 될 것입니다.
덩크

@Dunk 많은 개발자가 코드 품질에 신경 쓰지 않는다고 말하는 것처럼 들립니다. 일반적으로 그렇지 않다고 생각합니다. 실제로 저는 두 가지 더 큰 문제가 있다고 생각합니다. 첫째, 개발자가 예산과 마감일에 대한 견적을 제공하는 사람 일 수 있지만 견적은 쉽게 잘못 될 수 있습니다. 둘째, 프로젝트 이해 관계자는 시간 / 비용에 대한 최종 결정을 내립니다. 즉, 위험, 예산 및 마감일이 기술적 인 문제보다 우선합니다. "지연 적으로 늦게 / 예산 초과"또는 "잠재적으로 잘못된 코드"중에서 선택하면 이해 관계자가 후자를 자주 선택한다는 것을 알게되었습니다.
벤 Cottrell
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.