Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugs Optional? by. Kent Beck #45

Open
SuyeonChoi opened this issue Jan 19, 2025 · 0 comments
Open

Bugs Optional? by. Kent Beck #45

SuyeonChoi opened this issue Jan 19, 2025 · 0 comments

Comments

@SuyeonChoi
Copy link
Owner

출처: https://tidyfirst.substack.com/p/bugs-optional

결국 버그 퇴치의 핵심은 아래와 같을 듯

Continuous planning, so there’s enough time for implementation, for defect remediation, & for reflection.

  • 지속적인 계획 수립: 구현, 결함 수정, 회고를 위한 충분한 시간을 확보하기 위해 필요합니다.

Continuous design, so you can prevent recurrences & mistake “proof” code.

  • 지속적인 설계: 재발을 방지하고 결함 없는(mistake-proof) 코드를 작성할 수 있도록 도와줍니다.

Continuous integration, so you step on each other’s toes less frequently.

  • 지속적인 통합: 팀원 간의 작업 충돌을 줄이는 데 도움이 됩니다.

Continuous deployment, so defects that do get to production are more quickly identified & isolated.

  • 지속적인 배포: 프로덕션 환경에 발생한 결함을 더 빠르게 식별하고 격리할 수 있도록 합니다.

Continuous collaboration (pairing, ensemble), so a) bugs are more likely to be caught immediately & b) understanding of bugs (& safety) quickly percolates through the whole team.

  • 지속적인 협업(페어링, 팀 작업):
    • 버그를 즉시 발견할 가능성이 높아지고,
    • 버그와 안정성에 대한 이해가 팀 전체에 빠르게 전파됩니다.

Continuous testing, so you have an immediate double check on implementation decisions.

  • 지속적인 테스트: 구현 결정에 대해 즉각적으로 이중 확인(double check)을 할 수 있게 합니다.

Customer on the team, so you can just ask instead of feeling pressure to move forward on shaky assumptions. Also, everyone on the team can see the actual face of the person affected by bugs.

  • 고객의 팀 참여: 불확실한 가정에 의존하며 압박감을 느끼는 대신, 직접 물어볼 수 있습니다. 또한, 팀원 모두가 결함으로 인해 영향을 받는 실제 고객의 얼굴을 볼 수 있게 됩니다.
Image

+ 추가로 사람들이 버그 퇴치를 싫어하는 이유

First, this is just what it’s like trying to communicate from The Forest to The Desert. Assumptions in one realm seem absurd in the other.

  • 먼저, 이것은 “숲(The Forest)“에서 “사막(The Desert)“으로 소통하려는 시도와 비슷합니다. 한쪽 세계에서의 가정은 다른 쪽에서는 터무니없게 보입니다.

Second, it’s clear that folks in The Desert are attached to the notion of production defects as just part of development. That feels like a coping mechanism to me—folks feel bad about production bugs so they soothe themselves by assuming they are inevitable.

  • 둘째, “사막”에 있는 사람들은 프로덕션 결함(production defects)을 개발 과정의 일부로 받아들이는 사고방식에 집착하는 것처럼 보입니다. 이는 마치 문제를 받아들이는 방식(coping mechanism)처럼 느껴집니다. 사람들이 프로덕션 버그에 대해 죄책감을 느끼면서도, 이를 피할 수 없는 일이라고 스스로를 위로하고 있는 것입니다.

Last, getting from a Desert perspective on production defects to a Forest perspective is going to be mighty hard work. You’re changing the plane’s engine in the air. But no bugs is not rocket surgery. And it carries benefits for everyone involved.

  • 마지막으로, 프로덕션 결함에 대한 “사막”의 관점을 “숲”의 관점으로 바꾸는 것은 매우 어려운 일입니다. 이는 비행 중인 비행기의 엔진을 교체하는 것과 같습니다. 그러나 “버그 없는 상태(no bugs)“를 만드는 것은 로켓 과학처럼 복잡한 일이 아닙니다. 그리고 이는 관련된 모든 사람들에게 이점을 제공합니다.

핑계대지말고 열심히 버그 나면 의식적으로 고쳐야한다

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant