말차맛 개발공부

소프트웨어 스펙 소프트웨어를 만들 때 가장 중요한 것이 뭘까 보통은 코드를 생각할 것이다. 이는 반은 맞고 반은 틀리다고 할 수 있다. 코드만큼이나 소프트웨어 스펙을 작성하는 일이다. "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라 무엇을 개발할지 결정하는 일이다" - 프레드릭 브룩스 - 1장에서는 소프트웨어 스펙이란 무엇인지부터 스펙의 중요성에 대해 설명한다. 2장에서는 SRS 템플릿을 기반으로 작성법을 소개한다. 급할수록 돌아가라 처음으로 진행했던 프로젝트가 생각해보면 정말 무식했다. 지금 생각해보면 어떻게 그렇게 무식하게 코딩을 했나 싶다. 처음부터 좋은 팀원을 만나 체계적인 프로젝트를 경험하는 운 좋은 사람도 있긴하지만, 대부분은 나와 같이 주먹구구 식으로 진행을 했을 것이다. 나..

어릴 때, 무인도에서 살아남기라는 책을 재밌게 읽었다. 개발자를 꿈꾸는 지금, 개발자로 살아남기라니... 그냥 지나칠 수가 없었다. 개발자는 코드를 작성한다. 코드를 작성하는 것이 좋아 100살까지 코드를 작성할 수도 있다. 다만 작가가 걸어온 길은 코드만을 작성하는 것이 아닌, 개발과 관련된 일을 하는 30년이었다. 작가는 30년을 10년 씩 해서 크게 세 가지로 나누었다. 이 책에서 말하는 것이 정답이 아닐 수 있다. 다만 30년간 IT 업계에 몸 담아오며 산전수전 다 겪어본 프로의 이야기에 귀를 기울여야 하는 것만은 틀림없다. 개발자의 소양 3가지 1. 크리티컬 싱킹하라 (=비판적으로 생각해라) 상사가 일을 시키면 그냥 하지 마라. 그냥 일만 하면 일 잘하는 직원은 될 수 있다. 하지만 좋은 개발자..

개발자라고 하는 직업을 떠올리면 코드를 작성하는 모습이 가장 먼저 떠오른다. 사실 개발자도 여타 다른 직업들처럼 보고서를 써야한다. 장애 보고서, 제안 요청서 등 코드만 치는 것이 아니라 워드나 노션 키고 글을 써야한다. 기존에 깨끗한 코드를 작성하기 위한 바이블, 클린코드(나의 리뷰 보러가기)가 있다. 클린코드는 어떻게 변수 이름을 짓고, 함수를 만들고, 주석을 쓰는 지 등 깔끔한 코드 작성을 위한 세세한 내용을 다룬다. 이 책도 변수네이밍과 과련된 내용을 다룬다. 하지만 거기서 그치지 않고 고객을 위한 릴리스 노트, 비즈니스 관점에서의 장애 보고서, 기술 블로그 등 개발자가 해야하는 전반적인 글쓰기를 다룬다. 개발자는 혼자서 일하지 않는다. 개발자들과의 협업 개발을 혼자서 하는 경우도 있지만, 보통은..

일전에 동아리 프로젝트를 진행하면서 디자이너님이 질문을 한 적이 있다. "ㅇㅇ님 API 가 뭔가요??" 사실 이 때 적잖이 당황했다. API를 어떤식으로 설명해야하지?? 내 머릿속에서 API는 호출을 통해 서버에서 데이터를 가져오는 것이였는데, 이걸 개발을 잘 모르는 사람한테 설명하려고 하니 머리가 캄캄해졌다. 이럴 때 치트키, 위키백과를 사용했다. 위키백과 설명도 뭔가 직관적이지 않았다. 어떻게 하면 비전공자에게 개발지식을 잘 설명해줄 수 있을까 고민을 했다. 그러던 중 서점에서 재미있는 책을 발견했다. 바로 오늘 리뷰하는 책 "오늘도 개발자가 안 된다고 말했다" 이다. 책 표지의 개발자 표정에 이끌려 책을 열어보았다. 책의 내용을 언뜻 훑어보니, 현업에서 개발자와 협업을 하며 어려움을 겪었던 기획자와..

시험기간이라 한동안 책을 못 읽었는데 어제 종강한 기념으로 한 권 읽었다. 2주전 쯤에 3장까지 읽었던거 같은데 오랜만에 보니까 기억이 흐릿했다. 틈틈히 읽어서 좋은 책도 있지만 이 책처럼 흐름에 따라 진행되는 책은 한 번에 읽어야 머리에 잘 들어오는 것 같다. 유닉스는 컴퓨터의 역사에 대해 들어본 사람이라면 한 번쯤은 들어본 이름이다. 지금 많이 쓰이는 운영체제인 리눅스와 Mac OS의 기원이기도하다. 현대 운영체제의 밑거름이라고 볼 수 있겠다. 이런 유닉스의 탄생과정을 직접 만든 사람 (브라이언 커니핸) 한테 얘기를 들을 수 있다는 점에서 이 책의 메리트는 충분한 것 같다. 벨 연구소 = 6~70년대 실리콘 밸리 유닉스는 벨 연구소에서 탄생했다. 아마 벨 연구소하면 맨 처음 생각나는 것은 C언어일 것..

좋은 코드란 무엇일까? 모두가 한 번쯤 생각해봤을 질문이다. 우선은 제대로 동작해야할 것이다. 원하는 기능을 수행하지 못하면 코드가 아니라 그냥 타이핑 한 텍스트일 것이다. 테스트를 통과할 수 있어야 한다. 그 다음은? 바로 "깨끗한 코드" 이다. 왜 깨끗한 코드가 필요할까?? 개발 방법론에 따라 다르기는 하겠지만, 보통 프로젝트를 기획하고 하나의 소프트웨어를 만든다고 하자. 개발 기간이 1년이라면, 사용하면서 유지보수 하는 기간은 10년에서 길게는 100년까지도 본다. 즉 무언가를 만드는 것보다 유지보수하는데 더 많은 시간과 노력이 필요된다. 유지보수하는데에는 여러가지 어려움이 있지만 그 중에서도 이해할 수 없는 코드가 가장 대표적인 장애물이다. 이해할 수 없다는 것에는 특정 언어에 대한 이해력이 부족..