개시하다 나는 소프트웨어 엔지니어가 필요로 하는 기술을 생각했다. 여기서 처리하는 것은 넓은 의미의'소프트웨어 엔지니어'로 SE, 프로그래머를 포함하고 SIER가 아니라 주로 자기 회사에서 개발한 엔지니어를 대상으로 한다.또 배경이 소프트웨어가 아닌 사람을 전제로 한다. 왜 기술을 의식해야 하는가 눈앞의 임무만 하고 있다면 몇 년이 지나 뒤돌아보면 자신의 기술이 낮다는 것에 깜짝 놀랄 것이다.그리고 이 레이더처럼 교체할 수 있는 인재가 될 것이다. 미래를 상상하고 필요한 기술을 의식적으로 습득하는 것이 중요하다. 기술의 수치화는 영원한 주제이다. 예를 들어 각 항목에 대해 "공공장소에 등장할 수 있는지, 인터넷에 투고할 수 있는지, 거기에 대응할 수 있는지의 질의응답"이라고 생각하면 구체적일 수 있다. 중견이 됐을 때는 각자의 기량 모두 5∼8까지 달성하는 것을 목표로 하고, 그 전에 자신이 잘하는 분야를 찾아 그곳을 10으로 만드는 것이 좋다는 인상을 주는 게 좋다. 기능 여기서는 각 기술이 부족하면 어떤 일이 될지에 착안해 정리한다. 논리적 사고
논리적 사고를 하지 못하면 공식적인 설계를 할 수 없다
문제가 있어도 논리적으로 공격할 수 없기 때문에 시간이 걸리거나 해결할 수 없다
개발 중 치명적
프로그램 설계
가장 무서운 것은'이동=프로그래밍 완성'을 확신하는 것이다.
읽기 어려운 코드, 확장성이 낮은 코드, 제대로 테스트되지 않은 코드는 유해하다
회사의 개발 주기 효율이 떨어지는 것을 발견하지 못했다
'부분적으로 다른 사람이 만든 코드를 수정=스스로 프로그래밍할 수 있다'는 것에 만족
당연히 다른 사람의 코드를 읽을 수 있는 기술이 필요하지만, 코드를 강제로 입력하는 수정은 해롭다
물론 내려다보며 적당한 방법으로 수정하는 행위는 의미가 있다
사양(요구 사항/외부 설계)
생각나는 건 조목조목 쓴 것만 스타일북으로 하는 거예요.
시스템 논의에 따라 프로젝트가 충분하거나 부분적으로 포맷될 수 있는지를 고려하지 않으면 실패할 때의 피드백을 할 수 없음
이 공정에서 노동력과 자재를 줄이기 때문에 품질이 나쁜 것이 생길 수 있다
먼저'아제르'라는 단어로 인코딩
비슷한 것을 만들 수 있지만 치명적인 누락이나 쓸모없는 재작업이 발생한다
※ 나는 물소 신봉자가 아니다 사양(내부 설계)
프로그래밍 프로젝트와 비슷하지만 기능 추가, 수정 개선이 어려운 구조 발생
누구보다 못 받는 코드가 돼
회사의 개발 주기 효율 저하
기능 추가와 규격 변경에 시간이 걸린다고 해서 자신의 디자인이 좋지 않다고 생각해서는 안 된다
생략되고 무시되는 경향이 있다
문서
독자 인상의 상상력이 부족하고 자기 중심의 자료
의사기록 없음
어떤 경과가 일을 결정하거나 어떤 행동을 필요로 하는지 정리하지 못하는 사람과의 회의는 소용없다
절반까지 쓴 자료에서 의기양양한 표정을 지었다.문자수로서 마지막 10%는 부족할 수 있지만 이 10%를 메우기 위해서는 필요한 고려가 의미가 있고, 반대로 이 10%의 자료를 완성하지 못한 것은 기능으로서 가치가 없다
발표하다
문서와 마찬가지로 청자의 입장을 인상으로 하는 구조/내용을 채택할 수 없다
"발표불가"≈"이해불가"
도메인 이름
여기서 말하는 영역은 개발 대상과 그 관련 전문 분야에 대한 지식(대상물, IT 시스템의 개발 환경, 언어, 하드웨어, 업계 동향)
을 말한다.
부분은 매일 업무에서 자연스럽게 배운 것으로 이 정도면 만족하고 깊이 파고들 수 없다
자체 발굴 작업에서 얻을 수 없는 신기술 등
커뮤니케이션
'교류'≠'사교성'
고객의 요구 사항을 제대로 들을 수 없음
단순히 고객의 말을 통째로 맹신하는 것이 아니라 그 배경과 이유가 잘 들리지 않아 기대와는 다른 것을 만들어낸다
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
