<div id="readability-page-1" class="page"><div>
  <main>
    <ul>
<li>
<p>요즘 나도 글쓰기가 정말로 중요하다는 생각이 들었다. 그러던 와중에 해당 글을 읽고나서 많은 것을 느끼게 되었다.</p>
</li>
<li>
<p>업무를 하면서 글쓰기가 정말로 중요하다는 것을 느끼고 있었는데, 최근에 오픈 소스 개발을 하면서 이메일을 작성할 일이 많은데 나의 상황을 논리적으로 설명을 못하는 것 같아 더욱 뼈저리게 느끼고 있는 것 같다.</p>
</li>
<li>
<p>이를 위해서 글또라는 매주 기술 블로그 글을 작성하는 동아리까지 가입했는데 바쁘다는 핑계로 요즘 글도 잘 안적고 있는 것 같아서 반성을 하게 된다.</p>
</li>
<li>
<p>사실 요즘 글을 작성하지 않는 것은 요즘 개인적인 공부를 하지 않고 있기 때문인 것 같기도 하다.</p>
</li>
<li>
<p>오픈 소스 개발을 하면서 느낀점을 적는 것도 유의미 하다는 것을 알지만, 너무 시간이 많이 소요될 것 같아서 미루고 있다. 하지만 막상 생각했던 것과는 달리 생산성이 더욱 향상될지는 모르겠다.</p>
</li>
</ul>
<h3 id="최근에-어떤-신입분과-같이-일을-하게-되었다">최근에 어떤 신입분과 같이 일을 하게 되었다</h3>
<hr>
<ul>
<li>
<p>사실 그전에는 거의 혼자 작업하는 일이 많아서 그런지 문서화의 중요성을 알긴 했지만 와닿지는 않았다.</p>
</li>
<li>
<p>나름 나중에 프로젝트를 이어받거나 같이 할 사람을 위해서 커밋 메시지 작성이나 이슈 관리를 잘 했다고 생각했지만 지금 다시 보니 여전히 부족하다.</p>
</li>
<li>
<p>따라서 개인적인 취향보다는 팀내에서 규칙을 만들어서 컨벤션을 정하는 것이 중요할 것 같다는 생각을 했다. 또한 회사에서는 깃랩을 사용하는데 PR TEMPLATE이 있는지는 모르겠지만 도입하면 좋을 것 같다.</p>
</li>
</ul>
<p><strong>예시</strong></p>
<pre tabindex="0"><code>[Feature / BugFix 등등] 변경점 요약

- What. 무엇을 바꿨는가
- How. 어떻게 바꿨는가
- (Optional) 주의할 사항, 신경쓸 사항
  - ex) client 측에서 사용하는 api 응답값 변경
- (Otpional) 참고사항
  - ex) wiki, jira link
  - ex) 관련 reference
</code></pre><h3 id="좋은-변수명을-짓는-방법">좋은 변수명을 짓는 방법</h3>
<hr>
<ul>
<li>이 글에서 좋은 변수명을 적는 방법에 대해서 나왔는데 참고하면 좋을 것 같아서 적어본다.</li>
</ul>
<pre tabindex="0"><code>1. 검색하기 쉽게 (easy to searh)
2. 조합하기 쉽게 (easy to mix)
3. 수긍하기 쉽게 (easy to agree)
4. 기억하기 쉽게 (easy to remember)
5. 입력하기 쉽게 (easy to type)
</code></pre><h3 id="내가-작성하려는-글이-어떤-성격인지를-파악하자">내가 작성하려는 글이 어떤 성격인지를 파악하자</h3>
<hr>
<table>
<thead>
<tr>
<th>구분</th>
<th>내용</th>
<th>종류</th>
</tr>
</thead>
<tbody>
<tr>
<td>저</td>
<td>직접 경험하고 실험한 과정이나 결과</td>
<td>개발기, 도입기, 적용기</td>
</tr>
<tr>
<td>술</td>
<td>어떤 것을 분석하여 의미를 풀이하고 해것한 것</td>
<td>기술 소개, 용어 분석, 에러 해결 방법</td>
</tr>
<tr>
<td>편</td>
<td>산만하고 복잡한 자료를 편집해서 질서를 부여한 것</td>
<td>프로그램 설치, 설정 방법, 튜토리얼, 세미나 후기, 책 리뷰</td>
</tr>
<tr>
<td>집</td>
<td>여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것</td>
<td>명령어 모음, 팁, OO가지 규칙</td>
</tr>
</tbody>
</table>
<ul>
<li>다음은 기술 글쓰기의 종류인데 내가 지금 쓰려는 글일 어떤 종류의 글인지를 파악하고 적으면 좋을 것 같아서 발췌해서 적어본다.</li>
</ul>
<h3 id="개발자와-기획">개발자와 기획</h3>
<hr>
<ul>
<li>
<p>개발자도 기획을 어느정도 해야한다는 대목을 읽고나서 많이 공감을 했다. 사실 나는 개발자로 일하고 있기는 하지만, 기획자로 일해보고 싶은 마음도 있고 디자이너로 일하고 싶은 마음도 있는 상태이다.</p>
</li>
<li>
<p>여기서 말하는 기획은 기술적인 문제에 대해서 제안을 하고 설득을 하기 위해서 기획을 어느정도 알아야 된다고 말하고 있지만 나는 언젠가는 기획자로 일을 해보고 싶다.</p>
</li>
<li>
<p>기획의 신이라는 책에서는 기획의 핵심 기술을 아래 내용으로 설명을 한다고 했다.</p>
</li>
</ul>
<pre tabindex="0"><code>1. 기획의 목적 -&gt; WHY
2. 기획안의 본론, 발견한 문제에 대한 해결책이 구체화되는 단계 -&gt; WHAT
3. 세부적인 실행 계획을 제시하는 단계 -&gt; HOW
</code></pre><ul>
<li>내가 개발하려는 기능의 목적과 어떻게 해결하면 좋을지 기획자의 시건에서 생각을 해볼 필요도 있을 것 같고, 무엇보다 사용자 입장에서 정말로 원하는 기능일까를 많이 생각을 해봐야겠다.</li>
</ul>
<h3 id="참고-문헌">참고 문헌</h3>
<hr>
<ul>
<li><a href="https://dev.gmarket.com/30">개발자의 글쓰기는 다르다</a></li>
</ul>

    <a href="../../../../"> &gt;&gt; Home</a>
  </main>
</div></div>

Home on 개발자 이동욱

Lee Dong Wook

요즘 나도 글쓰기가 정말로 중요하다는 생각이 들었다. 그러던 와중에 해당 글을 읽고나서 많은 것을 느끼게 되었다.
업무를 하면서 글쓰기가 정말로 중요하다는 것을 느끼고 있었는데, 최근에 오픈 소스 개발을 하면서 이메일을 작성할 일이 많은데 나의 상황을 논리적으로 설명을 못하는 것 같아 더욱 뼈저리게 느끼고 있는 것 같다.
이를 위해서 글또라는 매주 기술 블로그 글을 작성하는 동아리까지 가입했는데 바쁘다는 핑계로 요즘 글도 잘 안적고 있는 것 같아서 반성을 하게 된다.
사실 요즘 글을 작성하지 않는 것은 요즘 개인적인 공부를 하지 않고 있기 때문인 것 같기도 하다.
오픈 소스 개발을 하면서 느낀점을 적는 것도 유의미 하다는 것을 알지만, 너무 시간이 많이 소요될 것 같아서 미루고 있다. 하지만 막상 생각했던 것과는 달리 생산성이 더욱 향상될지는 모르겠다.
최근에 어떤 신입분과 같이 일을 하게 되었다
사실 그전에는 거의 혼자 작업하는 일이 많아서 그런지 문서화의 중요성을 알긴 했지만 와닿지는 않았다.
나름 나중에 프로젝트를 이어받거나 같이 할 사람을 위해서 커밋 메시지 작성이나 이슈 관리를 잘 했다고 생각했지만 지금 다시 보니 여전히 부족하다.
따라서 개인적인 취향보다는 팀내에서 규칙을 만들어서 컨벤션을 정하는 것이 중요할 것 같다는 생각을 했다. 또한 회사에서는 깃랩을 사용하는데 PR TEMPLATE이 있는지는 모르겠지만 도입하면 좋을 것 같다.
예시
[Feature / BugFix 등등] 변경점 요약
- What. 무엇을 바꿨는가
- How. 어떻게 바꿨는가
- (Optional) 주의할 사항, 신경쓸 사항
  - ex) client 측에서 사용하는 api 응답값 변경
- (Otpional) 참고사항
  - ex) wiki, jira link
  - ex) 관련 reference
좋은 변수명을 짓는 방법
이 글에서 좋은 변수명을 적는 방법에 대해서 나왔는데 참고하면 좋을 것 같아서 적어본다.
1. 검색하기 쉽게 (easy to searh)
2. 조합하기 쉽게 (easy to mix)
3. 수긍하기 쉽게 (easy to agree)
4. 기억하기 쉽게 (easy to remember)
5. 입력하기 쉽게 (easy to type)
내가 작성하려는 글이 어떤 성격인지를 파악하자
구분
내용
종류
저
직접 경험하고 실험한 과정이나 결과
개발기, 도입기, 적용기
술
어떤 것을 분석하여 의미를 풀이하고 해것한 것
기술 소개, 용어 분석, 에러 해결 방법
편
산만하고 복잡한 자료를 편집해서 질서를 부여한 것
프로그램 설치, 설정 방법, 튜토리얼, 세미나 후기, 책 리뷰
집
여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것
명령어 모음, 팁, OO가지 규칙
다음은 기술 글쓰기의 종류인데 내가 지금 쓰려는 글일 어떤 종류의 글인지를 파악하고 적으면 좋을 것 같아서 발췌해서 적어본다.
개발자와 기획
개발자도 기획을 어느정도 해야한다는 대목을 읽고나서 많이 공감을 했다. 사실 나는 개발자로 일하고 있기는 하지만, 기획자로 일해보고 싶은 마음도 있고 디자이너로 일하고 싶은 마음도 있는 상태이다.
여기서 말하는 기획은 기술적인 문제에 대해서 제안을 하고 설득을 하기 위해서 기획을 어느정도 알아야 된다고 말하고 있지만 나는 언젠가는 기획자로 일을 해보고 싶다.
기획의 신이라는 책에서는 기획의 핵심 기술을 아래 내용으로 설명을 한다고 했다.
1. 기획의 목적 -> WHY
2. 기획안의 본론, 발견한 문제에 대한 해결책이 구체화되는 단계 -> WHAT
3. 세부적인 실행 계획을 제시하는 단계 -> HOW
내가 개발하려는 기능의 목적과 어떻게 해결하면 좋을지 기획자의 시건에서 생각을 해볼 필요도 있을 것 같고, 무엇보다 사용자 입장에서 정말로 원하는 기능일까를 많이 생각을 해봐야겠다.
참고 문헌
개발자의 글쓰기는 다르다

개발자의 글쓰기는 다르다는 글을 읽고나서 적은 생각

댓글