파카

”사용하는 도구로 다룰 수 없는 문제를 마주쳤다는 생각이 들면, 도움이 될 만한 뭔가 다른 것이나 더 강력한 것을 찾아보아야 한다는 것을 명심하라. 필요에 따라 도구를 취하도록 하라.” 어느 순간부터 잊고 있던 거 같다. 익숙해지는데에만 급급하고 막상 익숙해지면 변화를 싫어하게 되는 것.. 책에 다음과 같은 말이 나온다. 언제나 일을 하는 데에 더 나은 방법이 없는지 살펴라 갈고 닦아 보자.. ㅎㅎ 이번 장은 전체적으로 공감이 되면서도 지난 날의 나를 돌아볼 수 있는 시간이었다. 특히나 디버깅을 하는 부분은 공감도 하고 예전에 재미를 느꼈던 추억이 떠올랐고 이진분할 부분의 내용을 보면서 이렇게 생각할 수 있고 적용할 수도 있구나 했다. (알고리즘을 실생활에 적용해보는 ? 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 시간이 해결해 준다는 말이 있긴 하지만 실제로 일을 변화시켜야 하는 것은 바로 당신이다. 라는 뜻이다. 예전부터 회피하지 말고 열심히 하자는 생각을 가지기 위해서 기억하던 글이다. 실용주의 프로그래머가 되기 위해 가장 중요한 것은 나는 문제를 해결하는 사람, 해결책을 찾아내야 하는 사람이라는 것이다. 내가 주체가 되어야 한다. 적극적이어야 하고 계속해서 고민하고 발전해야 한다. 책에 보니 이런 문장이 있었다. “자신의 기술이 낡아 빠지는 것을 그저 관망하다가 회사가 교육을 시켜 주지 않..

JavaScript를 잘 알고 사용하고 싶어서 스터디에 참여하게 되었다. 막상 JS가 기초이고 중요하다고 하는데 JS 실력이 부족하다고 느껴서 신청을 했는데 검증도 되고 배움이 큰 거 같아서 신청하길 잘했던 거 같다. 전체적인 과제의 목적은 JS를 이용해서 자연스럽게 현재 기술이 나오게 된 역사적인(?) 이유를 아는데에 목적이 있는거 같다. 시작은 JS를 이용해서 Component 형식으로 만드는 연습이었다. 막상 주어진 과제들을 하려고 보니 어색하다고 해야할까.. 처음에 멍하다가 다른 분들의 PR을 보면서 정신차리고 할 수 있게 되었다. 변수명부터 함수이름까지 나름대로 통일하면서 작성하려고 노력했고 막히는 부분에 대해 공부하면서 이전보다 더 잘 이해가 되었다. tip programmer 과제의 해설에서..

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

책을 2권 정도 샀다. 하나는 "리액트를 다루는 기술"이라는 책이고 다른 하나는 "실용주의 프로그래머"이다. 리액트 책은 리액트 개발자 벨로퍼트라는 이름으로 유명한 김민준 님이 쓰신 책이다. 리액트를 공부하는데 알아야 하는 기초를 놓치는 느낌이 있어 인터넷 검색도 좋지만 기본기를 채우고 싶어서 사전처럼 사용하기 위해서 추천을 많이 받은 책을 구매했다 그리고 다른 하나인 실용주의 프로그래머는 책 읽는 모임에 참여하기 위해서 실용주으 프로그래머를 구매하였다. 이것 또한 요즘 광고로 많이 보이는 클린코드와 같이 개발자 필독서로 추천받는 책 중 하나로 보인다. 클린코드도 노마드코더의 북클럽을 통해 읽게 되었는데 다른 사람들의 느낀 점과 TIL을 통해 인사이트를 얻을 수 있었고 특히나 하나의 모임에서 서로의 작성..

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

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

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