전체 글 (154) 썸네일형 리스트형 평생 조금씩 공부하자 항상 가슴이 답답했다. 개발자는 평생 이렇게 공부만 하면서 살아야할까 하고. 근데, 세상에 어떤 일이든 비슷한 거 같다. 개발자든 아니든, 계속 새로운 일을 마주하게 되고 실패하기도 하고 성공하기도 한다. 실패하고 한계를 마주했다면 방법을 찾아야한다. 주로 공부가 되겠지. 이 때, 스스로 공부하기를 멈추고 쉬면 거기까지인 거 같다. 쉬는 게 나쁜 게 아니다. 쉴 때도 있는 거지. 욕심이 나서 스스로를 채찍질하고 더 나아갈 수 있으면 나아가는 거고. 채찍질 할 힘이 필요하면 잠시 쉬어가고 그런 거 같다. 나는 평생 조금씩 나아가기로 했다. 취미생활마냥 꾸준히 나아가는 거지. 느낌이 오면 몇 시간씩 몰두도 해보고, 질리면 적당히 나아가면서 꾸준히 조금씩 계속 앞으로 가는 것이 목표가 되었다. 비교나 조바심이.. 틀리는 무서움이 줄어들었다. 예전에 공통 컴포넌트나 공통 로직 만드는 게 너무 무서웠다. - 내가 잘못 만들어서 다른 부분에 악영향을 주면 어떡하지... - 만들어 둔 게 다른 부분에서 쓰여서 수정하기 어려우면 어떡하지... 요런 고민이 너무 많았는데, 지금은 달라졌다. 실수나 틀림은 당연한 것이다. 처음부터 완벽할 수는 없다. 완벽한 것은 미신이다. 실수나 틀림을 무서워하기보다는 그냥 지금 최선을 다할 생각을 하자. 같은 실수를 안 하고 최선을 다하다보면, 완벽에 가까워질 것이다. 그리고, 나중에 버그 생겼을 때 만 개를 수정할 생각하면 정말 답도 없다 생각이 든다. 공통된 거 잘 만들어서 잘 사용하는 게 중요하다. [독후감] 클린코드 Clean Code 클린 코드 - 예스24 애자일 소프트웨어의 혁명적인 패러다임을 제시하는 책이다. 저자 로버트 마틴은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제 www.yes24.com 강연 내용이 클린코드에 관한 내용이여서 읽게 되었다. 정리한 걸 올리다가 너무 공부할 게 많다보니, 멈추고 독후감을 먼저 올리게 되었다. 한줄평 : 너무나 좋지만, 오래된 책 장/단점이 너무 뚜렷한 책이라 생각한다. 참고로, 이 책은 코드가 아니라 유지보수에 관한 책이다. 코드를 잘 짜야 유지보수를 잘 할 수 있기 때문에, 코드 스타일, 코드 아키텍처, 코드간의 관계를 깔끔하게 작성하는 법을 알려준다. 좋았던 점 1. OOP와 SOLID 원칙.. [독후감] 구글 엔지니어는 이렇게 일한다 구글 엔지니어는 이렇게 일한다 - 예스24 구글은 어떻게 개발하고 코드를 관리하는가지난 50년의 세월과 이 책이 입증한 사실이 한 가지 있다. 바로 `소프트웨어 엔지니어링의 발전은 결코 정체되지 않는다`라는 것이다. 빠른 기술 변화 www.yes24.com 강연을 듣다가 "저와 같은 기업 엔지니어들의 고민을 먼저 생각하고 해결한 책들이 있어서 꼭 읽어보시길 추천한다" 하여서 읽게되었다. 한줄평 : 너무 배울 점이 많은 책. 개발자 지인/ 동료들에게 강제로 읽게 하고 싶은 책 장점이 너무 많아서, 다 적을 수가 없을 거 같다. 매우 쉽게 풀어서 적었지만, 나한테는 어려운 부분도 너무 많았다. 네이버 검색플랫폼 총괄 곽용재님이 "시중에 나온 많고 많은 자기계발/실천법 서적들을 응축하여 구글이 핸드드립한 에스.. 클린 코드 11장: 시스템 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. - 레오 오지, 마이크로소프트 최고 기술 책임자(CTO) 저자는 소프트웨어를 도시에 비유한다. 도시는 수도 관리 팀, 전력 관리 팀 등 다양한 팀으로 구성되어 있다. 이런 도시에는 큰 그림을 그리는 사람과 작은 사항에 세부적으로 집중하는 사람들도 있다. 이렇듯 도시는 적절한 추상화와 모듈화를 가지고 있으며, 큰 그림을 이해하지 못하더라도 추상화가 잘 되어 있기때문에 개인이 관리하는 "구성요소"는 효율적으로 돌아간다. 이번 장에서는 도시처럼 소프트웨어 시스템을 높은 추상화 수준으로 깨끗하게 관리하는 법을 살펴본다. ※ 저자가 처음으로 시스템이란 용어에 대해서 설명하지 않는다. 내용 및 단어 선택으로 봤을 .. 클린 코드 10장 : 클래스 이 장은 깨끗한 클래스를 작성하는 법에 대해서 다룬다. 객체지향의 특징인 S.O.L.I.D 원칙을 어떻게 적용하는 지 매우 구체적으로 코드를 통해서 설명해주신다. 이 글부터는 길고 구체적인 예시가 많이 나오므로, 정말 요약만 전달하겠다. 클래스는 작아야한다. 함수와 동일하게 클래스도 작을 수록 좋다. 다만, "작다"의 기준은 함수와 다르게 책임이 적어야한다가 기준이 된다. 단일책임원칙(SRP) 책임이 작아야하지만, 사실 원칙상 클래스의 책임은 하나여야한다. 즉, 클래스를 변경해야할 이유는 단 하나여야한다. 만약, 클래스를 변경해야할 이유가 두 가지라면 클래스를 쪼개야한다는 의미이며 큰 클래스 하나보다 책임이 하나인 작은 클래스 여러 개가 더 바람직하다 표현한다. 저자는 많은 개발자가 SRP를 알지만, 본.. 클린코드 9장 : 단위 테스트 단위 테스트에 대한 저자의 의견이다. TDD 법칙 세 가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. (단위) 테스트코드는 코드의 유연성, 유지보수성, 재사용성을 제공하는 버팀목이다. 이런 테스트코드가 없다면, 코드를 수정하고 개선하는 능력이 떨어진다. 다만, 이렇게 만든 테스트코드도 여러가지 문제를 야기한다. 프로젝트가 커짐에 따라서 테스트 코드는 점점 많아져서 저자의 경험에 따르면 (실제 코드처럼) 테스트 코드를 잘 깨끗하게 작성하지 않으면 점점 이를 사용하고 리팩터링 힘들어지게 되고 결국 폐기하게 된다한다. 그러면 테스트.. 클린 코드 8장 : 경계 때로는 우리 버그인지 라이브러리 버그인지 찾아내느라 오랜 디버깅으로 골치를 앓는다. 이런 상황은 그리 놀랍지도 않다. 이번 장은 외부코드(다른 팀, 라이브러리)와 내부 코드(우리 팀이 만든 코드)의 경계를 처리하는 방법을 서술한다. 학습 테스트 - 에러가 발생하였을 때, 외부 코드의 문제인지 내부 코드의 문제인지 어려울 때가 생긴다. 하지만, 외부코드는 익히는 것도 통합하는 것도 어렵다. - 그렇기 때문에, 외부 코드를 호출하기 전, 간단한 테스트 케이스를 작성하여 외부 코드를 테스트하는 방식이 있는데 이를 학습테스트 라 부른다. (짐 뉴커크의 테스트 주도 개발에 나온다 한다.) - 학습 테스트를 통하여, 통제된 환경에서 API를 호출하여, 제대로 이해하였는 지 확인하는 것이다. - 패키지의 새 버전이 .. 이전 1 ··· 3 4 5 6 7 8 9 ··· 20 다음