저는 대학에서 새로 온 비교적 새로운 개발자입니다. 대학에서 그리고 구직 활동을하는 동안, 저의 교육에는 부족한 "현대"소프트웨어 개발 방법론이 많이 있음을 깨달았습니다 : 단위 테스팅, 로깅, 데이터베이스 정규화, 민첩한 개발 (일반 민첩성 개념), 코딩 스타일 가이드, 리팩토링, 코드 검토, 표준화 된 문서화 방법 (또는 요구 사항) 등

전반적으로, 나는 이것이 문제라는 것을 보지 못했습니다. 나는 나의 첫 직업이이 모든 아이디어를 받아들이고 그 직업에 대해 나에게 가르쳐 줄 것을 기대했다. 그런 다음 대기업에서 첫 번째 직업 (풀 스택 웹 개발)을 얻었 으며 이러한 일을 전혀 하지 않는다는 것을 깨달았습니다 . 사실, 팀에서 가장 경험이 적은 저의 팀은 "현대적인"프로그래밍 기술을 사용하여 팀의 속도를 높이려고 노력하고 있습니다.

먼저 로깅 소프트웨어 (log4J)로 시작했지만 빠르게 내 자체 스타일 가이드를 작성하고 Google 스타일 가이드를 위해이를 포기했습니다. 그런 다음 Java 웹 개발에서 직접 작성된 전면 컨트롤러를 사용한다는 사실을 깨달았습니다. Spring의 채택-그러나 우리는 단위 테스트가 없다는 것을 깨달았지만 이미 Spring을 배우고 있습니다 ... 보시다시피, 특히 정상적인 개발 작업과 짝을 이룰 때 너무 빨리 압도적입니다. 더욱이,이 방법론에서 그들 중 한 사람에게 너무 많은 시간을 할애하지 않고 다른 사람을 가르치기에는 "전문가"가되기가 어렵습니다.

오늘날의 소프트웨어 개발 세계에서 "예상 된"것으로 여겨지는이 모든 기술 중에서 어떻게 자신과 팀을 압도하지 않고 새로운 플레이어로서 팀에 통합 할 수 있습니까?

팀에보다 민첩 해지려면 어떻게해야합니까? 관련이 있지만 여기에 asker와 같은 Agile 개발자가 아니며 Agile보다 훨씬 광범위한 방법론을 찾고 있습니다.

말보다 카트를 꽂는 것처럼 들립니다.

팀이 직면 한 주요 문제는 무엇이고 어떤 기술이 문제를 해결하는 데 도움이됩니까?

예를 들어, 특히 많은 회귀 형 버그가있는 경우 단위 테스트가 시작점이 될 수 있습니다. 팀에 시간이 부족한 경우 프레임 워크가 도움이 될 수 있습니다 (중장기). 사람들이 서로의 코드를 읽는 데 어려움이 있다면 스타일링이 유용 할 수 있습니다.

사업의 목적은 코드를 만드는 것이 아니라 돈을 버는 것입니다.

자바? 현대?! 첫 번째 장애물에서 실패했습니다. 당신이 진정 현대적이고 "전문적인 자살"을 피하고 싶다면 Rust 코드를 작성해야합니다. 물론 다음 주에는 모든 것이 바뀌고 계속 유지하려면 더 새로운 것을 배워야합니다!

또는, 화두 기술이나 방법 또는 프레임 워크 또는 기타 아무리 받아 들일 수 금일은 사용자의 작업 품질의 제품을 구축하려는 사실을 변경하지 않습니다. 올바른 출력을 성공적으로 생성하는 경우 민첩성을 사용하지 않더라도 중요하지 않습니다. 물론, 그렇지 않다면, 당신은 상황을 바꾸고 싶을 수도 있지만 특별한 연습이 문제를 해결하지는 않을 것입니다. 그들은 다양한 방법으로 고칠 수있는 인간의 문제로 남아있을 것 입니다.

직업적인 자살에 관해서는, 당신이하고있는 일을 알고 융통성이 있다면 언급 한 것이 필요하지 않습니다. 사람들은 이전 작업을 수행하는 새로운 방법을 계속해서 제시 할 것이며 항상 따라 잡을 것입니다. 또는 현재 회사가 사용하는 기술에 관계없이 간단히 사용할 수 있습니다. 회사를 바꿀 때는 단순히 그들이 사용하는 기술을 배우고 사용합니다.

너무 많은 아이들이 그들이 사용할 수있는 모든 새로운 도구에 매달리며,이 도구는 초보자에게 무가치하다는 것을 잊어 버립니다. 실습을 먼저 배우십시오. 숙련 된 개발자가되면 "멋진 새로운 것"으로 개발 실무를 "수정"할 수 있지만, 그때까지는 현재 생각만큼 중요하지 않다는 것을 알게 될 것입니다. 실제로 필요할 때만 사용하십시오.

많은 회사들이 이렇게 붙어 있습니다. 개발자 동료 중 일부는 자율 교육을 받았으며 공식적인 배경 지식이없는 개발자가되었다는 사실에 놀랄 수도 있습니다. 이 개발자들은 새로운 기술을 배우고 단순히 일을하는 대신 성공하도록 유도하는 사람들이되기 때문에 종종 자신의 업무에 더 능숙합니다. 불행히도 이것은 프로그래밍에 능숙하지만 이러한 관행의 이점을 알지 못할 수도 있습니다. 사실은 이러한이입니다 최고의 관행이 아닌 일반적인 관행. 최고의 그들은 단순히 쉽게 성공을 돕는 도구, 그것들을 사용하지만, 그들은 성공하기 위해 모든 요구 사항에 없습니다.

당신은 절대적으로 맞습니다. 모든 것을 한 번에 구현하려고 시도하는 것은 압도적입니다. 새로운 방법론 / 기술을 채택하려는 미래의 추진력을 자극 할 것입니다. 이런 상황에서 가장 좋은 것은 하나를 선택하는 것입니다(로깅은 버그없이 버그를 발견하기에 앞서 어려운 길을 가졌고 버그가있을 것이므로) 로깅은 좋은 시작일 것입니다. 이것을 직접 구현할 필요는 없습니다. 팀과 장단점에 대해 더 잘 논의하고 (이와 같은 일에 절대적으로 참여 해야하는 상사) 구현 계획을 세우는 것이 좋습니다. 가능한 한 고통스럽지 않아야합니다 (이제 사람들에게 이미 수행 한 작업 외에도 추가 코드 를 작성해야한다고 말하고 있음을 기억하십시오 ).

그리고 나를 다시 가정 해 봅시다 당신의 상사에서 구입해야합니다 . 이것은 매우 중요합니다. 새로운 기능을 구현할 때 수정 / 릴리스 속도가 느려질 수 있습니다. 요점은 선을 절약하기 위해 선불로 지불한다는 것입니다. 그들은 반드시 이것을 이해하고 당신 편이되어야합니다. 당신이 그들을 보드에 넣지 않으면, 당신은지는 전투에서 최선을 다하고 있습니다.

이러한 항목을 테이블로 가져 오면 팀과 논의하고 구현 방법을 계획 한 후 후속 조치를 수행하면 두 번째, 세 번째, 여덟 번째 등이 더 쉬워집니다. 뿐만 아니라 제안 사항이 구현되고 부가 가치로 인식 될 때 팀과 상사가 귀하를 존중할 가능성이 있습니다. 큰! 유연성을 유지하십시오. 여기에서 관성을 향하고 있으며 변경이 쉽지 않습니다. 천천히 작게 만들 준비를하다변경 사항을 확인하고 진행률과 가치를 추적 할 수 있는지 확인하십시오. 새로운 프로세스에서 로깅을 구현하고 3 주 만에 버그를 찾는 데 시간을 절약 할 수 있다면 큰 문제를 해결하십시오! 회사가 올바른 일을 미리 수행하여 방금 $ XXX를 절약했다는 사실을 모든 사람에게 알리십시오. 반면에 푸시 백을 받거나 마감 기한이 촉박 한 경우 문제를 강요하지 마십시오. 새로운 변화가 잠시 멈추고 다시 원을 그리십시오. 팀이 원하지 않는 일을하도록 강요해도 결코 이길 수 없으며, 가장 먼저 떨어 뜨릴 것을 제안하는 것은 새로운 '추가'작업 (기록 작성 또는 다음과 같은)입니다. '작동시키는 것'대신 스타일 가이드).

귀하의 게시물에서 우리에게 한 것처럼 동료에게 문제를 제시하지 않았기를 바랍니다. 그것은 전문적인 자살 일 것입니다.

첫 번째 문제는 약간의 구식일지도 모르지만 직업을 "완료"시키는 프로그래머 그룹에게 경험이없는 기술과 방법을 가르치려고한다는 것입니다. 그 역풍의 가능성은 끝이 없으며 아마도 동료들에게 많은 기쁨을 가져다 줄 것입니다. 자신과 부서를 향상시키고 싶지만 "선봉"과 같은 용어를 사용하지 않는 것이 흥미롭고 훌륭합니다. 진심으로, 그 단어를 사용하지 마십시오.

위의 부수적 인 문제로, 작업을 수행하고 있는지 확인하십시오 . 저는 고독한자가 학습 프로그래머로 오랫동안 일해 왔으며 유망한 프레임 워크, 기술 등을 탐색하기 위해 실제 작업을 따로 정리하는 것이 얼마나 쉬운 지 알고 있습니다. 성능이 예상되는 매개 변수 내에 있는지 확인하십시오 (아무도 해당 보고서가 요청하지 않은 경우 Spring을 조사하는 데 20 시간을 소비하는 사람은 없습니다).

위의 모든 것에서 교사가되는 것을 피하십시오 (실제로 충분한 경험이있는 현장 / 기술과 관련이없는 한). 보다 중립적 인 표현은 자동화 된 테스트의 장점을 지적하고 경영진이 그러한 관행의 장단점을 연구 할 대상을 선택하게하는 것입니다.

이제 이러한 "모범 사례"를 제시하기 위해 두 가지 방법으로 팀에 설명 할 수 있습니다.

• 그들이 모범 사례라고 말하면 충분합니다.
• 유용하고 문제 해결에 도움이되기 때문입니다.

첫 번째 주장을 사용하면, 당신이 상사 나 팀의 고위 구성원이 아닌 한, 그들이 당신에게주의를 기울이지 않을 것입니다. "Knuth에서 저술 한 책을 읽었습니다."또는 "SE의 사람들은 그렇게 말하지도 않습니다"라는 인상을주지 않을 것입니다. "). 그들은 그들의 방법, 루틴, 절차 및 "더 많거나 적은"일을 가지고 있는데 왜 변화의 노력과 위험을 감수해야합니까?

두 번째 접근 방식이 작동하려면 문제가 있음을 인식 해야 합니다 . 그래서:

• 자동 테스트를 위해 밤낮으로 밀지 마십시오. 업데이트로 인해 일부 기능이 중단 될 때까지 기다렸다가 팀에서 초과 근무를하여 수정 한 다음 자동화 된 테스트 시스템을 구축하도록 제안해야합니다.
• 코드 검토를 요청하지 마십시오. Joe가 장기 휴직 할 때까지 기다렸다가 Joe 만 알고있는 해당 모듈을 변경해야 할 필요가 있으며 Joe의 코드를 이해하기 위해 시간을 얼마나 잃어 버렸는지 상사에게 지시하십시오.

물론, 변화는 느리고 점진적으로 진행될 것입니다 (대기업에서는 더 그렇습니다). 5 년 내에 코드 검토 및 자동화 된 테스트를 도입 할 경우 잘 수행 한 작업에 대해 스스로 축하해야합니다. 완전히 재 작성이 외부 요인에 존재하지 않는 그러나, 그들은 (말하자면, 봄에 핵심이 전환됩니다 어떤 환상에 대해 잊지 당신이 태어나 기 전에도 조엘은 내가 수보다 그런 식으로 더 나은 설명 ¹ ); 그 당시에는 지원되지 않는 플랫폼 목록에서 Spring을 사용하여 중요하지 않은 시스템을 작성할 수 있습니다.

엔터프라이즈 IT의 세계에 오신 것을 환영합니다. :-피

¹ : 좋아, 어쩌면 조금만 확장되고 있지만 너무 많지는 않습니다.

Michael Feathers의 레거시 코드 로 효과적으로 작업하기 책을 시작해야합니다 . 이 책의 소개에서 "그것은 얽힌, 불투명하고 복잡한 시스템을 천천히, 점진적으로 한 단계 씩 가져 와서 간단하고 훌륭하게 구조화되고 잘 설계된 시스템으로 만드는 것입니다." 그는 대부분 자동화 된 테스트로 시작하여 안전하게 리팩토링 할 수 있으며 (아무것도 깨면 알게 됨) 자동화 된 테스트에서 어려운 코드를 가져 오는 많은 전략을 포함합니다. 이것은 아직 개발중인 모든 프로젝트에 유용합니다. 기본적인 순서가 정해지면 프로젝트에서 실제로 얻을 수있는 다른 최신 기술을 확인할 수 있지만 모든 기술이 필요하다고 가정하지는 마십시오.

현재 프로젝트에 실제로 필요한 것이 아니라 전문적인 이유로 새로운 프레임 워크 (또는 무언가)를 배우려면 개인 프로젝트 (자신의 시간에)에서 사용해야합니다.

소스 컨트롤.

이미 언급 되었기 때문에 언급하지 않았지만 그렇지 않은 경우에는 시작하십시오.

병리학 적으로 다른 것을 필요로하는 드문 상황을 제외하고, 소스 제어는 가장 큰 뱅 뱅크입니다.

처음에 아무도 사지 않으면 혼자 시작할 수 있습니다.

직접 답변

다른 답변은 더 나은 사례를 채택하는 것에 대한 좋은 '메타 포인트'를 만들지 만 직접 관련 지침을 제공하기 위해 팀 (또는 모든 팀)이 채택 할 것을 제안 하는 모범 사례 의 대략적인 순서는 다음과 같습니다.

1. 소스 컨트롤
2. 이슈 트래킹 (프로젝트 및 작업 관리)
3. 자동화 된 빌드 ¹
4. 자동화 된 배포

^{1 _{매우 관련성이 높은 관행은 개발하거나 유지 관리중인 각 앱 또는 소프트웨어 프로젝트의 빌드 및 개발 환경 을 자동화하거나 문서화 하는 것입니다. 당신이 (희망적으로) 이것을 드물게 또는 거의하지 않기 때문에 훨씬 유용하지 않습니다.}}

그 밖의 모든 것

"단위 테스트, 로깅, 데이터베이스 정규화, ... 리팩토링, ... 문서"와 같은 몇 가지 다른 모범 사례를 언급했지만 점진적이고 점진적으로 채택 해야하는 모든 사례입니다 . 그들 중 누구도 한 번에 모두 채택 할 필요가 없습니다 당신은 아마 더 잘 채택하는 것 모두 신중하고주의 깊게을 채택하여.

위에 열거 한 네 가지 방법을 통해 새로운 방법을 최대한 쉽게 채택하고 실험 할 수 있습니다. 예를 들어, 단위 테스트를 자동화 된 빌드에 통합하고 자동화 된 배포의 일부로 문서를 게시 할 수 있습니다.

"애자일 개발, 코딩 스타일 가이드, ... 코드 리뷰, ... 표준화 된 문서화 방법"및 프레임 워크 (예 : 스프링) 등 언급 한 다른 방법 중 일부는 실제로 선택 사항이거나 모호한 가치가 있습니다. 그리고 그것은 당신이 발견하거나 접하게 될 많은 (가장?) 가능한 관행에 해당됩니다.

민첩한 개발은하지 분명히 사용하는 다른 방법보다 우수. 그리고 나 자신을 포함한 많은 사람들이 그것에 대해 끔찍한 경험을했습니다. 그러나 많은 사람들이 정말로 그것을 좋아하거나 좋아합니다. 시도 해봐!

코딩 스타일 가이드는 특히 대규모 프로젝트 나 대규모 팀에 도움이 될 수 있지만 이러한 가이드 라인 을 시행 하는 데 많은 작업이 필요하며이를 수행 하는 시간을 최대한 활용하지 못할 수도 있습니다.

코드 검토도 매우 유용 할 수 있습니다. 동료에게 코드를 검토하도록 요청 했습니까? 모범 사례를 채택하기 위해 공식적인 프로세스가 필요하지 않습니다.

문서는 훌륭합니다 – 전혀 없습니까? 그렇다면, 당신에게 좋습니다! "표준화 된"문서를 보유함으로써 예방할 수있는 많은 추가 작업에 직면하고 있습니까? 당신이 그렇다면, 아마도 그럴만 한 가치가 있습니다. 그러나 소그룹의 사용자가 소프트웨어를 사용하는 경우 문서 가 필요 하지 않을 수 있습니다. (또는 문서를 소프트웨어에 직접 통합 할 수도 있습니다. 항상 선호합니다.)

프레임 워크는 ... (매우 날카로운) 양날의 칼입니다. 소프트웨어의 핵심이 아닌 기능을위한 잘 캡슐화되고 잘 관리 된 솔루션은 훌륭합니다. "손으로 쓴 프론트 컨트롤러"가 정확히 무엇인지 잘 모르겠지만 왜 스프링을 활용하는 코드보다 열등한 지에 대한 명확한 설명은 없습니다 . 이러한 모든 컨트롤러의 공통 로직을 자체 사내 프레임 워크로 캡슐화하는 것을 고려 했습니까? Spring을 채택하고 모든 기존 코드를 다시 작성하는 것은 엄청난 리팩토링 (또는 재 작성) 프로젝트 일 수 있으며 코드를 변경하는 최선의 변경이 아닐 수 있습니다 . 물론 사용하는 모든 소프트웨어를 작성해서는 안됩니다. 프레임 워크 (및 라이브러리)가 훌륭합니다!그러나 훌륭한 웹 응용 프로그램을 작성하기 위해 Spring (또는 대안)을 사용할 필요는 없습니다.

당신이 속한 팀을 둘러보십시오. 테스트 중심 개발 또는 데이터베이스 표준화로 작성중인 소프트웨어의 품질이 향상되거나 사람들의 생산성이 높아진다는 증거가 있습니까?

개발 관리자 중 한 명이나 개발 책임자에게 이야기를 해 보셨습니까? 정말 비공식적 인 대화는 좋은 출발이 될 것입니다. 위의 사람들이 같은 아이디어를 가지고 있지 않지만 비즈니스에서 허용하지 않기 때문에 구현할 수 없거나 구현할 수 없다고 생각하는 이유는 무엇입니까?

모범으로 인도하는 것이 좋은 방법이라는 것을 알았습니다. 다른 사람이 이미 작업을 수행했으며 복제 방법을 보여줄 수 있다면 사람들은 훨씬 저항력이 떨어집니다. 작업중인 프로젝트에 TDD를 소개하십시오. 나머지 팀 또는 다른 사람들에게 프리젠 테이션을하고 자신이 한 일을 보여줄 것을 요청하십시오. @DrewJordan이 보스로부터 구매하는 것에 대해 말한 것은 아마도 당신이 생각하는 것보다 중요합니다.

결함을 찾으십시오. 결함을 수정하십시오. 수정 사항을 표시하십시오.

먼저 정규화 *를 봅시다. 그리고 정규화가 부족하면 실제로는 존재하지 않는 실제 버기 데이터가 발생할 가능성이 높지만 나머지는 모범 사례가 도움이 될 수 있지만 "버그 정책 X "를 따르지 않아서 발생했습니다." 정규화되지 않은 데이터베이스가있는 경우 데이터가 일치하지 않을 수 있습니다.

일치하지 않는 데이터의 실제 사례를 찾을 수 있다는 것이 좋습니다. 이제 두 가지를 발견했습니다.

1. 데이터에 버그가 있습니다.

2. 데이터베이스 스키마의 버그.

실제로 두 번째 버그에 대해 먼저 알고 있었지만 첫 번째 버그는 더 쉽게 설명 할 수 있으며 이론 상으로는 불가능한 것이 아니라 실제 문제를 일으키는 것입니다.

불행히도 정규화되지 않은 비정규 화 된 데이터베이스에 저항하는 실제 이유 중 하나는 그러한 버그가있는 데이터로 무엇을해야하는지에 대한 질문이 항상 쉽지는 않지만 실제 버그를 발견 한 것입니다.

(일부 데이터를 의도적으로 비정규화할 수있는 이유가 있음을 알고 있어야합니다. 규칙의 무지에 대한 규칙을 지식 적으로 위반 한 것으로 오인하지 마십시오. 의도적으로 조회 속도로 비정규 화 된 테이블을 정규화하면 그럼에도 불구하고, 비정규 화가 복잡 해짐은 절차 적으로 수행되어야하는 것이므로, 비정규 화 된 테이블이 정규화 된 테이블의 내용을 기반으로 자동으로 생성되지 않으면 여전히 진행해야합니다).

나머지는 단기적으로 도울 때 소개하고 나중에 장기적으로 구축 할 수 있습니다. 예를 들어 빌드 할 작은 코드 조각이 있다면 단위 테스트를 작성하십시오. 더 나은 방법으로, 만약 당신이 고칠 버그가 있다면, 버그로 인해 실패한 유닛 테스트를 작성하고 버그를 고쳤을 때 버그를 닫을 때 통과한다는 사실을 언급하십시오. , 또는 무엇이든).

* 우연히 현대적이지는 않습니다. 호출 될 이유 정상화 하지 정상화 또는 뭔가 다른 시간에이 붙어있는 국소 농담이다 -ization 리처드 닉슨의 이름의 재미를 만들기 위해 사물의 끝에 베트남 화의 정책을.

나는 이력서에 반대하여 말할 것입니다. 이력서에 약간의 시간을 투자하여 이력서를 조금 구축 한 후 새로운 일자리를 찾으십시오. 1 년 정도 조준하십시오. 많은 것들이 "버즈 워드"이지만, 단위 테스트의 완전한 부족과 같은 문제는 단일 개발자에게는 다루기 어렵고, 거기에서 일하는 프로그래머가 테스트를 원치 않으면 구매를하지 않으며 자신의 입장을 위태롭게 할 수도 있습니다 사람들이 당신을 헛소리라고 생각하게하여 회사에서 문화를 기본 역량으로 끌어 올리려고 하지 말고 멘토링을받을 수있는 곳에 있어야합니다 .

프로그래밍 패러다임 을 개선하기위한 많은 제안이있었습니다 . 가장 인기있는 유행어는 이제 민첩한 프로그래밍 및 객체 지향적 인 것 같습니다. 아니면 그들입니까? 둘 다 5 년 전과 비교했을 때 실질적으로 퇴색되었습니다.

어떤 방법론을 사용하든 동일한 최종 결과를 달성하려고 노력하고 있다는 사실을 확신 할 수 있습니다. 즉, 엔지니어가 충분한 최종 제품을 경제적으로 생산할 수 있도록 도와줍니다.

: 논쟁은 1960 년대에 도입 된 하나의 패러다임이 프로그래밍 구조는 : 전용 "높은 수준의"와 같은 구조를 사용 while, for, repeat, if/ then/ else, switch/ case대신 많이 사용의 문 goto기본적으로 수락했다 문을. 합법적 인 사용 여부에 대한 논란 이 여전히 남아 있습니다 goto.

나는 사용을 최소화 goto하는 것이 좋은 일 이라는 것을 인정 하지만 모든 좋은 것들과 마찬가지로 너무 멀리 갈 수 있습니다.

당신은 agile방법론을 긍정적 인 것으로 언급 합니다. 나는 약 6 개월 동안 한 개발 팀에 있었으며 의도적으로 민첩한 처방을 의도적으로 따랐습니다. 나는 모든 것이 이름이 바뀌는 것을 제외하고는 수십 년 전부터 깨달은 프로젝트 관리 방법론과 비슷하다는 것을 알았습니다. 아마도 누군가를 의사 소통하기위한 아이디어를 다시 묶고 재판매함으로써 생계를 유지하고 회사는 황제의 새 옷을 "보는"것에 대해 기분이 좋을 것 입니다.

오래 전에 알려진 애자일의 가장 귀중한 교훈은 완제품으로가는 더 나은 길을 찾을 수있는 유연성은 좋은 일이며 그 길을 찾을 수있는 능력은 상급 관리자 만이 아니라 다른 사람으로부터 나올 수 있다는 것입니다.

안티 고토 링 리더 Edsger Dijkstra의 글에서 :

프로그래밍 기술은 복잡성을 구성하고, 다수를 마스터하고, 나쁜 놈들을 최대한 효과적으로 피하는 기술입니다.

—Dijkstra, in : Dahl, Dijkstra & Hoare 1972, pg. 6. ( 여기 6 페이지 참조 )