[실용주의 프로그래머] 2일차

책.책.책을 읽어요!

• 오늘의 책읽기: 서문 ~ 1장.실용주의 철학 까지!
• 오늘의 과제: TIL 작성하기
• 제출기간: 익일 오전 6시까지

TIL 작성하기

• TIL, Today I Learned 는 책 감상평을 쓰는 방법 중 하나 입니다.
• TIL 작성방법을 숙지한 후. TIL을 작성해주세요.
• TIL 책 감상평 예시 를 참고하세요.

슬랙에서 이야기를 나눠봐요!

• 책 읽으면서 궁금했던 것들! 다른 사람들은 어떻게 생각할까? 궁금하지 않았나요?
• 슬랙 채팅방에 놀러와서. 이야기를 자유롭게 해봐요 ;)
• 슬랙 채팅방 참여하기 #book-club-pragmatic 으로 오세요

제출방법

• 제출기간: 익일 오전 6시까지
• 업로드 하신 게시물 링크를 아래 제출하면 끝!

---

당신의 인생이다 - "왜 직접 바꾸지 않습니까?"   구직자에게 주도권이 있는 직업 순위를 뽑아보면 소프트웨어 개발은 제일 윗부분에 자리잡을 것이다. 우리 기술은 수요가 많고 ...

확실히 맞는 말이다. 주장하고 요구하면 어떤 요구라도 들어주는 곳이 바로 소프트웨어 세계라고 생각한다. 물로 실력이 조금 있어야 하지만...
지금 3개의 스터디를 진행하고 있다. 하지만 책을 읽고 토론을 진행하다 보니 시간대비 효율이 조금 떨어진다. (인터넷 강의는 수동적으로 실습하면되지만 토론은 다 준비해야한다.)
그러니 인터넷 강의를 하나 더 추가해 실습과 개발을 하나 시작해야할듯 하다. 

 

고양이가 내 소스 코드를 삼켰어요 - 팀내 신뢰 - 책임지기 변명 말고 대안을 제시하라. 안된다고 하지말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.  ... 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해 보라. 그래도 꼭 해야겠다면 여러분의 고양이에게 먼저 해보라. 아무튼 야옹이가 대신 비난을 받을 수만 있다면야... ... 은행원이나 자동차 수리공, 가게 점원이 여러분 앞에서 어설픈 변명을 늘어놓으면 어떻게 반응하겠는가? 그들에 대해, 그리고 결과적으로 그 회사에 대해 어떤 생각이 들겠는가?

  흠... 최근 개발과정에서 DUE DATE 에 대해 전달받지 못해 문제가 생긴 경험이 있다. 
  분명 힘들 배포가 힘들것이라고 이야기했던거 같지만 '일정관리하는 사람 문제지..' 라고 책임없는 생각을 반성하게 되는 순간이다.
  나는 대안으로 서버에서 처리하는 방법이나 배포없이 적용할 수 있도록 하는 방법을 모색했어야 했다. 

반성하고 기억하자!

 

소프트웨어 엔트로피 - '깨진 창문'을 고치지 않은 채로 내버려 두지말라. 나쁜설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. - 우선 망가트리지 말라

  레거시는 언제나 문제를 일으킨다. '어차피 개편하는데 없어질 코드인데...', '나는 이게 더 익숙하니깐...'등등 다양한 이유에서 이런 변명을 한다.
  이런 사소한 부분에서 팀내 신뢰가 깨지고 '깨진 창문'이 늘어난다. 결국 누군가 해야하는데 말이다. 일정이 급해서, 인력이 부족해서.. 이런 이유는 우리에게 적절하지 않다. 
왜? 
클린코드에서 배웠으니까, 
'르블랑의 법칙' - 나중은 절대 돌아오지 않는다. 
'보이스카웃 규칙' - 들어올때보다 나갈때 깨끗해야한다. 

이처럼 레거시를 깔끔하게 리팩토링하는 과정은 필수!

 

돌멩이 수프와 삶은 개구리 돌멩이를 내놔야할때다. 큰 무리 없이 요구할 수있을 많나 것을 찾아라. 그리고 그걸 잘 개발하라. 일단 무언가 생기면 사람들에게 보여주고 그들이 경탄하게 하라. 그로고는 '물론......를 추가하면 도 나아질 수도 있겠죠'라고 말하면서 그다지 중요하지 않은척 가장하라.

거의 대화의 기술.
하지만 그만큼 전략적으로 다른사람에게 요구하는 것을 쟁취해야한다. 
어쩌면 '당신의 인생이다'와 전혀 상반된 내용일지 모른다. 그렇지만 필요한 기술이다.
실패에 무게감이 '당신의 인생이다.'보다 덜할 것이다.  

 

적당히 괜찮은 소프트웨어 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라, 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다....

이번책에서 가장 궁금한 부분!

적당히는 어느 정도의 수준인가?
항목 45, 항목 46에서 집중하자!

 

벌써 어렵다..

하지만 만들어볼 만한 체크리스트다. 
매월 기술관련 체크리스트를 만들어서 이런 작업을 실력을 쌓아보자!

 

소통하라 코드와 문서를 함께 둬라 소스코드에 다는 주석은 프로젝트에서 쉽게 누락되는 다른곳에서 문서화 할 수 없는 부분을 문서화하기에 최적의 기회다. 예를들어 기술적인 절충점, 어떤 결정의 이유, 폐기한 다른 대안등을 기술 할 수 있다.

이런 경우는 잘 사용하는 것을 본 적이 없다. 
노션을 추가하여 기록하는 것을 좋아한다. 
기능안전 프로세스때문일 것이다. 
하지만 덕분에 문서를 남기고 해당 문서를 전달하고 리뷰받는등 현업에서 잘 쓰이고 있다. 

문서화는 중요하다고 생각한다.
이유를 전달하고 알리고 개발 목표와 절충점, 결정의 이유, 폐기이유등 다양한 의사소통이 오갔지만 코드는 단순하게 결과물뿐이다. 
그래서 문서화는 그만큼 중요하다!