파카

클래스는 작아야 한다. (단위는 책임, 얼마나 많은 부분에 영향을 주는가?) [클래스,, 추상화 잘 만들고 싶다.] 클래스부터 잘 만들기란 쉽지 않다는 것을 알고 있다 이 장을 읽으면서 느낀 점은 저자는 큰 맥락에서 순차적으로 설명해주는 느낌이었다. 그러면서 프로그래밍은 결국 유지하고 보수하면서 확장해나가면서 변화에 적응하고 발전해야 하기때문에 변경에 용이하도록 코드를 짜는 법을 익히는 느낌이었다. 책을 읽으면서 알고 싶었던 단어나 키워드 소감 - 확장성을 염두해두면서 프로그래밍하자 - 함수나 클래스나 작은 단위로 쪼개져 있을때 이해하기 쉽다. - 소프트 웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다 참고 사항 SOLID 위키백과 S SRP 단일 책임 원칙 (Single..

아직 부족함을 느낀다.. TDD를 직접적으로 실습해보진 못했지만.. 이번 장을 통해 개념 정도만 알고 현재 공부하는 JavaScript와 리액트가 어느정도 익숙해지면 테스트 코드를 작성하는 실습도 해야 할 거 같다.. TDD (Test Driven Development) 는 어렵다.. 그저 언젠가 배워야지 하고 말았던거 같다. 테스트 케이스에 따라 동작을 잘하는지 염두하면서 프로그래밍을 했었는데 평소보다 잘 읽히지 않아서 계속 또 읽어 보려고 한다. 예전에는 내가 어떤 것을 통해 TEST를 했었지 ? PC에서 테스트를 하기 위한 간단한 코드나 테스트 케이스에 집중했던 거 같다. 프론트엔드 개발자가 되면서 TDD가 필요하다, 정말 중요하다는 얘기는 많이 들었는데 나는 그저 막연하게 테스트 프레임워크를 알고..

실상은 null 확인이 너무 많아 문제다.. null을 반환하지마라라는 생각은 하지 못했었던 거 같다. null을 전달하지 마라라니 그냥 내가 해왔던 것들도 이전 장에서 말했듯이 내가 본 누군가의 코드 형식을 그대로 사용하다보니 생각없이 사용한 것도 있는 것 같다. 책을 읽으면 읽을수록 생각할 거리를 던져주고 생각하게 해줘서 좋은 시간을 보내고 있는 거 같다. 예전에 어떤 데이터 구조를 던질 때 null이 들어와서 화면에 아예 안들어가지는 경우가 있었는 데 생각해보면 경우에 따라 다르겠지만 null을 던지지 않고 책에 나온대로 data list를 초기화하고 보냈다면 조금 더 유연하게 처리할 수 있지 않았을까 고민해볼 수 있었다. (아예 안들어가지는 것보다 들어가지고 나서 일부분만 안보이는 게 더 나을수도..

이번 장을 읽으면서는 경험과 개념이 정말 중요하다고 느꼈다. 나는 예전에 기초가 부족해서 스스로 아쉬웠던 적이 있었고 그래서 지금은 공부할 때 기초에 대해 조금 더 중요성을 가지고 공부하려고 노력하고 있다. 아는 만큼 보인다고 이번 장은 처음 읽을 때는 잘 읽히지 않았다 아무튼 본론으로 다시 넘어와 여러 번 읽어봐야겠다 생각을 하면서도 집중해서 읽으려고 했다. 객체와 자료구조는 프로그래머가 잘 이해하고 사용해야 하며, 정확하고 잘 고려한 목적(설계)을 가지고 사용해야 한다. 애매하게 사용하면 결과적으로 좋지 않다는 것을 이해하고 느끼게 되었다. 추후에 유지보수가 필요해지게 될 테니까.. 책 내용 中 객체는 동작을 공개하고 자료를 숨긴다. / 자료 구조는 별다른 동작 없이 자료를 노출한다. 시스템을 구현할..

코드 자체가 최고의 구현 표준 문서가 되는 예다 본문을 보면 코드를 신문 기사처럼 작성하라고 한다. 프로그래밍에 적용하면 아래와 같다. - 이름은 간단하면서도 설명이 가능하게 짓는다. - 첫 부분은 고차원 개념과 알고리즘을 설명한다. - 아래로 내려갈수록 의도를 세세하게 묘사한다. - 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 경험적으로 완전히 아 이거구나 하진 않았지만 공감가면서도 아 이렇게 해봐야지 하고 생각하게 만들어준다. 책을 읽으면서 잠시나마 생각을 정리할 수 있는 것은 좋은거 같다. 마지막으로.. "프로그래머는 공동저자이면서 독자가 되어주는 동료들과 같이 일하는 사람이다"라고 알려주는 것 같다. 읽으면서 정말 글짓기를 하는 것처럼 잘 작성하는 습관을 통해 잘 읽히도록 만들어야 한다는 ..

사실상 주석은 기껏해야 필요악이다 주석은 기껏해야 필요악이다.. 클린 코드에 나오는 문장이다. 어렴풋이 생각했던 개념을 이번 장을 읽으면서 정리할 수 있었다. 이렇게 책을 읽으면서 좋은 인사이트를 얻을 수 있다는 것에 감사하면서 책을 읽어 나갈 수 있었다. [주석! 습관적으로 쓰지말자] 간혹 주석이 다른 이들과의 협업을 위한 배려라고 생각했던 적이 있다. 근데 나도 생각해보면 주석을 읽으면서 “이게 뭔소리야 ?” 하고 툴툴 거렸던 기억이 있다. 그에 대한 명확한 답이 책에 있었다. “코드는 변화하고 진화한다” 코드는 변화하고 진화했지만 주석은 그대로였기 때문이다. 주석에 대해 인사이트를 주어서 너무 좋은 시간이었다. 의미없는 주석은 오히려 가독성을 해치고 불편함을 초래한다. 주석을 달아놓아야하지 하면서 ..

3장 함수를 읽으면서는 여러 생각이 들었다. 일단 어렵다.. 만약 이게 필수 규칙이었다면.. 프로그래밍의 진입장벽이 더 어려웠을 것이라고 생각한다. 함수를 작게 만들어야 한다는 내용은 이해를 했고 내려가기 규칙이라고 설명한 추상화의 단계를 점차 하향하면서 작성하는 부분은 좋은 인사이트가 되었다. 결국 함수를 보기 좋고 읽기 쉽게 만든다면 의도를 파악하기는 좋을 테니깐 다만 프로그램 단위가 커질수록 함수를 잘게 쪼개는 것이 가능한가? 에 대한 의문과 고민이 남는다. 아직 나는 경험이 부족하다보니 이 부분은 공감하고 지향하면서 익혀나가야 될 거 같다는 생각이다. 소프트웨어를 짜는 행위는 어느 글짓기와 비슷하다. 인수의 개수와 관련된 부분은 공감도 되고 아직 이해가 되지 않는 부분이 있다. Flag는 추하다고..

간단하게 남기는 글 프로그래머는 작명을 하는 사람이라는 것을 새삼 깨닫는다. 기존에도 잘하고 있다고 오만할 수도 있었는데 읽으면서 내가 너무 구닥다리 코드 컨벤션을 이용하고 있지 않았는지 고민해볼 수 있었다. 어찌되었든 코드는 나를 위해서도 그렇지만 남을 위해서 고민해야 할 필요가 있다는 것을 다시 한 번 생각한다. 아직은 내가 비즈니스에서 프로그래밍 하고 있지는 않지만 다시 하게 된다면 내가 정말 남들과 일하기 좋은 그런 개발자가 되기를 희망한다. 아래와 같은 문장이 나온다. 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다. 먼저는 코드로, 그리고 좋은 서비스로 영향을 주도록 노력하자. 소감 요약 - 코드의 가독성을 위해 이름 짓기를 잘해야 한다. - 먼저는 나를 위해서..

요즘 인스타나 웹 광고에 정말 많은 광고가 보인다. OO 회사 개발자와 같이 읽는 클린코드 요런식으로.. 정말 개발자 필독서인가보다 싶다 이전에 그냥 회사에만 다니고 있었다면 나는 관심을 가지기는 했을까 싶기도 하다. 하던 공부나 열심히 해야하는데 왠 책인가 싶기도 하는데 우연히 북클럽에 참여할 수 있는 기회가 생겨서 관리만 받는다면 기존에 공부하던 것에 영향을 받지 않는 선에서 할 수 있을 거라는 기대감에 책을 사고 읽게 되었다. 1장을 읽으면서 많은 생각이 교차했다.. 네이버 웹툰 가우스전자에서 현실이 별로면 과거가 후회라고 하던데 책에 이런 문장이 있다. "나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다." 여러 생각이 교차했다. 나는 전문가였을까부터.. 어쩔..

개발자 필독서라고 불리는 책이다.. 꾸준히 읽으면서 좋은 습관을 기르길 기대하면서 구매하였다 완독해보자~~ 옆에두고서 코딩하다 답답할때마다 읽어야지.. 그럼 다 읽게 될 거라고 생각한다 ㅎㅎ