IT 5분 잡학사전 (ep.6 ~ ep.10)
😁 책에서 기억하고 싶은 내용을 써보세요. 오류를 발견했다면 해야 할 일 에러 메세지를 읽고 에러가 왜 생겼는지 예상 원인 목록 작성 나의 휴먼 에러가 있지 않았는지 체크 에러 리스트 하나씩 소거해 가면서 에러 범위 줄이기 Programming is making something!! 무언가를 만드는 개발자가 되자. 아직 준비가 되지 않아서 눈으로 하는 공부(책 읽기, 강의 듣기)를 지속한다면 점점 더 프로그래밍을 할 기회를 잃어버리게 되는 것이다. 뭐든지 만들기 시작하면 완성된 결과물이 눈에 보여서 우리의 두뇌는 나는 준비가 되어있구나!라고 생각하게 된다. 실력을 확인해야 믿음이 생기고, 실력은 무언가를 만드는 데서 나온다. 업무 자동화에는 파이썬이 찰떡! 인터프리트 언어는 실시간으로 실행과 해석이 동시..
😁 책에서 기억하고 싶은 내용을 써보세요. 새로운 프로그래밍 지식 공부할 때 과정을 이해하면 자연스럽게 내것이 된다. 그래서 암기보다 직면한 문제에 어떻게 접근해서 어떻게 해결할 것인지가 더 중요하다. 문제를 해결하다 보면 멋진 소프트웨어가 나온다. 개발은 재능의 세계가 아니라 근면, 성실의 세계다. 끈기, 근면, 성실함이 재능을 이긴다. 개발에서 중요한 건 포기하지 않는 마음! '이 함수 고칠 때까지 잠자지 않겠다'라는 각오가 필요하다. 수학 잘 못해도 괜찮다. 왜냐하면 지금 하려는 분야는 수학이 중요한 게 아니니까. 그리고 필요할 때 공부하면 되니까 괜찮다! 새 언어를 배우는 노하우 1. 공식 문서 읽기 (철학/패턴/커뮤니티 등) 2. 문법 확인 3. 다른 언어와 **비슷한 특징** 집중해서 보기 4..
나쁘게 디자인되어있는 시스템은 어디를 바꿔야 하는지, 바뀐 부분이 기존 코드에 어떻게 영향을 줄지 파악하기가 어렵다. 파악하기 어렵기 때문에 실수를 하고 버그를 만들 가능성이 높아진다. 만약 프로그램이 구조가 좋지 않다면, 먼저 프로그램을 리팩토링 해서 구조를 개선하고, 그 뒤에 변경 내역을 추가하는 게 더 쉽다. 먼저 프로그램을 기능을 추가하기 쉽게 리팩토링하고, 그다음에 기능을 추가하라 만약 프로그램이 다시는 변경하지 않을 거라면, 리팩터링을 하지 않고 내버려 둬도 괜찮다. (과연 그런 프로젝트가 얼마나 될까?) 리팩터링의 첫 스텝은 테스트 코드 작성이다. 수정하고 문제가 생기지 않았다는 걸 어떻게 체크할 것인가 수동 테스트 vs 테스트 코드 테스팅 프레임워크 사용해서 수동 체크한 레퍼런스 값과 새로..
TIL (Today I Learned) 날짜 2022.5.31 (화) 오늘 읽은 범위 9장. 실용주의 프로젝트 책에서 기억하고 싶은 내용을 써보세요. 소프트 웨어 개발 방법론의 목표 = 함께 일하는 것을 돕는 것 실용주의 팀은 작다. 구성원은 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로를 잘 알고, 진화하며, 의존해야 한다. -> 작고 안정적인 팀을 유지하라. 깨진 창문을 없애라 팀 전체가 깨진 창문을 용납해서는 안된다. 사소한 결점도 반드시 해결해서 제품의 품질에 책임을 져야 한다. 이 철학에 공감하는 개발자를 지원하고, 그렇지 못한 개발자들은 이해하도록 독려해야 한다. 환경 변화를 감시해라 범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간..
📌 연습문제 33 다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라. 1. 응답 시간은 500ms 이하여야 한다. 📖 책의 해답 : 이 문장은 진짜 요구 사항처럼 보인다. 환경 때문에 애플리케이션에 제약을 추가해야 할 수 있다. 💡 나의 해답 : 우선 응답시간이 500ms이어야 하는 이유를 물어볼 것 같다. 어떤 이유에서 그래야 하는지 파악하고, 담당팀에서 여태까지 파악한 정보, 자료를 제공받은 뒤 나 스스로도 빠르게 자료 조사를 할 것이다. 정말로 해당 이유로 제약을 지켜야 하는지, 혹시 최신에 업데이트된 부분이 있는지.. 그럼에도 불구하고 응답 시간을 지켜야 한다면, 우선 응답 시간을 많이 소요하는 작업을 리스트로 만든 다음에 다시 자료조사를 ..
TIL (Today I Learned) 날짜 2022.5.29 (일) 오늘 읽은 범위 8장. 프로젝트 전에 책에서 기억하고 싶은 내용을 써보세요. 요구 사항 완성이란 더 이상 더할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때 달성되는 것이다. 프로그래머는 의뢰인의 말을 해석해서 의뢰인이 원하는 바를 구체화해야 한다. 의뢰인이 미처 고려해보지 못한 부분을 찾아내 사실을 전달하고 의뢰인이 더 나은 결정을 내리도록 해야 한다. 신입 개발자들이 자주 하는 실수는 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다. 경험상 최초의 요청 사항과 궁극적인 요구 사항이 다른 적이 많았다. 피드백을 주고받으면서 의뢰인은 자기 생각을 더 가다듬을 수 있다. 요구 사항은 과정이다. 만든 모형이나 프로토타입을 이..
TIL (Today I Learned) 날짜 2022.5.28 (토) 오늘 읽은 범위 7장. 코딩하는 동안 책에서 기억하고 싶은 내용을 써보세요. 우연에 맡기는 프로그래밍 STOP! 우연에 맡기는 프로그래밍 특징 적극적으로 자기 코드에 대해 생각하지 않는다. 코드가 왜 그렇게 작동하는지 설명 못한다. 실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라보고 우리가 만든 프로그램과 설계에서 언제나 개선의 여지를 찾아낸다. 의식적 수련 안전 운전과 마찬가지다. 언제나 상황을 검토하고, 잠재적인 문제들을 점검하며, 예상하지 못한 일이 생길 때에도 잘 대처해야 한다. 파충류의 뇌에 귀 기울이기 경험이 늘어 갈수록 뇌에 암묵적인 지식이 쌓인다. 암묵적인 지식 = 잘 되는 방법, 잘 안 되는 방법, 오류 형태별..
TIL (Today I Learned) 날짜 2022.5.25 (수) 오늘 읽은 범위 6장. 동시성 책에서 기억하고 싶은 내용을 써보세요. 동시성 : 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것 - 소프트웨어 동작 방식 병렬성 : 실제로 동시에 실행되는 것 - 하드웨어 작업 시스템 규모가 어느 정도를 넘어가면 동시성을 고려하지 않고 작성하기란 거의 불가능하다. 사용자와 상호 작용을 하고, 데이터를 불러오고, 외부 서비스를 호출하는 일을 동시에 해야 하기 때문에 동시성은 필수다. 유연해지려면 A -> B 라는 시간적 결합에 의존하면 안 된다. 가장 큰 문제는 공유 상태(shared state)이다. 둘 이상의 코드 뭉치가 하나의 변경 가능한 데이터를 참조하고 있다면 공유 상태가 ..
TIL (Today I Learned) 날짜 2022.5.21 (토) 오늘 읽은 범위 5장. 구부러지거나 부러지거나 책에서 기억하고 싶은 내용을 써보세요. 코드 조각 간에 의존 정도가 높다 = 결합도 증가 결합도가 낮은 유연한 코드를 작성하자. 결합도가 높은 코드의 특징 이리저리 연결되어 있어서 여러 가지를 동시에 바꿔야 해서 바꾸기 더 어렵다. 바꿔야 하는 곳을 모두 찾아내느라 시간을 들인다. '딱 하나만' 바꾸고 결합된 다른 것들은 잊은 채 왜 프로그램이 죽는지 고민하느라 시간이 많이 걸린다. 소프트 웨어 구조는 유연해야 한다. 결합도 체크하기 코드를 쓰거나 이해하기 위해 알아야 하는 것이 너무 많지 않은가? 메서드나 속성들이 모두 연결되어 있지 않은가? 메서드 호출을 엮지 말라. 사실 애플리케이션에..
TIL (Today I Learned) 날짜 2022.5.18 (목) 오늘 읽은 범위 4장. 실용주의 편집증 책에서 기억하고 싶은 내용을 써보세요. 우리는 완벽한 소프트웨어를 만들 수 없다. 그렇기 때문에 실용주의 프로그래머는 실수애 대비할 수 있는 방어책을 마련해야 한다. DBC (Design By Contract) 설계 기법 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데 초점을 맞추는 설계법 계약에 부응하지 못하는 것 = 버그 선행조건 + 후행 조건 시작하기 전에 수용할 것은 엄격히 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다. DBC는 모든 입력값에 대해 성공과 실패를 정의하는 반면 테스트는 하나가 한 가지 경우만 다룬다. 코드를 작성하기 ..