티스토리 뷰

읽은책

개발자의 글쓰기 - 김철수

승가비 2020. 12. 27. 07:58
728x90

 

내년이면(일주일 뒤) 5년차 개발자가 된다.

개발자가 되기로 결심을 15살때 했으니, 15년동안 경험한 내용을 가지고 책을 보았다.

40 페이지까지는 중간에 책을 덮고 싶을만큼 노잼이었으나,

나머지 230 페이지는 4일만에 다본 것 같다.

 

정말 오랜 경험과 노하우가 없어면 하지 못할 이야기가 잘 적혀있고,

클린코드에서 봤던 내용 & 일하는데 과연 무엇이 중요한지?

제대로 알려주는 책이다. 좋은 책 감사드립니다. :)

 

(이상적인 내용은 배제하고 80% 에 집중할 것)

 


 

정확성 ,간결성, 가독성

클래스나 함수의 이름, 주석, 에러 메시지, 릴리스 문서, 개발가이드, 장애 보고서

제안서, ERD, 기능 명세서

정확하고 간결하며 가독성이 높아야 한다.

(확실한 것, 간단하고 깔끔한 것, 핵심만)

 

- 쉬운 용어

- 표 & 그림

- 문단과 문서 전체에 체꼐와 위계가 갖췅져야 한다.

 

모든 것은 Trade-Off 다..!

정확성을 높이면 간결성과 가독성이 낮아진다.

가독성을 높이면 간결성과 정확성이 낮아진다.

정확성 vs 간결성, 가독성

 

서술식: ~다

개조식: 헤드라인

도식: 그림, 서식

 

계층을 표현하면 문서의 체계를 먼저 이해할 수 있으므로 읽는 시간이 덜 걸린다.

항상 위계가 잘 드러나게 글을 쓰고 표현해야 한다.

 


 

change: 내용을 바꾸는 것

modify: 잘못된 것을 바로잡는 것

revise: 새로운 정보나 아이디어를 덧붙여 기존 내용과 달라졌음 (patch 가 나을듯?)

 

parameter: 매개변수, 함수 정의문에서 (static?)

argument: 함수를 호출할 때 전달되는 값 (dynamic?)

둘다 코드상에 static 하게 정의해서 사용하는데, 좀 더 이해하기 쉬울 것 같아 표기

 

attribute: HTML에서 태그 안에 속성을 넣을때, (비공식필드?)

property: HTML DOM에서 가리킬때, (공식필드?)

공식 vs 비공식 느낌

 

must: 필수

should: 권고 or 권장

 

일관성과 개연성이 있다면 괜찮다.

표준이 없기 때문에,

개발의 모든 부분에서 그렇다.

하지만, 대다수 개발자가 하는 방식대로 해야한다. (https://github.com)

 

개발자들이 대화할 때는 대부분 릴리즈라고 말한다.

basic을 베이식이라 하지 않고 베이직이라 말하고 쓰는 것과 같다.

 

파이썬(Python)도 파이선으로 써야 옳다.

대략 20명 정도 되는 최초의 한국 뱀신족들이 파이썬을 '파이썬'으로 부르기로 합의했기 때문에

 

모두가 짜장면이라 쓰고 짜장면이라 발음.

"이미 굳어진 외래어는 관용을 존중하되, 그 범위와 욜례는 따로 정의한다."

외래어 표기법에 따라서 표기

 


 

개발자들의 절반이 이름 짓기가 가장 힘들다고 대답했다.

자기 코드에 주석을 주렁주렁 달고 싶은 개발자는 세상에 없다.

모든 개발자는 자기 코드를 읽는 사람이 주석 없이도 금방 이해하게 코드를 작성하고 싶어한다.

함수가 어떤 일을 하는지 이름만 보고도 짐작하게 만들고 싶어한다.

그러면서도 간결하고 명료하며 일관성을 가진 이름을 짓고 싶어한다.

하지만 현실은 어렵다.

 

이름 하나 잘못 지었을 뿐인데 일이 몇 배가 된다.

잘만 하면 코드를 짜기도 쉽고 이해하기도 쉽다.

다른 개발자와 소통하기도 쉬워지고,

공개할 경우 외부 개발자들에게 인정도 받는다.

문서를 최소로 만드는 시대,

코드로 소통하려면 좋은 이름 짓기는 필수다.

 

아주 간결해야 한다.

기존 방식이나 이름을 차용해서 새로운 이름을 짓는 경우가 대부분이다.

오픈소스의 네이밍 특징들(https://brunch.co.kr/@goodvc78/12)

 

- 자바 네이밍 컨벤션을 철저히 준수

  ㄴ 클래스: UpperCamelCase

  ㄴ 함수, 변수: lowerCamelCase

  ㄴ 상수: UPPER_DELIMITER_CASE

 

- 네이밍은 보통 16글자, 3단어 조합

  ㄴ 클래스: 3.18

  ㄴ 함수, 변수: 3.36

  ㄴ 상수: 2.57

클래스의 함수, 변수는 추상화의 정도에 따라 더 짧게도 가능할듯?

클래스 이름을 길게 잘 쪼개면됨

 

상수는 모두 대문자로 쓴다.

상수를 대문자로 쓸지 말지는 개인의 자유지만, 어느 쪽이든 회사 안에서는 통일하는 것이 좋다.

 

패키지와 모듈은 모두 소문자로 쓴다.

모듈 이름과 함수 이름을 헷갈릴 수 있어서 패키지와 모듈 이름은 모두 소문자로 쓰는 것으로 누군가가 정했고,

그것이 그대로 컨벤션으로 자리 잡았다.

 

BEM(Block Element Modifier)

CSS(Cascading Style Sheets)에서 사용하는

`대상__요소--상태`

from__button--disabled {}

 

중요한 것은 가독성 & 통일성 & 커뮤니케이션

코드를 읽기 쉽게 만들고 다른 개발자와 협업을 하기 위해서

가독성이 높다고 소통이 더 잘되는 것은 아니다.

기본적인 컨벤션 규칙을 정하는 것이 우선이다.

 

관습으로 박혀 있는 것

반복문 카운터: i, j, k

좌표: x, y

 

복수 단어는 `-s`를 붙이면 눈에 잘 띄지 않으므로,

`-ListOf`

`-Array`

쓰는 편이 더 나을 수도 있다.

 


 

한 번에 좋은 이름을 지을 수는 없다. (SMART)

- Search: 검색

- Mix: 혼합

- Agree: 수긍

- Remember: 기억

- Type: 타이핑

 

Search: 검색

잘 검색도게 한다면 누구나 쉽게 검색할 수 있어 시간 낭비를 줄일 수 있다.

고전적 범주화, 태그처럼 덧붙이자.

`prefix`, `suffix`

 

Mix: 혼합

개발 언어의 문법과 조합해 이름을 짓는 것

기존 태그와 조합

 

Agree: 수긍

논리적 정합성

마땅하다고 생각

이름 짓기도 효율적으로 해야함

 

Remember: 기억

어떤 이름을 기억해내느냐가 중요

Amazon Simple Storage Service (S3)

이미 널리 알려진 용어는 그냥 쓴느 것이 효율적

 

Type: 타이핑

HTTP Referer 원래 Referrer 인데 오타로 사용중

RFC 문서에서 r을 하나 빼먹어서 쓰는 바람에 이후에 모두 Referer로 사용중

lambda, 가운데 b가 묵음

타이핑 하다보면 lamda로 검색하고, lambada로 검색할 수도 있다.

- 오타를 낼 가능성이 적은지

- 다른 사람에게 말로 전달하기 쉬운지

- 자판으로 입력할 때 잘 틀리는 단어의 예

  ㄴ successes, classes, committee, parallel

  ㄴ lambda, thumbnail, debt

  ㄴ chief, receive, retrieve, friends, achieve

  ㄴ position, commission

  ㄴ continuous, fabulous, genius

 


 

이름이 주석이 할 일을 대신하기 때문이다.

키 이름을 잘 정하기만 하면 주석을 쓸 이유가 없다.

`is-`: boolean

 

어순을 잘못 이해하면

- 3글자 이하

  ㄴ 3 and order

  ㄴ 3 or less

  ㄴ 3 or below

-  3글자 미만 (되도록 미만을 사용하자)

  ㄴ under 3

  ㄴ below 3

  ㄴ lessthan 3

  

중요한 것을 뽑으려면 덜 중요한 것을 빼야 한다.

리팩토링해서 주석을 없애는 편이 더 좋은 방법이다.

그래서 이렇게 잘못된 주석이 늘어나고,

그러다 보니 개발자가 주석을 믿지 않는 풍토가 생기고,

그러니 더 주석에 신경 쓰지 않게 된다.

 

주석은 악순환의 늪에 빠진다.

주석 리뷰도 꼼꼼히 해야 한다.

불필요한 주석은 없애고 꼭 필요한 주석은 반드시 코드처럼 다뤄야 한다.

 

HTTP 404, Google - That's all we know

404 에러가 죄송할 일인가?

죄송하게 생각한다면 당연히 사용자가 404 에러 페이지를 만나지 않게 만들어야 한다.

사용자가 URL을 잘못 입력한 경우

사용자가 링크를 클릭했으나, 해당 페이지가 없는 경우

 

링크

깨진 (broken)

죽은 (dead)

나쁜 (bad)

 

깨진 링크는 개발자의 책임이다.

개발자가 자기 소임을 다하지 못했다는 뜻

브로큰링크체크닷컴(https://www.brokenlinkcheck.com)

구글 서치콘솔(https://www.google.com/webmasters/tools)

 

개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자

개발하다가 미처 지우지 못해서 사용자가 볼 때도 있다.

C에서 #define 전처리기

매크로로 처리하면 여러 에러 메시지를 한 번에 쉽게 관리할 수 있다. (env 변수)

 

적절한 메시지가 되려면 먼저 사용자가 무엇을 잘못했는지 알려줘야 한다.

사용자 스스로 에러를 해결하게 하는 것이다.

- 내용

- 원인

- 해결방법

 

해결방법 > 원인 > 내용 순으로 배치해서, 빠른 해결을 돕는다.

적절히 줄바꿈해서 가독성을 높인다.

 

애매해지는 상화을 만들지 말자

이중부정은 긍정이다.

 

예 / 아니오

확인 / 취소

보다는 버튼에 좋은 네이밍을 부여하자.

페이지에서 나가기 / 페이지에 머물기

 

확인이 오른쪽에 있는 이유는 행동의 연속성 때문이다.

우리는 글을 쓸 때 왼쪽에서 오른쪽으로 쓰고

왼쪽에서 오른쪽으로 화살표를 그린다.

 

아랍어는 오른쪽에서 왼쪽으로 쓴다.

한자도 과거에는 오른쪽에서 왼쪽으로 썼다.

 

현 시점에서 국제 표준을 정의하는 것은 사실상 불가능하다.

서비스 내에서 일관성을 가지는 것이 좋다.

  확인 > 취소

  취소 > 확인

어떤 순서든 한가지 순서로만 표시하도록 하자. (결국엔 통일성)

 

사용자에게 앞으로 남은 로그인 횟수를 메시지로 보여주면 된다.

어떤 사용자든 로그인 가능 횟수가 줄어들면 자기 행동에 주의하게 된다.

 


 

한 번도 발생하지 않게 프로그램을 온전히 개발할 수 있는 개발자는 없다.

개발자도 사용자의 사용 방식을 이해해야 한다.

 

사용자를 이해하면 에러를 예방할 수 있다.

4자 띄어쓰기한 이유는 숫자를 더 잘 읽기 위해서

  4729427485038305

  4729 4274 8503 8305

숫자는 똑같다. 띄어쓰기 여부가 다를 뿐이다.

띄어 쓴 두 번째 숫자가 읽기에 훨씬 편하다.

 

이메일은 서비스 안내, 광고에 활용되므로 정확히 입력 받아야 한다.

메일 뒷부분을 선택할 수 있게 해놓음으로써 사용자의 에러를 줄인다.

 

Caps Lock이 켜져 있을 경우 그 사실을 미리 알려줌으로써

배터리가 부족하다 싶으면 사용자에게 예방 메시지를 보내서 사용자가 스스로 결정하게 만든다.

 

예방 메시지: 적은 비용으로 에러 발생을 막을 수 있다.

사용성을 높이고 서비스를 활성화하는 비즈니스 감각이 있는 개발자가 될 것이다.

 

결재 요청을 취소하는 일은 DB에서 해당 내용을 모두 지워야 하니 무척 번거롭다.

취소 기능을 요구하기 시작했고, 개발자들은 하는 수 없이 취소 기능을 만들었다.

재확인 -> 취소 기능이 섞여 버렸다. (비효율)

 

사용자가 자신의 행동을 주체적으로 책임지게 만들어야 한다.

꼭 필요한 것인지, 본래 역할을 제대로 수행하는지 고려해야 한다.

사용자가 에러 메시지를 어떻게 받아들일지는 모두 개발자의 철학에 달렸다.

 

체인지 로그(change log)

간단히 쓰면 한 일이 없어 보이고, 자세히 쓰면 아무도 읽지 않아 쓸모가 없다.

일을 열심히 하고도 체인지 로그를 제대로 안 쓰면, 이렇게 일한 보람도 없고 인정도 못 받는다.

 

상사나 고객의 만족도는 체인지 로그의 양이 적절할 때 가장 높다.

  1. 선정

  2. 분류

  3. 요약

  4. 종합

(1 > 2 > 3 > 4; 의식의 흐름대로 처리하는게 가장 좋은듯)

 

1. 선정 

기준표

x축: 독자의 관심의 정도 (우선순위 높음)

y축: 개발자의 관심의 정도

 

2. 분류 

관점에 따라, 비슷한 체인지 로그끼리 묶어야 한다.

개발관점: 새로운 기능 추가, 기능 개선, 오류 수정

독자관점: 게임준비, 게임중, 게임종료

 

3. 요약

불필요한 부사, 형용사, 조사, 어미를 없애기

정확하고 적절한 단어로 대체하기

 

4. 종합

"그래서, 핵심이 뭔가요?"

릴리스 내용 전체를 종합해서 한 문장으로 만들고 그것을 체인지 로그 첫 줄에 적어야 한다.

시간 절감, 정확한 사용, 결과를 쉽게 확인

사용성, 안정성, 편리성, 효율성 (결국 고객이다.)

 


 

고객 관점으로 쓰려면, 개발자의 문제를 해결하면 고객의 문제도 해결된다.

UI를 어떻게 개선했으면 이런 개선으로 고객이 얻는 혜택이 무엇인지 분명히 얘기해줘야 한다.

 

첫 번째 체인지 로그는 일반 사용자 관점으로 쓰고,

두 번째 체인지 로그는 개발자 관점으로

세 번째 체인지 로그는 그다지 중요하지 않은 것을 묶어서 기타로 처리

 

개발자가 언제 해결할지 약속하지 않는다면 고객이 어떻게 생각할까?

하지만 다음 릴리스 항목으로 검토하는 것이 있다면 중요한 것은 공개하는 게 좋다. (검토 중인 항목)

 

Semantic Versioning(유의적 버전)

https://semver.org/lang/ko/

 

첫번째 자리: Major 거의 호환되지 않는다.

두번째 자리: Minor 일부 호환될 수 있으나, 하위 버전에서, 새로운 기능을 사용할 수는 없다.

세번째 자리: Patch 간단한 패치

 

단일 표준은 없다.

최초 공개는 1.0.0 이어야 한다.

만약 상위 자리가 올라가면 하위 자리는 0으로 초기화 되어야 한다.

최초 개발 버전은 0.0.0 이 아니라 0.1.0 이다.

 

릴리즈 pre-release

1.0.0-alpha

1.0.0-alpha.1 점으로 구분하고 숫자를 덧붙인다.

일단 배포된 버전은 변경해서는 안된다.

변경이 있다면 무조건 버전을 올려야 한다.

 


 

문제 해결 보고서: 릴리스 문서를 정식으로 만들어서 고객에게 제공해야 한다.

버그를 잡거나 새로운 기능을 추가하거나 성능을 개선하는 것은 모두 어떤 문제를 해결하기 위해서다.

 

목표를 일치시키는 것이 중요하다. 문제를 해결하는 것

발생형 문제: 해결하기 위해, 원상 복구가 필요하다.

탐색형 문제: 개선하거나 효율을 높이는 문제다. 놓아두면 뒤에 큰 손실이 따르거나 해결할 수 없는 문제로 커진다.

설정형 문제: 미래 상황에 대응하는 문제다. 새로운 기능이나 대폭적인 업그레이드가 대부분 설정형 문제다.

 

 

문제, 문제점, 해결책, 후속계획

어떤 문제점을 선택하느냐에 따라 문제 해결 방법은 완전히 달라진다.

어떤 문제점을 선택했는지를 독자에게 정확히 알려줘야 한다.

 

사용자 급증은 문제점이 아니다.

문제점은 시스템의 잘못된 설정이나 최적화되지 않은 프로그램, 잘못된 DB 설계 등일 수 있다.

최적화하거나 DB를 재설계할 수 있다.

 

문제: 사용자가 급증하면 서버가 정지

문제점: 잘못된 시스템 설정, 프로그램 비 최적화, 잘못된 DB 설계

해결책: 시스템 설정 변경

후속계획: 프로그램 최적화, DB 재설계

 

 

법적인 문제를 문제를 고려해서 쓰자

이 릴리스 노트의 내용은 예고 없이 변경될 수 있습니다.

명시적 보증서만을 근거로 합니다.

노트의 어떤 내용도 추가 보증으로 해석할 수 없습니다.

당사는 이 문서에 포함된 기술적 오류나 편집상의 오류에 대해 책임을 지지 않습니다.

 

필수인지, 권장인지, 선택인지 명확히 알려줘야 한다.

 

필수

~해야한다.

~하지 않으면 안 된다.

~하면 안 된다.

~해서는 안 된다.

 

권장

~할 것을 권장한다.

~하는 것이 좋다.

~하는 것이 이상적이다.

 

선택

~할 수도 있다.

~해도 된다.

~하는 방법이 있다.

 

다음 릴리스 노트에는 해결 대상으로 적을 수 있게 해보자.

이번 릴리스에서 그 문제를 해결했습니다.

 


 

하지만 장애 보고서를 쓸 사람은 개발자 말고는 없어서, 개발자가 장애도 고치고 보고도 해야 한다.

 

첫째, 장애 보고서는 개발자가 원할 때 쓸 수 없다.

해결 직후나, 다음날 오전까지 장애 보고서를 쓰는 시간이다.

장애를 해결하면서 동시에 신속하고 계속적인 장애 보고 지시에 늘 시달린다.

 

둘째, 장애의 1차 원인은 대부분 다른 원인의 결과다.

원인의 원인을 계속 찾아 나가야 한다.

원인의 원인을 찾을 수 없을 때 그 원인이 장애의 최초 원인이다.

그 원인이 발생한 이유를 알아야 한다.

이유는 사람에게 있다.

 

셋째, 장애 보고를 받는 윗사람은 대부분 개발자가 아니다.

 

넷째, 장애를 해결했다고 해서 100% 해결한 것은 아니다.

재발하지 않는다고 확정할 수 없다.

확정적인 대답, 확정적이고 신뢰할 만한 결단을 정치적으로 내려야 한다.

 

 

신속한

원인과 이유를 찾는 분석적인

비즈니스 관점

정치적 글쓰기

 

글을 빨리 쓰는 방법 중에 대화를 글로 옮기는 방법이 있다.

일단 무슨 말이든 내뱉고 나서 생각을 정리하고, 질문을 받으면 답하면서 다음 생각으로 이어간다.

 

"서버 개발자가 잘못한 거지, 함수를 바꾸려면 나한테 말하고 바꿨어야지."

서버 쪽과 프론트 쪽 커뮤니케이션 단절

 

핵심원인: 서버쪽과 프론트 쪽 커뮤니케이션 단절

향후대책: 서버, 프론트 쪽 팀장이 소통 방법 협의하여 보고

 

 

5Whys: 원인과 이유를 찾는 분석적 글쓰기

사물이나 현상, 동작이 문제를 초래하는 원인,

사람이 문제를 초래한 이유다.

어떤일 또는 사람

 

IT 분야에서 장애는 대부분 재발한다.

시스템 자원 부족

대부분 사람이 문제다.

모르고 있다가 장애가 난다.

 

원인 대신 이유를 물어봐야 한다.

항상 사람이 주어가 되어야 한다.

커뮤니케이션 문제를 해결해야 한다.

 

"가진 것이 망치뿐이면 모든 것이 못으로 보인다."

"if all you have is a hammer, everything looks like a nail"

각자 자기 위치와 입장에서 최선을 다하는 것뿐이다.

 

모든 직원의 역할과 업무와 성과는 모두 월급이나 상여금 같은 돈으로 측정된다.

비즈니스도 마찬가지다.

모든 활동은 매출과 비용으로 연결되고 측정된다.

회사에서 어떤 일이 매출이나 비용으로 측정될 수 없다면 그 일을 해서는 안된다.

개발자가 장애를 해결하는 일도 매출을 늘리거나 비용을 줄이기 위함이다.

 

1시간 동안 결제하지 못함.

00억 원의 매출 손실이 발생함.

시간은 곧 돈이다.

 

 

장애는 보통 예상하지 못한 데서 발생한다.

그러니 장애를 해결했다고 해서 다시는 그 장애가 발생하지 않는다고는 볼수 없다.

미묘한 차이가 있다.

대답을 원한다. 심지어 재발 가능성을 백분율로 말해주기까지 원한다.

 

개발자는 어떤 일을 과격하게 표현해야 할 때가 있다.

  1%: 절대 재발하지 않는다.

  20%: 재발할지도 모른다.

  60%: 재발하지 않는다고 볼 수 없다.

  99%: 반드시 재발한다.

 

장애가 발생할 확률이 10%도 안되는데 90%인 양 호들갑을 떨거나,

장애 발생 확률이 99%나 되는데도 별일 아니라고 보고하면 안된다.

(허위 보고는 하면 안된다.)

`정치적 == 글에 힘을 싣는다`는 의미임

일반적인 정치는 극혐;;

 


 

개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징 순으로 쓰는 것이 좋다.

유사한 용어를 여러 개 사용한다.

개발자가 범주를 정할 때는 신중하게 결정해야 한다.

범주는 서비스를 소개하거나 설명하는 첫 문장인 만큼 정확하고 적절하게 정해야 한다.

보편적인 서비스 범주

 

정체성을 나타낼 뿐만 아니라 검색어와도 연관이 있다.

 

장점과 강점을 뽑아 쓰자.

개발자에게 차별화는 서비스의 장점과 강점이다.

장점은 자기 기준에서 잘하는 것이고,

강점은 경쟁 서비스와 비교해서 나은 것이다.

 


 

글에 묘사를 더하면 이해가 빠른다.

글 아래에 그림을 그려 넣으면 독자가 직접 그림을 그리지 않아도 되고 더 빨리 이해할 것이다.

글과 그림의 내용을 일치시키자.

 

기획자에게 객관적 묘사를 기대할 수 없으므로, 스스로 주관적 묘사를 객관적 묘사로 바꿔야 한다.

개발자가 주관적 묘사와 객관적 묘사를 둘 다 잘하면 기획자나 디자이너와 협업할 때 주도권을 가질 수 있다.

개발자가 주도권을 가지면 비교적 개발이 쉬워지고 나중에 변경할 것도 줄어든다.

 


 

의견을 쓰려면 근거를 대자

논증은 옳고 그름을 이유나 근거를 들어서 밝히는  것이다.

논술의 핵심이 논증인 셈이다.

객관적이고 논리적인 방식으로 어떤 사실을 증명해서 상대를 설득하는 일이다.

 

품질이 좋아지지만 인코딩에 더 많은 시간이 소요 (trade-off)

 

가장  좋은 방법은 개발자가 직접 체험한 결과를 알려주는 것이다. (경험 공유)

 

 

거칠게도 공손하게도 쓰지 말자 (애매하기 때문이다.)

  어쩌라는 거지?

  시도하라는 건가?

  하지말라는 건가?

독자의 기대치를 충족하지 못할 때 쓴다.

 

개발문서에서 공손한 표현은 좋지 않다.

세상에 어떤 일이든 100% 확신할 수는 없다.

하지만 개발문서는 독자에게 여지를 줘서는 안된다.

 

호의가 계속되면 권리인 줄 알듯이, 개발문서가 너무 공손하면 독자를 가이드할 수 없다.

주장을 했으면 이유를 바로 이어서 말해야 한다.

 

결국 개발문서가 시키는 대로 하지 않는다.

버그가 생기고 한참을 고생해서 디버깅하다가 개발문서를 보고 욕한다.

 

논증은 문제 해결과 비슷하다.

문제가 있으면 바로 답을 알기를 원한다.

지루한 과정을 먼저 보여줄 필요가 없다.

불필요한 세 문장을 읽어야 한다.

답의 거리를 좁혀서 쓰면 이해하기도 쉽고 불필요한 문장을 읽지 않아도 된다.

 


 

서사는 사실을 있는  그대로 순서대로 적는 것을 말한다.

어떤 일을 하라고 지시한다는 것이다.

 

단순한 사건이나 상황을 시간 순으로 무조건 기술하는 것은 아니다.

개발자는 어떤 행동에 의미를 두고 글을 쓸지 직접 결정해야 한다.

 

의미 없는 것은 빼고 중요한 것은 넣기를 원한다. (context가 유지되는 선에서)

 

기술의 범용성을 기준으로 하는 것이다.

기본적인 수준을 맞춰놓는 것이다.

최소 분량으로 기본적인 지식을 설명한다.

최초 실행될 때 중요한 사용법을 몇 개의 화면으로 미리 보여주는  것과 같다.

 

시스템 구성도(As-Is)를 분석해서

새로운 시스템(To-Be)를 구상해

목적, 목표, 전략, 방안, 효과, 특징, 장점, 강점을 기술하는 것은 개발자의 본래 업무를 뛰어넘는 일이다.

"시스템의 성능, 안정성, 확장성을 위해 다음과 같이 시스템을 구성함."

 

제대로 분석

논리적으로 완결

고객의 요구, 고려사항, 전략, 목표, 방안, 특장점, 기대효과가 들어가야 한다.

 


 

고객의 문제 인식이다.

문제 해결에 드는 비용보다 문제 해결로 얻는 효과가 낮으면,

즉 비용 대비 효과가 낮으면 문제를 그냥 놔둔다. (효율)

 

제안사의 문제 해결 능력도 제안서에 영향을 끼친다.

탁월한 솔루션

세부 기능이나 스펙을 비교해서 제안해야 한다.

 

솔루션도 없는 제안사가 '나도 할 수 있다'라거나 '한번 해보겠다'라고 쓰면 그 프로젝트는 망한다고 봐야 한다.

제안서에서는 누가 더 일리 있는 안을 내놓느냐가 중요하다.

 

충분한 학습시간이 필요하다.

 

 


 

개발하는 중에 요구사항이 바뀌기도 하고,

새로운 요구사항이 들어오기도 하고,

힘들게 개발한 기능이 요구사항에서 빠지기도 한다.

이럴 때마다 개발자는 허탈하고 속상하고 황당하다.

 

고객은 자기가 원하는 제품이 정확히 뭔지 모른다.

알아서 판단하고 내게 정확한 요구사항을 제시해 주시오.

고객에게 요구사항을 제시해서 고객이 선택하게 만들어야 하고 그 선택에 따라 개발해야 한다.

 

동시에 구현할 수 없다고 알려주면서 요구사항을 다시 제시해야 한다.

요구사항이 끊임없이 변한다는 것을 이해해야 개발자가 대응할 수 있다.

가장 좋은 방법은 요구사항 정의와 구현, 고객의 검수 사이의 시간 차이를 줄이는 것이다.

 

반복적으로, `분석-설계-구현-테스트-검수` 하면서 점검한다.

 

개발하기 직전에 고객과 요구사항을 다시 한 번 구체적으로 점검하는 것이다.

개발이 끝나면 즉시 고객에게 테스트를 요청하고 검수를 받는다.

시간 차이를 최소화 & 고객의 변덕에 대비할 수 있다.

 


 

그러니까, 요구사항을 모두 충족하는 개념이 아니라, 고객의 총 만족도를 높이는 것이다.

고객의 총 만족도를 높이는 쪽으로 설계해야 한다는 뜻 (fact..!!)

 

당연한 요구를 당연히 수행한 것이다.

로딩 시간이 짧으면 짧을수록 고객의 만족도는 커진다.

지문이나 홍채 인식으로 로그인할 수 있는 기능을 추가하면 고객은 크게 만족한다.

 

개발자는 기본적으로 기본 기능 요구는 모두 수용해야 한다.

요구는 한계를 정해야 한다.

기능의 성능을 강화할 수는 없다.

특별한 기능은 하나쯤 만들어야 한다.

특별한 기능 하나가 개발자의 다른문제(해결하지 못한 몇몇 요구나 버그)를 해결해 줄 수도 있다.

 


 

블로그에 글을 쓰는 방법

배운 글쓰기 방법과 다르기 때문이다.

논설문이나 설명문을 쓰는 방법이었다.

 

- 왜 쓰는가?

- 읽는 독자?

- 무엇을 말하려고 하는가?

- 주장하는 바가 무엇인가?

- 주장하는 바의 근거는 명확한가?

 

문제해결 과정의 핵심은 문제를 충분히 고민하여 해결 방안을 전략적으로 선택하는 것이다.

 

계획을 세우는데, 시간을 충분히 할애

충분히 생각해서 주제를 정하고 주제 의식을 확립한 후 글을 쓸 때 필요한 자료나 아이디어를 구해야 한다.

부족함이 있으면 근거가 완벽해질 때까지 글을 쓰면 안 된다.

 

단지 개발자가 했던 선택과 몇몇 상황에서 더 좋은 방법을 제시할 수 있을 뿐이다. (경험)

우선 글쓰기, 자기 수준 글쓰기, 재미있는 글씨기

 

비유법: 본질 통찰력 & 추상화능력

 

원래 사용하는 용어로 그냥 표기하되,

필요하다면 용어를 정의한 위키피디아 페이지 & 세부 내용을 볼 수 있는 사이트나 문건을 링크로 걸어두면 된다.

기술 블로그란 것은 결국 실력이 비슷한 독자를 위한 것이다.

독자가 공부할 수 있게 길만 터놓는 것이 현명한 방법이다.

 

OOP를 사용하면 코드의 중복을 어느 정도 줄일 수 있고

입력 코드, 계산 코드와 결과 출력 코드 등 코드의 역할 분담을 좀 더 확실하게 할 수 있어서 가독성이 높아질 수 있다.

추상화, 모듈화, 확장, 유지보수, 가독성

 


 

저: 직접 경험하고 실험한 과정이나 결과

술: 어떤 것을 분석항여 의미를 풀이하고 해석한 것

편: 산만하고 복잡한 자료를 편집해 질서를 부여한 것

집: 여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것

 

목차를 잘 구성해야 한다.

목차만 제대로 잡으면 다른 종류의 글보다 쓰기 쉽다.

 

본문 > 맺음말 > 머릿말

 

편: 산만하고 복잡한 자료를 편집해 질서를 부여한 것이다.

집: 여러 사람의 견해나 흩어진 자료를 한데 모아 정리하는 것이다. (부록)

 

개발기는 개발자의 수준을 보여준다.

 


기업의 기술 블로그 운영 팁

채용 직무에 적합하면서 개발 능력이 우수한 개발자 채용에 도움을 준다.

개발 과정에서 생긴 노하우를 체계적으로 축적할 수 있다.

 

개발자가 스스로 공부하게 만든다.

지식을 체계화 하는 과정이 필요하다.

과정에서 개발자는 모르는 것을 찾아내서 알아내고 아는 것을 재확인 한다.

기술을 더 빨리 익히고 문제를 해결하는 노하우를 기른다.

 

개발 수준을 높여서 개발자의 생산성이 향상된다.

개발자 스스로도 자신의 몸값을 높일 기회가 된다.

 

개인블로그, 육하원칙이나 두괄식 구성을 지키지 않아도 된다.

 

 

728x90
댓글