버그를 더 빨리 해결할 수있는 방법이 있습니까? 방금 상사로부터 경고를 받았습니다.


129

월요일에 상사로부터 부정적인 실적 검토를받을 것이라고 들었습니다. 그는 왜 내가 왜 그렇게 느리고 왜 버그 수정률이 그렇게 낮은 지 이야기하고 싶어합니다.

나는 프로그래밍과 문제 해결을 좋아하지만 실제로 내 직업이 정말 어렵다는 것을 알게된다.

저는 실제로 약 10 년 동안 프로그래머였습니다. 그러나 이것은 첫 번째 멀티 스레딩 임베디드 Linux 작업입니다. 저는 2 년 동안 여기에 있었으며 여전히 어려움을 겪고있는 모든 사람들에게 분명합니다. 그리고 저는 제가 너무 낙담 해져서 소외감을 느끼면서 일을 시작할 때 겪었던 많은 불을 잃어 버렸다고 생각합니다.

비슷한 상황에 처한 사람이 있습니까? 버그 수정률을 높이는 방법은 무엇입니까?


업데이트 : 나는 리뷰를했다. 나는 3 개월의 '직원 개발 프로그램'(Dunk에서 언급 한 유형)을 사용했습니다. 내가 이것을 바꿀 수 있는지 확실하지 않습니다. 그러나 계속 나아가 야할지 라도이 경험에서 많은 것을 배웠습니다.

다른 업데이트

첫 번째 검토 이후 약 6 주가되었습니다. 같은 상황에 처한 사람에게 저의 조언은 비판을 받고 실수를 통해 배울 수있을만큼 겸손해야한다는 것입니다. 그리고 멍청 해 보이는 것을 두려워하지 마십시오. 많은 양의 질문을하십시오. 배우려고한다는 것을 사람들에게 알리고 이해할 때까지 계속 물어보십시오. 그러나 운동하지 않도록 준비하십시오. 코드 포트폴리오를 구축하고 최상의 기회를 제공합니다.

또 다른 업데이트

나는 미래의 고용주를 내 스택 오버 플로우 프로파일로 참조 할 수 없을지 걱정하기 때문에 이것을 여기에 넣는 것을 주저합니다 ... 그러나 어쨌든이 질문을 읽는 사람에게는 관심이있을 수 있지만 실제로는 몇 주 전에 일 했어 나는 필요한 모든 기술을 연마하는 중입니다-여기에 제공된 조언에서 많은 것을 얻었습니다.


170
상사에게 문제가 있음을 알았을 때 언급하지 않고 검토를 위해 저장하는 것이 정말 좋았다는 것을 상사에게 알리십시오.
Blrfl

13
유지 보수 프로그래밍에는 특정 종류의 사람이 필요합니다. 어쩌면 그것은 당신의 것이 아닙니다. 마찬가지로, 새로운 개발에는 또 다른 종류의 사람이 필요합니다. 도구 / 팁 / 트릭 발견에 대해 이야기합니다. 자신이 사용하기 위해 몇 개의 도구를 만들었습니까? 대답이 없으면 유지 보수 프로그래밍 유형의 사람이 아니라고 생각합니다. 성능 부족으로 여러 프로젝트를 뒤섞은 경우에는 현재 위치에 적합하지 않다는 명확한 메시지로이를 받아들입니다. 더 적합한 것을 찾으십시오.
덩크

40
당신이해야하는 경우 추측 이 때문에 성능의 주위를 단행하고 있다는 것을, 관리 뭔가 잘못하고있다. 마찬가지로, 저 성과에 대해 처음 듣는 것이 2 년이 지나면 경영진이 잘못한 것입니다.
Michael Shaw

32
@Bee : 일반적으로 일단 누군가가 열악한 평가를 받으면 떠날 시간입니다. 그들은 "직원 개발 프로그램"에 당신을 넣을지도 모르지만, 나는 그 단계에 도달하면 아무도 회복하는 것을 본 적이 없다고 생각합니다. 직업을 찾는 가장 쉬운 시간은 이미 직업이있을 때입니다. 제가 당신이라면 이력서를 업데이트하고 곧 다른 곳을 찾아보기 시작할 것입니다. 또한 귀하가 취하는 직업 유형에 매우주의해야합니다. 7 년의 경험은 여전히 ​​옵션을 떠납니다. 10을 달성하면 회사는 특정 분야의 전문 지식을 기대하게됩니다. 좋아하고 잘하는 지역을 선택하십시오. 죄송합니다. 이미 10 점을 기록했습니다.
Dunk

8
답이 되기에는 충분하지 않지만 "더 빨리가는 길"에 관하여 : 당신은 그것이 새로운 도메인이라고 진술합니다. 당신이 고치는 방법은 너무 많은 시행 착오가 될 수 있습니다. "깊은"? 이 경우 기본 사항을 완전히 익히면 잠재적 인 문제를 더 잘 파악할 수 있습니다.
Matsemann

답변:


80

많은 답변들이 상사의 방법 / 전술 / 메트릭 / 등에 의문을 제기했습니다. 그러나 그것은 요점 옆에 있습니다. 아마 당신은 느리다. 개발자의 모든 방에는 나머지 방보다 느린 방이 하나 있어야합니다. (이것은 똑바로 설정되는 이론입니다.) 그래서 당신이라고 가정합시다. 답은 왜 느린가요? (확실히하는 방법에 대해 명시된 질문을 풀기 전에 반드시 대답해야하는 질문입니다.)

여러 가지 이유가있을 수 있지만 여기 에 고려해야 할가지 설명이 있습니다.

  1. 당신은 그들보다 덜 똑똑 합니다. 가능합니까? (학생들은 우리 모두 가 우리의 친구들보다 덜 인기 있고, 덜 흥미롭고 , 덜 똑똑 하다는 것을 보여주었습니다 .) 아마도 당신은 느리게 생각할 것입니다. 그런 다음 다시 귀하의 경우에는 이것이 불가능하다고 생각합니다. StackOverflow 프로필을 한눈에 살펴보면 광범위한 주제에 대한 지능적인 질문을 한 적이 있습니다. 그래서 당신은 분명히 사상가이고 아마도 그것에 좋은 사람 일 것입니다.

  2. 너무 얇게 퍼졌습니다. 당신의 SO 프로필과 마찬가지로 지난 2 년간 그래픽, 웹, 파이썬, C ++, c, 리눅스, 임베디드, 스레드, 소켓 등 다양한 기술이 당신의 질문에 포함되어 있음을 보여줍니다. 개인적으로, 나는이 다른 스트림의 다양한 탐구하는 데 (또는 원하는)의 상황에 넣어 때, 나 자신이 수영을 찾을 것을 알고 최대 전류 정말 빨리 (또는, 오히려 정말 천천히 ). 아마도 여기에 정말로 필요한 것은 FOCUS 입니다. 그리고 아마도 건강한 선량의 우선 순위 . 어쨌든 덜 중요한 냄비를 백 버너로 옮기고 메인 접시의 열을 올릴 수 있습니까?

  3. 재미 없어 화재가 발생하면 증기 엔진이 감속됩니다. 귀하는 귀하의 게시물에서 최근에 사기가 심각하게 타격을 받았다고 인정했습니다. 불행히도 당신은 자기 강화 음성 고조파의 빨라진 소용돌이에 삼 켜져 다리파괴 할 수 있습니다 . 그것은 너무나 익숙한 나선입니다. 어려운 과제-> 스트레스-> 마감일 누락-> 더 많은 스트레스-> 불충분 한 대처 메커니즘-> 더 많은 스트레스-> 지연-> 누락 된 마감일-> 비판 / 가십 (실제 또는 상상)- > 더 많은 스트레스. 당신은 그림을 얻는다. 이것은 거의 유용한 곳이 아닙니다. 급류 래프팅에서 저의 교훈을 얻으십시오. 급류 뒷면의 급류에 의해 수 중에서 빨려 들어 오면 구명 조끼 는 그렇지 않습니다.당신을 다시 표면으로 부표. 가장 직관적 인 전략은 (직관적이지 않지만) 강의 바닥 을 찾아서 물 밖으로 나가는 것 입니다. 그래서 당신에게 나의 충고는 : 어떤 근거 , 친구, (친구, 교회, 건강한 새로운 습관 등)를 찾아서 소용돌이에서 벗어나기 위해 그것을 사용하십시오.

  4. 당신은 당신의 영역에 없습니다. 마이클 조던은 꽤 절름발이 야구 선수를 만들었습니다. (괜찮아, 그는 여전히 나보다 낫지 만, 확실히 미성년자이다.) 아마도 "멀티 스레딩 임베디드 리눅스"는 당신의 공연이 아닐 수도있다. 그러나 소프트웨어 개발은 ​​매우 넓은 분야입니다 (위의 2 번 참조). 회사가 다른 틈새 시장을 찾을 수있을만큼 넓습니까? 마지막 직장에서 저는 임베디드 SW 개발자로 고용되었습니다. (나는 그 분야에서 경험이 없었지만 그들에게 내가 "빠른 학습자"라고 말했다.) 나는 돌처럼 빨리 침몰했다. 그러나 나는 열심히 노력 보관하고 내가 문제를 찾고 유지 했다그들을 해결하는 방법을 알고 있습니다. 결과적으로, 나는 점차 빛을 발할 수있는 새로운 책임으로 옮겨 갈 수 있었으며 결국 상당한 찬사를 받았습니다. 따라서 자신을 다시 브랜드해야 할 수도 있습니다.

요점은 : 당신이 느리다면 이유가 있습니다. 하지만 이봐 . 당신은 소프트웨어 엔지니어 야! 자신을 디버깅!


2
정말 훌륭한 답변입니다. 나는 당신의 모든 점이 나를 (그리고 # 1에 대한에 적용 할 수있는 생각, 잘 어쩌면 나는 입니다 . 어쩌면 내가이야 numbskull 임베디드 리눅스 디바이스 그래서 어쩌면이 # 4에 관련되어 - 내가 정보의 다른 유형이 있다고 듣고, 덜 지능형 그러나 아마도 웹에 능숙 할 것입니다 ... 지금은 그것에 대해 생각합니다. 실제로는 현실적 일 수 있습니다). 어쨌든-당신은 매우 지각 적입니다.
BeeBand

14
3과 4는 대부분의 보스가 상상할 수있는 것보다 (프로그래머의 경우) 더 큽니다. 프로그래머가 사기가 낮 으면 일에 집중할 수 없습니다. 프로그래머에게는 사기가 모멘텀이고 모멘텀이 전부입니다.
TimG

7
훌륭한 답변입니다. 자신을 디버깅 하는 것은 훌륭한 문구입니다. 나는 당신을 위해 두 번째로 투표 할 수 있기를 바랍니다.
Kyeotic

2
우정 역설은 두 사람 사이의 관계를 그래프에서 두 꼭짓점 사이의 단순한 양방향 가장자리로 모델링하는 반면, "따라야한다"는 점 1에서 효과가없는 반면 과도 성 규칙이 적용되지 않는다는 것은 말할 것도없이 다른 여러 가지 요소가 있습니다. 나는 2,3,4 점에 동의합니다. OP의 경우, 그의 상사는 독촉 자 효과로 고통받는 douchebag라고 생각합니다.
funkymushroom

1
프로그래머, 자신을 디버그하십시오. 그것을 사랑 :) 좋은 답변도. 그 상황에 있기 때문에가 아니라 지금 피하는 방법을 볼 수 있기 때문에 나에게 유용합니다. +1
jammypeach

56

당신의 상사가 맞을 수도 있습니다 : 당신은 "성능이 부족"할 수도 있습니다 (분 후에 더 자세히). 그러나 그것은 단지 당신의 책임 수준이 아닙니다. 컨트롤 외부의 힘이 스트레스를 유발하여 성능에 부정적인 영향을 미치는 것은 아닙니다.

상사가 지금이 문제를 제기하는 몇 가지 이유를 살펴 보겠습니다.

문화와 정치

상사가 자신의 우려를 표명해야하는 통제 할 수없는 힘이있을 수 있습니다. 작업중인 시스템을 이해하는 것이 중요합니다. 직무는 상사가 멋지게 보이도록하는 것입니다. 그렇게하는 유일한 방법은 자신이받는 압력을 이해하는 것입니다.

능력

그가 공개적으로 말한 것처럼 능력이 최고 수준이 아닐 수도 있습니다. 이 상황에서 내가 할 일은 다음과 같습니다.

가져 오기 특정 피드백 그는 성능을 측정하는 방법에 대한 당신의 상사에서합니다. 사람 X만큼 많은 버그를 끝내지 않습니까? 해결해야 할 일련의 버그가 있습니까? 혼자 일하는 경우 성과를 측정하는 사람들이 선입견을 바탕으로하지 않고 공정하게 측정하고 있는지 확인해야합니다.

성과가 느리고 실제 격차를 기반으로하는 경우 해당 격차를 식별하고이를 마무리하기 위해 상사와 함께 세부 계획을 세우십시오.

이 리뷰는 또한 당신이 행복하지 않다는 사실을 제기 할 수있는 좋은 기회입니다. 이 직업이 마음에 들지 않는다는 것을 확인한 것이 좋습니다. 그러나 왜 그런지 알아 내십시오. 직업의 어떤 부분을 좋아하고 무엇을 좋아하지 않습니까? 이 직업이 당신을위한 것이 아닐 수도 있습니다 ...


2
좋은 답변입니다. 왜 내가이 일을 즐기지 않는지에 대해 생각할 것이 있습니다. 주로 그들이 버그와 함께 우리에게주는 로그 파일입니다. 나는 다른 사람들보다 더 많이 숭배하게되었습니다. 나는 그들이주는 버그로 항상 완전히 완전히 어둠 속에서 시작합니다. 나는 이것이 내가 싫어하는 '어두운'느낌이라고 생각합니다.
BeeBand

4
같은 프로젝트에서 비슷한 문제가 발생하지 않는 한, 대부분의 사람들은 새로운 버그가 생길 때 "어두운 곳에서"시작합니다. 그런 다음 증상에 따라 문제를 재현하는 방법을 찾아 문제의 원인을 추측 할 수있는 위치에 대한 아이디어를 제공해야합니다. 당신은 단계적으로 계속합니다. 마법도없고 증오도 없습니다. 당신은 당신이 로그 파일을 싫어한다고 말합니다. 해당 로그 파일 분석을 자동화하기위한 도구를 스스로 작성 했습니까? 로그 파일이 유용하지 않다면 유용 할 것이라는 사실을 무시합니다. 그리 오래 걸리지 않았다면 분석 도구가 만들어졌습니다.
Dunk

1
@ 덩크 예 나는 다양한 방법으로 로그 파일을 구문 분석하는 도구를 만들었습니다. 그 후 누군가가 이미 1 년 정도 전에 이미 만들었 음을 알았습니다.
BeeBand

@Bee : 도구를 만들 때 필요한 이니셔티브가 표시됩니다. 프로젝트 간 전환시 개발 환경에 대한 개요를 아는 사람이 없습니까? 도구가 있으면 프로젝트 책임자가 해당 도구에 대해 알려 주어야 할 것 같습니다.
덩크

@ 덩크 다시 개요-아니. 첫 번째 팀장이 내게 특정 도구를 보여 주었지만 특정 종류의 버그를 수정하는 데 유용하거나 다른 프로젝트로 변환 할 수 있음을 나타내지 않았습니다. 이 새로운 유지 관리 프로젝트로 이사했을 때 아무도 개발 환경을 통해 나에게 이야기하지 않았습니다. 동료에게 물어 보는 도구를 직접 만들려고 애 쓰고 나서 원래 도구를 어떻게 사용할 수 있는지 언급했습니다. (NB 이것은 내 이전 의견과 다른 도구입니다).
BeeBand

38

일부 작업 환경은 작동하지 않습니다. 나는 문서화되지 않은 많은 것들과 질문들이 그토록 낙담했기 때문에 아무도 살아남을 수없는 환경을 보았습니다.

당신이 기대하는 바를 충족시키기 위해 제공되는 기대치와 자원에 대해 당신 자신에게 정직해야합니다. 문제가 아닐 수도 있습니다.

당신은 어려움을 겪지 않지만 5 년 이상 경험이있는 사람들과 비슷한 일을하는 사람들이 있다고 언급합니다. 그들은 당신을 완전히 (이 점에서) 능가하는 록 스타입니까, 아니면 당신과 같은가요? 아마도 그들은 시스템이 더 단순 할 때 시스템을 알게되었을 것입니다. 거기서 어떻게 했어? 당신이 위대한 일을했다면, 그것은 당신에게 무언가를 말해야합니다.

나를 놀라게 한 부분은 당신 이 오는 모든 버그와 관련 하여 어둠 속에 있다고 자신을 묘사하는 것에 관한 것입니다. 코드 기반이 너무 넓고 미지의 경우 기대치가 합리적이지 않을 수 있습니다.

당신이 가지고있는 한 그것을했다는 것은 당신이 옳은 일을했고 당신을 위해 무언가가 있다는 것을 의미합니다.

결론은, 자신과 자신이하는 일에 대해 기분이 좋아야한다는 것입니다. 그리고 그것이 계속 나아가는 것을 의미한다면, 그렇게하십시오.

직업이 인생을 망치게하는 것보다 계속 나아가는 것이 좋습니다.


2
나는 당신이 묘사 한대로 나의 직업 경력에있는 팀을 보았습니다. 그들이 유지 관리하는 코드는 방대하고 암호화되어 있으며 작동 방식에 대한 정보가 질투합니다. 새로운 팀원은 의도적으로 자신의 장치에 맡겨져 있으며, 결국 경력을 구하기 위해 이전합니다.
Anthony Giorgio

31

첫째,이 답변은 퇴직없이 직원을 해고하는 것이 불법 인 특정 지역에만 적용될 수 있습니다. 그건 ...

이것은 건설적인 해고 의 경우 일 수 있으며 불법입니다.

전술은 직원이 직장을 그만 둘 때까지 자존감을 낮추고 낮추는 것입니다. 회사가 퇴직금을 지불하거나 직원을 대면하여 해고해야하는 문제를 해결하지 않고도 비용을 절감 할 수있는 방법입니다.

그는 왜 내가 왜 그렇게 느리고 왜 버그 수정률이 그렇게 낮은 지 이야기하고 싶어합니다.

이 결함은 매우 모호합니다. 상대방의 한쪽이 다른 쪽을 잘못이라고 주장하는 것은 불가능합니다. 한 가지 버그를 수정하기 위해 한 달이 걸렸습니다. 그래서 무엇! 이를 통해 한 달이 필요하다는 주장을 뒷받침 할 사실을 제시해야합니다. 현재 기술, 경험 및 지식을 요인으로 고려하십시오. 고용주로서 직원의 시간과 노력을 관리하는 것은 고용주의 직무입니다. 버그 수정과 관련된 위험에 처한 사람이어야합니다. 직원이 아닙니다. 그는 항상 다른 사람에게 버그를 할당하도록 선택했습니다.

계약자 인 경우 계약에서 버그 수정을 담당하는 계약서에 따르면 완전히 다른 이야기입니다.

고용주가 너무 오래 걸린다고 불평하는 것이 잘못입니까? 절대로 그렇지는 않지만, 그는 당신에게 책임을 질 수 없으며, 당신을 해고 할 수 없습니다. "당신의 기술을 필요로하는 버그가 더 이상없고 휴가 중입니다." 그렇지 않으면, 그들은 퇴직으로 종료해야합니다. 그가 할 수없는 것은 당신이 처리 할 수없는 일을하고 그것에 대해 불평하는 것입니다. 나는 이것이 불법이라고 생각합니다.

나는 프로그래밍과 문제 해결을 좋아하지만 실제로 내 직업이 정말 어렵다는 것을 알게된다.

어려운 직장을 구하는 것과 고용주가 어려운 직장을 구하는 것에는 큰 차이가 있습니다. 회사에서 경력을 쌓지 못하도록 자신에게 할당 된 작업이 수행되었다고 생각되면 이는 불법 일 수 있습니다.

저는 실제로 약 10 년 동안 프로그래머였습니다. 그러나 이것은 첫 번째 멀티 스레딩 임베디드 Linux 작업입니다. 저는 2 년 동안 여기에 있었으며 여전히 어려움을 겪고있는 모든 사람들에게 분명합니다.

이것이 당신이 건설적인 해고의 한가운데서 자신을 발견했다고 생각하는 이유입니다. 그들은 당신과 함께 행복하지 않기 때문에 당신이 떠날 때까지 쓰레기를 쌓습니다.

그리고 저는 제가 너무 낙담 해져서 소외감을 느끼면서 일을 시작할 때 겪었던 많은 불을 잃어 버렸다고 생각합니다.

고용주는 안전하고 긍정적 인 업무 환경을 제공 할 책임이 있습니다. 더 많은 정보 (대부분의 개인 정보)가 없으면 외부인이 실제로 무슨 일이 일어나고 있는지 말하기가 어렵습니다. 무료 상담을 위해 고용 변호사에게 문의하십시오. 그들은 당신이 연주되고 있는지 말할 수 있습니다.

참고 문헌

저는 변호사는 아니지만 월요일에 리뷰를 입력하기 전에 읽을만한 가치가있는 건설적 해고 주제에 대해 Google에서 문서를 작성했습니다. 여기서 중요한 점은 급여, 굴욕감 감소 및 회사 경력의 갑작스런 변화를 주시하는 것입니다.

관련 사실에주의하십시오 :

  • 열악한 근무 환경에서 직원을 제대로 지원하지 못하는 경우
  • 직원에 대한 과도한 징계 직원의 근무지에 짧은 통지로 변경
  • 급여 또는 임금 감면 부과

법적 Q & A : 건설적 해고

건설적인 해고를 주장하는 이유

위키 백과

건설적인 해고의 요소


11
그것은 성능에 부정적인 리뷰를 제공하는 것은 불법이 아니다,하지만 그들은 않습니다 객관적해야하고 작업 가능한 기준을 동의하고 당신을 지원합니다.
pjc50

9
나는 그 대답을 올렸을 때 과잉 반응하고 있다고 생각했지만 게시물을 읽는 것은 내 경험과 공명했다. 버그 수정은 성능 컨텍스트로 측정 할 수있는 것이 아닙니다. 단일 버그를 수정하기 위해 3 개월을 한 번 보냈습니다. 일반적으로 똑똑한 사람들은 어려운 버그를 겪는 사람들입니다.
Reactgular

9
변호사라는 증거가없고 법적인 조언을한다고 주장하는 증거를 볼 수 없어 투표를 중단했습니다. 또한 다른 직원이 한 달에 평균 X 버그를 수정하고 있지만 OP가 X / 10을 수정하는 경우 이는 객관적이고 합리적입니다.
Andy

7
@Andy는 왜 다운 보트를 공유했는지 감사합니다. 버그 수정 비율이 지표라는 데 동의하지만 금요일에 누군가에게 다음 월요일에 부정적인 리뷰가 있다고 알리는 것이 객관적입니다. 주말 동안 땀을 흘리게하는 것 외에 원하는 결과가 직원이 검토를 위해 월요일에 나타나지 않는다고 가정하는 것이 안전하지 않습니까? 건설적인 해고로 분류되지 않습니까? 건설적인 해고는 우리 업계에서 계속되는 문제이기 때문에 귀하의 관점을 바꿀 수 있기를 바랍니다.
Reactgular

7
판사가 이것이 건설적인 해고라고 판결 할 방법은 없습니다. 법률 서한을 허위로 정리할 수 있지만 이러한 유형의 법률은 직원이 괴롭힘을 당하거나 학대를당하는 경우 적대적인 상황입니다. OP의 말을 바탕으로 버그 수정률에 이르기까지 동료에 대해 누적되지 않기 때문에 부정적인 리뷰를 받고 있다는 정보를 받았습니다. 그것은 어려운 상황이지만 적대적이지 않으며 불법이 아닙니다. 아마도 사장님이 더 재치가 있었을 수도 있지만 피드백은 공식 성능 검토로 제한 될 필요는 없습니다.
pdubs

26

아마도 당신은 프로젝트의 원래 프로그래머 중 하나와 비교되고있을 것입니다. 내가 작업하는 프로젝트 중 하나의 원래 개발자로서 버그를 수정할 때 엄청난 이점이 있음을 알고 있습니다. 나는 그것이 문서의 부족으로 인한 것이 아니라고 생각합니다. 뇌가 모든 코드를 알고 있기 때문에 잠재적 인 문제로 직관적으로 도약 할 수 있다는 것입니다.

당신이 그것에 비교한다면, 당신은 측정하지 않을 것입니다. 프로젝트 진행 속도를 높이려면 항상 더 많은 시간이 걸리며 잠재적 인 상호 작용 지점이 어디에 있는지 모를 것입니다.

다른 프로그래머가 문제를 해결하기 위해 사용하는 도구와 요령에 대해 알지 못하는 것에 대한 귀하의 의견을 읽었습니다. 다음 버그 수정을 위해서는 아마도 페어 프로그래밍을 시도해야합니다. 이것은 매우 유용 할 수 있습니다. 교대로 키보드를 운전하십시오. 말을 많이하십시오 .

노트북 또는 화이트 보드를 사용하여 기능 경로, 스레드 및 잠금 수명을 차트로 표시하고 다양한 동작을 관찰하는 위치와 새 프로브를 삽입 할 수있는 위치를 표시 할 수 있습니다.

이러한 종류의 저수준 스레딩 문제를 해결하는 것은 정말 어려울 수 있으며 많은 동정심을 가지고 있습니다. 2 줄 문제를 발견하기 전에 몇 기가 바이트의 로그 파일을 분석해야했습니다. 그리고 그거 알아? 나는 그 해에 인턴이었던 하급 엔지니어에게 도움을 요청하기 전에 며칠 동안 응시했으며, 그는 새로운 접근법을 생각해 내고 한 시간 안에 문제를 발견했습니다. 따라서 버그에 시간을 투자 한 후에는 새로운 시각을 가지십시오. 많은 도움이 될 수 있습니다!


3
이것은 환상적인 반응입니다. 매우 감동 받았습니다.
Daniel Hollinrake

26

이 업계에서 가장 일반적인 관리 기능 장애 중 하나는 디버깅이 본질적으로 어렵다는 것을 이해하지 못하는 것입니다 . 나는 경험이 거의 20 년을있어 나는 여전히 정기적으로 프로그램의 충돌을 쉰 중 1 시간을 만드는 한 줄 실수를 찾는 일주일 보내고있다. 그런 다음 관리자가 이러한 사항을 이해하지 못하면 한 줄의 코드를 변경하는 데 일주일이 걸리는 번거 로움이 있습니다.

그것에 대해 무엇을 할 수 있습니까?

  • 디버깅 할 때 메모하십시오. 항상 편집기 창을 열어두고 의식의 흐름을 적어 두십시오. 당신 외에는 누구에게도 의미가 없습니다. 이 방법을 사용하면 더 빨리 디버깅하는 데 도움이 될 수 있지만 일주일 내내 Nethack을하지 않았다는 것을 보여줄 수있는 구체적인 내용이 있습니다.

  • 모든 동료와 메모를 비교하십시오. 일반적으로 버그를 수정하는 데 시간이 얼마나 걸립니까? 버그는 수정되어 있습니까? 그들은 한 번의 작은 일을 얼마나 자주 바꾸고 계단식 결과에 묻혀 있는가? 이 질문에 대한 답변 은 나머지 부서와 비교하여 실제로 어려움을 겪고 있는지 여부를 알 수 있습니다 .

  • 품질 관리 담당자 및 고객 지원 담당자와 친구가 되십시오. 버그가 얼마나 중요한지 잘 알고있는 사람입니다 . 버그가 얼마나 어려운지 와 거의 상관 관계가없는 경우가 많으므로 시스템을 약간 게임하여 중요도가 높고 난이도가 낮은 모든 버그를 할당 할 수 있습니다. (이것은 실제로 부정 행위가 아닙니다. 잘 조직 된 팀은 항상 그 버그를 먼저 따릅니다.)

  • 만약 당신의 상사가 2 년 동안 당신의 공연에 대한 적절한 피드백을 제공하지 않았다면, 그것은 먼저이 성과 검토를 시작한 다음, 그에 대한 대안을 얻었을 때 상사의 상사와 함께 제기하는 문제입니다. 예의 바르게 행동하십시오. 특히 그들이 당신에게 얼마나 화를 내는지 알려주지 말고 서면으로 구체적인 비판을 받으십시오.


4
"디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵다." -Brian Kernigan (C의 아버지, UNIX)
TimG

4
@TimG : 다른 모든 프로그래머와 마찬가지로 Kernigan은 어려움을 과소 평가했습니다.
mu는

와우, 지적하고 싶습니다. 이것은 정말 어려운 질문이며 여기서 좋은 통찰력있는 대답을보고 놀랐습니다. 감사.
maksymko

12

프로그래밍과 문제 해결이 마음에 들지만 배우는 내용을 다른 분야에 얼마나 잘 적용하고 있는지에 대한 질문이있을 수 있습니다. 마지막으로 수정 한 수십 개의 버그 중 하나를 수정하는 데 도움이 된 버그가 다른 버그에 유용합니까? 이것은 당신이 한 일과 그 일을하는 데 얼마나 오래 걸 렸는지 되돌아 보는 것의 일부입니다. 고려해야 할 아이디어.

둘째, 나는 당신이 어떻게 일을하는지 살펴볼 것입니다. 정기적으로 중단되므로 버그 A를 수정하려고 할 때 버그 B와 C가 우선 순위가 높다는 메시지가 나타납니다. 상사가 알고 싶어하는 일의 일부일 수 있으므로 작업 수행 방식에 어떤 종류의 변경 사항이 도움이 될지 신중하게 고려하십시오.

나는 몇 곳의 직장에서 그들이 내 일을 끝내는 데 시간이 오래 걸리지 않았다고 말합니다. 코스는 내가 한 가지 일을하면 5 개의 새로운 것이 내 무릎에 떨어질 것이므로 압도하기 쉬운 곳이었습니다. 더 이상 그곳에서 일하지 않을 수도 있지만, 한 번에 1,000 가지를 마스터하려고한다고 느끼지 않도록 몇 가지 사항에주의를 기울이는 방법에 대한 좋은 해결책이 없었습니다. 내가해야 할 몇 가지 중요한 일과 내 작업이 어떻게 판단되는지 알 수 있다면, 마일이 길고 "누구나 할 일"목록을 갖고있는 경우보다 훨씬 낫습니다. 그것의 일부. 따라서 조직 내부에 문화적 요소가있을 수 있지만 여기서 변경해야 할 사항에주의해야합니다.


2
ended up getting micromanaged until I was terminated-방금 당신의 SO 프로필을 살펴 보았고 당신은 분명히 그로부터 되돌아 왔습니다. 월요일에 첫 번째 요점에 대해 이야기하려고합니다. 매우 다른 지역에서 버그가 발생했습니다.
BeeBand

10

2 년 동안 일을 한 후에는 모든 사람 (귀하, 상사, 동료)에게 서있는 곳이 분명해야합니다. 즉, 당신은 당신이 일년에 한 번 열악한 일을하고 있다는 것을 결코 알 수 없습니다. 이상적인 작업 환경은 지속적인 피드백을 제공합니다.

어쨌든 멀티 스레드 코드를 디버깅하는 방법과 관련 하여 코드인지 다른 사람 인지 언급하지 않았습니다 . 동시성을 처리 할 수있는 몇 가지 새로운 디버거와 정적 분석기가 있습니다. 그러나 실제로 패턴 을 아는 것이 무엇을 찾아야할지 알기 때문에 최선의 방법입니다.

중요한 섹션과 경쟁 조건 및 교착 상태가 어떻게 작동하는지 이해하면 예기치 않은 사항을 더 잘 파악할 수 있습니다. 조건 변수가없는 두 스레드간에 "통신"이 보이거나 특정 순서없이 리소스가 뮤텍스 된 경우 또는 static명백한 이유없이 로컬 변수가 선언 된 경우 잠재적 인 버그가 있습니다! 따라서 도메인의 모범 사례를 배우면 평범하지 않은 시점을 판단 할 수있는 더 나은 위치에있게됩니다.


2
예, 이것은 내 코드가 아닙니다. 10 년 전에 처음 설계된 거대한 확장 임베디드 시스템입니다. 나는 당신이 패턴에 대해 맞다고 생각합니다-기본으로 돌아 가야합니다.
BeeBand

1
@BeeBand 당신이 어떻게 생겼는지 아는 것이 좋을 것입니다. 일이 잘되기를 바랍니다.
Daniel Hollinrake

10

당신이하지 않는 한 혼자 투쟁하지 마십시오. 동료를 모집하십시오. 버그 찾기를 도와주세요. 그들의 사고 과정과 도구에 대해 물어보십시오. 아마도 개선 계획의 일부로 검토에서 이것을 언급 할 것입니다. 주위의 모든 사람들 이이 시스템 에서 더 잘하고 있다면 , 그들은 특정한 것을 알고 있습니까?


BeeBand가 이미이 작업을 수행했는지 알고 있으면 흥미로울 것입니다. 의견과 답변을 읽는 것은 꽤 비우호적 인 환경 인 것 같습니다.
Daniel Hollinrake

1
글쎄, 나는 그것에 동정 할 수 있습니다. 개발팀이 일을하고있는 회사에있는 것이 어떤 것인지 알고 있습니다. 다행히도 제 경우에는 훌륭한 동료들과 함께 일하면서 서로를 찾습니다. 페어링 할 수있는 사람이 있습니까? 당신을 훈련시키고 생산성을 높이는 데 도움이되는 시간은 모든 사람에게 보상이 될 것입니다. 당신이 돌보는 것들과 양심적 인 소리에서 당신의 회사는 당신을 지키는 데 도움이 될 것입니다.
Daniel Hollinrake

8

월요일에 상사로부터 부정적인 실적 검토를받을 것이라고 들었습니다. 그는 왜 내가 왜 그렇게 느리고 왜 버그 수정률이 그렇게 낮은 지 이야기하고 싶어합니다.

고장난 회사에서는이 주문이 발생하지 않습니다. 상사가 성과에 대해 우려하는 경우 단기 목표를 설정하고 결과에 대해 이야기하여 문제가 발생한 위치를 찾아야합니다.

대신, 그는 당신에게 부정적인 리뷰를하기로 결정하고 그 이유를 찾으십시오. 그는 문제에 기꺼이 관여하지 않는 것처럼 들리며 테이블에 결과를 원합니다.

버그를 더 빨리 해결하는 것을 목표로하지 마십시오. 자신의 능력을 평가하고 동료의 업무 방식을 확인하고 동료가 알고있는 것을 어떻게 알고 있는지 확인하고 이것이 이상적인 회사가 아니라는 것을 인식하십시오.

실용적인 팁은 코드 스 니펫과 자체 미디어 위키를 사용하여 메모합니다. 나는 항상 다음에 읽을 책과 학습을 계속하기 위해 어떤 방향으로 갈지 염두에 두었습니다. 학습은 더 나은 직업과 더 행복한 삶의 길입니다.


7

첫째, 자신감 향상 :

왜 고통? 버그 수정률에 관계없이 Linux 임베디드 작업을 수행 할 수 있기 때문에 "신"이라고 생각하는 직업을 쉽게 찾을 수 있습니다.

어쨌든 버그를 사냥하는 데 시간 제한을 설정하는 것은 불가능합니다. 버그 사냥은 기술이며 의심의 여지가 없으며 효율성은 매우 중요합니다.

다른 사람들이 알고있는 몇 가지 기본 트릭이 누락되어 속도가 느려질 수 있습니다.

예를 들어, 당신과 내가 리눅스 미들웨어를 사용하고 있고 메모리 손상 문제와 데이터 경쟁 조건을 찾기 위해 Valgrind를 사용하고 있다면 gdb와 printf에만 의존하고 있다면 아마도 엉덩이를 걷어차 게 될 것입니다. 넌 나보다 똑똑해

또한 동시성에 대한 이해는 어떻습니까? 10 년 동안 개발해 왔지만 대부분의 경험이 멀티 스레드 코드가 아니었다면 문제가 될 수 있습니다.

멀티 스레딩에 대해 자세히 연구해야합니다. API 사용법을 아는 것 이상이 아니라 실제로는 "깊게"얻습니다. 다중 스레드 프로그래밍을 수행하는 경우 1 마일 거리에서 코드베이스를보고 경쟁 조건, 교착 상태, 우선 순위 반전, 기아 상태 등을 발견 할 수있는 개발자 여야합니다.


1
동시성의 가장 큰 문제는 버그가없는 코드에서 버그를 수정하는 것보다 버그가없는 코드를 작성하는 것이 훨씬 쉽다는 것입니다. 특히 코드가 거의 올바른 경우. 버그는 대개 한 곳에 있지 않지만 많은 곳에 배포됩니다.
gnasher729 2014 년

5

최근 에 레거시 코드로 효과적으로 작업하기 책을 읽었 으며 모든 코드베이스에서 문제를 해결할 때 크게 자신감을 얻었습니다.

작업중 인 코드가 완벽하지 않은 것이라면이 책이 도움이 될 것이라고 생각합니다. 버그를 해결하기 위해 많은 시간이 걸렸음을 알았습니다. 먼저 코드를 이해 하기 위해 주변 코드를 리팩터링 한 다음 코드를 이해하면 코드를 테스트하고 추적 가능하게 만들고 문제를 해결하는 것은 어려운 일이 아닙니다 (때로는 코드를 이해하기 위해 코드를 다시 작성했지만 새로운 버그가 발생할 위험을 줄이기 위해 변경 사항을 되돌립니다. 그런 다음 버그 수정을 삽입합니다.이 기술은이 책의 요령을 기반으로합니다.)

내 제안은 문제의 일부와 다소 간접적 인 문제만을 다루고 있지만 레거시 코드를 사용하는 것은 모든 개발자에게 불가피하기 때문에이 책은 무엇이든 상관없이 읽을 가치가 있습니다.


나는 현재 당신의 추천에 그것을 읽고 있습니다.
BeeBand

3

버그를 수정하는 속도는 무엇이며 팀의 버그 수정 속도는 얼마입니까? 더 중요한 것은 버그 수정 속도가 어떻게 측정되는지 물어보십시오 ...

이것은 일종의 메트릭이 아닙니다. 실제로 메트릭이 아닙니다. 만약 그렇다면, LOC보다 더 신뢰할 수 없을 것입니다 (다른 것들을 측정하더라도). 그리고 적절한 측정 없이는 당신을 비난 할 이유가 없습니다.


아마도 문제가 닫힌 시간 / 단위 로 측정됩니다 . "일부 버그는 다른 버그보다 시간이 오래 걸린다"고 말하는 것이 합리적이지만 OP가 코드의 특히 어려운 부분에서 작동하고 다른 사람이 쉬운 일을하지 않는 한, 아마도 물을 보유하지 않을 것입니다.
Caleb

3

고용주 및 / 또는 고객이 아닌 사람과 함께 일한다는 것을 인식하십시오. 인터뷰에서 주저하지 말고 처음부터 바로 기록을 세우십시오.

당신은 당신의 소기업, 즉 당신 자신에 많은 투자를 한 전문가입니다.

당신은 매일 랙 밖으로 당신을 추진하는 Union of Interests가있는 동안 기꺼이 일할 것입니다.

그 추진력이 오랫동안 존재하지 않으면 계속하십시오.

관심있는 직무 / 기술을 지속적으로 업데이트 / 할당하거나 과제를 수행하기가 어렵거나 흥미롭지 않은 부랑자 고용주에게 시간과 에너지를 낭비하고 있습니다. 바로 경영직입니다. 그 외에는 순수한 오버 헤드입니다 .....

그것이 열쇠이기 때문에 열정을 계속하십시오.


2

도움을 요청하는 것이 두렵기 때문에 비슷한 상황에 처해있었습니다. 이 의견에서 말한 내용으로 판단하면 ...

"하지만 실망스러운 점은 1 년 반 만에 찾은 후에 만 ​​알아 낸 특정 도구 / 팁 / 트릭이 있다는 것입니다. 나는 팀에서 팀으로 이동했습니다. 이러한 '숨겨진'도구는 너무나 자주 있습니다. "

... 내가했던 것과 같은 문제가 있었을 것입니다. 디버깅은 처음에는 많은 디버깅이 필요하지 않은 코드 작성과 같은 기술입니다. 디버그 문제를 통해 다른 개발자가 작업하는 것을 보는 것은 매우 교육적 일 수 있습니다. 무언가를 분류하는 데 문제가있을 때 도움을 요청하십시오. 특히 당신이 전에 없었던 땅을 덮고 있다면. 아무것도하지 않기 때문에 당황하기 전에 이상적으로 그렇게하십시오.

즉, 경영진이 잘못하고 있다는 의견에 동의합니다. 누군가가 무언가로 어려움을 겪고 있다면 부정적인 리뷰 재미가 시작되기 전에 도움을 받아야합니다. 지옥, 팀의 누군가가 어려움을 겪고 도움을 얻지 못하면 팀의 모든 구성원이 무언가 잘못하고 있다고 말할 것입니다.


2

OP에서 빠진 것은 버그를 해결하기 위해 수행되는 반복 가능한 프로세스 또는 방법에 대한 언급입니다.

따라서 먼저 따르는 프로세스를 문서화하십시오. 프로세스의 각 단계가 달성해야하는 것을 문서화하십시오.

다음과 같은 작업이있는 것으로 프로세스를 설명 할 수 있습니다.

  1. 보고되는 문제가 무엇인지 정확하게 이해해야합니다.
  2. 문제를 재현 해보십시오.
  3. 문제를 더 작은 조각으로 나누기 시작하십시오.
  4. 문제의 가능한 원인을 생각하십시오.
  5. 그 가설을 테스트

버그가 오랫동안 존재했는지 또는 최근 변경 사항이 도입되고 있는지를 아는 것이 도움이 될 것입니다. 코드 검토를 수행하거나 사람들이 생성 한 코드를 읽은 최근 변경 사항으로 버그가 발생한 경우 도움이 될 수 있습니다.

예를 들어 "버그를 해결하려고 할 때 테스트 할 가설을 생각하는 데 문제가 있습니다"와 같이 문제를 명확하게 정의 할 수 있다면보다 집중적 인 조언을 얻을 수 있다고 생각합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.