파카

”사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 뭔가 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라. 필요에 따라 도구를 취하도록 하라.” 어느 순간부터 잊고 있던 거 같다. 익숙해지는데에만 급급하고 막상 익숙해지면 변화를 싫어하게 되는 것.. 책에 다음과 같은 말이 나온다. 언제나 일을 하는 데에 더 나은 방법이 없는지 살펴라 갈고 닦아 보자.. ㅎㅎ 이번 장은 전체적으로 공감이 되면서도 지난 날의 나를 돌아볼 수 있는 시간이었다. 특히나 디버깅을 하는 부분은 공감도 하고 예전에 재미를 느꼈던 추억이 떠올랐고 이진분할 부분의 내용을 보면서 이렇게 생각할 수 있고 적용할 수도 있구나 했다. (알고리즘을 실생활에 적용해보는 ? O(logN) ㅎㅎ) 그리고 찔림..

사람들은 대부분 유지 보수란 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 애플리케이션이 출시되었을 때 비로소 유지 보수가 시작된다고 믿는다. 우리는 이들이 틀렸다고 생각한다. 프로그래머는 늘 유지 보수 모드에 있다 책을 읽다보니 정말 기본에 충실한 것이 가장 베스트라는 생각을 가지게 된다. - ETC는 규칙이 아니라 가치 (Easier to Change) - 지식은 고정적이지 않다. 지식은 변화한다. 때로는 급격하게 변화한다. - DRY: 반복하지 말라 (Don`t Repeat Yourself) : DRY는 코드에만 해당 되는 것이 아니다! 이번 장은 분량이 매우 많았다.. 공감이 되는 부분도 있었고 이해가 잘되지 않는 부분이 있었다. 내용 자체가 많고 어렵다고 느꼈기 때문에 계속해서 검색해나가..

이번 장을 요약하려니 내가 좋아하는 명언이 떠올랐다. They say that time changes things, but you actually have to change them yourself. Andy Warhol 시간이 해결해 준다는 말이 있긴 하지만 실제로 일을 변화시켜야 하는 것은 바로 당신이다. 라는 뜻이다. 예전부터 회피하지 말고 열심히 하자는 생각을 가지기 위해서 기억하던 글이다. 실용주의 프로그래머가 되기 위해 가장 중요한 것은 나는 문제를 해결하는 사람, 해결책을 찾아내야 하는 사람이라는 것이다. 내가 주체가 되어야 한다. 적극적이어야 하고 계속해서 고민하고 발전해야 한다. 책에 보니 이런 문장이 있었다. “자신의 기술이 낡아 빠지는 것을 그저 관망하다가 회사가 교육을 시켜 주지 않..

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

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

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

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

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

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

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