작심삼일 개발이야기

올해 1월 중순부터 시작해서 끝까지 다 읽는데 거의 1달 반 정도 걸린 것 같다. 방금 전 마지막 장을 정리해서 업로드하고 바로 이 글을 작성하고 있다. 처음에는 책내용과 나의 생각을 같이 적으려고 했으나 가면 갈 수록 책 내용만 요약하는 글이 된 것 같아서 아쉽다. 비록 개발기술에 관련되지 않았지만 끝까지 다 읽었던 적이 정말 오랜만이라서 뿌듯한 기분도 생긴다. 책의 한 단원씩 읽으며 정리해서 블로그에 기록을 하고 있었는데 다른 사람들에게 도움이 되었으면 좋겠다. 확실히 한 번 읽고 글을 작성할 때 다시 여러번 읽어보게 되어 나에게도 도움이 되는 것도 분명하다. 책의 모든 내용이 나에게 딱 필요하다고 느끼지는 못한 것 같다. 아직 개발을 시작한지 얼마 되지 않아서 그런 것 같다. 여담으로 이 티스토리에..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 7장의 내용이 궁금해서 이 책을 읽었는데 정말 마지막에 있었다... 길고 길었지만 마지막 장을 정리한다. 1. 기술 블로그를 쉽게 쓰는 방법 3가지 첫째, 주제 의식을 버리고 소재 의식으로 쓰자 소재 의식이란 특정상 대상이나 상황에 자기만의 관점이나 생각이나 해결 방안을 말하는 것이다. 둘째, 독자 수준이 아니라 자기 수준으로 쓰자 보통 어려운 글을 쉽게 설명할 때 비유법을 많이 사용한다. 하지만 비유법은 한계가 있다. 그 원리에 대해 간접적으로 이해한 것으로는 실제로 사용할 수가 없다. 독자를 생각해서 어려운 용어를 해석해 풀어쓰거나 쉬운 용어로 바꿀 필요가 없다. 그대로 사용하되 필요하다면 용어를 정의한 자료를..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 1. 개발자가 알아야 할 제안서 작성 원칙 개발자라고 개발만 하지 않는다. SI에서 일을 한다면 공공 입찰 제안서를 작성해야 하는 경우가 생긴다. 첫째, 제안요청서 분석 제안요청서에서 거의 모든 문제와 답이 들어있다. 일부분만 보지 말고 전체를 잘 보아야 한다. 둘째, 논리적 완결성 항목을 논리적으로 완결해야 한다. 대부분 제안서를 소설 읽듯이 순서대로 읽지 않는다. 자기와 관련 있거나 관심 있는 항목을 골라 읽기 때문이다. 2. 고객의 문제 인식과 제안사의 문제 해결 능력 제안서의 시작은 문제가 아니라 고객의 문제 인식이다. 문제를 문제 삼지 않으면 문제가 되지 않는다. 고객이 문제를 어떻게 인식하는지에 따라 제..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 5장은 설명하는 글을 작성할 때 다양한 방법에 대해 알려준다. 1. 서비스 개념을 범주, 용도, 특징으로 설명하자 개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징 순으로 쓰는 것이 좋다. 범주는 여러 경쟁사가 사용하는 보편적인 서비스 범주를 따라 하면 좋다. 범주는 서비스의 정체성과 검색어와도 연관이 있기 때문에 신중하게 정해야 한다. 용도는 독자가 이 서비스를 이용하는 이유다. 서비스의 핵심 기능을 쓰면 용도를 기술할 수 있다. 특징은 차별화하는 내용을 적는다. 차별화는 서비스의 장점과 강점이다. 장점은 자기 기준에서 잘하는 것이고, 강점은 경쟁 서비스보다 나은 점이다. 2. 정확히 이해하도록 그..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 4장은 릴리스 문서와 장애 보고서에 관한 이야기를 주로 다룬다. 프로젝트를 진행하며 문서화를 해본 적이 없어서 앞으로는 이렇게 해야겠다 라는 생각을 가진 것이 전부 인 것 같다. 1. 체인지 로그를 분류, 요약, 종합하는 법 체인지 로그(changelog, 변경 기록)는 웹 사이트나 프로그램을 제작하는 것 같은 어떤 프로젝트를 진행할 때에 변경 사항에 대한 기록이다. 많은 오픈소스 프로젝트에서는 체인지 로그 파일을 가장 상위에 포함해서 배포한다. 보고서를 간단히 쓰면 한 일이 없어 보이고 자세히 쓰면 너무 길어 아무도 읽지 않아 무용지물이 되어 버린다. 뭐든 적당한 게 좋은 것 같다. 선정하기 분류하기 요약하기 종..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 1. 사용자 에러 메시지를 제대로 쓰는 법 사용자 에러 메시지에는 에러의 내용, 원인, 해결 방법이 포함돼야 한다. 내용 -> 원인 -> 해결 방법 순으로 나타낸다. 내용과 원인이 복잡하다면 해결 방법을 제일 먼저 알려 주는 것도 좋은 방법이다. 해결 방법 -> 원인 -> 내용 순으로 나타낸다. 2. 사용자의 에러를 줄이는 메시지 구조화 에러 메시지를 사용할 때 알림 창을 사용한다.아래의 사진은 windows에서 사용하는 알림 창이다. 아래의 사진은 ios에서 사용하는 알림 창이다. 같은 알림 창이 지만 확인, 취소 버튼의 순서가 서로 반대로 되어있다. OS에 따라서 순서가 달라 무엇을 따라가라고 하기엔 어렵지만 ..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 1. 네이밍 컨벤션, 이유를 알고 쓰자 어떤 방법으로 이름을 정하던 중요한 것은 표기법 자체가 아니라 사용하는 이유다. 많은 컨벤션이 생긴 이유는 가독성과 개발자들 사이의 소통 때문이다. 어떤 방법이든 좋다. 같이 일하는 팀원들과 컨벤션을 정하고 지키도록 노력해보자 2. 변수 이름을 잘 짓는 법 책에서 알려주는 방법 중 한 가지 방법은 중요한 단어를 앞에 쓰라고 한다. 개발 도구가 단어를 검색하면 다 잘 찾아주기 때문에 크게 의미가 없을 수도 있지만 중요한 것이 앞에 와야 한다는 기본 원칙을 지키라고 한다. 함수 이름은 1함수 1 업무 규칙을 적용해라(하나의 함수에서 한 가지 일만 해라) 3. 좋은 이름의 기준, ..

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다. 개발자의 생각을 글로 표현하는 3가지 방법 서술식 '~다'로 끝나는 완전한 문장으로 구성된 글 (줄거리가 있는 설명이나 이야기) 개조식 어떤 사항을 나열할 때 ( 여러 가지 종류의 항목과 내용이 반복되거나 서술식에서 강조가 필요한 내용) 글머리 기호를 써야 한다. 도식 그림이나 서식으로 보여주는 것 ( 각 항목이나 사항의 관계를 명확히 규정할 때 ) 영어 단어 선택과 외래어 표기법 예를 들어 리액트에서 어떤 컴포넌트를 보여줄 때 show, hidden을 사용하는데 hidden대신에 invisible을 사용하면 안 된다. invisible의 반대말은 visible이기 때문이다. 이처럼 비슷한 뜻을 가진 영단어가 많이..