말차맛 개발공부

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

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

현업 기획자 도그냥이 알려주는 서비스 기획 스쿨 다가오는 방학에 동아리에서 앱 런칭을 기획하고 있다. 지난 방학에 처음으로 앱을 만들었을 때, 내가 관심있어 하는 주제가 아니여서 그런지 조금은 흥미가 떨어졌었다. 이번에는 내가 원하는 방향의 앱을 만들기 위해 PM(프로젝트 매니저)를 하면서 개발을 할 것이다. 기획이라고 하면 서비스의 큰 틀만 제시하면 될 거라고 생각했다. 오산이였다. (경기도 오산시 아님) 지난 번 프로젝트에서 기획자와 함께 협업을 하면서, 기획자가 챙겨야하는 일이 정말 많다는 것을 배웠다. 기능 정의, 서비스 전략, BM(Buisness Model), 페르소나 정의 등 할 것도 많고 따져야 할 것도 많았다. 처음부터 완벽할 수 는 없겠지만 더 나아질 수는 있을거라 믿고 이 책을 읽었다..

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

6편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 06 5편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 05 4편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 04 3편을 못 봤다면 [개발 / 필독서 ] 소프 malchafrappuccino.tistory.com 지난 글에서 V&V에 대해 다루었다. 베타 테스트가 끝난 후 내가 만든 프로그램이 출시되었다! 이번 글에서는 프로그램이 출시된 후 어떤 식으로 유지/보수 하는지를 얘기하려고 한다. 유지 / 보수 (Maintenance) 드디어 프로젝트를 끝맞췄다! 이제는 자유다! 라고 할뻔.... 인스타그램은 2010년 10월 출시되었다. 그리고 2022년 2월인 지금까지 꾸..

5편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 05 4편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 04 3편을 못 봤다면 [개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 03 2편을 못 봤다면 [개발 / 필독서 ] 소프 malchafrappuccino.tistory.com 지난 글에서 구현을 완성했다! 이제는 내가 만든 프로그램이 잘 돌아가는지 확인 및 검증을 할 것이다. 확인 및 검증 (Verification & Validation) 확인 및 검증은 줄여서 V&V 라고도 한다. 확인(Vailidation)은 제대로 된 소프트웨어를 만들었는지 확인한다. 최종결과가 잘 돌아가는지 확인한다. 검증(Verification)은 소프트웨..