디자인 및 코딩 - 위에서 아래 또는 하단에서 상단까지? [닫은

Question

코딩 할 때 경험에서 더 나은 접근 방식은 무엇입니까?

1. 문제를 충분히 작은 조각으로 나눈 다음 각 조각을 구현하십시오.
2. 문제를 분해 한 다음 하향식 접근법을 사용하여 구현하십시오.
3. 다른 사람?

Answer 1

내가하는 일은 다음과 같습니다.

먼저 도메인을 이해하십시오. 해결해야 할 문제를 이해하십시오. 당신과 고객이 (고객이라도!)가 어떤 문제를 해결 해야하는지에 대해 같은 페이지에 있는지 확인하십시오.

그런 다음 문제에 대한 높은 수준의 솔루션이 제안되며, 그로부터 디자인은 페이지 등의 기포 나 총알로 변할 것이지만 요점은 설계 할 수있는 구성 요소로 흔들릴 것입니다.

그 시점에서 나는 아직 서면으로 작성되지 않은 수업에 대한 테스트를 작성한 다음 수업을 통해 그 테스트를 통과합니다.

테스트 우선 접근 방식을 사용하고 빌드 작업, 테스트 구성 요소를 작성합니다. 그것이 저에게 적합한 것입니다. 구성 요소 인터페이스가 알려지고 '규칙'이 서로 대화하고 서로에게 서비스를 제공하는 방법으로 알려져 있으면 일반적으로 간단한 '모든 것을 함께 연결'하는 운동이됩니다.

그것이 내가하는 방식이며, 그것은 나를 위해 잘 작동했습니다.

Answer 2

하향식을 설계하고 상향식을 구현하는 경향이 있습니다.

구현을 위해서는 가장 작은 기능적 조각을 구축하고 더 높은 수준의 구조로 조립하는 것이 저에게 가장 적합한 것 같습니다. 그러나 디자인을 위해서는 전체 그림에서 시작하여 해당 작품이 무엇인지 결정해야합니다.

Answer 3

당신은 다음을보고 싶을 수도 있습니다 민첩한 선언. 상단 아래와 바닥은 한 번에 디자인과 구성을 모두 구축합니다.

"포괄적 인 문서를 통한 작업 소프트웨어"는 가장 먼저 구축하는 것이 실행할 수있는 가장 작은 유용한 것임을 의미합니다. 맨 위? 맨 아래? 어느 것도 아니다.

---

어렸을 때, 나는 계약에 따라 엄격하게 최우선 프로젝트를 진행했습니다. 이것은 작동하지 않습니다. 실제로, 그것은 작동 할 수 없습니다. 결과적으로 중복 디자인과 코드의 산을 얻습니다. 무의식적으로 적용했을 때 건전한 접근 방식이 아니 었습니다.

내가 알아 차린 것은 민첩한 접근법 (작용하는 작은 조각)이 문제를 한 번에 파악할 수있는 부품으로 나누는 경향이 있다는 것입니다. 하향식/상향식은 더 이상 중요하지 않습니다. 실제로, 그것은 전혀 중요하지 않을 수 있습니다.

"민첩한 개발을 위해 어떻게 분해합니까?" 속임수는 창조를 피하는 것입니다 큰 것 그런 다음 분해해야합니다. 문제를 분석하면 배우가 모든 정보를 가지고 있지 않거나 시간이 지남에 따라 있지 않거나 결정을 실행할 수 없기 때문에 사용 사례를 달성하고 실패하려고합니다.

종종 이것들은 분해가 필요한 큰 것이 아닙니다. 그들이있을 때, 당신은 거꾸로 목표 방향. 목표에서 목표를 달성 할 수있는 것까지, 인 에이 블러 등을 가능하게하는 것들로 만들 수있는 것까지 목표는 종종 큰 일이기 때문에 일반적인 비즈니스 목표에서 상세한 비즈니스 프로세스 및 단계에 이르기까지 최우선 경향이 있습니다.

어느 시점에서, 우리는 목표로 이어지는 다양한 단계를 개요합니다. 우리는 분석 부분을 수행했습니다 (문제를 해결). 이제 합성 부분이 온다 : 우리는 실제로 우리가 가지고있는 것을 실제로 구축 할 수있는 것들로 재 조립합니다. 합성이 상향식입니다. 그러나 쫓겨나 지 마십시오. 우리는 몇 가지 관점이 있으며, 각각은 다릅니다.

우리는 모델이 있습니다. 이것은 종종 세부 사항에서 더 큰 개념 모델로 만들어집니다. 그런 다음 때때로 OLTP에 대해 정규화 된 모델로 다시 분해됩니다. 또는 OLAP에 대해 정규화 된 스타 스키마로 분해됩니다. 그런 다음 정규화 된 모델에서 ORM 매핑을 만들기 위해 다시 작업합니다. 위로 - 다운 - 위로.

우리는 처리가 있습니다. 이것은 종종 비즈니스 프로세스 요약에서 처리 단계의 세부 사항으로 구축됩니다. 그런 다음 소프트웨어는 단계를 중심으로 설계되었습니다. 그런 다음 소프트웨어는 클래스와 방법으로 나뉩니다. 다운 - 위로 - 아래로.

[탈퇴. 깨달은 사용자의 경우이 분해는 새로운 직책과 작업 방식을 정의합니다. 가벼운 사용자와 함께, 오래된 일자리는 머무르고 우리는 오래된 일자리를 새로운 소프트웨어에 매핑하기 위해 문서의 산을 씁니다.

구성 요소가 있습니다. 우리는 종종 조각을보고, 사용 가능한 구성 요소에 대해 알고있는 것을보고, 일종의 일치합니다. 이것은 가장 임의의 과정입니다. 결정이 형성되는 방식과 유사합니다. 핵 생성 중심이 있으며 그 중심 주위에 디자인의 종류가 굳어집니다. 웹 서비스. 데이터 베이스. 거래 관리. 성능. 용량. 어떻게 든 솔루션의 일부 또는 전부를 구현하는 구성 요소를 선택하는 데 도움이되는 다양한 기능입니다. 종종 상향식을 느낍니다 (기능에서 제품으로). 때로는 하향식 ( "망치를 잡고있는 모든 것을 잡고 손톱이라고 부릅니다"== RDBMS를 모든 것에 사용하십시오.)

결국 우리는 코딩해야합니다. 이것은 상향식입니다. 거의. 패키지 구조를 정의해야합니다. 클래스를 전체적으로 정의해야합니다. 그 부분은 맨 위로 내려 갔다. 수업 내에서 방법을 작성해야합니다. 나는 종종이 상향식을한다-방법을 거칠게하고, 단위 테스트를 작성하고, 방법을 완료한다. 다음 방법을 거칠게하고 단위 테스트를 작성하고 방법을 완료하십시오.

운전 원리는 민첩합니다. 작동하는 것을 구축하십시오. 세부 사항은지도 전체에 있으며, 위쪽, 다운, 전면, 후면, 데이터, 프로세스, 행위자, 주제 영역, 비즈니스 가치.

Answer 4

예. 그 모든 일을하십시오.

그것은 냉소적 인 것처럼 보일지 모르지만 (죄송합니다. 형태로 되돌아갑니다) 이것은 실제로 정답이없는 경우입니다.

Answer 5

Also in the agile way, write your test(s) first!

Then all software is a continual cycle of

• Red - the code fails the test
• Green - the code passes the test
• Refactor - code improvements that are intention-preserving.

defects, new features, changes. It all follows the same pattern.

Answer 6

Your 2nd option is a reasonable way to go. If you break the problem down into understandable chunks, the top down approach will reveal any major design flaws before you implement all the little details. You can write stubs for lower level functionality to keep everything hanging together.

Answer 7

I think there's more to consider than top- verses bottom-down design. You obviously need to break the design up into manageable units of work but you also need to consider prioritisation etc. And in an iterative development project, you will often redefine the problem for the next iteration once you've delivered the solution for the previous one.

Answer 8

When designing, I like to do middle-out. I like to model the domain, then design out the classes, move to the database and UI from there. If there are specific features that are UI-based or database-based, I may design those up front as well.

When coding, I generally like to do bottom-up (database first, then business entities, then UI) if at all possible. I find it is a lot easier to keep things straight with this method.

Answer 9

I believe that with good software designers (and in my opinion all software developers should also be software designers at some level), the magic is in being able to do top-down and bottom-up simultaneously.

What I was "schooled" to do by my mentors is start by very brief top-down to understand the entities involved, then move to bottom-up to figure out the basic elements I want to create, then to back up and see how I can go one level down, knowing what I know about the results of my bottom up, and so forth until "they meet in the middle".

Hope that helps.

Answer 10

Outside-in design.

You start with what you're trying to achieve at the top end, and you know what you've got to work with at the bottom end. Keep working both ends until they meet in the middle.

Answer 11

I sort of agree with all of the people saying "neither", but everyone falls somewhere on the spectrum.

I'm more of a top-down kind of guy. I pick one high level feature/point/whatever and implement it as a complete program. This lets me sketch out a basic plan and structure within the confines of the problem domain.

Then I start with another feature and refactor out everything from the original that can be used by the second into new, shared entities. Lather, rinse, repeat until application is complete.

However, I know a lot of people who are bottom up guys, who hear a problem and start thinking about all the support subsystems that they could need to build the application on top of it.

I don't believe either approach is wrong or right. They both can achieve results. I even try and find bottom up guys to work with, as we can attack the problem from two different perspectives.

Answer 12

Both are valid approaches. Sometimes one just "feels" more natural than the other. However, there is one big problem: some mainstream languages and especially their frameworks and libraries really heavily on IDE support, such as syntax highlighting, background type checking, background compilation, intelligent code completion, IntelliSense and so on.

However, this doesn't work with top-down coding! In top-down coding, you constantly use variables, fields, constants, functions, procedures, methods, classes, modules, traits, mixins, aspects, packages and types that you haven't implemented yet! So, the IDE will constantly yell at you because of compile errors, there will be red squiggly lines everywhere, you will get no code completion and so on. So, the IDE pretty much prohibits you from doing top-down coding.

Answer 13

I do a variant of top-down. I tend to try and do the interface first - I then use that as my list of features. What's good about this version is, it still works with IDE that would otherwise complain. Just comment out the one function call to what's not yet been implemented.