URI(Uniform Resource Identifier)란? - 식별자 - 인터넷에 있는 자원을 나타내는 유일한 주소로 하위개념인 URL, URN을 포함한다. URL(Uniform Resource Locator)란? - 위치 - 네트워크 상에서 자원의 위치를 나타내기 위한 규약으로 각각의 URL은 유일한 자원(HTML Page, CSS doc ...)을 가리킨다. ex) https://naekang.com/page.htm URN(Uniform Resource Name)란? - 이름 - urn:scheme을 사용하는 URI를 위한 역사적인 이름 ex) naekang.com/page.htm URI 설계 원칙(RFC-3986) 1. 슬래시 구분자(/)는 계층관계를 의미 ex) https://naekang.t..
Chapter6.1 - 개발자가 알아야 할 제안서 작성 원칙 개발자와 제안 PM의 차이 개발자는 제안서에서 주로 기술 부문을 작성함 대부분 그림과 표로 구성 시스템 구성도의 본질은 그림이 아니다 제안요청소에 있는 시스템 구성도(As-Is)를 분석해서 새로운 시스템 구성도(To-Be)를 구상해 그림을 그리고 제안서에 넣는 것이 본래 업무 첫째, 제안요청서 분석 제안요청서 제대로 분석하기 목표 시스템, 하드웨어 구상도, 소프트웨어 구성도, 요구 기능 등의 내용들이 이미 들어있음 개발자가 제안요청서에서 힌트를 잘 찾아내면 기술 부문을 더 전략적으로 쓸 수 있음 둘쨰, 논리적 완결성 항목을 논리적으로 완결하기 기업 담당자나 심사위원은 자기와 관련있는 항목 또는 페이지만 골라서 읽는다는 것을 알고있어야 함 참고문..
Chapter5.4 - 서사를 활용해 목차를 만들자 개발과 서사 서사: 사실을 있는 그대로 적는 것 그림이나 사진이 글과 붙어 있는 잡지처럼 글을 써야함 보통 글의 번호와 스크린샷 안의 번호를 같게하여 번호마다 글을 씀 독자의 수준 대신 기술의 범용성을 기준으로 쓰자 의미 있는 사건을 시간에 따른 전개 과정으로 써야 함 개발문서에서 서사는 개발자와 독자 사이에 줄다리기 범용성을 기준으로 기술하기! 순서에서 단계를, 단계에서 목차를 만들자 단계마다 나누어 단계별 목표를 정확히 하기 쉬운 단계 -> 어려운 단계 순 목차를 배치하여 링크를 거는 방법도 좋음 참고문헌: 개발자의 글쓰기
Chapter5.2 - 정확히 이해하도록 그림과 글로 묘사하자 글에 묘사를 더하면 이해가 빠르다 단순한 언어보다는 묘사를 위한 오감 추가하기 글과 그림의 내용을 일치시키자 그림에 있는 단어를 사용하여 글을 쓰기 객관적 묘사와 주관적 묘사 둘 다 하자 주관적 묘사와 객관적 묘사의 방식을 자유자재로 왔다갔다 할 수 있으면 개발이 쉬워짐 Chapter5.3 - 논증으로 유용한 정보를 제공하자 의견을 쓰려면 근거를 대자 논증의 기법 활용하기 개발자가 의견만 말하고 근거를 말하지 않으면 독자가 직접 테스트해볼 수 밖에 없음 거칠게도 공손하게도 쓰지 말자 ~할 수 있지만 ~하기 어렵다, ~ 해야 합니다만 반드시 해야하는 것은 아닙니다 -> ~하십시오, ~하지 마십시오 100% 확신은 불가능하지만 여지가 있다면 독자..
Chapter5.1 - 서비스 개념을 범주, 용도, 특징으로 설명하자 범주, 용도, 특징 버독자가 잘 아는 범주 -> 범주의 용도 -> 범주 내의 유사 서비스와 차별화하는 특징 범주를 정확하고 적절하게 선택하자 개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명 가능 범주는 정확하고 적절하게 여러 경쟁사가 사용하는 보편적인 서비스 범주 참고 용도를 범주의 핵심 기능으로 기술하자 독자 관점의 용도 개발자 관점에서 핵심 기능 추리기 특징을 장점과 강점에서 뽑아 쓰자 범주와 용도는 보편적인 내용이지만 특징은 차별화하는 내용 장점: 자기 기준에서 잘하는 것 강점: 경쟁 서비스와 비교해서 나온 것 참고문헌: 개발자의 글쓰기
Chapter4.4 - 비즈니스를 이해하는 장애 보고서 쓰기 장애 보고서의 특징 장애 보고서는 개발자가 원할 때 쓸수 없음 장애 발생 후 부터 가능 장애의 1차 원인은 대부분 다른 원인의 결과 원인과 이유를 찾는 분석적 글쓰기 필요 장애 보고를 받는 윗사람은 대부분 개발자가 아님 그들과 소통하기 위한 비즈니스 관점 글쓰기 필요 장애를 해결했다고 해서 100% 해결한 것은 아님 보고할 때는 확정적이고 신뢰할 만한 결단을 정치적으로 내려야 함 질문에 대답하는 신속한 글쓰기 대화를 글로 옮기고 글쓰기에 그대로 적용하기 원인과 이유를 찾는 분석적 글쓰기 5Whys 기법 사물이나 현상, 동작이 문제를 초래하는 원인 + 사람이 문제를 초래한 이유 IT분야에서 장애는 대부분 재발하며 원인은 사람의 문제 개발자 사이의..
