테스터로 시작하는 스타트업은 없습니다. 그리고 2년 후, 그 스타트업은 빅뱅으로 모든 것을 다시 작성하지 않는 한 최대 고객을 위한 새로운 기능을 출시할 수 없습니다. 이것을 계속해서 지켜보는 것은 고통스럽습니다. 우리 소프트웨어의 위생적인 품질을 유지하기 위해 해야 할 간단한 일이 있습니다. 그러면 이러한 상황이 발생하지 않습니다. 첫째, 두려움을 받아들이십시오. 엔지니어는 용감한 사람들이므로 우려 사항이 있음을 쉽게 인정하지 않습니다. 하지만 우리는 그러한 우려 사항을 빨리 인정하고 공유할수록 문제에 직면할 준비를 더 빨리 할 수 있습니다. 오늘날 소프트웨어를 구축하는 방법 우리는 너무 바쁘기 때문에 항상 늦습니다. 테스트할 시간이 없습니다. 단위 테스트를 할 시간이 없습니다. 리팩토링할 시간이 없습니다. 글쎄요, 우리가 엔지니어링 팀으로서 우리 자신을 계속 방해하는 동안에는 그것을 제대로 할 시간이 결코 충분하지 않을 것입니다. 시간이 얼마나 걸릴지 질문을 받고 단위 테스트, 수동 테스트, 심지어 API 테스트 및 리팩토링까지 추정에서 제외합니다. 그래서 우리는 다음과 같은 소프트웨어를 구축합니다. 빠르고 더러운 빠르지 않고 여전히 더러워요 빠르고 행복한 대각선 경로 테스트됨 다른 모든 것은 극단적인 경우로 간주됩니다. (에지 케이스 같은 것은 없습니다.) 우리 중 빠르거나 지저분한 것을 거부하고 빠르고 안정적인 소프트웨어를 구축할 만큼 용감한 사람은 거의 없습니다. 추정에서 제외해야 할 것은 품질이 아니라 범위입니다. 귀하가 작업 중인 해당 구성 요소의 품질에 대해 무엇을 알고 있습니까? 깨지기 쉽다는 것을 알지만 매우 깨지기 쉬우므로 만지고 싶지 않습니다. 오래 전에 이 작업을 해왔기 때문에 거의 건드리지 않으면 작동할 것입니다. 당신은 그것이 깨지기 쉽다는 것을 모릅니다. 테스트도 없고 실제로 얼마나 취약한지 테스트하고 노출할 사람도 없습니다. 이 더러운 소프트웨어를 매일 사용하는 것이 행복합니까? 당신의 작업 품질이 좋지 않다는 것을 알면서도 매일 작업 품질과 타협하는 것이 행복합니까? "청소할 시간이 없다"는 것에 대처하고, 더러워서 청소하지 않고는 앞으로 나아갈 수 없기 때문에 여전히 늦습니다. 당신이 다음 면접에 있다고 . 현재 직장에서 자랑할 점은 무엇입니까? 압박감 속에서도 업무를 수행하고 심야 수정 작업을 수행할 수 있습니까? 그들은 당신을 사랑할 것입니다. 그러나 그들은 또한 당신이 그것에 대해 아무것도 하지 않은 이유를 물어볼 것입니다. 어쩌면 그것은 당신의 직업이 아니었을 수도 있습니다. 상상해 보세요 이러한 결정을 내리는 데에는 팀 리더와 엔지니어링 관리자가 있었습니다. 그것이 당신에게 달려 있었다면 당신은 뭔가를했을 것입니다. 코드를 리팩토링해야 하며, 레트로할 때마다 기술 부서에 시간을 투자해야 한다고 말했지만 아무도 듣지 않았습니다. 글쎄, 추측해보세요. 허가가 필요하지 않습니다. 귀하의 작업 품질은 귀하에게 달려 있습니다. 누구도 형편없는 코드를 작성하도록 강요할 수 없습니다. 시간적 압박은 단기적인 변명일 뿐입니다. 빠르고 더러운 솔루션은 전체 프로젝트를 지연시키고 처음에 제대로 수행하는 경우보다 비용이 더 많이 듭니다. 나중에는 절대 고칠 수 없을 거예요 당신은 그 변화를 만들 의향이 있습니까? 그렇다면 해야 할 일은 다음과 같습니다. 징계를 받으십시오. 죄송하지만 다른 방법은 없습니다. 그리고 그것은 모든 수준에서 이루어져야 합니다. 더 높은 품질의 코드를 구축하기 위한 첫 번째 단계는 무엇입니까? 로깅 및 경고 구현 로깅 및 경고를 위한 수많은 도구가 있습니다. 이것이 가장 먼저 해야 할 일입니다. 귀하의 소프트웨어가 충돌하고 있으며 귀하는 전혀 알지 못합니다. 예외 알림에서 티켓을 쉽게 생성하고 "알려진" 것으로 표시하거나 보고된 후 그룹화할 수 있는 솔루션을 찾으세요. 경고를 관찰하고 보고하는 팀 루틴 구축 지루하다고 생각된다면 물어보겠습니다. 근무 시간 내내 깊숙한 곳에 빠져 있습니까? 모든 회의와 힘든 프로그래밍 작업을 마친 후에는 집중력을 조금 완화해야 합니다. 음, 알림 채널을 통해 탐색하는 것이 다른 채널을 통해 탐색하는 것보다 훨씬 낫습니다. "티켓 신고" 버튼이나 "알려진 것으로 표시" 버튼을 클릭하세요. 그리고 흥미가 생기면 아마도 한두 가지를 고칠 것입니다. 여기에 가장 큰 주장이 있습니다. 몇 가지를 고칠 수 있지만 누군가 확인해야 하고 배포해야 하는 테스트를 작성하고 있으며 이로 인해 팀에 계획되지 않은 작업이 더 많이 발생합니다. PM은 우리가 우선순위가 높은 항목을 작업하는 것이 아니라 작은 경고를 도금하는 작업을 하고 있다고 소리칠 것입니다. 모든 "M" 역할을 가진 팀은 이에 동의합니다. 경험 법칙 게시 - "작고 위험도가 낮아 보이고 진행 중인 다른 작업이 전혀 없다면 그냥 가서 수정하세요. 스프린트당 "범위를 벗어난" 수정된 작은 경고 한두 개를 처리할 수 있습니다. , 계획된 것과 함께." 아주 간단합니다. 로그 및 경고를 하나씩 정리 시작 가끔 수정하는 것 외에도 정리를 적절하게 계획하십시오. 계획이란 문제를 해결하기 위해 일일/주간 시간을 할당하는 것을 의미합니다. 처음 5개를 수정하는 것보다 우선순위를 평가하는 데 더 많은 시간을 낭비하게 됩니다. 따라서 수정을 시작하세요. 심각도나 우선순위에 관계없이 각 개발자에 대해 하나의 알림이 있는지 확인하거나, 대부분의 시간을 이동하는 경우 알림에 대한 일일 시간 슬롯을 설정하십시오. 그리고 저는 아침에 일어나서 가장 먼저 그것을 할 것입니다. 왜냐하면 그렇지 않으면 결코 그것을 하지 않을 것이기 때문입니다. 다시 말하지만, 이는 새로운 기능이 아니며 중요한 우선 순위에서 시간을 잡아먹는 것처럼 보일 수 있지만 숨겨진 문제로 인해 중요한 우선 순위가 이미 늦어졌습니다. 넌 이미 늦었어! 빈 Try-Catch 문을 모두 제거하고 충돌을 일으키도록 하세요! 경고 및 로깅은 많은 정보를 노출하지만 숨긴 내용은 기록할 수 없습니다. 그러니 당신의 문제를 카펫 아래로 쓸어 넘기는 것을 멈추십시오. 2년 전에 추락한 일이 오늘날에는 완전히 다른 이유를 알지 못했습니다. 충돌이 발생하도록 두고 문제를 해결하세요. 아마도 같은 방식으로 충돌하지도 않고 심지어 충돌하지도 않을 것이므로 어떤 식으로든 코드가 없으면 더 나은 모양이 될 것입니다. 지금 바로 단위 테스트 작성을 시작하세요 진심이야. 당신은 지금 일부 코드를 작업하고 있습니다. 그러면 단위 테스트 작성을 방해하는 것은 없습니다. 알겠어요! 단위 테스트를 위한 인프라가 준비되어 있지 않습니까? 어서 해봐요! 어쨌든 당신은 그 워너비 기능을 연기할 것입니다. 테스트를 실행하기 위해 단위 테스트 프레임워크와 CI를 설정하는 데 하루 이상이 필요하지 않습니다. 그냥 해. 버그 수정을 위해 TDD를 시작하세요 "우리는 무엇이 문제인지, 어떻게 해결해야 할지 모릅니다. 아직 존재하지 않는 코드에 대한 테스트를 작성할 수 없습니다." 사랑하는 개발자 여러분, 테스트의 목적은 가설을 확인하는 것입니다. 이는 소프트웨어 테스트뿐만 아니라 일반적인 테스트에도 유효합니다. 따라서 테스트를 작성해야 하는 것은 코드가 아닙니다. 예상되는 동작과 결과가 필요합니다. 이제 사용자 스토리가 모호하고 불분명하고 사용자 스토리에 대한 테스트 작성을 시작할 준비가 되지 않은 경우 이에 대한 해결책도 있지만 그 전에 버그에 대한 테스트 우선 코드 작성을 시작하세요. 버그 설명에는 "예상 결과"라는 구성 요소가 있으며 재현 단계는 테스트 사례입니다. 따라서 이미 테스트 케이스가 눈앞에 있습니다. 이제 수정 사항 코딩을 시작하기 전에 먼저 코딩하세요. 테스트 중심 개발은 올바른 작업을 수행했는지 확인하는 테스트를 작성하는 것이지 올바른 작업을 수행했는지 확인하는 테스트를 작성하는 것입니다. 단위 테스트는 올바르게 수행했는지 확인합니다. 적용 범위 로드맵 그리기 테스트 자동화와 기술 부채는 비슷한 비극적 운명을 가지고 있습니다. "우리는 결코 모든 것을 다룰 수 없고, 모든 것을 정리할 수 없으며, 오버헤드가 너무 많습니다. 그럴 시간이 없습니다." 때문에 결코 시작되지 않습니다. 내 말을 들어보세요. 모든 것을 자동화할 필요는 없습니다! 그러나 우선순위가 높은 사용 사례, 중요 인프라, 핵심 기능 등 미션 크리티컬 요소를 반드시 자동화해야 합니다. 원하는 대로 부르세요. 하지만 비즈니스는 코드와 인프라의 20%에 의존하고 고객은 기능의 20%를 사용합니다. 내가 어디로 가는지 알 수 있습니다. 지금 당장 이러한 기능에 대한 자동화된 테스트 작성을 시작할 필요조차 없습니다. 가장 먼저 해야 할 일은 우선순위를 정하는 것입니다. 상위 및 하위 수준 아키텍처 다이어그램 앞에서 팀으로 함께 모이세요. 그런 건 하나도 없지, 그렇지? 아니면 2년 반 전에 찍은 화이트보드 사진이 존재하는 걸까요? 알아요. 예, 반나절 정도 시간을 들여 이를 최신 상태로 유지해야 합니다. 좋은 소식은 여러분을 도와줄 재미있는 도구가 있으므로 수동으로 유지 관리할 필요가 없다는 것입니다. 조사 좀 해봐. 결국 당신은 R&D 팀이잖아요?! 전체 범위를 목표로 삼지 말고 대신 낮은 위험과 높은 신뢰도를 목표로 하십시오. 최신 아키텍처 및 인프라를 다이어그램으로 작성하는 동안 다음과 같은 모든 부분에 메모나 원을 추가하거나 굵게 표시하거나 빨간색으로 칠하십시오. 귀하의 비즈니스와 소프트웨어에 매우 중요한 역할을 합니다. 리팩토링이 절실히 필요합니다. 그렇지 않으면 다른 미션 크리티컬 기능을 항상 연기하게 됩니다. 끊임없이 부수고 먹는 데 시간을 들여 고치는 것은 며칠 후에 다시 깨질 것이기 때문에 거의 헛된 일입니다. 도면이 준비되면 팀과 함께 앉아 원으로 표시된 모든 구성 요소에 대해 테스트가 필요한 것이 무엇인지 브레인스토밍하세요. "이건 너무해! 이걸 다 커버하려면 다른 일을 다 멈춰야 해!"라는 함정에 빠지지 마세요. 이 모든 것을 한 번에 다룰 필요는 없습니다. 하지만 계획이 필요합니다. 이제 다른 보드를 열고 테스트 목표 작성을 시작하세요. 예: 성공 및 실패에 대한 모든 데이터 가져오기 API 요청을 처리하여 잘못된 요청을 보내지 않으며, 실패하면 공급업체 때문에 실패한다는 것을 알 수 있습니다. 미션 크리티컬 사용자 여정을 간략하게 설명합니다. 단위로 나누어 보세요. 단위 테스트를 작성합니다. 테스트 피라미드가 발명되었을 때 단위는 메서드가 아닌 구성 요소를 의미했기 때문에 메서드나 클래스가 아닌 기능을 다루었습니다. 교통 정체를 식별하고 이를 어떻게 해결할 것인지 결정하십시오. 올바르게 할 계획을 세우십시오. 빠르고 더러운 코드는 더티 테스트로 인해 더러워진 상태로 유지됩니다. 나는 의도적으로 테스트 피라미드가 아닌 커버리지 맵을 사용했습니다. 왜냐하면... 이 단계에서 수동 또는 자동 테스트가 없으면 피라미드를 사용할 준비가 되어 있지 않기 때문입니다. 많은 팀이 먼저 96% 단위 테스트 적용 범위를 달성한 다음 통합 테스트 등으로 이동해야 한다는 잘못된 인상을 가지고 있습니다. 최신 단위 테스트 범위의 문제점은 기능이 아닌 메서드와 클래스를 테스트한다는 것입니다. 더 많은 팀이 UI 자동화로 시작하는데, 이는 똑같이 잘못된 것입니다. 그것은 실제로 당신이 할 수 있는 최악의 일이고, 실패할 운명입니다. 그러므로 피라미드의 꼭대기나 밑바닥에서 시작하지 말고 대신 위험 지도를 구축하십시오. 일부 기능에는 광범위한 통합 테스트가 필요할 수 있고, 다른 기능에는 광범위한 UI 테스트가 필요할 수 있으며, 다음 부분은 실제로 모든 것이 의존하는 핵심 기능일 수 있으며(또 다른 위험 신호) 위에서 아래까지 완전히 다루어야 합니다. 또는 데이터 수집 서비스인 경우 예를 들어 API 성능에 집중해야 합니다. 강력한 테스트가 필요한 소프트웨어 핫스팟의 지도를 구축하세요. 그런 다음 해당 테스트를 자동화할 수 있는 방법에 대해 생각해 보세요. 유사에서는 발전할 수 없으며 오직 당신만이 그곳에서 빠져나갈 수 있습니다 마무리합시다. 인생의 절반을 테스트도 없이 한 곳에서 보내다 보면, 코드도 엉망이고, 시간도 없고, “시간이 없다”고 계속 타협을 하게 됩니다. 당신은 완전히 행복하지 않거나 적어도 꽤 무관심합니다. 그들은 돈을 지불하고 그것은 그들의 요구이며 그것은 당신의 결정이 아닙니다. 정말 슬프네요. 나는 당신이 당신의 직업을 자랑스러워하지 않을 것이라고 확신합니다. 그리고 당신이 일과 목적을 좋아할 만한 곳에서 다음 유니콘이 당신을 채용할 때까지 기다릴 수도 있습니다. 글쎄요, 작년에는 상황이 많이 바뀌었죠, 그렇죠?! 우리는 유니콘이 존재하지 않는다는 사실을 다시 한번 배웠습니다. 계속 고용되려면 뛰어난 개발자가 되어야 합니다. 기업은 기여도에 관계없이 사람을 버릴 수 있다는 것을 알아냈습니다. 그럼에도 불구하고 회사가 유지하기 위해 모든 노력을 다할 엔지니어가 있습니다. 그들 중 하나가 되려면 변화를 주도하고 비즈니스가 당신과 같은 사람들에게 달려 있다는 것을 끊임없이 증명해야 합니다. 형편없는 소프트웨어는 누구나 작성할 수 있지만 정말 좋은 사람들은 훌륭한 소프트웨어를 즐겁게 작성할 뿐만 아니라 다른 사람들에게 영감을 주고 코드 품질 문화를 확산시킵니다. 당신은 유사(流沙) 속에서는 발전할 수 없고 오직 당신만이 스스로 빠져나올 수 있습니다.

이 오디오는 이야기의 원래 언어로 제작되었습니다!

나중에 고칠 수는 없습니다 - 팀을 유사에서 끌어내는 방법

너무 오래; 읽다

@hriskoleva

관련 기사