프로그래밍 방법과 프로그래밍 방법을 알고 있지만 시스템을 올바르게 만드는 방법 / 어떻게 배울 수 있습니까? [닫은]


11

시스템을 만들 때 고려해야 할 사항이 많이 있습니다. 예를 들어 사용자가 서로 로그인하고 상호 작용하여 콘텐츠를 만들고 편집하는 웹 기반 시스템을 예로 들어 보겠습니다. 이제 보안, 유효성 검사에 대해 생각해야합니다 (수행이 100 % 확실하지 않다고 생각합니다). 예기치 않은 상황을 통해 데이터베이스 데이터에 문제가 없는지 확인하십시오. 어떻게, 어디서 배울 지 모르는이 모든 것들에 대해 이런 종류의 책이 있습니까? 내가 말한 것처럼 코드 작성과 실제로 올바른 코드 작성 간에는 큰 차이가있는 것 같습니다. 현재 프로그래밍 작업에 설명 된 내용이 부족하고 나중에 발생하는 문제를 볼 수 있다고 생각합니다. 데이터가 존재하고 사람들이 사용하기 때문에 문제를 해결하기가 훨씬 어렵습니다. 그렇다면 누구나이 유형의 학습에 대한 책이나 리소스 또는 프로그래밍의 적절한 하위 집합 (?)을 가리킬 수 있습니까?

추신 : 태그를 자유롭게 수정하십시오. 내가 무슨 말을하는지 모르겠습니다.

편집 : 필자가 작성한 예제 중 일부는 다른 유형의 시스템에도 적용된다고 가정합니다. 웹 작업에 주로 관여했기 때문에 다른 좋은 예를 알지 못합니다.

답변:


10

내가 알 수있는 한 전문 프로그래머는 다음 세 가지 주요 방법을 배웁니다.

  1. 나쁜 경험으로부터 배우기 -당신 은 잘못된 것을 겪 습니다. 고치세요 "이봐 요, 다시는 안 돼요. 다음에는 X를하겠습니다." 당신은 분명히 그 두께에 있습니다.
  2. 나쁜 경험을하기 전에 배우기 -결국에는 어떤 종류의 문제가 오는지 알게됩니다. 당신이 할 때, 당신은 그것을 피하려고 노력할 것입니다. 아마도 책을 읽거나 웹을 검색하거나 실험을 해보는 것도 있습니다.
  3. 숙련 된 동료로부터 배우기 -여전히 쉽지는 않지만 가장 쉬운 방법입니다. 요령은 동료가 여전히 관련된 나쁜 경험에 반응하고 있는지 파악하는 것입니다. 결국 기술은 발전합니다.

나는 당신이 세 가지 모두를 촬영하도록 권장합니다. 똑똑하고 경험이 풍부한 동료와 함께 질문을 할 장소를 찾으십시오. 많은 일을 시도 할 수 있도록 일찍 그리고 자주 배송 할 수있는 장소인지 확인하십시오. 그리고 연구와 반성을위한 시간이 걸립니다.


# 1)에 관해서는, 당신이 배우는 나쁜 경험과 실수가 반드시 자신의 것이 될 필요는 없다는 것을 명심하십시오. 웹에서 시간을 보내거나 프로그래머가있는 곳에서 놀거나 프로그래머가 겪은 미친 실수에 대한 공포 이야기를 배우고 프로그래밍 할 때 머리 뒤에 두십시오.
Shadur

1
동의합니다, Shadur, 그러나 나는 나쁜 경험 중 일부는 당신 자신의 것이되어야한다고 생각합니다. 어떤 사람들은 부업에 앉아 완벽한 것을 만들 수있을 때까지 기다립니다. 그러나 그들은 실제로 거기에 들어가서 기술을 향상시키고 싶다면 만들기 시작해야합니다.
William Pietri

4

웹 응용 프로그램에 관해서는, 내가 본 다른 장소 보다이 답변에 컴파일 된 더 좋은 정보 가 있습니다.

그러나 현실은 완전한 시스템을 잘 구성하기 위해 알아야 할 것이 많다는 것입니다. 숙달 수준에 도달하는 데 필요한 연습 의 양으로 10,000 시간을 지원하는 연구가 있으며 정보 시스템 개발도 예외는 아닙니다.


그렇다면 다른 점이 다르다고 생각합니다.
MetaGuru

예를 들어, 웹 앱과 관련된 많은 문제가 있으며 더 많은 문제가 더 일반적입니다. 당신이 무엇을 요구하는지 완전히 이해하지 못합니다.
quentin-starin

3

나는 William Pietri의 답변을 많이 좋아하지만 (+1) 추가해야한다고 생각합니다. 시스템이 의미하는 바는 전적으로 소프트웨어로 구성되어 있다고 가정합니다.

그러나 그것의 고기에 들어가기 전에, 나는 도울 책을 모른다. 다음에 오는 모든 것들은 경험에서 배웠습니다 (윌리엄이 세 가지 점을 의미 함).

당신이 말하는 것은 최소한 네 가지 광범위한 역할에 걸쳐 있습니다. 때로는 한 사람이 중소 규모의 프로젝트에 대해 모든 역할을 수행 할 수도 있지만 대규모 프로젝트를 시작할 때는 최소한 그 역할을 분리해야합니다. 모든 사람이 의미있는 방식으로 전문가가 되기는 어렵습니다.

  1. 비즈니스 분석가

    고객과 대화하고 요구 사항을 건축가가 이해할 수있는 것으로 해석하는 사람입니다. 기본적으로 올바르게 구성된 요구 사항 목록 여기에는 명백한 기능 요구 사항 (이 시스템이 제공해야하는 것)과 비 기능 요구 사항 (시스템이 충족해야하는 일반적인 특성은 무엇입니까? 여기에는 보안, 안정성, 가용성, 복원력, 용량, 성능, 견고성 및 사용자 관점에서의 다른 요구 사항).

    이것은 시스템이 무엇을해야하는지에 대한 첫 번째 단계이며, 진지한 사고의 시작입니다.

  2. 시스템 아키텍트

    이 사람은 작업 할 수있는 고급 기술 프레임 워크를 생성합니다. 그들은 개요 일치 계획을 제공합니다. 일반적인 도구, 기술, 구성. 그들은 전체 시스템을 더 작은 구성 요소로 나누고 서로 어떻게 어울리는 지, 외부 세계와 어떻게 어울리는 지 ...

    이것은 여러 가지면에서 생각해야 할 사항을 개선하는 데 도움이됩니다. 비즈니스 분석가가 작성한 요구 사항에 대해 해당 단계에서 종종 문제가 발견됩니다. 그들이 원하는 것에 대한 이해와 표현에 대한 이해를 향상시키기 위해 반복을 위해 그들에게 돌아갑니다.

  3. 시스템 디자이너

    이 역할은 모든 기능을 수행하는 방법에 관한 것입니다. 이것은 한 사람의 쇼보다 더 많은 팀워크 일 수 있습니다. 그러나 전체 시스템 설계를 감독하는 리드 디자이너가있을 수 있습니다. 이 사람은 세부 사항을 파고 건축가의 시야가 실제로 구축 할 수있는 것이어야합니다.

    시스템 아키텍처와 비즈니스 분석의 추가 개선이 필요합니다.

  4. 테스트 관리자

    이 역할은 종종 잊혀집니다. 그러나 하루가 끝나도 테스트 할 수 없다면, 그것을 만들 수 있다는 것을 어떻게 증명할 수 있습니까? 모든 단계의 결과에 대한 검토가 필요합니다 : 테스트에 능숙한 사람에 의한 비즈니스 분석, 아키텍처 및 설계 : 결함을 강조하고 코드를 작성하기 전에 조기에 정정 할 수있는 사람.

간단한 요약입니다.

그 녀석 / 놈들은 체인에서 밀 사람들이 일반적으로 운영하는 것에 대해서만 생각해야합니다.

대규모 은행 업무 또는 우주 응용 프로그램과 같은 복잡한 프로젝트의 경우 두 가지 예 (수백에서 수천 명에 이르는 인력) 만 고려하면 모든 단계에서 프로젝트를 검토하고 지원하기 위해 많은 주제 전문가가 있습니다. 이러한 역할에는 보안 분석, 시스템 크기 조정, 용량, 성능, 데이터베이스, 클러스터링 및 정밀한 비즈니스 영역을 포함한 기타 좁은 전문 영역이 포함됩니다. 다양한 역할은 시스템의 크기와 복잡성에 따라 다릅니다.

모든 것을 시도하고 알면 안된다고 말하면 안됩니다. 그러나 전체적인 그림과 작은 프로젝트를 파악할 수 있습니다. 복잡성의 수준이 더 둥글게되어 있기 때문에 큰 프로젝트보다 훨씬 더 많은 것을 탐구 할 수 있습니다.

시스템 설계 방법을 알고 싶다면 상자 밖에서 생각하여 질문을 시작해야합니다. 고객의 입장에서 충분한 노력을 기울이고 무엇이 잘못 될 수 있으며 무엇을 테스트해야하는지 생각해보십시오. 그런 다음 실제 고객과 함께 모여 필요한 시스템의 범위와 한계를 설명하도록합니다. 또한 '고객'이라고 말할 때마다 여러 다른 사람들이 여기에 해당한다는 것을 이해해야합니다. 하루 종일 시스템을 사용하도록 설계된 사람이 있습니다. 운영자, 기술 지원, 보고서 또는 기타 보고서가 필요한 관리자, 감사 자, 인프라 팀, 비용을 지불 한 이해 관계자, 시스템을 테스트 할 수단이 필요한 품질 관리자가 있습니다. 그들은 한 사람이고 한 번에 하나씩 모든 모자를 착용하도록 요청하십시오.) 필요한 것을 모두 요청하면 시스템 요구 사항이 무엇인지 알 수 있습니다. 거기에서 아키텍처와 디자인을 파생시킬 수 있습니다.

복잡한 시스템의 경우 (소프트웨어 만 또는 가장 일반적인 의미로 하드웨어와 통합하는 경우) 위에 나열된 네 가지 역할 각각에 대해 한 사람만으로는 충분하지 않을뿐만 아니라 시스템이 무엇을 정의해야하는지에 대한 정의도 프로젝트 관리해야합니다. 다른 단계는 물론입니다.

HPH, asm.


2

여기서 배울 것은 이런 종류의 것들에 관한 책이 있습니까?

"책"이 아닙니다. 많은 책.

왕도 없다

내가 말했듯이 코드 작성과 실제로 올바른 코드 작성 사이에는 큰 차이가있는 것 같습니다

권리.

당신은 "아키텍처"에 대해 이야기하고 있습니다.

1 단계. 많은 코드를 읽으십시오. 진짜 많이 하고 싶은 일을 생각하십시오. 관련 오픈 소스 프로젝트를 찾으십시오. 코드를 읽으십시오. 그것의 모든.

2 단계. 더 많은 코드를 읽으십시오. 훨씬 더.

3 단계. 건축에 관한 책을 읽습니다.


2
읽고, 읽고, 읽습니다. 그러나 실제 시스템을 실제로 구현할 때 배우는 것과 동일하지 않다는 것을 제안해야합니다.
quentin-starin

@qes : 문제는 "시스템을 올바르게 만드는 방법을 어디에서 배우는가?"였습니다. 실제 시스템을 잘못 구축하여이를 배울 수는 없습니다. 실제로 실제 시스템을 잘못 구현하는 것은 학습과 정반대입니다.
S.Lott

3
Code Complete에서 내가 가장 좋아하는 것 중 하나 : "소프트웨어 엔지니어링 분야는 과거의 성공과 실패의 예를 매우 제한적으로 사용합니다. 건축에 관심이 있다면 [유명한 건축가]의 그림을 연구 할 것입니다 ... 일부 건물을 방문하십시오 ... ".
Jacob

@ S.Lott : 누가 그것을 잘못한 것에 대해 말했습니까?
quentin-starin

@ qes : 선행 기술을 읽지 않고 대규모 프로그램을 잘 수행 할 가능성은 무엇입니까? 자신과 같은 천재의 경우, 모든 규모와 규모에 상관없이 좋은 프로그램을 작성하는 것이 가능할 수 있습니다. 그러나 대규모 프로그래밍을 보지 않은 다른 사람들에게는 아무것도 읽지 않고 큰 시스템을 구현하는 것으로 시작하는 것이 실수를 많이 포함하는 무언가를 작성하는 길입니다. 당신의 경험은 다를 수 있지만, 나는 먼저 읽지 않고 일할만큼 똑똑하지 않다는 것을 알고 있습니다.
S.Lott

1

많은 책을 읽고 증폭하려면 ....

이제 당신은 문제가 있음을 알고 있습니다.이 책들을 읽도록 지시 할 때가 있습니다. (실제 작업을 수행하기 전에이 책에 대해 논의 할 점이 거의 없습니다.)

프로그램 디자인 1,2,3 및 4의 감마, 헬름, 존슨 및 Vlissides 패턴 언어에 의한 디자인 패턴

그러나 모든 패턴을 사용할 수있는 곳이면 어디든 적용하지 마십시오.

그것도 나쁜 것입니다.

도움이 되었기를 바랍니다.


1

무엇을하는 방법을 배우는 가장 좋은 방법은 그것을하는 것입니다. 프랑스어를 사용하는 방법을 배우려면 프랑스어를 말하고 프랑스어를 읽고 프랑스어를 쓰고 프랑스어에 대해 읽고 프랑스에 가서 프랑스 사람들과 프랑스어로 대화해야합니다. 피아노를 연주하는 방법을 알고 싶다면 실제로 피아노를 연주해야합니다. 간단한 노래를 연주하고 피아노의 구조와 음악의 구조를 배워야합니다. 음악을 읽는 방법과 손가락을 사용하여 피아노를 통해 음악을 표현하는 방법을 배워야합니다. 기타 나 플루트 나 색소폰이 할 수있는 것과 음악이 어떤 소리를 내는지, 피아노가 어떤 종류의 소리를 낼 수 있는지 알아야합니다.

프로그래밍은 정확히 동일합니다. 데이터베이스를 디자인하는 방법을 알고 싶다면 데이터베이스를 디자인해야합니다. 암호화를 이해하려면 암호화 알고리즘 및 암호화 프로토콜을 구현하십시오. 여러 사용자에게 동시에 서비스를 제공 할 수있는 소프트웨어를 작성하려면 디스크 IO, 네트워크 IO 및 스레드 작동 방식을 이해해야합니다. 작동 방식을 이해하려면 파일에서 읽고 쓰는 코드를 작성하고 네트워크를 통해 데이터를 전송하며 리소스에 대한 액세스를 동기화하십시오. 이 모든 것은 연습이 필요합니다.

"시스템"은 일반적으로 물건의 모음입니다. 전체를 구성하기 위해 조정되는 조각. 큰 것을 만들려면 작은 부품을 많이 만들어야합니다. 따라서 시스템 구축 방법을 배우려면 시스템 구축을 시작하십시오. 문제를 해결하고 조각으로 나누고 각 조각을 하나씩 구현하십시오. 결국 당신은 통합 된 "시스템"을 갖게 될 것입니다. 당신은 아마 길을 따라 몇 번 실패 할 것입니다,하지만 괜찮습니다. 당신이 실패하지 않으면 그것은 일반적으로 당신이 충분히 열심히 노력하지 않는 것을 의미합니다.

또한 컴퓨터 과학을 공부하기 위해 학교에 갈 것을 권장합니다. "연습"부분에는 큰 도움이되지 않습니다. 직접해야하지만 노출 부분에 도움이됩니다. 컴퓨터와 컴퓨터 시스템의 작동 방식과 관련된 거의 모든 것에 대해 많은 것을 배우게되는데, 이는 스스로 배우기가 어렵습니다.


1
+1, 그냥하는 것만으로는 충분하지 않다고 제안하지만. 일정 시간이 지난 후 동일한 코드를 다시 방문 할 때까지 제대로 수행했는지 나쁜지를 알 수 없습니다. 그럼에도 불구하고 무언가 잘못되었다는 것을 알 수는 있지만 어떻게 개선 할 수는 없습니다. 이 모든 것을 바로 잡는 한 가지 방법은 배우려는 것에 더 많은 경험이있는 사람들로부터 많은 promtp 피드백을 보장하는 것입니다. 그렇습니다. "do"는 매우 중요하지만 학습 과정 속도를 높이기 위해 할 수있는 일에 대한 피드백입니다.
Marjan Venema
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.