전문 소프트웨어 개발 팀은 사소한 프로젝트의 설계 복잡성을 어떻게 처리합니까?


9

첫째, 나는이 질문이 다소 길고 모호 할 수 있음을 깨닫고 사과드립니다. 이것은 아마도 "얻은"사람에게는 짧은 이름을 가진 기본적인 문제 일 것입니다. 그러나 이와 관련하여 부족한 점을 발견하면 그 문제를 설명 할 때 저와 함께 해주십시오.

나는 11 살 때부터 이런 식으로 프로그래밍을 해왔다. 이것은 내가 처음부터 모든 것을 스스로 가르치고 있음을 의미합니다. 나는 기술 교육을 받았지만 컴퓨터 과학 (엄밀하게는 Photonic Engineering에서 학위를 취득했습니다)에서는 아닙니다. 우리는 물론 프로그래밍 과정을 가지고 있었지만 이것은 주로 저에게 기본적인 내용이었고 많은 새로운 것을 배우지 못했습니다. 나는 그것의 기쁨을 위해 길을 따라 나 자신을 교육하고 항상 프로그래밍 경력을 추구한다는 것을 알았지 만 그 당시 내 모든 프로젝트는 아주 작았습니다. 나는 그것들을 생각하고 유지하는 데 어려움이 없었습니다.

이제는 팀에서 주도적 인 역할을하지만 회사 환경에서는 그렇지 않습니다. 저는 엔지니어링 응용 프로그램을위한 과학 소프트웨어 (C ++)를 개발하는 대학에서 일하고 있습니다. 갑자기 프로젝트가 (상대적으로) 커지고 있으며 대부분 내 마음을 감싸는 데 어려움을 겪고 있습니다. 나는 주로 두 가지 일에 많은 시간과 노력을 잃고 있습니다.

  1. 한동안 작업하지 않은 코드 섹션으로 돌아 가야 할 때 작동 방식을 기억하기가 어렵습니다. 관련 클래스의 헤더 파일을 검토하고 소스 파일을 따라 배치 한 주석을 읽는 데 많은 시간을 할애합니다. 나는 "도식적"의 형태가 있었으면 좋았고 그림을 더 쉽게 볼 수 있었다.
  2. 변경 사항을 소개 할 때 때로는 내가하려고하는 일이 다른 곳에서 문제를 일으킬 것이라고 반쯤 깨달았습니다 (또는 런타임에 놀랍게도 나타납니다). 나는 다른 구성 요소에 대한 영향을 무시한 것을 알기 위해서만 되돌리고 다르게 행동하기 시작합니다. 작업 방식, 수행하려는 작업이 다른 구성 요소에 어떻게 영향을 미치는지, 변경 사항을 구현하기 전에 세부 계획을 세우는 방법을 볼 수있는 "아키텍처 다이어그램"이 있었으면합니다.

내가 일하는 대부분의 사람들은 나 자신과 비슷한 이야기를 가지고 있습니다. 강한 기술 지향과 때로는 훌륭한 기술이지만 그들의 일을 조직 할 방법은 없습니다. 그러나 그들의 프로젝트는 대개 내 프로젝트보다 훨씬 작기 때문에 어떻게 든 대처합니다. 어쨌든, 그것이 저에게 의미하는 것은 제가 혼자 있고 좋은 관행을 배울 사람이 없다는 것입니다.

나는 IT 관리에 대학원 과정을 수강했고, 그것을 만족스럽게 생각하지만, 주로 소프트웨어 설계 및 계획이 아닌 프로젝트 관리 방법론, 예산 / 일정 추정, 엔터프라이즈 아키텍처 등에 대해 가르치는 비 프로그래머를 대상으로합니다. 괜찮습니다. 저도 배우려고 노력하고 있습니다. 물론 UML과 같은 일부 도구와 소프트웨어 개발 프로세스 유형 (캐스케이드, 반복, 민첩성 ...)이 소개되었지만 분명히 자세하게 설명되어 있지 않으며 선택 및 사용해야 할 사항을 결정하기가 어렵습니다. 그리고 어느 정도까지).

SO의 소프트웨어 디자인에 대한 많은 질문과 답변을 읽었습니다.이 도구 또는 특정 도구 또는 방법론을 사용하여 소프트웨어를 작성하는 방법에 대한 많은 것이 있으며 UML 문서가 문제를 해결할 것이라고 확신한다면-그것을 선택하고 사용을 시작하십시오. 그러나 어떤 사람들은 맹세하고 다른 사람들은 쓸모가 없다고 말합니다. 더 높은 수준의 추상화에 대한 답을 찾고 있습니다. 두 가지 문제를 해결할 수있는 방법이 있습니까? 어떻게 개인적으로 수행합니까? 특정 도구에 얽매이지 않고 어떻게 할 수 있는지 배워야합니까? 이것들은 때때로 스타일이 바뀌지 않으며 적용 가능성은 프로젝트 유형에 따라 다릅니다.

읽어 주셔서 감사합니다. 소프트웨어 디자인 경험과 어휘가 부족하다는 것을 더 간략하게 말씀 드릴 수 없었습니다.


2
나는 당신이 말하고있는 어려움에 대한 가장 일반적인 전문적인 반응은 "성공"에 이어 관리, 제품 또는 다른 임의의 SOB를 비난하는 것이라고 생각합니다.
Edward Strange

답변:


9

한동안 작업하지 않은 코드 섹션으로 돌아 가야 할 때 작동 방식을 기억하기가 어렵습니다. 관련 클래스의 헤더 파일을 검토하고 소스 파일을 따라 배치 한 주석을 읽는 데 많은 시간을 할애합니다.

당신을 따라온 가난한 사람이 어떻게 느끼게 될지 상상해보십시오. 그는 코드가 어떻게 작동하는지 한 번 알지 못합니다. 코드를 해독하는 대신 문제의 모듈에 대해 작성한 문서를 검토해야합니다. 이 문서는 모듈이 왜 어떤 일을하는지에 대한 합리적으로 정확한 견해를 제공해야합니다. "이 모듈은 트리플 for 루프를 사용하여 3 개의 배열을 초기화하여 시작합니다 ..."가 아니라 "이 모듈은 Fabulotron의 메인 센서에서 수집 한 데이터를 검색하여 표준 Neopolitan (초콜릿, 바닐라, 딸기) 형식으로 재 배열합니다. "분석 모듈로 전달합니다."

완벽한 세상에서, 시스템에 다양한 모듈을 설정하고 각각의 책임을 설명하는 디자인 문서가있을 것입니다. 각 모듈은 해당 문서를 다시 참조하여 그들이하는 일을 설명 할 수 있습니다. "이 모듈은 설계 문서의 4.8 절에 설명 된대로 Fabulotron 데이터 수집 서비스 : http://fabulotron.org/design/section4-8.html . " 그런 것이 없다면 각 모듈에 대한 개요를 작성해보십시오. 책을 쓸 필요가 없습니다. 몇 개의 단락만으로도 충분합니다.

변경 사항을 소개 할 때 때로는 내가하려고하는 일이 다른 곳에서 문제를 일으킬 것이라고 반쯤 깨달았습니다 (또는 런타임에 놀랍게도 나타납니다). 나는 다른 구성 요소에 대한 영향을 무시한 것을 알기 위해서만 되돌리고 다르게 행동하기 시작합니다.

모듈이 상호 연결되어 있음을 나타냅니다. 모듈 / 클래스 / 유닛을 더 독립적으로 만들수록 이런 종류의 문제가 발생할 가능성은 줄어 듭니다. 가능한 한 모듈 사이의 인터페이스를 명확하게 만들고 필요한 곳에만 제한하십시오. 인터페이스는 계약입니다. 일부 모듈이 인터페이스에 지정된대로 의무를 수행한다는 것을 알고 있으면 다른 모듈을 알 필요가 없습니다. 이렇게하면 작업중인 모듈의 변경 사항이 다른 모듈에 영향을 미치지 않습니다.

일이 어떻게 진행되는지 볼 수있는 "아키텍처 다이어그램"이 있었으면 좋겠습니다.

표준 부품을 사용하면 이와 관련하여 도움이 될 수 있습니다. C ++는 표준 템플릿 라이브러리 형태로 표준 부품을 제공하며, 해당 부분을 사용하면보다 높은 수준의 추상화에서 작업 할 수 있습니다. 목록과 같은 데이터 구조를 관리하기 위해 자신의 코드를 작성했다면, 당신과 그 다음에 오는 것들은 소스 코드를 지속적으로 읽고 무슨 일이 일어나고 있는지 알아 내야합니다. 대신 STL에서 제공하는 표준 부품을 사용하는 경우 모든 C ++ 프로그래머는 데이터 관리 루틴을 파헤 치지 않고 코드가 수행하는 작업을 빠르게 알 수 있습니다.

또 다른 종류의 표준 부분은 디자인 패턴에서 비롯됩니다. 그것들은 두 객체 사이의 관계가 어떻게 작용하는지 설명하기위한 속기로서 사용될 수있는 표준 개념입니다.


답변 해주셔서 감사합니다. 물론 나는 수년 동안 STL을 사용해 왔지만, 프로그램이 계획된 계산을 수행하기 위해 수행하는 일련의 단계는 때때로 사용법과 함께 전체를 이해하기가 어렵습니다. 모듈도 마찬가지입니다. 나는 하나를 바꾸는 것이 다른 것을 깨뜨릴 것을 의미하지는 않았지만, 어딘가에서 무언가를 바꾸는 것은 예를 들어 사용자가 GUI에서 비표준적인 것을 할 때 복잡한 순서가 더 복잡한 단계가 더 복잡하여 완료하는 데 걸리는 단계로 인해 결함을 초래한다는 것을 의미합니다.
neuviemeporte

5

나는 짧은 기간 동안 전문 개발자였으며 ​​처음 시작할 때이 작업을 수행하는 방법으로 많은 어려움을 겪었습니다. 나는 대학을 통해서조차도 자체적으로 교육을 받았다. 다행스럽게도 나와 함께 일한 사람들은 많은 경험을 가지고 있으며 대규모 프로젝트를 관리하고 작업하는 방법에 대해 교육 할 수있었습니다.

내가 한 첫 번째 일 중 하나는 앉아서 깨끗한 코드를 읽는 것이었다 . 다시 돌아 왔을 때 이해할 수 있거나 다른 사람이 이해할 수있는 코드를 작성하는 방법을 이해하는 데 도움이되는 훌륭한 책입니다.

두 번째는 좋은 품질 테스트, 단위, 통합, 수락을 작성하는 것이 었습니다. 코드가 제대로 테스트되면 문제가 발생한 시점을 신속하게 파악하고 문제를 신속하게 진단 할 수 있습니다. 인터넷에는 훌륭한 테스트 리소스가 많이 있으며, 어느 것이 당신에게 추천 할 지 잘 모르겠습니다.

나의 핵심은 Testing and Clean Code입니다.


제안에 감사드립니다. 자막의 "민첩한"책이 대부분 해당 방법론과 관련이 있음을 나타내더라도 책을 확인하십시오. 나는 테스트를하고 많은 코딩 스타일의 책 (예를 들어 Pragmatic Programmer)을 읽었다. 나는 항상 깨끗하고 분리 된 인터페이스를 만들기 위해 노력하고 있지만, 한 번의 자동화 된 테스트를 위해서는 내 응용 프로그램의 GUI 부분이 어렵고 여전히 비교적 작은 규모의 코드에서 "깨끗한"관행을 구현하는 것 이상의 우수한 전체 디자인을 대규모로 구현하는 방법.
neuviemeporte

2

다음은 대규모 소프트웨어 시스템을 구성하기위한 몇 가지 고급 아이디어입니다. 내 경험의 대부분은 인터넷 시스템에 관한 것이지만, 이러한 아이디어는 엔지니어링 소프트웨어에 적용된다고 생각합니다.

  • 기능을 비교적 고립 된 모듈 식 블록으로 분리합니다. 예를 들어, 소프트웨어가 제공하는 각 계산 제품군에 대한 모듈이있을 수 있습니다.
  • 사용자 인터페이스에 대한 MVC 디자인 패턴이있는 경우이를 적용하십시오. 인터페이스와 모델을 명확한 경계로 분리하십시오.
  • 모듈을 그룹화하기 위해 레이어 사용을 고려하십시오. 추상화 계층을 사용하는 응용 프로그램에서 각 계층은 그 아래 계층에만 의존합니다.
  • 문서를 작성할 때 모든 구현 세부 사항을 잊어 버릴 것이라고 가정하십시오. 이 가정하에 많은 문서를 작성하게 될 것입니다. 코드의 절반 정도가 주석 일지 모르지만 나중에는 훨씬 덜 혼란 스러울 것입니다.
  • 자동화 된 단위, 통합 및 승인 테스트는 일부 영역에서 훌륭하지만 C ++ 개발자는 이에 대해 여러 가지 감정을 갖고있는 것 같습니다.
  • 디자인 패턴을 크게 그 립니다. 일반적으로 좋은 아이디어 일뿐 아니라 디자인 패턴은 소프트웨어 엔지니어링에서 공통된 어휘를 제공합니다. 위젯을 클래스로 호출하는 것은 위젯을 만들기 위해 존재하는 클래스임을 알리는 간결한 방법입니다.

엔지니어링 소프트웨어로 작업 한 지 오랜 시간이 지났으므로이 제안에 따라 마일리지가 다를 수 있습니다. 행운을 빕니다!


1

답은 소프트웨어 공학입니다.

즉, 대규모 프로젝트의 경우 실제 코딩을 수행하기 전에 일련의 요구 사항 수집, 프로세스 정의, 사양 등을 따릅니다.

환경과 문화에 따라 다양한 방법론이 사용됩니다. 엔터프라이즈 유형 비즈니스는 " Rational Unified Process "또는 이와 유사한 방식을 따르는 경향이 있으며 , 기술 부서는 대개 Agile , 정부 부서에서 일부 과업 폭포 방식을 변형합니다 .

모든 경우에 프로세스는 수행중인 작업을 정확하게 정의하는 데 도움이되며 프로젝트가 끝날 무렵에 작업이 완료되었음을 증명할 수 있습니다.


요구 사항이 변경되지 않는다고 가정하면 (많은 경우 비현실적 인 가정), 코딩하기 전에 모든 것을 지정하고 실제로 큰 변경없이 사양에서 작동하는 소프트웨어를 만들 수 있습니까? 난 그냥 그림을 그릴 수 없습니다. 느낌을 얻으려면 코딩을 시작해야합니다. 조금 조정, 더 많은 조정 등 ...
neuviemeporte

소규모 프로젝트에서는 효과가 있지만 대규모 프로젝트에서는 먼저 요구 사항을 파악해야합니다. RUP의 중요한 부분은 UML 및 시퀀스 다이어그램을 사용하여 제안 된 시스템을 모델링하는 것입니다. 실제 코드보다 모델을 조정하고 리팩토링하는 것이 훨씬 쉽습니다.
제임스 앤더슨

@neuviemeporte : 그것은 달려 있습니다. 때때로 요구 사항 변경 또는 새로운 요구 사항이 개발 중에 발견됩니다. 때로는 요구 사항이 처음부터 명확하고 개발 과정에서 약간의 세부 사항 만 변경되지만 전체 아키텍처는 동일하게 유지됩니다.
조르지오

1

무료는 아니지만 아카데믹 가격을 제공하는 Enterprise Architect를 사용해 보는 것이 좋습니다 . 거시적 수준과 미시적 수준 모두에서 프로젝트를 다이어그램으로 표현할 수있는 훌륭한 도구입니다. 또한 소스 파일을 클래스 다이어그램으로 리버스 엔지니어링 할 수 있습니다. 이는 아마도 응용 프로그램의 구성 방식을 문서화하고 재구성하는 데 좋은 출발일 것입니다.

또한 @Klee의 권장 사항에 이어 두 번째입니다. 민첩한 프로세스를 수행하는 경우에도 필수 (필수적이지 않은 경우도) 유용한 모범 사례 항목이므로 "민첩한"도구로 생각하지 마십시오. 그러나 지속적인 통합 (예를 들어)은 방법론에 관계없이 중요합니다. 또한 단위 테스트 (cppUnit?)는 친구입니다. UI를 직접 테스트하지 않고 UI에서 호출 한 논리 클래스를 테스트하는 경우 단위 테스트를 수행 할 수 있어야합니다. UI 테스트를 자동화하는 데 도움이되는 도구도 있지만 백엔드를 먼저 정리하려고합니다.

행운을 빕니다!


1

나는 당신의 문제가 3 차원이라고 믿습니다

  1. 프로그래머 지향
  2. 프로그램 지향
  3. 프로그램 유지 관리-지향

첫 번째 문제와 관련하여 프로그램의 개념을 이해하지 못하는 프로그래머가있을 수 있습니다 (종종 회사 설정에서 발생 함). 그러나 귀하의 질문과 귀하가 속한 도메인으로 이동하면 귀하와 귀하의 팀이 프로그램의 기능을 제어하지만 빠른 시간 내에 작동하는 프로그램으로 변환 할 수없는 것 같습니다 (예를 들어, 사람들에 대해 들었습니다) 물리학에서 박사 학위를 소지하고 프로그래밍의 포인터를 이해하는 데 어려움을 겪고 있으며 물리학이 C ++보다 훨씬 어렵다는 것을 확신합니다). 이 경우 문제는 대부분 프로그램 중심입니다. 주변 사람들이 귀하의 프로그램이 무엇을하고 있는지 이해할 수있을 정도로 운이 좋을 것입니다.

프로그램 중심의 문제의 경우, 파이썬 또는 Haskell과 같은 새로운 언어를 배우는 것과 같이 C ++보다 더 높은 수준의 추상화로 옮기는 것이 나의 끔찍한 제안 중 하나입니다 (Python은 배우기가 매우 쉽고 수학자가 좋은 경우, 하스켈은 훌륭합니다). 더 높은 수준의 추상화로 이동하면 코드 크기를 줄이고, 이해하기 쉽고 장기적으로 이해하고 유지하며 변경 사항을 신속하게 적용 할 수 있습니다. 따라서 원래 50 줄의 코드 대신 10 줄의 코드를 가질 수 있습니다. 또한 컴퓨터 프로그래밍에 전문 지식을 가진 사람이 있으면 도움이 될 것입니다. 대학에 다니는 동안 몇 명의 학생을 GUI 및 인터페이스에 참여시켜 기능에 더 집중할 수 있습니다. 또한 John Lakos의 Large-Scale C ++ Software Design 책을 추천합니다.(이 책은 꽤 큰 책입니다. 책을 읽는 데 걸린 시간에 능숙한 Python 프로그래머가 될 수 있습니다)

문제의 처음 2 개 차원에서 정렬하면 세 번째가 자동으로 해결됩니다. 하나의 큰 프로젝트를 진행하고 있다고 생각하기 때문에 적절한 프로젝트 관리 소프트웨어가 필요합니다. 선행 계획이 필요합니다. 바로 코딩을 시작하면 큰 그림을 잊어 버린 프로그램에 너무 많이 참여할 수 있습니다. 큰 프로젝트에는 문제가되지 않습니다. 종이나 컴퓨터에 모든 것을 넣습니다. 위키를 사용하여 정보를 공유하십시오. 방법론에 대해서는 민첩한 방법론을 선호합니다 (단순하게, 민첩성은 소프트웨어 개발을위한 세련된 이름입니다). 또한이 분야에 대한 전문 지식을 가진 사람을 고용하여 핵심 프로그램에 집중할 수 있도록 관리합니다. 결론적으로 모든 프로젝트 관리 방법론은 프로그램의 성공을 보장하는 방법 일뿐입니다. 다른 사람이 가장 추천하는 것을 선택하는 대신 자신과 팀에 적합한 사람을 선택할 수 있습니다. 또한 다음 소프트웨어가 도움이 될 수 있습니다.

  • 무료 마인드-마인드 매핑 소프트웨어
  • Trac-빠르고 쉬운 소프트웨어 버그 프로그램 및 위키
  • MoinMoin-프로그램에 대한 지식 공유를 가능하게하는 빠른 위키

위의 팁은 장기적으로 가치가있는 학습 곡선이 필요합니다. 마지막으로 프로그래밍은 Photonic Engineering보다 쉽습니다 (C ++ 프로그래밍은 아님).


0

귀하의 질문처럼 귀하에게 유용한 답변은 매우 길고 모호합니다. 그러나 짧은 대답은 "소프트웨어 엔지니어링"입니다.

소프트웨어 개발 경력에 대해 진지한 경우 가능한 한 많은 자유 시간을 지우고 Steve McConnells 사이트 를 방문하여 시작하는 것이 좋습니다. 프로그래밍은 쉬우 며 한 학기에 가르 칠 수 있으며, 소프트웨어 엔지니어링은 훨씬 더 복잡하고 배우는 데 더 오랜 시간이 걸립니다.

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