더 나은 버그 해결사되기

나는 프로그래머가되는 것을 좋아한다. 나는 말했다. 그러나 그 말로, 나는 최근에 실제로 버그 수정을 참을 수 없다는 것을 깨달았습니다 . 조금도.

실제로 무언가를 개발하는 동안 생산성이 매우 높습니다. 단위 테스트를 작성하고 내 개발에 대한 자체 테스트를 수행 할 때도 일반적으로 생산성이 높습니다. 집중할 수 있고 과제를 완수 할 수 있습니다.

그러나 QA 시간이 다가오고 버그를 수정하려고 할 때 영감을 얻으려면 엄청난 노력이 필요합니다. 나는 무언가를 끝내기 위해 매우 극단적 인 조치 (당신이 알고있는 BPM 음악, 과도한 양의 카페인 등)를 강요해야 합니다. 내 직업은 일반적으로 기존의 대규모 프로젝트를 시작하고 새로운 기능을 추가하거나 버그를 수정하는 것과 관련이 있으므로 모든 코드에 대해 단위 테스트를 작성하는 데 몇 주가 필요하다고 정확하게 고용주에게 알릴 수 없습니다. 우리가 자주 사용하는 서버 기술은 꽤 많은 Java 클래스 로더 문제가 있기 때문에 단위 및 통합 테스트 모두에 매우 금지되어 있습니다. 나는 버그 수정에 완전히 반대하지 않으며 때로는 재미있을 수도 있지만 전혀 재미 가 없습니다. 사소한 변경이 필요한 경우 (시스템 작동 방식으로 인해) 30 초에서 3 분 동안 기다렸다가 작동하는지 확인할 수 있습니다.

버그 수정시 생산성과 동기를 어떻게 향상시킬 수 있습니까? 이것은 대부분의 프로그래머가 다루는 것입니까?

사소한 변경을하고 30 초에서 3 분 동안 기다려야 작동하는지 확인할 수 있습니다.

이것이 실제 문제입니다. 피드백을 너무 오래 기다려야한다면 비생산적인 느낌이들 것입니다. 아마도 더 많은 서비스를 위조하고 더 나은 테스트 도구를 만들어 즉각적인 피드백을 얻을 수 있습니다.

레거시 코드 단위 테스트는 비용이 많이 들거나 위험한 리팩토링과 관련 될 수 있습니다. 그러나 더 나은 테스트 픽스처를 작성하면 몇 분에 비해 몇 초 만에 손으로 테스트 할 수 있으며 새로운 단위 테스트 가능 코드를 사용하는 것과 거의 동일한 생산성을 얻을 수 있습니다.

버그 자체를 수정하는 행위가 아니라 피드백을 기다리는 시간이 지루하고 도전적입니다.

버그 수정은 반드시 알아야하는 매우 중요한 기술입니다. 나는 어딘가에서 읽습니다. 일반적으로 응용 프로그램에서 문제의 20 %를 해결하는 데 80 %의 시간을 소비합니다.

나는 실수로부터 배우는 것을 믿으며, 버그 수정은 다른 실수로부터 배우는 기회 입니다. 당신은 그것을 배우고 미래에 더 나은 프로그래머가 될 수 있도록 도울 것입니다. 이것은 많은 버그를 수정 하고 코드를 리팩토링 하기 시작했을 때의 동기 입니다.

개인적으로, 버그를 '작은 것'으로 생각하지 말고 몇 시간의 디버깅 후에 몇 줄의 코드를 변경하는 것만으로도 거대한 기능만큼 중요한 큰 쇼 토퍼처럼 생각하는 것이 도움이되었습니다. 그렇게하면 하루 종일 버그 추적기 항목 3 개를 죽이는 것이 덜 우울합니다.

동료와 함께 게임을 만드는 데 도움이 될 수 있습니다 ( 하루에 가장 많은 버그를 수정하는 사람은 누구입니까? 아니면 하루에 가장 적은 수의 재건을 한 사람은 누구입니까? )

나는 당신의 신발에 있었다. 언제 어디서나 자동화 된 테스트를 구축하십시오. 한 번에 다있을 필요는 없습니다. 버그를 발견하면 잠시 시간을내어 테스트 사례를 프로그래밍하십시오. 테스트 사례를 프로그래밍 할 수없는 경우 수동 테스트 방법 (예 : 여기를 클릭, 입력 등)에 대한 빠른 설명을 작성하여 기술 자료에 저장하십시오.

디버깅은 매우 까다로울 수 있습니다. 특히 작성하지 않은 복잡한 코드의 경우 더욱 그렇습니다. 목표는 "금요일에 버그 13533 수정"입니다. 그런 다음 목표를 달성하면 "금요일 밤 친구와 파인트를 줘"보상을 설정하십시오. 이것은 좀 더 보람있는 데 도움이 될 것입니다.

그 외에는 때로는 일이 그저 일입니다.

이런 상황에서는 창의적인 도전이 필요합니다. 일반적으로 코드를 작성하고 있지만 여기에는 없습니다.

그러나 모든 것이 손실되지는 않습니다. 메타 문제 해결을 위해 노력하고 그것에 에너지를 쏟아 부으십시오. 피드백을받는 데 30 초에서 3 분이 걸리는 이유 는 무엇 입니까? 어떻게 당신은 시간을 단축 할 수 있습니까? (아마도 체크인하지 않은 스크립트 또는 유틸리티 앱을 작성하면 도움이 될 수 있습니다). 이것이 새로운 문제 영역, 새로운 창의적 도전입니다.

개인적으로 결함을 고치기위한 단계에있을 때마다 신속하고 고통없이 처리 할 수있는 가장 큰 장벽을 찾아 내고 그 장벽을 제거하기 위해 자동화해야하는 작업을 자동화합니다. 이로 인해 생산성이 향상되고 개인 포트폴리오를 추가하여 부팅 할 수 있습니다.

요컨대 나는 "항상 개발 중"이라고 말하고 싶습니다. :)

문제가 디버깅 또는 버그 수정입니까? 문제를 일으키는 구성 요소를 격리하기에 충분히 디버깅 할 수 있으면 새로운 개발 작업으로 살펴보십시오.

1. 깨지기 쉬운 코드 조각에 대한 단위 테스트를 작성하십시오. 원하는 모든 기능과 특히 버그가있는 동작을 분리하는 기능을 검증하는 테스트가 있는지 확인하십시오.
2. 방금 작성한 모든 테스트를 통과하는 새 코드를 작성하십시오.
3. 이전 코드를 새 코드로 바꿉니다.
4. 일부 통합 테스트를 실행하십시오. 여기서 3 분 동안 서버를 다시 부팅 할 수 있지만 1 ~ 3 단계를 제대로 수행하면 최소화해야합니다.
5. 짜잔!

아마도 1995 년 미국 과학자에 실린 기사 인 Brian Hayes의 Debugging Myself를 보아야 할 것입니다. 요다 조건을 습관적으로 사용하는 것과 같은 단계를 밟아서 당신이 생산하는 가장 혐오스러운 종류의 벌레를 줄이거 나 없앨 수 있습니다.

디버깅은 프로그래밍과는 다른 기술이지만 관련이 있다고 생각합니다. 특히 멀티 스레드 프로그램을 디버깅하는 것은 작성하는 것과 거의 완전히 다릅니다.

소프트웨어 개발이 지루하다면 잘못하고있는 것입니다. 다시 말해, 그것은 당신에게는 문제가 아니라, 당신의 플랫폼과 프로세스에 관한 문제입니다. 서버가 다시 시작할 때까지 기다릴 필요가없는 동적 언어 (예 : Python, Ruby, JavaScript)를 사용하여 위치를 찾는 것을 고려 했습니까?

불행히도 그것은 일의 일부입니다. 당신은 엉터리 프로젝트와 엉뚱한 고용주를 가질 것입니다 (저는 여기서 일반화되는 것이 아니라고 말하고 있지 않습니다).

코드에 대해 단위 테스트를 작성할 수 있습니다 . 할 수있는대로 몰래 들어와 상사에게 보여줄 수있는 것이 있으면 조수를 돌릴 수 있습니다.

디버깅 도구를 사용하여 속도 저하를 해결하고 단위 테스트를 사용하여 새 코드를 테스트하고 기존 코드 문제를 해결하고 기존 코드를 더 작은 조각으로 나누는 데 사용하십시오.

당신은 그것을 도전으로 만들고 프로세스 개선 영웅이 될 수 있습니다. 그리고 그것이 효과가 없다면, 다음 고용주에게 가져갈 좋은 경험이있을 것입니다.

대부분의 프로그래머는 경력의 어느 시점에서 버그 수정 개인 문제를 처리해야합니다.

일과 거리의 올바른 감각은 동기 부여에 필수적입니다. 당신의 일을 과대 평가하거나 과소 평가하지 마십시오. 자신의 작업에 대해 지나치게 자신을 식별하는 경우 설명한 것과 같은 문제가 발생할 수 있습니다. 절반의 시간이 자신을 비난하기 때문에 버그를 수정하는 것을 꺼려 할 수 있습니다. 약간의 거리를두고 합리적으로 문제를 해결하는 방법을 찾으십시오.

플랫폼의 특정 문제와 관련하여 긴 배포 및 테스트 시간을 줄일 수있는 몇 가지 방법이 있습니다 (측면에서 특히 길지 않음).

첫째, 테스트 시간이 길수록화물 컬트에 대한 혐오감이 높아집니다. 변경하는 경우 버그가 해결 될 것이라고 확신 할 때까지 생각하십시오 . 물론 테스트주기의 길이에 얼마나 자신감이 있는지. 테스트주기가 길어, 긴 테스트를 피할 수없는 경우가 빠르다 기 때문에, 디버깅에 더 많은 시간 생각을 보내고, 당신은 보상을받을 수 있습니다 더 많은 행복 과 "피아트 룩스의 좋은 순간의 보람 효과가 ".

둘째, 단위 테스트에 대한 편향과 통합 테스트에 대한 편향이 적습니다. 디버그하기 어려운 플랫폼에서 모든 실패 지점을 제거하십시오.

버그 수정은 "멋진"또는 "지루한"일 수 있습니다. 나는 하나의 단일 버그-다른 사람이 고칠 수없는 충돌 버그를 수정했기 때문에 게임 크레딧이 있습니다. 그러나 bugzilla의 일상적인 정리는 마음을 사로 잡습니다. 사소한 버그는 지루합니다. 주요 버그는 가치가 있습니다.

실현은 다음과 같습니다. 사소한 버그의 거대한 목록이 있다는 사실 자체가 하나의 주요 버그입니다. 코드 버그가 아닙니다. 프로세스 또는 관리 버그입니다.

그 버그를 찾아 수정하십시오.

좋은 "디버거 / 버그 해결사 / 문제 해결사"인 동료와 지인들 사이에서 발견 한 한 가지는 일반적으로 퍼즐을 풀고 싶어한다는 것입니다. 크로스 워드 퍼즐, 숫자 게임 (예 : 스도쿠) 및 논리 퍼즐 등을 의미 할 수 있습니다.

따라서 더 나은 버그 수정자가 될 수있는 한 가지 방법은 문제 해결 또는 퍼즐 해결 기술에 시간을 투자하는 것입니다.

다음은 더 나은 문제 해결자가 될 수있는 좋은 출발점이 될 수 있는 Wikipedia 링크 입니다.

일부 사람들은 문제 해결에 더 능숙하거나 더 좋아합니다. 어떤 사람들은 그것을 전혀 좋아하지 않아서 스스로를 강요하기는 어렵지만 실수하지는 않습니다. 퍼즐 해결사로 배우도록 강요하면 미래에 좋은 버그 해결자가되는 것이 더 쉬워 질 것입니다 .

버그 수정은 버그가 당신의 모든 시간을 차지하고 새로운 재미있는 것들로부터 멀어지게하는 것처럼 느끼게 할 수 있기 때문에 일반적으로 집안일처럼 느껴집니다. 그러나 실제로 버그 수정은 우리가하는 일의 많은 부분이며, 코드의 첫 줄을 작성하고 컴파일러를 실행하는 것부터 시작합니다. 처음으로 코드를 릴리스 할 때는 이미 버그를 수정하는 데 몇 시간을 보냈을 것입니다. 기능 구현 프로세스의 일부로 버그를 수정했기 때문에 그렇게 보이지 않는 것 같습니다. 사실, 프로그래머가 아무리 훌륭하더라도 버그가 시스템에 들어갑니다.

어떻게 재밌게합니까? 글쎄, 나는 그것이 당신의 개별 보트를 떠 다니는 것이 실제로 무엇인지 상상할 수 없기 때문에 당신에게 정말로 대답 할 수 없습니다. 나에게는 약간의 도구 중독자가 있으므로 대답은 매우 안정적인 도구 체인과 유연한 개발 프로세스를 통해 버그 수정을 덜 번거롭게하고 더 간단한 문제를 해결하는 데 기여했습니다. 빨리. 저는 현재 C #을 주로 개발하고 있으며 소프트웨어 작성에 시간을 낭비하는 지루한 시간을 없애는 도구를 항상 찾고 있습니다. StoryQ 라는 매우 우수한 BDD API로 지원되는 테스트 우선 개발 방법을 사용합니다 . Resharper 를 사용 하여 리팩토링과 StyleCop의 많은 부분을 자동화하여 코딩 스타일과 같은 것들에 뚜껑을 닫았습니다. 툴체인에 제가 최근 추가 한 것은코딩 하는 동안 백그라운드에서 지속적으로 동시에 테스트를 실행하는 NCrunch 는 게임 체인저로 입증 된 NCrunch 입니다.

이러한 도구를 모두 조합하면 컴파일 또는 실행을 기다리는 데 시간이 거의 걸리지 않으므로 생산성이 최근 지붕을 통과하는 것으로 나타났습니다. IDE 내에서 시각적으로 즉각적인 피드백을 받아 수정해야 할 문제가 있음을 알려주고 테스트 코드를 몇 줄의 코드 내에서 정확한 위치에 정확히 찾을 수있는 방식으로 배치합니다. 실패가 발생하지만 StoryQ 에서 얻은 멋진 장황한보고로 인해 실패의 원인이 발생하는 위치테스트 패스의 어느 부분, 실패 및 코드의 실패 위치를 정확하게 알려줍니다. 개발 시간에서 낭비되는 모든 시간을 제거하면서 적극적으로 디버깅하는 데 시간이 거의 들지 않으며 문제를 해결하고 테스트 및 코드를 작성하는 데 더 많은 시간을 할애합니다. 높은 이직 문제는 나를 바쁘게하고 내 작업에 많은 변화를 가져옵니다. 또한 업무 시간 동안 다른 관심 분야를 추구하여 제품 라인과 프로세스에 새롭고 혁신적인 아이디어를 주입 할 수있는 시간을 많이주었습니다.