엔지니어는 어떤 지식이 필요합니까?

진정한 자격을 갖춘 프로그래머가 되거나, 진정한 자격을 갖춘 일을 해낼 수 있다.

코드를 만드는 프로그래머가 가져야 할 자질.

1: 팀워크와 협력 능력

그것을 기본적인 자질로 생각하는 것은 중요하지 않다. 오히려 프로그래머가 가져야 할 가장 기본적인 것이다. (조지 버나드 쇼, 자기관리명언)

안식처의 가장 중요한 토대이기도 하다. 높은 수준의 프로그래머를 독행협이라고 부르는 사람은 모두 허튼소리, 어떤 개인의 권력이다.

수량이 제한되어 있어서 레너스와 같은 천재도 통과해야 한다.

강력한 팀을 구성하여 기적을 창조하다. 전 세계가 리눅스를 위해 핵심을 쓰는 고수들은 협력 정신이 전혀 없다.

상상하기 어렵다. 독행협은 작은 소프트웨어를 만들어 작은 돈을 벌 수 있지만, 일단 큰 시스템 연구에 들어가면,

한 팀을 개발하여 상업화와 상품화 임무에 진입하고, 부족하다.

이런 자질의 사람은 완전히 불합격이다.

2. 기록 습관

고급 프로그래머가 문서를 절대 쓰지 않는다고 말하는 사람들은 틀림없이 젖내도 마르지 않았을 것이다. 좋은 문서는 공식적인 연구개발이다.

그 과정에서 매우 중요한 부분 중 하나는 코드 프로그래머로서 근무 시간의 30% 가 기술 문서를 작성하는 것이 정상적이라는 점이다. (윌리엄 셰익스피어, 윈스턴, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머)

선임 프로그래머이자 시스템 분석가로서 이 비율은 훨씬 높다. 부족함

문서가 없으면 소프트웨어 시스템에 생명력이 부족하여 향후 오류 감지, 업그레이드 및 모듈 재사용에서 모두 발생할 수 있습니다.

귀찮아요.

3. 표준화 및 표준화 된 코드 작성 습관

외국의 몇몇 유명 소프트웨어 회사들의 규칙, 코드의 변수 명명, 코드의 주석 형식, 심지어 중첩과 같은 것들이다.

행 들여쓰기의 길이와 함수 사이의 빈 행 수는 모두 명확하게 정의되어 있습니다. 좋은 글쓰기 습관은 코드에만 도움이 되는 것이 아니다.

이식과 오류 수정도 서로 다른 기술자 간의 협조에 도움이 된다. 팬

S 아우성치는 고급 프로그래머가 쓴 코드는 다른 사람이 영원히 이해할 수 없다. 이런 소란은 그들이 자칭할 자격이 전혀 없다는 것을 증명할 수 있을 뿐이다.

프로그래머. 코드가독성이 좋다. 프로그래머의 기본 자질 요구 사항이다. 전체 리눅스 구조를 보세요.

표준화되고 표준화 된 코드 습관, 글로벌 연구 개발 없음

협력은 절대 상상할 수 없다.

4. 수요를 이해하는 능력

프로그래머는 모듈의 요구를 이해해야 한다. 많은 아이들이 프로그램을 쓸 때 종종 하나의 기능적 요구에만 집중한다.

과학자들은 모든 성능 지표를 하드웨어, 운영 체제, 개발 환경에 귀결시키고 자체 코드의 성능 고려 사항을 간과하고 있다.

어떤 사람들은 광고 교환 프로그램을 쓰는 것이 매우 간단하다고 자랑한 적이 있다. 이런 사람은 어디에서 왔습니까

수백만, 심지어 수천만 명의 방문이 있을 때 성능 지수가 어떻게 이루어졌는지 모르겠다. 이런 과정을 위해,

음순기, 네가 그에게 진한 파란색 시스템을 주면, 그도 태극체인의 병렬 접속 능력을 할 수 없다. 성능 요구 사항에서 안정성

, 병렬 액세스 지원 기능 및 보안은 프로그래머로서 매우 중요합니다.

시스템 운영 환경, 부하 압력 및 모듈의 다양한 잠재적 위험 및 악의를 평가합니다.

공격의 가능성. 이 시점에서 성숙한 프로그래머는 최소한 2 ~ 3 년의 프로젝트 개발 및 추적 경험이 필요합니다.

뭔가를 배울 수 있습니다.

재사용 가능성, 모듈 식 사고 능력

프로그래머들이 몇 년 동안 프로그램을 썼다고 불평하는 것을 자주 들을 수 있고, 숙련공이 되어 매일 그렇다. (윌리엄 셰익스피어, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머)

어떤 참신함도 없는 코드를 반복해서 쓰는 것은 사실 중국 소프트웨어 인재에 대한 가장 큰 낭비이며, 일정한 반복성을 가지고 있다.

일은 이미 숙련된 프로그래머의 주요 업무가 되었는데, 이것들은 사실 완전히 가능하다.

그것을 피하기 위해서.

재사용 가능한 디자인, 모듈식 사고는 프로그래머에게 모든 기능 모듈이나 기능을 완성하도록 요구하는 것이다.

더 많이 생각하고, 현재 임무를 완수하는 간단한 아이디어에 국한되지 말고, 모듈이 이 부서에서 벗어날 수 있는지 생각해 보세요.

시스템이 있습니다. 매개변수를 간단히 수정하여 다른 시스템 및 애플리케이션 환경에서 직접 참조할 수 있습니까

소프트웨어 R&D 단위와 워크그룹이 매번 개발될 수 있다면, 중복 개발 작업은 크게 피할 수 있을 것이다.

이러한 문제들은 모두 과정에서 고려되기 때문에 프로그래머들은 반복적인 업무에서 너무 많은 시간을 지체하지 않고 더 많은 시간을 가질 수 있다. (윌리엄 셰익스피어, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머)

혁신적인 코드 작업에 더 많은 시간과 에너지를 투자하십시오.

일부 좋은 프로그램 모듈 코드, 심지어 70 년대에 쓴 코드도 이제 작품으로 일부 시스템에 넣는다.

모든 기능 모듈은 잘 맞지만, 제가 지금 보고 있는 것은 많은 중소기업들이 항상 자신의 소프트웨어를 업그레이드하거나 개선하고 있다는 것입니다.

코드 재작성, 대부분의 반복적인 작업은 불필요한 시간과 정력이다.

6. 테스트 습관

상용화와 표준화가 발달하면서 전담 테스트 엔지니어가 필수적이지만, 그렇다고 해서

풀 타임 테스트 엔지니어로 프로그래머는 자체 테스트를 중지 할 수 있습니다. 소프트웨어 개발은 하나의 프로젝트로, 매우

중요한 특징은 문제를 빨리 발견할수록 문제 해결 비용이 낮을수록 절차가 많다는 것이다.

멤버들은 각 코드 세그먼트, 각 하위 모듈이 완료된 후 세심한 테스트를 실시하여 가능한 한 조기에 잠재적인 문제를 놓을 수 있다.

시스템의 발견과 해결은 전체 시스템 건설의 효율성과 신뢰성을 보장할 것이다.

사실 테스트는 두 가지 측면을 고려해야 한다. 한편으로는 정상적인 호출 테스트인데, 프로그램이 가능한지 아닌지를 보는 것이다.

정상 통화 하에서 기본 기능을 완성하는 것이 가장 기본적인 테스트 책임이지만, 많은 회사에서 유일한 테스트입니다.

시도 작업은 실제로 멀리 떨어져 있습니다; 두 번째 측면은 고압 부하에서의 안정성과 같은 비정상적인 호출 테스트입니다.

성적 테스트, 잠재적인 비정상적인 사용자 입력 및 모듈이 영향을 받는 경우 전체 시스템의 로컬 오류를 테스트합니다.

조건 테스트, 자주 비정상적인 요청이 리소스를 차단할 때의 모듈 안정성 테스트 등이 있습니다. 물론 프로그래머가 자신을 제대로 봐야 한다는 뜻은 아니다

모든 코드는 완전한 테스트가 필요하지만 프로그래머는 자신의 코드 작업을 잘 알고 있어야 합니다.

신체 프로젝트의 상태 및 다양한 성능 요구 사항, 관련 실험을 목표로 하고 가능한 한 빨리 문제를 발견하고 해결할 때

그러나 이를 위해서는 위에서 언급한 요구 사항을 이해할 수 있는 능력이 필요합니다.

7. 배우고 요약하는 능력

프로그래머는 인재가 쉽게 탈락하고 낙오되는 직업이다. 한 기술이 3 ~ 2 년 동안 지속될 수 있기 때문이다.

내부 리더십으로 프로그래머는 새로운 기술을 따라잡고 새로운 기술을 배워야 한다. (윌리엄 셰익스피어, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머)

공부를 잘하는 것은 어떤 직업으로든 진보의 필수 동력이다. 프로그래머에게 이 요구 사항은

더 높습니다. 하지만 공부도 목표를 찾아야 한다. 작은 코드와 코딩토가 바로 이렇다. (알버트 아인슈타인, 공부명언)

바로 Cfans 입니다. 자신의 학습 능력에 대해서도 이야기합니다. 그들은 ASP 와 ph 를 조금 배웠다.

P, 얼마 후 JSP 를 배우면 자랑의 자본으로 여기고 겉만 번지르르하고 피상적인 것을 쫓아다닌다.

시와 명사, 네트워크 프로그램으로서의 통신 전송 프로토콜, 응용 프로그램으로서의 인터럽트 벡터로 처리되는 것을 모릅니다.

인원은 아무리 많은 이른바 새로운 언어를 습득해도 결코 질적으로 향상되지 않을 것이다.

총화를 잘하는 것도 학습 능력의 한 표현이다. 연구 개발 임무를 완수하고, 코드를 완성할 때마다,

목적 추적 프로그램의 응용 상태 및 사용자 피드백을 위해 언제든지 요약하여 자신의 부족한 부분을 발견하고 하나를 해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 목적명언)

단계적으로 프로그래머가 성장할 수 있습니다.

성장하지 않은 프로그래머는 현재 고수일지라도 선택하지 말 것을 제안한다. 그가 낙오되었기 때문이다.

거의 때가 되었다. 위의 모든 자질을 갖춘 사람은 모두 자격을 갖춘 프로그래머여야 한다. 위에 주의하세요.

각종 자질은 IQ 가 결정한 것도 아니고, 일부 대학 교과서에서 배울 수 있는 것도 아니다. 필요한 것은 절차일 뿐이다.

직원들의 자신의 일에 대한 이해는 의식의 문제이다.

그래서 수석 프로그래머로서, 심지어 시스템 분석가로서, 프로그램 프로젝트의 디자이너들에게도 말이죠. (존 F. 케네디, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머)

, 위의 모든 자질 외에도 다음과 같은 자질이 필요합니다.

첫째, 수요 분석 능력.

프로그래머에게 요구 사항을 이해하면 자격을 갖춘 코드를 완성할 수 있지만 R&D 프로젝트의 구성 및 관리에는

관리자는 고객의 요구를 이해해야 할 뿐만 아니라 자신의 수요를 자주 제시해야 한다. 왜 그렇게 말하죠?

일반적으로 R&D 의 임무는 고객 또는 마케팅 부서에서 제출할 수 있습니다.

네, 이때 R&D 부서에 있어서 그들이 보는 것은 완전한 수요가 아닙니다. 일반적으로, 수요는

일부 기능 요구 사항 또는 보다 공식적인 경우 전체 사용자 보기를 얻을 수 있습니다. 하지만 그것으로는 충분하지 않습니다. 왜냐하면

고객의 경우, 더 많은 비기술적 요인으로 인해 완전하고 명확한 성능 요구 사항이나 전문적인 성능 요구 사항을 제시하기가 어려울 수 있습니다.

네, 하지만 프로젝트 주최자와 기획자에게는 이러한 요구 사항의 존재를 명확하게 이해하고 이를 완성할 수 있어야 합니다.

분석 보고서를 찾을 때는 적절하게 제출해야 하며, 프로세스를 용이하게 하기 위해 설계 사양에 충분히 명확하게 반영해야 합니다.

시퀀스 생성기가 인코딩되면 이러한 표준은 손실되지 않습니다.

프로그래머는 사용자 요구 사항이 있는 환경을 정확하게 이해하고 다음과 같은 용도에 맞는 요구 사항 분석을 해야 합니다

즉, ASP 임대 및 라이센스를 통해 배포되는 동일한 소프트웨어의 성능 요구 사항이 있을 수 있습니다.

차이점은 전자가 더 나은 지원 능력과 안정성을 강조하는 반면, 후자는 다양한 플랫폼을 강조할 수 있다는 것입니다.

설치 및 사용의 공통성과 단순성

둘째, 프로젝트 설계 방법 및 프로세스 처리 능력.

프로그래머는 최소한 2 ~ 3 가지 프로젝트 설계 방법 (예: 하향식 설계) 을 파악할 수 있어야 합니다

방법 (예: rapid prototyping 방법 등). ), 프로젝트 요구 사항 및 리소스 구성에 따라 적절한 설계 방법을 선택할 수 있습니다.

라인 항목의 전체 디자인. 디자인 방법의 부적절한 선택은 R&D 주기를 지연시키고 R&D 자원을 낭비하며 심지어 영향을 미칠 수도 있습니다.

좋은 연구 개발 효과.

프로그래머는 또한 순서도의 설계와 처리에 많은 시간을 할애해야 하는데, 그는 데이터 흐름도를 만들어야 한다.

데이터 사전 작성 그는 전체 시스템 처리 프로세스를 형성하기 위해 논리적 순서도를 처리해야 한다. 프로세스에 문제가 있습니다

시스템, 아무리 아름다운 코드, 아무리 정교한 모듈이라도 좋은 시스템이 될 수는 없다. 물론, 과정을 잘 수행하십시오.

좋은 프로젝트 설계 방법을 분석하고 선택하려면 수요 분석 능력을 잘 파악해야 한다.

셋째, 재사용 설계 및 모듈 분해 기능.

이것은 또 낡은 것 같다. 기본적인 자질은 이미 이 문제를 설명하지 않았는가? 노예로 삼다

모듈 임무의 프로그래머로서, 그는 자신이 직면하고 있는 특정 기능 모듈의 재사용 가능성을 고려해야 합니다.

시스템 분석가, 그가 직면해야 할 문제는 훨씬 복잡하며, 전체 시스템을 모듈식으로 분석해야 한다.

힘은 재사용 가능한 많은 기능 모듈과 기능으로 분해되어 각 모듈은 독립적인 설계 요구 사항을 형성합니다. 상승하다

예를 들어, 자동차 생산과 같은 경우, 처음에는 각 자동차가 독립적으로 설치되었으며 각 부품은 맞춤식이었습니다.

하지만 나중에는 달라졌다. 기계가 양산되었다. 한 자동차 공장이 조립 라인과 독립 부문을 통해 자동차를 생산하기 시작했다.

부품은 어느 정도 재사용성을 갖기 시작했고, 나중에는 표준화가 대세, 모델, 브랜드, 심지어 다른 제조업체로 바뀌었다.

자동차 부품도 쉽게 교체하고 업그레이드할 수 있어 자동차 생산의 효율성을 극대화할 수 있다.

소프트웨어 엔지니어링도 마찬가지다. 성숙한 소프트웨어 산업은 일부 관련 프로젝트와 시스템에서 다르다.

Microsoft 의 많은 데스크탑 소프트웨어, 많은 운영 모듈 (예: 파일 열기) 과 같은 구성 요소를 자유롭게 교체할 수 있습니다.

파일 저장 등. ) 는 재사용되는 동일한 기능 모듈 세트입니다.

일부 클래스 라이브러리를 통해 데스크톱 애플리케이션 개발자 후크를 쉽게 사용할 수 있으며 멀티플렉싱 모듈 설계에 잘 나타나 있습니다.

한 가지 증거.

거대하고 복잡한 애플리케이션 시스템을 비교적 독립적이고 재사용 가능한 애플리케이션 시스템으로 분해합니다.

또한 고급 프로그래머와 시스템 분석가인 몇 가지 매개변수로만 데이터 연결의 모듈 조합을 완성할 수 있습니다.

가장 중요한 작업, 적절한 프로젝트 설계 방법 및 명확한 흐름도는 이러한 목표를 달성하는 데 중요한 보증입니다.

넷째, 프로젝트의 전반적인 평가 능력

시스템 디자이너로서, 너는 반드시 대국에서 출발하여 프로젝트 전체에 대해 명확한 인식을 가질 수 있어야 한다. 예를 들면 회사의 것이다.

자원 배분이 합리적이고 제자리에 있는지 여부 (예: 프로젝트 진행이 효율성을 극대화하고 진행 요구 사항을 충족하지 못하는지 여부).

완료되었습니다. 전체 프로젝트와 각 모듈의 작업량을 평가하고, 프로젝트에 필요한 리소스를 평가하고, 프로젝트에 발생할 수 있는 문제를 평가합니다.

어려움은 대량의 경험 축적을 필요로 한다. 즉, 이것은 끊임없이 총결하고 축적해야 도달할 수 있는 경지이다. 존재

일부 서구의 소프트웨어 시스템 설계 책임자는 4, 50 세, 심지어 더 오래되어 코딩 방면에 있다.

겉으로는 젊은 사람들만큼 활동적이지는 않지만, 프로젝트 평가에서는 수십 년간의 경험 축적이 가장 많다

중요하고 귀중한 재산. 중국에는 이런 세대의 프로그래머가 부족하는데, 주로 그 시대의 프로그래머가 부족한 것이 아니라

모든 연령대의 프로그래머들은 기본적으로 연구소에서 나온 것이지 전문 제품 소프트웨어가 개발한 것이 아니다.

예, 그들은 제품 연구 개발 경험을 쌓지 못했고, 아무것도 할 수 없었습니다.

다섯째, 팀 조직 관리 능력.

프로젝트를 완성하기 위해서는 팀의 제신이 한마음 한뜻으로 협력해야 한다. R&D 의 프로젝트 설계자 또는 책임자로서 그는 다음을 수행해야 합니다

팀의 전반적인 역량을 극대화할 수 있는 능력이 있을 때, 기술 관리는 그 직업적 성격 때문에 일반 인력과 다르다. (존 F. 케네디, 일명언)

관리, 몇 가지 기술 지표와 요소 설계가 있기 때문이다.

첫 번째는 일의 정량화이다. 수량화 없이는 적절한 성과 평가를 달성하기 어렵고 절차의 수량화도 쉽지 않다.

코드의 행 수는 계산할 수 있으므로 기술 관리자는 모듈의 복잡성과 작업을 실제로 평가할 수 있어야 합니다.

측량하다.

둘째, 팀워크 모델 조정. 일반적으로 프로그램 개발의 협력은 보통 소그룹으로 나뉜다.

그룹에는 주요 프로그래머 방식, 민주적 방식, 프로그래머 간의 능력 수준 격차, 그리고 항목에 따라 달라진다.

목표는 R&D 요구에 적응하고, 적절한 팀 구성 방식을 선택하며, 구성원의 책임과 권리를 결합하는 것이다.

일과 임무가 긴밀하게 결합되어 팀 건설의 효율을 극대화하다.

코드 수준이 높은 사람은 반드시 자격을 갖춘 프로젝트 R&D 책임자가 아닐 수도 있으며, 이 방면의 능력은 부족하다.

과거는 쉽게 간과되었다.

요약하면 R&D 의 책임자이자 프로젝트 디자이너로서 어떤 자질을 갖추어야 하는지 알 수 있습니다.

그리고 능력은 프로그램 코드를 쓸 수 있는 능력이 아니다. 물론 프로그래머는 끊임없는 총결산을 통해 향상된다.

그가 이 자질에 도달했을 때, 그가 코드를 쓰는 능력은 이미 상당히 간단했지만, 이 점에 유의해야 한다.

인과관계, 높은 수준의 프로젝트 디자이너는 보통 매우 우수한 코드 작성자이지만,

코드가 우수한 프로그래머가 프로젝트 설계를 할 수 있는 것은 아니다. 여기에는 지혜가 없다.

업무와 교재의 문제는 프로그래머가 경험을 쌓고 점차 향상될 때 자신이 생각해야 한다는 것을 깨닫지 못하는 것이다.

어떤 것을 테스트하는지, 프로젝트의 구성과 재사용 설계에 대해 자각적으로 생각하지 않고, 정기적인 문서도 없다.

습관과 총결 습관, 이런 것을 바꾸지 않고, 우리의 합격한 프로젝트 디자이너는 여전히 매우 희소하다.

또한, 지루한 사람들이 나와 함께 심각 하 게 되는 것을 방지 하기 위해, 이 문서는 상용화 소프트웨어 항목을 목표로 추가 합니다.

프로젝트 및 엔지니어링, 과학 연구 기관의 프로그래머, 예를 들어 알고리즘 전문가, 이미지 처리 전문가, 그들의 업무.

상업용 소프트웨어를 직접 완성하는 것이 아니라 연구 과제다. (물론 결국 간접적으로 업무가 될 것이다.

Microsoft Institute 가 진행하고 있는 연구 프로젝트와 같은 제품이기 때문에, 그들이 강조하는 품질은 다른 것일 수 있습니다.

어떤 사람들 (전문가) 은 프로그래머라고 할 수 없고, 프로그래머의 기준으로 측정할 수 없다.

마지막으로, 소프트웨어 프로젝트가 개발한 설계 프로세스는 무엇입니까? 일반적인 표준 설계에서

예를 들어, (하지만 저는 빠른 프로토타입을 좋아합니다.)

첫 번째 단계는 시장 조사이며, 기술과 시장을 결합해야 최대의 가치를 구현할 수 있다.

두 번째 단계는 수요 분석이며 세 가지, 사용자 뷰, 데이터 사전, 사용자 작업이 필요합니다.

수첩을 하나 만들다. 사용자 보기는 소프트웨어 사용자 (최종 사용자 및 관리 사용자 포함) 가 볼 수 있는 페이지 스타일입니다

여기에는 많은 운영 절차 및 조건이 포함되어 있습니다. 데이터 사전은 데이터의 논리적 관계를 지적하고 정렬하는 동양이다.

동, 데이터 사전이 완성되면 데이터베이스 설계도 절반 정도 완성된다. 사용 설명서에는 운영 절차가 설명되어 있습니다.

설명하다. 사용자 운영 프로세스 및 사용자 뷰는 요구 사항에 따라 결정되므로 소프트웨어 설계에 있어야 합니다.

이러한 작업의 완성은 프로그램 개발을 위한 제약과 표준을 제공합니다. 불행히도, 너무 많은 회사들이 그렇게 하지 않았다.

인과가 뒤바뀌어 순서를 가리지 않다. 따라서 개발 작업과 실제 수요는 종종 분리되어 있습니다.

요구 사항 분석, 위의 작업 외에도 필자는 프로젝트 디자이너로서 프로젝트의 성능 요구 사항을 완벽하게 해야 한다고 생각합니다.

요청해 주세요. 성능 요구 사항은 기술을 아는 사람만이 알 수 있고, 기술 전문가와 수요자가 필요하기 때문입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 기술명언)

(고객 또는 회사 시장부) 는 진정한 소통과 이해를 가질 수 있다.

세 번째 단계는 시스템의 기능 모듈을 초보적으로 분할하여 합리적인 R&D 프로세스와 자원을 제공하는 요약 설계입니다.

요구하다. 빠른 프로토타입 설계 방법으로 요약 설계를 완료한 후 코딩 단계로 들어갈 수 있으며 일반적으로 사용됩니다.

방법은 관련된 R&D 임무가 새로운 분야에 속하기 때문에 기술 감독이 올라오면 명확하고 상세한 디자인 이론을 제시할 수 없기 때문이다.

명서이지만 상세한 설계 사양이 중요하지 않다는 뜻은 아니다. 실제로 프로토타입 코드를 완성한 후 빠른 프로토타입 방법이 뿌리를 내렸다.

평가 결과와 교훈을 바탕으로 상세한 설계 단계를 다시 수행해야 합니다.

네 번째 단계는 상세 설계입니다. 이것은 기술 전문가의 설계 사고를 시험하는 중요한 관문, 상세한 설계 설명입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)

구체적인 모듈은 가장 깨끗한 방식 (블랙박스 구조) 으로 코드자에게 제공되어야 전체 시스템이 모듈화될 수 있다.

최대치에 도달하다. 코딩의 복잡성을 최소화할 수 있는 좋은 상세 설계 사양은 사실 엄격하다.

상세 설계 조건은 필요에 따라 각 기능에 대한 각 매개변수의 정의를 상세히 제공해야 합니다

분석에서 요약 설계, 상세 설계 설명서 완성에 이르기까지 소프트웨어 프로젝트는 절반쯤 완성해야 합니다. 다른 말로 하자면

하나의 대형 소프트웨어 시스템이 절반을 완성했을 때, 실제로는 한 줄의 코드 작업을 시작하지 않았다. 그것을 부드러운 계란으로 취급하는 사람들.

그것을 코드 작성으로 간단히 이해하는 프로그래머는 근원에서 실수를 저질렀다.

다섯 번째 단계는 인코딩입니다. 표준화된 R&D 과정에서 프로젝트 전체에서 인코딩이 가장 많지 않습니다.

1/2 를 초과하면 일반적으로1/

크게 향상되었고, 서로 다른 모듈 간의 진도 조정과 조화는 인코딩할 때 가장 조심해야 할 것, 아마도 작은 모듈일 것이다.

문제는 전체 진도에 영향을 줄 수 있어 많은 프로그래머들이 일을 멈추고 기다리도록 강요당하는 것은 많은 연구의 문제이다.

그것은 이미 머리카락 과정에 나타났다. 코딩 과정에서의 상호 소통과 응급방안은 프로그래머에게 매우 중요하다.

일반적으로, bug 는 항상 존재할 것이고, 너는 항상 이 문제에 직면해야 한다. 유명한 마이크로소프트가 3 개월 연속 없을 때가 있나요?

패치는 언제 보내요? 절대 안 돼!

여섯 번째 단계는 테스트입니다.

테스트는 다양합니다. 테스트 수행자에 따라 내부 테스트와 외부 테스트로 나눌 수 있습니다. 테스트 범위에 따라

모듈 테스트와 전체 디버깅으로 나눌 수 있습니다. 시험지에 따라 정상 작동 테스트와 비정상 작동 테스트로 나눌 수 있습니다.

테스트; 테스트의 입력 범위에 따라 전체 범위 테스트와 샘플링 테스트로 나눌 수 있습니다. 이상은 이해하기 좋아서 더 이상 군말을 하지 않는다.

설명해 주세요.

결론적으로, 테스트도 프로젝트 개발에서 매우 중요한 단계이다. 대형 소프트웨어 1 대, 1 까지 3 개월이 걸립니다.

2008 년 외부 테스트는 항상 예측할 수 없는 문제가 있기 때문에 정상이다.

테스트, 수락 및 일부 최종 도움말 문서가 완료된 후 전체 프로젝트는 물론 종결되었습니다.

앞으로 업그레이드, 수리 등의 작업도 있을 것이다. 단번에 장사를 해서 돈을 속이고 싶지 않다면, 계속 소프트웨어를 추적해야 한다.

소프트웨어 상태, 수리 및 업그레이드, 소프트웨어가 완전히 폐기될 때까지

멈춰.

이 단계들을 쓰는 것도 자랑할 것이 없다. 솔직히 내가 손에 책' 소프트웨어 공학' 을 가지고 있는 것은 대학 시절이기 때문이다.

이것은 컴퓨터 전공을 위한 필수 과목이지만, 많은 프로그래머들이 항상' 에센스 30 일' 에 열중하는 것 같다는 것을 알고 있다

Pass VC 같은 것은 나처럼 게릴라이고, 정식으로 이 전공을 배운 적이 없고, 어떤 것은 초기이다.

학점을 충분히 섞은 후에, 나는 이 정말 유용한 물건들을 선생님께 돌려드렸다.

팬들이 고함을 지르며 시청각을 혼동하다. 사실, 진정한 기술 고수들은 저자와 같이 인터넷에 글을 올리는 경우는 거의 없다. (윌리엄 셰익스피어, 윈스턴, 과학명언)

조금 심으면, 사실 고수도 아니고, 이런 기술을 좋아하지 않을 뿐, 프로그래머에게는.

오해, 허튼소리, 어쩔 수 없이 나서서 일을 똑똑히 말해야 했다. 그 팬들이 진지하게 생각해 보고 갔으면 좋겠다.

올바른 길에서, 결국, 그 총명한 머리는 정당한 역할을 발휘하지 못했다.

프로그래머부터 엔지니어까지

프로그래머부터 엔지니어까지 나처럼 소프트웨어에 관심이 많은 사람들은 졸업 후에도 망설이지 않았다.

나는 사업에 들어가 프로그래머 생활을 시작했다. 그때 우리는 대전, 비적 같은 책에 매료되었다.

내 마음속에는 코드만 있다. 지루한 코드 행이 전화를 걸 수 있는 장치로 바뀌고 화면에 떠 있는 것을 보았을 때.

밝은 탁자가 아름다운 음악으로 변하여 성취감이 저절로 생겨났다. 나도 훌륭한 프로그래머라고 생각한다.

。 이용실에서 3 일 3 박 3 일 동안 소프트웨어 버그를 해결하는 것도 자화자찬의 자격이 되었다. 5 년 전 어느 곳.

어느 날, 나는 많은 코드와 나를 흥분시키고 자랑스럽게 했던 몇 개의 문서를 제출한 후 화웨이에 왔다. 이것은

학교에는 젊은이들이 비교적 많은데, 나도 물고기처럼 물을 얻어 상상력을 충분히 발휘할 수 있다. 여전히 코드이고, 여전히 서두르고 있습니다.

황급히 종이에 덧없는 영감 (우리가 문서라고 부르는 것) 을 적어도 끊임없이 버그와 싸우고 있다.

어느 날, 한 새 동료가 내 이름이 적힌 서류를 들고 나에게 자세히 물었을 때, 나는 나 자신을 발견했다

나는 모르는 것 같다. 좀 답답한 것 같아요. 코드를 보고 문서에 기록된 영감 중 일부를 발견했어요.

면목이 완전히 다르다. 나는 새 동료가 당시 어떤 느낌인지 모르지만, 나는 그때부터 무언가를 깨달은 것 같다.

지금 돌이켜 보면, 당시 많은 일들이 더 적은 노력으로 더 많은 일을 할 수 있었다. (윌리엄 셰익스피어, 템페스트, 희망명언)

나는 또한 나의 프로젝트 매니저, 키가 크고 날씬한 젊은이를 만났는데, 방금 미국에서 돌아왔다고 한다.

5 ~ 6 년 동안 일했습니다. 이 말을 듣고 나는 매우 기뻤다. 이번에는 하나씩 두 손을 배우고 싶습니다. 수요 분석 시간은 1 입니다.

지난 달, 프로젝트 관리자는 (실제로 고객을 대신하여) 제안서 내용을 논의하고 모든 것을 확보했습니다

그런 다음 그는 모듈을 대충 나누어 계획 학습 단계에 들어가기 시작했다. 모두들 학습반에 있다.

단락은 기능적으로 묘사된 영화를 써서 다른 사람에게 설명하려고 한다. 어느새 프로젝트 팀의 모든 사람이 완전한 프로젝트를 갖게 되었다.

신체에 대한 이해.

그는 또한 회사의 소프트웨어 개발 모델, 프로젝트 팀의 각 역할에 대한 정의와 같은 교육을 마련했습니다. 나중에,

시기적절한 훈련은 여전히 계속되고 있다. 프로젝트 팀에 수요가 있는 한, 그는 항상 QA 나 관련 사람을 초청하여 매우 전문적으로 교육한다. 필요

분석이 완료되면 40 페이지 이상의 문서를 제출했습니다. 내가 영어 문서를 보았을 때, 나는 모든 부분을 깔끔하게 썼다.

내가 그 안에 들어갔을 때, 나의 기분은 복잡하고 기쁨이 있었지만, 더 많은 것은 씁쓸했다. 이것은 내가 한 번도 본 적이 없는 것이다. (아리스토텔레스, 니코마코스 윤리학, 행복명언)

당신은 이런 수요 분석을 해본 적이 있습니까?

문서를 작성하는 과정에서 QA 는 SRS 글쓰기 템플릿에 대한 교육을 받았지만, 나중에는 안심할 수가 없었습니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 문서명언)

경험 많은 엔지니어가 한 단락을 썼는데, 우리 한번 생각해 봅시다. 이 SRS 는 많은 사람들이 썼지만 바람을 많이 피운다.

일관되고 상세하다. 더 중요한 것은, 마지막까지 이 수요 분석의 내용은 변경되지 않았다는 것이다.

우리에 관해서는, 우리는 그들의 수요 변화 과정을 경험할 기회가 없다.

수요 분석은 프로젝트의 첫 번째 단계이며, 두 번째 단계의 개발 시간은 수요 분석 결과에 따라 결정됩니다.

상대방의 수석 기술관 (우리 업무 부서의 전체 팀 책임자와 동일) 이 와서 방안에 대해 토론할 때 그들은 열거했다.

모듈당 코드 행 수에 대한 가능한 위험을 예측합니다. 그들의 회사 생산성에 따르면 -300

선/사람-월, 그는 프로젝트의 두 번째 단계에 몇 주가 걸릴지 계산했다.

우리는 당시 이의를 제기했다: 1) 회사는 이 프로젝트가 절실히 필요하다. 2) 한 달에 300 줄이 너무 적습니까? 3) 을 참조하십시오

다운로드한 소스 코드 참조도 있습니다. 그는 300 개의 생산 라인/사람-월이 이 프로젝트를 품질 기준에 부합시켰다고 설명했다.

경험 데이터, 소스 코드 참조를 고려하면 생산성은 최대 350 줄/사람-월을 초과할 수 없습니다.

그가 우리 회사의 생산성에 대해 물었을 때, 나는 머릿속을 세 바퀴 돌았는데, 감히 말을 많이 하지 못했다. 아마 6,700 행일 겁니다.

。 그는 잠시 침묵을 지킨 후, 우리의 계획은 품질을 보장하는 기초 위에 세워졌다고 굳게 말했다.

인도에 와서 소프트웨어를 개발할 때 가장 먼저 봐야 할 것은 우리 인도 회사이다.

품질 보증. 나는 네가 소프트웨어 개발자가 부족하지 않다는 것을 알고 있는데, 너는 왜 다운로드한 소프트웨어를 선택하지 않니? 몇 마디

나의 아픔에 대해 말하자면, 국내 형제들은 여전히 소프트웨어 이식 제품을 다운로드하기 위해 분주히 뛰어다니고 있다!

뒤이어 개발 활동이 질서 정연하여 우리는 성실하게 따라갔다. 시스템 테스트 계획, 사용 사례, 요약 설계

설계, 통합 테스트 계획, 사용 사례, 상세 설계, 단위 테스트 계획, 사용 사례, 코딩, 단위 테스트, 통합 테스트

해봐, 시스템 테스트. 각 프로세스에 대한 검토가 있는 완전한 V 모델 개발 프로세스입니다. 우리가 몇 가지를 만들었을 때,

내가 아직 계획 방법을 잘 알지 못했을 때, 프로젝트 매니저가 우리에게 관련 자료를 보내왔고, 나도 그가 당시 무슨 생각을 하고 있었는지 모르겠다.

몇 가지 기본적인 분석과 설계 방법은 10 년 전, 심지어 20 년 전의 소프트웨어 엔지니어링서에 언급되어 있다. 인도에서 매번

이 내용은 모든 컴퓨터 전공을 위한 필수 과목이다. 특정 프로토콜의 코드에 익숙한 것 외에도,

, 이러한 일반적인 방법에 대해 아무것도 모르는 것 같습니다. 창피해서 시내 서점에 직접 가서 나열해 주세요.

책이 발견되어 밤에 침대에 누워 열심히 연구하다. 갑자기 나에게 조언을 해줄 수 있는 멘토를 만난 것 같다.

친구. 이제 인도는 강한 학습 분위기를 형성했습니다. 돌아와서 700 여 권의 책을 팔아서 우리에게 가르쳐 주었다

공사 방법으로 소프트웨어를 개발하는 방법은 소프트웨어 엔지니어의 필수 자료이다.

우리의 프로젝트 매니저는 강력한 계획 통제 능력을 가지고 있다. 프로젝트 계획에 영향을 미치는 일이 발생할 때, 예를 들면

직원들이 사임하고, 실험실이 이사를 하고, 어떤 모듈은 예측이 정확하지 않다. (이 모듈은 우리가 예측한 것이다.) 그는 항상 필요한 조치를 취한다.

지연을 줄이고 계획을 조정하는 조치. 처음에 우리는 그들에게 매일 아침 1 1, 오후 4 시에 아래층으로 내려가 커피를 마시라고 말했다.

나는 여전히 약간의 평론이 있는데, 나중에 나도 댓글을 따랐다. 원래 커피를 마실 때의 교류는 프로젝트 관리에서 디자인에 이르기까지 매우 풍부했다.

방법, 기술 발전에서 풍토인정에 이르기까지, 모든 것을 포괄하며, 서로의 분위기와 팀의 분위기에 대해 잘 알고 있다.

살려주세요. 우리 프로젝트의 QA 도 적절한시기에 우리 앞에 나타났습니다. 우리는 그녀의 일에 대해 약간의 감정을 가지고 있습니다.

서로 알다. 매번 회의를 할 때마다 그녀는 손에 체크리스트 한 장을 들고, 프로젝트 매니저는 그에 상응하는 자료를 준비한다.

몇 가지 질문에 대답하고, 그녀는 체크하거나 프로젝트 매니저의 설명을 썼다. 그녀가 우리에게 훈련을 줄 때도 인내심이 있어서 한 점을 볼 수 있다.

나는 여전히 그녀가 우리에게 준 도움이 그립다, 왜냐하면 그녀는 매우 헌신적이기 때문이다.

나는 소프트웨어 개발에 종사한 지 이미 9 년이 되었지만, 나는 여전히 내가 자격을 갖춘 소프트웨어 엔지니어라고 말할 수 없다.

, 자격을 갖춘 관리자는 말할 것도 없습니다. 나는 스위스 로잔의 한 권위기관이 중국의 기술을 가지고 있다는 보도를 보았다.

종합경쟁력이 원래 13 위에서 20 여 위로 조정된 것은 다음과 같은 평가 기준을 조정했기 때문이다

하나는 중국의 합격엔지니어 수가 매우 적다는 것이다. 형제 두 사람이 눈을 붉히며 뛰어다니며 피로를 업그레이드한다고 생각한다.

지친 그림자 아래, 나는 강한 소망이 있다: 빨리 자신을 합격한 엔지니어로 업그레이드하라!