나는 현재 5,000 줄 이상의 코드에 도달하려는 프로젝트를 진행하고 있지만 디자인을 완전히 생각하지는 못했습니다. 코드를 구성하고 구성하려면 어떤 방법을 사용해야합니까? 종이와 펜? UML 다이어그램? 다른 것?
답변:
당신은 아마도 대답이있을 수있는만큼 많은 다른 견해를 얻을 것입니다. 그러나 여기 내 관점이 있습니다.
우선 5000 줄 이상의 코드는 매우 작은 프로젝트입니다. 자, 성장하는 프로젝트를 설계하는 방법은 무엇입니까? 먼저 코드가 아닌 시스템을 설계합니다. 코드는 실제로 아키텍처의 2 차입니다. 최소 전류 요구 사항을 지원하는 것으로 시작하십시오. 관련된 구성 요소의 간단한 도면을 작성하십시오. 나는 개인적으로 UML을 좋아하지만 시각적으로 좋아질 것입니다. 이상적으로는 훌륭한 설계 관행 (인터페이스, 관심사 분리 등)을 준수하고자합니다.
디자인에서 최소한의 요구 사항을 지원하면 코딩하십시오. 다시 한 번 좋은 코딩 방법을 따르십시오.
그런 다음 새로운 요구 사항이 발생함에 따라 더 많은 기능을 반복적으로 추가합니다. 이상적으로 디자인도 업데이트하고 싶습니다.
내 경험에 비추어 중요한 것은 기존 요구 사항이 아닌 것을 예상하여 시스템을 설계하지 않는 것입니다. 그렇지 않으면 프로젝트가 매우 빠르게 성장하고 단기간에 매우 복잡해집니다. 다시 한번-모범 사례를 준수하고 구체적인 현재 요구 사항으로 시작하십시오.
플로우 다이어그램, 클래스 다이어그램, 유스 케이스 다이어그램은 대규모 프로젝트의 필수 다이어그램입니다. 필요한 외부 라이브러리를 검색하고 선택하고 사용할 수있는 유사한 오픈 소스 코드를 검색하십시오 (개발 시간을 배우고 줄이기 위해).
화이트 보드와 화려한 자석, 포스트잇을 구입하는 것이 좋습니다. 작업을 식별하는 데 도움이됩니다.
ps 5000+ 코드 라인은 "큰"것이 아닙니다. CMS / 포럼 소프트웨어에는 5000 줄 이상의 코드가 있습니다.
패키지 및 클래스 다이어그램을 작성합니다. 패키지 다이어그램에서 논리적으로 클래스와 인터페이스를 그룹화하는 데 관심이 있습니다. 내부 패키지 등을 만들고 싶습니다 ...
그러나 먼저 프로그램이 무엇을해야하는지 생각해야합니다. 유스 케이스 다이어그램을 작성하거나 수동으로 수행 할 수 있습니다. 코드를 즉시 얻는 것을 선호하고 나중에 패키지 클래스 다이어그램으로 바꾸는 것이 더 쉽기 때문에 클래스 다이어그램으로 수동으로 수행합니다. 클래스 다이어그램을 사용하면 Java를 얻을 수 있습니다. 마음에 들지 않으면 수동으로 변경하십시오. 새 코드는 자동으로 다이어그램으로 업데이트됩니다. 시각적으로 높은 수준의 업데이트 된 코드 표현이 있습니다. 코드를 작성하더라도 프로젝트가 그래픽 방식으로 진행되는 방식을 보는 데 몇 분이 걸릴 수 있기 때문에 정말 유용합니다. 구성하기 위해 올바른 패키지에서 엔티티를 수동으로 끌어서 놓기 만하면됩니다. 더 높은 수준의 추상화 패키지 및 클래스 다이어그램을 사용하면 코드가 더 좋다고 생각합니다.
(출처 : ejb3.org )
내 동료 중 일부는 내가 일하는 방식이 쓰레기라고 말했지만 ...- :)
명확히. 이런 종류의 물건에 사용할 수있는 작은 "태블릿"건식 지우기 보드가 있지만 편한 것을 사용하십시오. 중요한 것은 생각을 쉽게 내리고 모든 것이 어떻게 조화를 이루는 지에 대한 큰 그림을 볼 수 있다는 것입니다.
어떤 사람들은 UML 다이어그램과 같은 더 공식적인 계획을 선호하지만 각 방법의 모양을 미세하게 관리하기가 너무 쉽다고 생각합니다. 다시 한 번, 편한 것을 사용하십시오.
편집 : 당신은 또한 문맹 프로그래밍에 관심이있을 수 있습니다 . 아이디어는 모든 것을 계획하고 점차 더 구체적으로 얻을 수 있다는 것입니다. 예를 들어, 프로그램이 다음과 같이 구성되어 있다고 말할 수 있습니다.
그런 다음 텍스트를 이미지로 변환하려는 아이디어를 구체화 할 수 있습니다. 따라서 다음과 같이 보일 수 있습니다.
그런 다음 임의의 색상을 선택한다는 아이디어를 구체화하고 곧 일반 코드를 작성하는 것입니다.
저에게있어 소프트웨어 개발 활동은 특정 문제를 해결하기 위해 점진적으로 세밀하게 디자인 된 일련의 디자인입니다. 무엇을 구축하고 있는지에 대한 높은 수준의 아이디어가있을 때 디자인은 "SQL 데이터베이스 및 여러 웹 서비스와 통신하는 웹 응용 프로그램이있을 것"과 같은 매우 높은 수준 일 수 있습니다. 그런 다음 각 조각의 세부 사항을 자세히 살펴보면 디자인이 세분화됩니다. 솔루션의 복잡성에 따라 디자인 노력이 반복 될 것입니다. 마지막 반복에는 더 높은 수준의 디자인을 구현하는 실제 코드를 만드는 것이 포함됩니다.
저에게는 아키텍처와 디자인의 차이가 최소화되어 있으며 위에서 설명한 프로세스의 반복과 다릅니다. 둘 사이의 경계는 모호하고 사람들마다 다릅니다.
어느 수준의 설계 세부 사항, 응용 프로그램의 어느 부분 및 프로젝트 수명주기의 어느 시점에 들어가는지를 결정하는 기술이 있습니다. 위험도가 높고 복잡성이 높은 프로젝트의 경우 코드를 작성하기 전에 매우 세부적인 디자인을 원할 수 있습니다. 소규모 프로젝트의 경우, 최소한의 선행 설계를 수행하고 일부 코드를 생성 한 다음 작동하지 않는 부분을보고 해당 영역을 다시 디자인하면됩니다. 여기에는 하나의 쓰기 답변이 없습니다. 보통 두 극단 사이에 있습니다.
아키텍처에 접근 할 때 사용하는 몇 가지 원칙에 대해 설명 하는 블로그 게시물 이 있습니다. 이 라인을 따라 생각할 때 도움이 될 수 있습니다. 이 기사 중 일부는 .NET에만 해당되지만 대부분은 그렇지 않습니다.
나는 나 자신에게 똑같은 질문을했다. 이제 테스트 중심 개발을 연습하고 걱정하지 않아도됩니다. 선택한 아키텍처의 표준을 따르는 것을 제외하고는 코드를 전혀 계획하지 않습니다. 프로젝트를 시작할 때 무엇이 필요한지에 대한 아이디어가 있지만 개발이 진행됨에 따라 열린 마음을 유지하려고 노력합니다. 테스트 중심 개발을 따르고 지속적으로 코드를 리팩터링함으로써 코드를 "계획"할 필요가 없습니다. 나는 단지 하나의 테스트 사례를 계속 만족시키고 디자인은 리팩토링에서 나온다. 코딩하기 전에 계획했던 것보다 항상 더 나은 디자인입니다.