더 많은 돈을 위해 소프트웨어 개발 원칙을 어느 시점에 포기 하시겠습니까?

매체가 어디에 있는지 흥미롭게 보려고이 질문을 던지고 싶습니다.

지난 12 개월 동안 소프트웨어 개발에서 TDD와 많은 애자일 가치를 선택했습니다. 소프트웨어 개발이 훨씬 더 나아 져서 절대로 소프트웨어를 그만 두지 않을 것에 너무 압도되었습니다. 그때까지… 나는 계약직 역할을 맡아 올해의 집값을 두 배로 늘 렸습니다.

내가 참여한 회사는 특정한 방법론을 따르지 않았고, 팀은 코드 냄새, SOLID 등과 같은 것을 듣지 않았으며, 팀이 결코 실제로 단위 테스트를 보았습니다. 나는 매진입니까? 아니요, 완전히는 아닙니다 ... 코드는 항상 "깨끗한"(Bob 아저씨의 가르침에 따라) 작성 될 것이며 SOLID의 원칙은 항상 필요할 때 작성하는 코드에 적용될 것입니다. 그래도 테스트는 중단되었지만 회사는 솔직히 테스트 프레임 워크를 만들었더라도 테스트 프레임 워크를 올바르게 사용 / 유지 관리하지 않는 팀에게 알 수없는 힘을 줄 수 없었습니다.

예를 들어, 개발자가 개인적으로 돈 / 기타 혜택을 위해 장인 정신을 떨어 뜨리지 말아야 할 점은 무엇입니까? 본인은 이것이 자신의 요구, 비즈니스 요구 및 장인 정신에 얼마나 관심이 있는지에 대한 매우 개인적인 의견 일 수 있음을 이해합니다. 그러나 회사가 오히려 테스트 팀은 프로그래밍에서 단위 테스트를 이해하는 것보다 내가 한 것처럼 스스로 용서할 수있는 것입니까? 따라서, 당신이 떨어 뜨릴 무언가가 있다는 점을 감안할 때, 비즈니스에서 당신이 떨어 뜨린 것을 보상하는 균등 한 비용이 있어야합니다. 물론 커뮤니티 / 사회적 협력이 아닌 자신의 주머니를 안고있는 것이 아니라면; ).

돈을 두 배로 늘리고 RAD로 돌아 갑니까 아니면 계속해서 애자일을하는 사람을 찾으십시오.

10 년 전에 단위 테스트에 중독 된 이후, 대부분의 직장에서 이러한 사실을 처음으로 들었습니다. 그럼에도 불구하고 나는 가능할 때마다 작은 단위 테스트를 계속 작성하고 작업에 대한 단위 테스트 비용을 추정했습니다. 누군가 내 코딩 습관에 대해 물었을 때, 내가하고있는 일과 그것이 왜 효과가 있었는지 말해주었습니다. 보통 적어도 일부 사람들이 관심을 보였으며 결국 주제에 대한 프레젠테이션을하고 사람들에게 첫 단위 테스트를 작성하도록 멘토링했습니다.

새로운 직장에서 첫날 민첩한 방법에 대해 사람들을 설득 할 필요가 없습니다. 당신이 할 수있는 한 자신의 일에서 원칙을 따르십시오. 잘하면 더 나은 코드를 제공 할 수 있습니다. 동료 및 / 또는 경영진이이를 알아 차리면 어떻게하는지 물어볼 것입니다. 그럼 그들에게 말할 수 있습니다.

최신 정보

노련한 개발자 (및 관리자)의 대부분은 트렌드와 유행이왔다 갔다하므로 최신 유행어에 흥분하지 않습니다. 그러나 실제 프로젝트에서 특정 접근법 (공구, 사고 방식)이 실제로 실제로 작동한다는 것을 입증 할 수 있다면 공예에 관심이있는 사람들은 거의 항상 앉아서 듣고 있습니다. 그러나 팀에 그러한 사람들이 없다면 더 나은 곳을 찾을 때가되었을 것입니다 ...

모든 개발자들도 약간의 프로젝트 관리를 알아야한다고 생각합니다. 모든 것은 시간, 돈 및 자원 간의 상충 관계입니다. 자신을 자원이라고 생각하십시오.

12 년간의 프로그래밍 과정에서 프로젝트를 완성했다고 생각하지도 않았습니다. 내가 더 좋거나 더 깨끗하게 해 줄 수있는 일이 항상 있었다. 이것이 트레이드 오프 때문이라는 것을 깨닫는 데 오랜 시간이 걸렸습니다.

따라서 방법론이 없기 때문에 일자리를 바꾸는 것에 대해 생각하고 있다면 내가 당신이라면 다시 생각할 것입니다. 이러한 트레이드 오프는 일정하며 모든 소프트웨어 개발자에게 적용됩니다. 가장 헌신적 인 게임 개발자조차도 다시 할 수있는 일이 있거나 기회가 있다면 다른 방법론을 다시 연습 할 수 있기를 바랍니다.

민첩한 개발 관행을 살펴보고이를 마이크로 레벨에서도 수행 할 수 있음을 알고 싶습니다. 라라 랜드에서 팀원이 원하는대로 행동 할 수는 있지만 개인적 만족도는 더 높고 장기적으로는 더 나은 코드를 생성 할 것입니다. 그런 다음 관리자가 와서 왜 코드가 훨씬 더 좋은지 물으면 팀을 전환 할 수있는 기회가 있습니다. :)

그러나 사람들이나 직업이 마음에 들지 않으면 이미 답을 알고 있다고 생각합니다. 그러나 누군가가 방에 들어 와서 코딩하는 동안 민첩한 개발 원칙을 사용하지 말라고 ...

장기적으로 불행하게 만들 수있는 물건을 버리지 마십시오. 물론, 당신은 노 맨 랜드에서 시작하여 팀이 당신의 방향으로 움직 이도록 시도 할 수 있습니다. 노력을 기울이고 그만한 가치가 있다면, 이것은 흥미로운 도전 일 수도 있습니다.

그러나 코딩에서 즐거움을 유지하는 것 (또는 그 문제에 대한 직업)을 떠나야한다면, 내 경험은 조만간 나갈 것입니다. 나는 좌절감을 과소 평가해서는 안된다는 것을 배웠다 ...

마지막 직장 사람들은 이미 TDD, SOLID 등에 대해 알고있었습니다. 훌륭합니다. 나는 당신이 그곳에서 일하는 것을 즐겼고 많은 것을 배웠습니다. 이제 당신은 그 개념 을 가르 칠 수있는 기회가 있습니다 (동시에 큰 돈을 벌면서). 내 경험상, 다른 사람에게 개념을 가르쳐야한다는 것은 항상 더 자세히 배우는 데 도움이되었습니다. 그들에게 인내심을 갖고 한 번에 하나씩 개념을 계속 추진하십시오. 좌절하면 집에 가서 돈을 세십시오. 또는 SE에 대한 지원을 찾으십시오.

나는 그런 점에서 내가 아프다는 것을 인정해야한다. 프리랜서로서, 고객이 프로젝트에 적합한 방법론으로 간주하는 것은 무엇이든 괜찮습니다. 그렇다고 돈이 내가 신경 쓰는 유일한 것은 아니지만,해야 할 일과해야 할 일에 대한 결정은 고객에게 달려 있습니다. 그래도 나쁜 근무 조건 (크고 긴 시간 등)을 받아들이지 않을 것입니다.

전 동료를 인용하고 싶습니다. 그는 구직 또는 파트 타임 프로젝트를 찾을 때마다 프로젝트가 충족해야 할 세 가지 기준이 있다고 말했다.

• 함께 일하는 것은 재미 있어야합니다
• 역량 개발에 도움이되어야합니다 (구문을 표현하는 올바른 방법인지 확실하지 않음)
• 잘 지불해야합니다

귀하의 질문을 읽으 면서이 프로젝트는 마지막 기준 만 충족시킵니다.

당신이 TDD를 좋아하면서 (나처럼) 매일 당신이 돌아 다니고 모든 동료들이 당신과 같은 통찰력에 도달하기를 바랍니다. 따라서 첫 번째 기준을 충족하지 못할 수 있습니다.

둘째, TDD 프로젝트를 추구하고 민첩한 팀을 구축하는 데 더 많은 경험을 얻고 싶다면이 프로젝트를 수행하는 것이 그러한 기술을 강화하는 데 도움이되지 않습니다. 따라서 두 번째는 아마 충족되지 않을 것입니다.

개인적으로, 내가 당신의 입장에 있고 회사에 TDD를 소개 할 수있는 입장이 아니었다면 다른 곳을 볼 것입니다.

못.

인생은 당신이 미워할 일을하기에는 너무 짧습니다 (특히 나이가 들수록).

물론, 직업을 바꾸는 것이 더 어려워지고 직장이 적습니다.

그러나 적어도 레거시 코드 만 냄새가 좋지 않습니다. (그리고 나는 자율성을 가지고 있기 때문에 레거시 코드베이스에서 컴파일러 경고를 제거하는 데 일주일을 보내는 것과 같은 합리적인 일을 할 수 있습니다.

간단히 말해서 개발 방법론은 당신의 일부가 아닙니다. 그것은 종교가 아니며 당신이 누구도 아닙니다. 도구입니다. 들은 내용, 듣게되는 방식, 추가 비용을 지불하십시오. 수천 개의 시스템이 개발되어 오늘날 TDD, Code Smell 등없이 운영되고 있습니다. 몇 년 안에 도시 버스보다 방법론이 더 자주 등장하기 때문에 이러한 용어의 의미를 아는 사람은 아무도 없을 것입니다. 당신이 말한대로 열심히 일하고 언제든지 감사합니다. :)

새로운 팀과 함께 일하는 것이 시간에 대한 좋은 투자인지 확인하십시오.

아마도 그들은 지금까지 경험했던 것보다 더 효율적인 방식으로 작동합니까? 그렇게한다면 그들과 함께 일하는 것이 당신에게 훌륭한 학습 경험이 될 것입니다 (따라서 좋은 투자).

다른 한편으로, 새로운 팀의 방법론은 당신에게 거의 가치가 없을 수 있습니다 (너무 많은 "카우보이 코딩"등). 이 경우 추가 자금은 가치가 없을 것입니다 (IPO 사전 시작 또는 특별한 것이 아닌 한). 당신은 아마 많이 배우지 않을 것입니다 ... 당신은 화상의 위험이 있습니다.

나는 내가 원하는 방식으로 일할 수없는 곳에서 일하지 않을 것입니다. 즉, 나는 마이크로 관리되고 싶지 않다는 것을 의미합니다.

나는 내가하는 일에 능숙하다는 가정하에 일하고 있으며, 당신이 나에게 몇 가지 과제를 주면 효율적이고 효과적으로 수행 할 수 있습니다. 코드 지침과 패턴을 위반하지 않으면 구현 방법은 전적으로 본인에게 달려 있습니다. 그것은 내 직업의 재미있는 부분입니다.

내가 작성한 모든 수업을 단위 테스트하고 싶다면 문제가 될 수 있지만 단위 테스트를 작성하는 것은 일반적으로 마감일을 준수하는 한 괜찮습니다. TDD 지지자는 단위 테스트 작성이 실제로 생산성 (나중에 등)을 증가 시킨다고 주장 할 것으로 기대합니다. 나는 신발에 있다면, 나는 쓸 것 일부 나에게 절약 할 수 단위 테스트 몇 가지 트랙 (아마도 덜 버그, 쉽게 수정) 아래로 시간을. 더 많은 테스트에 절약 된 시간을 다시 투자하면 더 많은 시간을 절약 할 수 있고, 멋진 테스트를받을 때 큰 웃음으로 앉아 새로운 11 시간이되면 코드 변경 사항을 쉽게 확인할 수 있습니다 요구 사항이 들어옵니다.

그렇게 할 수 없다면 거기서 일하고 싶은지 모르겠습니다.

내가 말하는 것은이 문제를주고 받아야한다고 생각합니다. 그들이 나에게 더 많은 돈을 지불할수록, 내가 기대하는 비화 폐적 미덕은 줄어 듭니다. 그러나 특히 거부 할 필요가없는 경우에는 항상 자율성과 자존심이 필요합니다. 자율권이있는 한 다른 원칙은 버리겠습니다. 결국, 거꾸로 미친 방법론처럼 보이는 것이 당신이 한 최고의 일이 될 것입니다!