"가장 낮은 개발자"로서 기술 부채와 싸우고 있습니까?

회사에서 일하고 있으며 회사를 위해 소프트웨어를 개발한다고 가정 해 봅시다. 당신은 큰 그림이나 어쩌면 약간의 생각이 없습니다. 당신이 가진 것은 이슈 트래킹 시스템을 통해 당신에게 할당 된 작업입니다. 작업이 주어지고 작업을 설명하는 방식으로 작동하게하고 다시 보냅니다. 2 개의 정수를 추가하는 것과 같이 :

function add(a,b){return a + b;}

그러나 나중에 프로젝트가 진행됨에 add따라 매개 변수를 추가하고 값을 반환하는 함수 이상의 아키텍처 형식이 필요하다는 것을 알았습니다. 그러나 당신은 그것을 몰랐습니다. 우선, 그들이 필요한 것은 간단했습니다 add. 추가가 그렇게 복잡해질 것으로 기대하지 않았습니다.

프로젝트는 처음에는 기대하지 않았던 더 많은 기능으로 진행됩니다. 그리고 결국 기존 코드를 깨거나 다시 쓰지 않도록 함수 계층에 해킹과 계층을 계속 쌓습니다.

이러한 상황을 어떻게 처리합니까? "최저 개발자"로서 기술 부채와 어떻게 싸우십니까?

설명:

• 계층 구조에서 가장 낮은 "구현 자"입니다.

• 당신은 문제를 보지만 그 문제에 대해 아무 말도하지 않습니다.

• 기술 부채를 수량화하거나 도구를 찾고 있지 않습니다.

• 에 관한 세 번째 "중복"

  • 리팩토링 및 재 작성-작업에 잠겨 있습니다. 추가 비용을 지불하지 않았습니다.
  • 아키텍처 개요-전체 시스템은 알고 있지만 아키텍처는 모릅니다.
  • 코드 동결-당신의 전화가 아닙니다. 당신은 관리가 아닙니다.
  • 모듈화-아키텍처에 대한 아이디어가 없습니다. 요구 사항이 변경되면 모듈이 변경됩니다.
  • 자동 테스트-존재하지 않습니다.

그런 것을 발견 할 때마다 문제 추적 시스템에 새 티켓을 입력하십시오.

문제 추적기를 주요 도구 로 사용하는 습관을들이십시오. 거기 에서 문제 를 추적하는 책임이있는 선임 동료 / 지도자 / 관리자 / 누군가가 쉽게 선택하고 평가하고 우선 순위를 정할 수 있기 때문입니다. 프로젝트 .

작업에 적합한 도구를 사용하십시오. 나는 항상 그것을하고 당신이 똑같이 하는 것이 좋습니다.

예를 들어, 약 한 달 전에 만든 티켓이 있습니다. 특정 기능이 완료되면 코드가 이전보다 훨씬 더 복잡해졌지만 기능 구현을 위해 기한 내에 수정할 수는 없습니다.

(실제 트래커에 사용 된 기능, 티켓 및 코드 이름은 가려 지지만 텍스트는 그대로 복사됩니다).

요약 : 설계를 포함한 단순화ParticularPieceOfCode

설명 :
TICKET-12345에 따라 구현 과정에서 ParticularPieceOfCode발생 하는 사용과 관련된 코드 가 약간 복잡 해져서 읽고 이해하고 유지하기 가 다소 어려워졌습니다. (아래의 코드 스 니펫 예제 참조).

단순화하는 방법을 찾으십시오.

재 설계에 바람직한 코드의 예는 다음에서 찾을 수 있습니다 ClassName#methodName.

<a piece of code like one behind the right door here:>

FWIW 나의 조언은 당신이 어떤 "레벨"인지에 관계없이 적용됩니다.

나는 당신의 현재 ( "가장 낮은") 수준에서 그것을 사용하고 있으며 지금은 나의 수준이 "가장 낮은"것과는 거리가 멀고 그것을 사용할 때 만족스러운 "말하기"를 가지고 그것을 사용하고 있습니다. 항상 어쨌든.

아무리 많은 권한이 있더라도 아무리 레벨도 생각하지 말고 더 좋은 방법은 없습니다.

당신이 " 이봐 " 우리 문제 가 있다면, 그것은 단지 공기 방울뱀입니다. 그리고 당신의 상사 / 지도자가 동의하고 당신이 옳다고 말하더라도 , 우리는 문제가 있습니다 . 이것은 아무것도 바뀌지 않습니다.

• ^{당신의 말을 이메일로 작성하는 것이 더 좋을 것이라고 생각할 수도 있지만, 생각한다면 실제로는 그렇지 않습니다. 프로젝트에 상당한 양의 메일 활동이있는 경우 한 달 후에 작성된 내용이 손실되고 오랫동안 잊혀 질 것입니다.}

작업에 적합한 도구를 사용하십시오. 설명하는 작업의 경우 이슈 트래커 가 바로 올바른 도구입니다.

당신은 문제를 발견하고, 당신은 이것을 추적하기 위해 설계된 시스템에 그것을 입력하고 가장 좋은 방법으로 나머지 를 처리합니다 .

보고 된 고객 문제를 생성, 업데이트 및 해결하기 위해 또는 조직의 다른 직원이보고 한 문제까지 조직에서 필요에 따라 문제 목록을 관리하고 유지 관리하는 컴퓨터 소프트웨어 패키지 ... 시스템은 " 버그 트래커 " 와 유사 하며 종종 소프트웨어 회사가 둘 다 판매하며 일부 버그 트래커는 문제 추적 시스템으로 사용될 수 있으며 그 반대도 마찬가지입니다. 문제 또는 버그 추적 시스템의 일관된 사용은 "좋은 소프트웨어 팀의 특징"중 하나로 간주됩니다 ¹ ...

다른 어떤 수단을 사용하든 통신하고자하는 것을 선택하면, 추적기에 티켓이 있으면 더 쉬워집니다.

"TICKET-54321에 대해 토론하고 싶습니다 ..."라고 말하면서 공기 를 덜 ttle 거리는 것을 선호하더라도 "내가 처리 한 코드에 대해 이야기하고 싶습니다." ... "그리고 우편으로 티켓에 대한 참조를 안전하게 전달할 수 있습니다. 우편물을 잃어버린 경우에도 트래커에 문제가 있습니다.

시나리오에 대해 기분이 좋지 않은 것은 제목에 몇 번이고 질문 텍스트에 여러 번 쓴 것입니다.

당신은 체인에서 가장 낮은 개발자입니다

그 점이 왜 그렇게 중요한가요? 글쎄, 우선, 그리고 순수한 기술적 인 관점에서, 당신은 확실히 옳습니다. 당신은 당신이 "구현 자"라고 부르는 것으로, 주어진 명령에 따라 행동하는 일벌입니다.

그러나 순위와 관련하여 개발자가 가장 적더라도 여전히 옳지 않습니다. 열쇠는 여기에만 것을 실현하는 것입니다 지각 가장 낮은 개발자로서 자신을. 그 자아 인식을 극복하고 실제로 무언가에 대한 책임을 맡으 려고 노력한 적이 있습니까?

갖다! 누군가가 당신을 책임질 때까지 기다리지 마십시오.

• 당신은 문제를 보지만 그 문제에 대해 아무 말도하지 않습니다.
• 기술 부채를 수량화하거나 도구를 찾고 있지 않습니다.
• 당신은 당신의 작업에 잠겨 있습니다. 추가 비용을 지불하지 않았습니다.
• 당신의 전화가 아닙니다. 당신은 관리가 아닙니다.

일반적으로는 정반대입니다 : 당신은 더 지불하고 당신이 돈을 가치가있는 것을 보여 일단 당신의 의견은 더 존경 . "반드시해야 할 일"이지만 다른 방향은 아닙니다.

우리 팀원들에게 기대하는 바는 다음과 같습니다. 우리가 만들려고하는 프로젝트 나 제품 및 그 노력과 관련된 모든 프로세스에 대한 책임감. 팀원 중 누군가가 개선을 제안하거나 스스로 개선을 시작하는 등의 책임을 맡음으로써 저에게 깊은 인상을 줄 때마다 이들은 승진 할 사람들입니다.

다른 방법으로 말하면 : 아무도 노동자 벌을 승진 시키지 않습니다. 사람들은 수동으로 자신이 할당 된 작업을 수동으로 기다리고 있습니다. 마지막으로 기회가 없었 음을 고집합니다.

물론,이 모든 것은 당신의 회사 문화, Joel이 Arthur가 연결 한 "Two Stories"에서 무엇과 관련이 있는지에 달려 있습니다. 회사 관리자가 자신의 직원이 진전을 막는 것을 정말 바보로 생각하는 경우 변동 비율이 이미 매우 높을 수 있으며 그로부터 결론을 도출해야 할 때입니다. 그러나 그렇지 않은 경우 실제 문제는 자신의 문제 일 수 있습니다.

당신은 전문가입니다. 고용주가 당신을 직업으로 고용했습니다. 따라서, 귀하의 우려는 전문가 싶어 같은 방법으로 치료 하면 치료하기 위해 고용 자신의 전문 의견을 . 특히, 이러한 최적화로 인해 예상치 못한 비용이 발생하지 않으면 다른 전문가가 필요한 최적화 및 수정 작업을 수행 할 수 있습니다.

예를 들어, 자동차를 정비사에게 가져 가서 램프를 교체한다고 가정 해보십시오. 정비공은 다음 네 가지를 주목합니다.

1. 램프로 이어지는 전선이 마모되어 위험합니다. 그러나 눈에 띄게 비용을 늘리지 않고도 다듬을 수 있습니다. 와이어를 자르려면 몇 분이 걸릴 것으로 예상됩니다.
2. 볼트가 느슨합니다. 그것은 전혀 관련이 없습니다. 그는 단지 그것을 보았습니다. 필요한 드라이버를 잡고 조이는 시간은 20 초입니다. 그래서, 당신은 그를 할 것으로 기대합니다.
3. 램프의 섀시가 깨져 램프가 덜 ttle 거립니다. 교체 비용이 많이 듭니다. 그리고 필수는 아닙니다. 그래서, 그는 당신에게 전화를 걸어 전화를합니다 – 당신이 "아니오"라고 말하면, 방문 요약에 서면으로 추천서를 작성 합니다.
4. 차 아래에 상당한 양의 브레이크 오일이 있습니다. 누군가 누수를 해결할 때까지 자동차를 사용 하지 못하도록 전문가가 필요할 수도 있습니다 .

이러한 시나리오와 다른 시나리오는 소프트웨어 개발과 유사합니다. 특히 자신 을 모든 수준 의 전문가 로 생각할 경우 더욱 그렇습니다 . 전문가는 예외가 거의 없지만 전문가의 이해에 따라 특정 방식으로 제품을 개선하려는 최종 목표를 달성하는 것 입니다.

1. 관련이 없는지 여부에 관계없이 수정 사항이 사소한 경우 수정하십시오.
2. 수정이 사소하지 않고 불필요하다면 동의 한 공식 커뮤니케이션 / 문제 추적 메커니즘을 사용하여 공식적인 권장 사항을 작성하십시오.
3. 기본 작업을 수행하기 위해 수정이 필요하지만 예기치 않게 비용이 증가 할 경우 범위 변경을 알리십시오.
4. 확인 된 문제가 프로젝트 성공에 심각한 위협이되는 경우이를 분명히하십시오. 공식적으로. 문제를 해결하기 위해 윤리적 문제가있는 경우 (예 : 건강, 응급 또는 운송 시스템과 같이) 제품을 배송하기 전에 문제를 해결해야합니다 (윤리적으로 필요한 경우 미디어 또는 당국에 알립니다).

법률 사무소 직원이 비 윤리적 행동과 싸우거나 패스트 푸드 노동자가 비위생적 행동과 싸우거나 주차 집행관이 경찰 부패와 싸우는 것과 같은 방식으로이 작업을 수행합니다.

1. 좋은 모범이 되십시오. 가능한 한 깨끗하고 합리적인 코드를 생성하십시오. 선택권이 주어지면, 단점이 적은 요구 사항을 충족시키는 것을 선택하십시오. (기술 부채는 모기지 부채와 다르지 않다는 것만으로도 반드시 나쁜 것은 아닙니다.)
2. 우려 사항을 전달하십시오 . 기술 부채 관리 및 기업 자원 할당에 대한 실제 책임이있는 사람, 팀장 또는 고객 또는 건축가가 있어야합니다. 자신이 나쁜 것으로 생각되는 것을 발견하면 그들에게 걱정을 전하십시오. 그들이 귀하의 의견을 이해하고, 응답하고, 신용을 줄 것이라고 확신하지 못하는 경우, 서면 (예 : 이메일)으로 작성하십시오.
3. 스트레스를주지 마십시오. 기술 부채는 기업의 고용 종료 실패를 거의 일으키지 않습니다. 우려 사항을 전하고 업무를 수행하는 한 기술 부채와 같은 중대한 문제는 문자 그대로 문제가 아닙니다. 예, 그들은 당신에게 영향을 미칠 수 있지만 보안관의 재선은 주니어 경찰관의 걱정보다 더 이상 당신의 걱정이 아닙니다.

제공 한 예제에서 add완전한 기능이 약화 된 기능으로 몇 분이 걸리고 개선 할 사항의 개요를 작성하십시오. 이를 구현하려면 승인이 필요한 사람에게 보내십시오.

귀하의 기업이 매우 유능한 직원에 의해 관리되고 올바르게 구조화되었다고 가정하면, 귀하의 우려가 결정을 위해 올바른 시스템 설계자에게 전달되거나 귀하의 제안을 이행 할 여지가 생길 것입니다. 주니어 개발자 인 저는 기술 부채보다 기업의 운영 방식을 배우는 것에 대해 더 걱정할 것입니다. 전자 부채를 알고 있다면 후자를 처리하는 방법이 분명해야합니다.

직원이 참여하기를 원하지 않는 조직에 대해 들어 본 적이 없습니다. 당신은 당신이 그 일을하기 위해서만 돈을받는다고 말합니다. 나는 당신이 올바른 과제를 염두에두고 진심으로 의심합니다. 좋은 소프트웨어를 작성하기 위해 돈을 지불하기 때문입니다.

이 책임을 져야합니다. 베이스를 지원할 수없는 경우 기능 추가를 거부하십시오. 전문 지식을 갖춘 고객에게 조언하십시오. 너무 늦기 전에 브레이크를 밟으십시오. 더 이상 유지 보수 할 수 없기 때문에 전체 프로젝트를 버려야합니다.