도서 (22) 썸네일형 리스트형 실용주의 프로그래머 #20일차(마지막 미션!) 실용주의 프로그래머 북클럽을 마무리하며 책에서 소개하는 총 97가지 tip 들 중 10가지를 선정해 보았습니다 ! 1. 자신의 기예(craft)에 관심을 가져라. 2. 어설픈 변명 말고 대안을 제시하라. 3. 깨진 창문을 내버려 두지 말라. 4. 결합도가 낮은 코드가 바꾸기 쉽다. 5. 우연에 맡기는 프로그래밍을 하지 말라. 6. 일찍 리팩터링하고, 자주 리팩터링하라. 7. 테스트할 수 있도록 설계하라. 8. 이름을 잘 지어라. 필요하면 이름을 바꿔라. 9. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. 10. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라. 😀 후기 ! 책 읽는 내내 전담 길잡이 선생님이 한땀한땀 어떻게 해야할지 방향을 제시해주는 책이었습니다 ~! 이렇게 좋은 책들을 여러.. 실용주의 프로그래머 #19일차 🧑🏻💻 오늘 TIL 3줄 요약 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. 프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용한다. “소프트웨어 개 발자”나 “소프트웨어 엔지니어” 비슷한 이름일지 몰라도 진정한 여러분의 직 함은 “문제 해결사”다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. TIL (Today I Learned) 2022. 4. 5. 📕 오늘 읽은 범위 9장. 실용주의 프로젝트 🙂 책에서 기억하고 싶은 내용 Topic 49. 실용주의 팀 _p.378 Tip 84. 작고 안정적인 팀을 유지하라. 팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치 지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. 모든 .. 실용주의 프로그래머 #18일차(Mission) Mission(3) 연습문제 33. 다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라. 1. 응답 시간은 500ms 이하여야 한다. -> 요구 사항으로 볼 수 있을 것이다. 응답 시간을 구체적으로 500ms로 제한 하였다. 500ms 으로 정확히 명시한 이유에는 어떤 것들이있을까? 500ms 가 단순히 사용자 편의성 차원에서 제한한 것 인지, 500ms를 초과할 시 시스템 상에서 예외를 콜하는 등 문제를 야기하는지, 아니면 외부 환경에서 어떤 절차나 법적으로 문제 사항이 발생하는 지, 더 느슨해지는건 괜찮을지라도 더 촉박해지면 시스템 전체를 수정해야할 수 있으므로 500ms이란 수치를 변경하기도 어려울 것이다. 다만, 조금 더 구체적인 이유를 물.. 실용주의 프로그래머 #17일차 🧑🏻💻 오늘 TIL 3줄 요약 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. 요구사항 문서는 의뢰인을 위한 것이 아니다. 코드에 혼자 들어가지 말라. TIL (Today I Learned) 2022. 4. 3. 📕 오늘 읽은 범위 8장. 프로젝트 전에 🙂 책에서 기억하고 싶은 내용 애자일 선언 Agile Manifesto은 “공정 process과 도구보다 개인과 상호 작용”으로 시작한다. 하지만 역설적이게도 거의 모든 “애자일” 프로젝트가 어떤 공정과 도구를 사용할지에 대한 논의로 시작한다. 하지만 아무리 세심하게 계획하거나, 최고의 “모범 사례”를 따라 하더라도, 생각하기를 대신할 수는 없다. 여 러분에게 필요한 것은 특정한 공정이나 도구가 아니다. _p.349 Topic45. 요구 사항.. 실용주의 프로그래머 #15일차 이번 장은 내용이 참 많다 ... 하지만, 어디 하나 빼놓을 부분이 없다 .ㅜ 공부하자 .. 공부하자 .. 🧑🏻💻 오늘 TIL 3줄 요약 우리는 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 '의도적으로 프로그래밍'해야 한다. 소프트웨어 개발은 건축보다 정원 가꾸기에 더 가깝다. 딱딱하기보다는 유기적인 활동이다. 정원의 건강 상태를 지속적으로 관찰하며, 필요하면 토양, 식물, 정원 배치를 조정한다. 일정의 압박은 리팩터링을 하지 않는 단골 핑계다. 하지만 이는 설득력이 떨어진다. 지금 리팩터링을 하지 않으면 일이 더 진척되었을 때, 즉 신경 써야 할 의존성이 더 많아졌을 때 문제를 고쳐야 하고, 따라서 훨씬 더 많은 시간을 투자해야 한다. TIL (Today I Learned) 2.. 실용주의 프로그래머 #12일차 🧑🏻💻 오늘 TIL 3줄 요약 순서에 의존하는 시간적 결합을 끊어낸다면, 코드의 유연성 과 생산성을 상승시킬 수 있다. 여러 비동기 작업들이 리소스를 공유할 상황을 만들지 말고, 액터를 이용해 동시성을 구현하자. 아키텍처에서 액터와 칠판, 마이크로서비스를 활용하면 거의 모든 종류의 동시성 문제를 예방 할 수 있지만, 배포하고 관리하기 까다롭다 는 점 그러나 시스템을 더 잘게 쪼개서 ETC 측면의 이득을 볼 수 있다는 득과 실이 존재한다. TIL (Today I Learned) 2022. 3. 29. 📕 오늘 읽은 범위 6장. 동시성 🙂 책에서 기억하고 싶은 내용 ‘동시성(병행성) concurrency’은 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것이다. 그리고 ‘병렬성 par.. 실용주의 프로그래머 #9일차 요몇일 컨디션이 좋지못해 포스팅이 좀 지체되었다.. ㅠㅠ 🧑🏻💻 오늘 TIL 3줄 요약 유연함을 유지하는 한 가지 좋은 방법은 물론 가능한 한 코드를 적게 작성하는 것이다. 코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관의 일부가 되어야 한다. 어렵다. 이 챕터는 최소 3회이상 반복해서 정독 해야겠다. TIL (Today I Learned) 2022. 3. 28. 📕 오늘 읽은 범위 5장. 구부러지거나 부러지거나 🙂 책에서 기억하고 싶은 내용 유연함을 유지하는 한 가지 좋은 방법은 물론 가능한 한 코드를 적게 작성하는 것이다. _p.182 Topic28. 결합도 줄이기 Tip44. 결합도가 낮은 코드가 바꾸기 쉽다. _p.184 Tip45. 묻지 말고 말하라 Tell, Don't Ask, TD.. 클린 코드 #19일차 TIL (Today I Learned) 2022.03.08 📕 오늘 읽은 범위 10장. 클래스 🙂 책에서 기억하고 싶은 내용 '클래스는 작아야 한다!' (p.172) '단일 책임 원칙(Single Responsibility Principle, SRP)은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.' (p.175) '문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. ‘깨끗하고 체계적인 소프트웨어’라는 다음 관심사로 전환하지 않는다. 프로그램 으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.' (p.176) '큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프.. 이전 1 2 3 다음
