일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 모두를위한딥러닝
- SQL
- 깃허브 로그인
- 스터디
- 모두의네트워크
- 문자열
- 백준
- 데베
- 자바
- HTTP
- 백준 4358번
- 깃허브 토큰 인증
- 백준 4949번
- 딥러닝
- 네트워크
- 리액트 네이티브
- 머신러닝
- 깃 터미널 연동
- 모두의 네트워크
- 지네릭스
- 깃 연동
- 백준 4358 자바
- 모두를 위한 딥러닝
- 리액트 네이티브 시작하기
- 백준 5525번
- 데이터베이스
- 팀플회고
- 리액트 네이티브 프로젝트 생성
- 정리
- React Native
- Today
- Total
목록책을 읽자/개발자의 글쓰기 (7)
솜이의 데브로그
1. 기술 블로그를 쉽게 쓰는 방법 3가지 블로그에 글을 쓸 때 적합한 세가지 방법 소재 우선 글쓰기 자기 수준 글쓰기 재미있는 글쓰기 주제 의식을 버리고 소재 의식으로 쓰자 소재 의식은 특정한 대상이나 상황에 대한 자기만의 관점이나 생각이나 해결 방안을 뜻한다. 독자와 상관 없이 대상이나 상황에 맞닥뜨렸을 때부터 그 대상이나 상황에서 벗어날 때까지 겪은 일을 정리한다. → 기술블로그는 일상을 다룬 수필이나 에피소드와 비슷하다. 독자 수준이 아니라 자기 수준으로 쓰자 기술블로그는 독자들의 수준이 정해져있지 않다. 따라서 작성자 수준에 맞추어 쓰는 편이 낫다. 개발자가 기술블로그를 쓸 때는 독자를 생각해서 어려운 용어를 일부러 해석해 풀어쓰거나 쉬운 용어로 바꿀 필요가 없다. 원래 사용하는 용어로 표기하되..
1. 개발자가 알아야 할 제안서 작성 원칙 SI 개발 업체에서 일을 한다면 공공 입찰 제안서를 반드시 작성하게 된다. 제안서에서 개발자는 주로 기술 부문을 쓴다. 제안서의 기술 부분은 대부분 그림과 표로 구성된다. 개발자가 제안서에 쓰기 어려운 것은 전략적 제안에 관한 것이다. 제안 요청서 분석 제안 PM은 거의 모든 요구를 제안 요청서를 기반으로 한다. 제안 요청서는 고객이 제안을 요청하는 문서 제안 요청서는 제안서 작성의 시작이다. 제안 요청서 안에 목표 시스템, 하드웨어 구성도, 소프트웨어 구성 등등이 모두 포함되어 있으며 이유와 배경, 상황과 답 모두 포함되어 있다. 따라서 잘 분석하고 작성해야 한다. 논리적 완결성 항목을 논리적으로 완결한다. 해당하는 항목 안에 포함되는 내용을 작성해야 한다. ..
1. 서비스 개념을 범주, 용도, 특징으로 설명하자 개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징 순으로 쓰는 것이 좋다. 개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명할 수 있다. (참고) 일반적으로 웹 하드 서비스, 웹 스토리지 서비스, 파일 호스팅 서비스는 별도의 클라이언트를 설치하거나 ActiveX를 이용해 파일을 올리거나 내려받는다. 클라우드 스토리지 서비스는 HTTP 프로토콜을 이용해 파일을 올리거나 내려 받는다. 인터넷 브라우저에서 바로 사용할 수 있으므로 클라우드 스토리지 서비스만으로 웹 서비스가 가능하다. 범주는 서비스를 소개하거나 설명하는 첫 문장인 만큼 정확하고 적절하게 정해야한다. 가장 좋은 방법은 여러 경쟁사가 사용하는 보편적..
1. 체인지 로그를 분류, 요약, 종합하는 법 상사나 고객의 만족도는 체인지 로그의 양이 적절할 때 가장 높다. 체인지 로그를 적절한 양으로 쓰기 위해서는 일정한 기준으로 선정하고 비슷한 것끼리 분류한 뒤 문장을 요약해야 한다. 1단계 : 선정하기 2단계 : 분류하기 3단계 : 요약하기 4단계 : 종합하기 1단계: 선정하기 체인지 로그의 양을 줄이기 위해서는 쓸것과 없앨것을 구분하는 기준이 필요하다. 개발자가 노력을 많이 들인 것 / 회사가 말하고 싶은 것 / 독자가 듣고 싶은 것 우선순위대로 작성한다. 2단계: 분류하기 공개할 체인지 로그를 선정 후 비슷한 체인지 로그끼리 묶어야한다. 개발 관점에서 비슷한 작업을 묶는 방법. (독자가 개발자인 경우) 새로운 기능 추가, 기능 개선, 오류 수정 사용자 관..
1. 에러메시지를 쓰기 전에 에러부터 없애자 친절한 404, 불친절한 404 사용자가 보는 화면은 UI/UX 디자이너가 만든 것이다. 따라서 사용자는 개발자의 산출물 그 자체를 볼 수는 없다. 사용자가 개발자의 산출물을 볼 때는 바로 에러 메시지가 뜰 때다. 대표적으로, HTTP 404 에러인 "요청하신 페이지를 찾을 수 없습니다" 페이지이다. 404 에러 : 클라이언트가 서버와 통신할 수는 있지만 서버가 요청한 페이지를 찾을 수 없다는 것을 가리키는 HTTP 표준 응답 코드. 구글에 찾아보면 여러 사이트들의 404 에러 페이지가 나온다. 해당 페이지는 그저 찾을 수 없다고 표시하기만 하거나 (구글), 사용자가 의도한 URL을 추측해 제안하거나(위키피디아), 또는 고객센터 링크를 덧붙인다(다음, YES2..
1. 네이밍 컨벤션, 이유를 알고 쓰자 개발자의 가장 큰 고민은 이름 짓기 함수가 어떤 일을 하는지 이름만 보고도 짐작하게 만들어야한다. 즉, 다른 개발자가 봤을 때 한 번에 무슨 뜻인지, 무슨 기능을 하는지 알아낼 수 있는 이름이어야한다. 그러면서도 아주 간결해야 한다. 네이밍 규칙들 자바 네이밍 컨벤션을 철저히 준수한다. 클래스는 UpperCamelCase 함수와 변수는 lowerCamelCase 상수는 UPPER_DELIMITER_CASE 네이밍은 보통 16글자, 3단어를 조합한다. 클래스 네임 : 3.18단어 함수 네임 : 3.36 단어 변수 네임 : 2.57 단어 품사는 주로 명사, 동사, 형용사의 조합이다. 명사 + 명사 + 명사 동사 + 명사 + 명사 형용사 + 명사 + 명사 등 코드의 네이..
1. 문장과 단락을 구조화하는 법 문장을 구조화하는 법 문장을 어떻게 만드느냐에 따라 글을 쓰는 속도가 달라진다. 문장을 쉽게 쓰려면 간단한 문장 구조로 핵심만 말한 뒤, 필요에 따라 부가 설명을한다. 이 때 첫 문장의 주어를 가져다가 소제목으로 만들면 자연스럽게 문단을 구성할 수 있다. ex) 입력 데이터는 3차원 벡터다. 색상 RGB 값을 각각 사용하기 때문이다. 서술식, 개조식, 도식의 차이 서술식 : '~다' 로 끝나는 완전한 문장으로 구성된 글. 개발 가이드 문서는 대부분 서술식으로 쓴다. 개조식 : 신문의 헤드라인을 쓰거나 어떤 사항을 나열할 때 사용한다. 종결어미('~다') 대신 명사(완료, 증대 등)나 용언의 명사형 (~했음) 으로 끝내는 것을 개조식이라 한다. 릴리스 문서나 장애 보고서를..