Bandong-ta Bandong-ta

TIL 요약 "사용자를 기쁘게 하라" "자신의 코드에 서명을 할 수 있어야 한다." "버전 관리, 가차 없는 테스트, 전체 자동화" "팀은 한 목소리를 내야 한다." "테스팅은 버그의 존재만 보여줄 수 있지 버그의 부재까지는 보여줄 수 없다." TIL 날짜 2022.04.05 오늘 읽은 범위 9장 - 실용주의 프로젝트 마지막 장은 저자가 하고 싶었던 말을 짧고 굵게 모두 쏟아내었다. 책의 요약본이라고 해야 할까. 팀은 무엇인지에서부터 수많은 개발론에 대해서 그리고 사용자의 부분까지 볼 수 있는 장이었다. 내가 그중에서 눈에 띄었던 건 팀에 대한 부분이었다. 저자가 인용한 부분에서 크게 공감했는데 수많은 프로그래머를 운영하는 것은 고영이 떼를 모는 것이라는 문장이 크게 와닿았다. 어떻게 보면 꽤 많은 공동..

연습 문제 33 다음 문장들이 진정한 요구사항인가? 가능하다면 진정한 요구 사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라. 응답 시간은 500ms 이하여야 한다. 모달 창의 바탕색은 회색이다. 애플리케이션은 프론트엔드 프로세스 몇개와 백엔드 서버로 구성된다. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32mb이내여야 한다. 내가 생각한 풀이 먼저 사용자가 요청하는 입장에 대해서 생각을 해보았다. 5개의 문항들을 두 가지 유형으로 나눠볼 수 있는데 먼저 사용자가 직접 사용할 때 일어나는 일(사용자가 눈으로 볼 수 있는 것)과 아닌 것이다. 2, 4, 5번은 사용자가 눈으로 보고 사용할 때의 요구 사항이..

TIL 요약 "사용자는 팀의 일원" "코드에 혼자 들어가지마라" TIL 날짜 2022.04.03 오늘 읽은 범위 8장 - 프로젝트 전에 1. 프로그래머는 사람들이 자신이 원하는 바를 깨닫게 돕는다. (만든다.) 상담 치료로서의 프로그래밍 올바른 질문으로 답(또는 타협점)을 이끌어낸다. 2. 의뢰인의 입장에서 보라. 의뢰인은 섬세하게 생각하지 않는다. 말 그대로 의뢰자인 것이다. 3. 요구사항 문서는 의뢰인의 것이 아니다. 그들은 몇 백장의 서류를 볼 필요가 없다. 4. 불가능한 퍼즐 풀기 자신의 자유도를 먼저 체크해보자 단순한 행동 (ex. 산책, 간단한 요리 등) 중에 쉽게 풀릴 수 있다. 5. 사용자와 밀접하게 일하라 사용자는 팀의 일원이다. 6. 함께 일하기 짝 프로그래밍 몹 프로그래밍 코드에 혼자..

TIL 요약 "파충류의 감각을 느끼기" "항상 스스로에게 질문을 던지고 답하라" TIL 날짜 2022.04.02 오늘 읽은 범위 7장 코딩하는 동안 (TDD까지) 어쩌면 추상적인 말을 좋아하는 나로서는 파충류의 감각에 귀 기울이라는 말이 되게 마음에 든 7장이었다. 한마디로 요약하자면 코드를 작성할 때는 그 시간에 몰입을 해야 하고 작성해야 한다고 한다. 마치 안예은의 홍연에 나오는 가사처럼 코드와 내가 붉은 실로 연결된 듯한 기분을 가져야 한다고 생각이 들었다. 1. 우연에 맡기는 프로그래머가 되지 말자. 자기 코드에 대해서 설명을 할 줄 알아야한다. 2. 정신을 기민하게 유지 운전을 잘하는 사람과 아닌 사람의 차이 시야 추상적일 수 있지만 동물적 감각에 예민해져라 파충류의 뇌에 귀 기울이기 은연중에 ..

TIL 요약 "공유 상태는 틀린 상태" "불규칙한 실패는 동시성 문제인 경우가 많다." TIL 날짜 2022.03.30 오늘 읽은 범위 6장 - 동시성 내가 지금까지 했던 코딩은 행동과 행동이 연결된 코딩들이었는데 그래서 어느 한 곳에서 에러가 난다면 멈추거나 혹은 예외처리로 다른 행동을 하거나 였다. 이번 6장에서는 어떻게 프로그래밍을 동시적으로 작성할 수 있는지, 그리고 예전부터 어떤 문제를 맞닿뜨려 왔고 해결해왔는지를 알 수 있는 장이었다. 먼저 병렬적이라는 단어와 동시성이라는 단어의 차이는 하드웨어의 입장이냐 소프트웨어의 입장이냐의 차이가 있다고 한다. 그래서 프로그래밍에서는 동시성이라는 단어를 쓴다고 한다. 먼저 기존의 코드를 동시성을 띈 소스코드로 만들기 위해서는 동시성을 찾는 과정으로부터 시..

연습 문제 23 "X 언어에는 파이프라인이 없는데요."에서 우리는 다음과 같은 코드를 썼다 const content = File.read(file_name); const lines = find_matching_lines(content, pattern); const result = truncate_lines(lines); 많은 사람이 객체 지향 코드를 짤 때 메서드 호출을 연결해서 쓴다. 그래서 어쩌면 위 코드도 다음과 같이 바꾸고 싶을지도 모른다. const result = content_of(file_name) .find_maching_lines(pattern) .truncate_lines(); 두 가지의 코드의 차이는 무엇인가? 여러분이 보기에 우리는 어느 쪽을 선호할 것 같은가? 내가 생각한 풀이 ..

TIL 요약 "톱니바퀴를 따로 돌게 만들어라." TIL 날짜 2022.03.26 오늘 읽은 범위 5장 - 구부러지거나 부러지거나 어떤 일을 진행하려고 할 때 밀접하게 작업들이 연결되어있음을 알았을 때 불편하다 라는 생각이 많이 들었다. 예를 들면 어떤 일은 5분 만에 끝나고 그다음 해야 할 일이 10분 만에 끝난다고 하였을 때 미리 다 만들어 놓고 마지막에 순서를 맞추는 것이 빠를지 아니면 차례대로 흘러가게 두는 것이 빠를지에 대한 느낌이다. 당연히 전자로 일을 하는 것이 생산성을 높이는 데에는 정답일 것이다. 소스 간의 결합도를 낮추는 것은 마찬가지로 피로감을 줄여줄 수 있는 행위일 것이다. 뒤로 이어지는 장점들도 무수히 많다.

TIL 요약 "오류 메세지를 읽어다오." "방어적 프로그래밍은 시간 낭비다. 그냥 멈추는 게 낫다!" TIL 날짜 2022.03.23 ~ 2022.03.24 오늘 읽은 범위 4장 - 실용주의 편집증 방어적으로 코딩하라 DBC 게으름뱅이 코드 일단 그놈의 오류 메시지 좀 읽어라 얼랭 -> 방어적 프로그래밍은 시간 낭비다. 그냥 멈추는 게 낫다! 슈퍼바이저가 실패시 관리해줌 슈퍼바이저가 실패할시 또 다른 슈퍼바이저가 관리한다. (슈퍼바이저 트리)