구조 바위. 우리는 프로그램을 구성하고 가능성, 오류, 솔루션 등을 탐색하는 방법을 배웁니다. - 페이지 4

 
C-4 :

그리고 프로젝트 중간 또는 거의 끝나갈 무렵에 고객이 갑자기 바뀌면 명확한 구조는 어떻게 됩니까?

  • 초기 청구의 5%;
  • 초기 클레임의 10%;
  • 초기 청구의 25%.

이것은 프로젝트가 변경에 대한 준비가 되어 있고 변경에 저항하는 방법을 보여주는 좋은 테스트입니다.

이것이 문제입니다. 그래서 제가 이 스레드에 있는 것입니다.

나는 그의 위시리스트가 만족하고 프로젝트가 중단되지 않도록 그러한 방식으로 디자인 하는 방법(또는 그러한 프레임워크에 고객을 밀어 넣는 방법)에 대한 답을 찾고 싶습니다.

위협, 결국 메달에는 양면이 있습니다. 한편으로는 프로젝트를 변경할 수 있고 다른 한편으로는 "아니요, 이것은 이 프로젝트의 틀 내에서 할 수 없습니다"라고 말할 수 있습니다. 진실은 중간 어딘가에 있습니다.

가장 좋은 점은 고객의 본질적인 바램이 대부분 실현될 수 있도록 개발을 설계하는 것입니다.

 
C-4 :
이제 일반 프로그래머는 순서도를 그리지 않습니다. 이 모든 것은 학생들을 가르치기 위해 고안된 이론적 넌센스이지만 실제 프로젝트에서 작업하기 위한 것은 아닙니다.

그것은 모두 당신이 종이에 쓰는 것에 달려 있습니다.

나는 글쓰기를 지지하는 편은 아니지만, 가끔은 종이에 전체적인 구조를 그려야 하는 경우가 있다. 편리하고 빠르며 보석상을 위한 제품 스케치와 같으며 일반적으로 그림이 선명해야 합니다.

순서도를 그리지 않는 비정규 프로그래머로 가득 차 있기 때문일 것입니다.

 
C-4 :
이제 일반 프로그래머는 순서도를 그리지 않습니다. 이 모든 것은 학생들을 가르치기 위해 고안된 이론적 넌센스이지만 실제 프로젝트에서 작업하기 위한 것은 아닙니다.
글쎄, 나는 그것을 너무 날카롭게 "이론적 넌센스"라고 부르지 않을 것입니다. 어떤 형태로든 종이에 "화살표가 있는 사각형"을 그리는 것은 프로그래밍에서 널리 사용됩니다. 최소한 동일한 UML을 사용하십시오 - "사각형이 있는 화살표". :) 따라서 초기 단계 의 블록 다이어그램이 유용 할 수 있습니다 ...
 
C-4 :
이제 일반 프로그래머는 순서도를 그리지 않습니다.
블록다이어그램이 없습니다. 그리고 여전히 건축을 그려야 합니다.
 
sanyooooook :

순서도를 그리지 않는 비정규 프로그래머로 가득 차 있기 때문일 것입니다.

;)
 
MetaDriver :
글쎄, 나는 그것을 너무 날카롭게 "이론적 넌센스"라고 부르지 않을 것입니다. 어떤 형태로든 종이에 "화살표가 있는 사각형"을 그리는 것은 프로그래밍에서 널리 사용됩니다. 최소한 동일한 UML을 사용하십시오 - "사각형이 있는 화살표". :) 따라서 초기 단계 의 블록 다이어그램이 유용 할 수 있습니다 ...

UML, 헛소리(IMHO)의 도움으로 디자인 을 시도했습니다.

머리에 화살표가 있는 이 모든 사각형을 완벽하게 유지하지만 추상화가 머리에 맞지 않아 스케치합니다.

더 깊이 파고들면 위협 인간의 뇌는 그림, 지도, 행동 패턴을 기억하는 데 적합하지만 아무리 추상화를 구축하지 않아도 추상화는 사람에게 가장 어려운 작업입니다.

따라서 ZZY는 항상 추상화를 보다 친숙한 것으로 공식화하기 위해 노력합니다.

 
Urain :

더 깊이 파고들면 위협 인간의 뇌는 그림, 지도, 행동 패턴을 기억하는 데 적합하지만 아무리 추상화를 구축하지 않아도 추상화는 사람에게 가장 어려운 작업입니다.

따라서 ZZY는 항상 추상화를 보다 친숙한 것으로 공식화하기 위해 노력합니다.

동의한다.

무엇을 할까요? 그게 우리의 방식입니다. 나는 이 분야에서 내 자신의 두뇌를 자극하는 나만의 방법이 있고 심지어 소프트웨어 개발도 있지만(때때로 공유할 수 있음) 개발은 매우 느립니다(돌아보면 눈에 띌지라도).

--

좀 더 걸어. 좋은 주제. 어떤 의미에서 모든 것과 모든 프로그래밍은 추상화로 작동하지만 추상적인 개념으로 실제로 작동하는 수준과 기술에는 큰 차이가 있습니다.

 
MetaDriver :

동의한다.

무엇을 할까요? 그게 우리의 방식입니다. 나는 이 분야에서 내 자신의 두뇌를 자극하는 나만의 방법이 있고 심지어 소프트웨어 개발도 있지만(때때로 공유할 수 있음) 개발은 매우 느립니다(돌아보면 눈에 띌지라도).

--

좀 더 걸어. 좋은 주제. 어떤 의미에서 프로그래밍의 모든 것과 모든 사람은 추상화 작업을 하고 있지만 추상화의 실제 작업 수준과 기술에는 큰 차이가 있습니다.

우리는 추상화를 위해 추상화에 관심이 없잖아요?

우리가 진화적으로 추상화에 가장 잘 적응하지 않았기 때문에 제 생각에는?! (아마도, 적어도 이 행성의 다른 주민들보다 낫습니다) 목발을 만들 가치가 있습니다.

예를 들어, 사람들은 브레인스토밍과 같은 기술을 발명했습니다.

나는 종종 엔티티의 이름을 지정하는 방법에 대해 문제가 있습니다. 이해하기 쉽고 매우 짧은 이름을 지정합니다. 이것이 성공하면 추상화는 소화하기 쉽습니다.

ps. 지금 글을 많이 못써서 죄송합니다(휴대폰으로 하기 불편합니다). 내일은 더 좋다.

 
나는 구조 형태의 솔루션이 그 자체로 마음에 들지 않으면 TOR를 읽었습니다. 다른 프로젝트 의 회전율을 처리합니다. 일반적으로 첫 번째 날에는 구현을 시작하지 않습니다. 프로그램이 MKL 또는 HTML이 아닌 경우 구현 변형, 구조, 유형, 클래스를 읽고 계산합니다. 전체적인 그림이 머릿속에 떠오르면 블록을 자르거나 주요 모듈을 작성하기 시작합니다. 뭔가 서두르지 않으면 테트리스 같은 장난감을 가지고 소파에 쓰러지고, 문제가 완전히 풀릴 때까지, 아니면 지루해질 때까지 놀아요 :)
 
Urain :

ps. 지금 글을 많이 못써서 죄송합니다(휴대폰으로 하기 불편합니다). 내일은 더 좋다.

괜찮아요. 나에게도 시간이 지나면서 오늘은 그렇게 덥지 않다. 나는 그 분기가 영구적이기를 정말로 희망한다("오류, 버그, 질문"과 같은). 논의의 형식만 차츰 건설적인 방향으로 자리 잡게 된다면.