새로운 시스템 용 코드를 작성할 때 디자인에 불필요한 복잡성을 도입하고 싶지는 않을 것입니다. 그래서 여기 YAGNI를 따르고 있으며 유연성이 더 필요하거나 책임이 명확 해짐에 따라 리팩토링이 필요합니다. 이것은 내가 더 빨리 움직일 수있게 해줍니다.YAGNI 및 주니어 개발자
그러나 주니어 개발자의 경우 리팩터링을 할 때나 디자인을 빌드 할 때를 인식하지 못하기 때문에 문제가 있습니다. 기존 디자인에 더 많은 코드가 들어 있습니다.
그래서이 문제를 해결할 수있는 가장 좋은 방법은 무엇입니까? 미래 지향적 인 디자인을 더 자주 만들어야할까요? 추가 할 때마다 추가 할 필요가없는 경우에도 따라야 할 좋은 예가 있습니까? 아니면 더 많은 코드 리뷰, 교육 등을 진행해야합니까? 아니면 둘다?
이런 유형의 문제에 경험이있는 사람이 있습니까? 어떻게 그걸 해결 했니?
그들은 중학교에 입학 한 이유가 있습니다.
디자인 변경이 필요한 시점을 알 수있는 기능 중 하나입니다.
나는 당신이하고있는 것처럼 계속 할 것이지만, 상황이 어려워 질 때 그들이 당신에게 올 것을 권장합니다. 그런 다음 필요에 따라 디자인을 변경하기 위해 작업을 수행 할 수 있습니다. 리팩토링보다는 손쉽게 수행 할 수 있으며 중학교 개발자에게 지식을 전달하는 데 도움이됩니다.
코드 검토 또는 페어 프로그래밍을 권장합니다. 동료 개발자를 교육하고 전반적인 품질을 향상시킬 수있는 기회를 제공합니다.
실제로, 나는 주니어 개발자가 필요할 때를 대비해서 당신이 필요로하는 많은 코드를 작성하는 것보다 더 나은 코드 리뷰와 일반적으로 주니어 개발자에게 멘토링을 기대한다. (어쨌든 디자인과 충돌하여 종종 수행 할 것입니다.) – SingleNegationElimination
설계를 얼마나 멀리 만들지 표시하는 가장 좋은 방법은 설계가 빌드 될 때 수행 할 작업을 지정하고 새 기능을 다루는 테스트를 작성하는 것입니다. 테스트가 통과되면 개발이 완료됩니다.
길을 따라 뭔가를 시험하는 것을 잊어 버렸을 수도 있습니다. 괜찮습니다. 다음 번에 더 잘 지정할 수 있도록 도움을주는 유용한 피드백입니다. 누락 된 테스트를 작성하고 테스트를 통과 할 수있는 충분한 코드 만 작성하십시오.
그런 다음 리펙터. 리팩토링을 할 때 알아야 할 점은 약간의 연습이 필요합니다.
수십 번 반복하면 더 쉽게 사용할 수 있습니다.
아마 당신은 직업의 일부가 주니어 개발자를 개발하는 데 도움이된다는 것을 분명히 인식하는 것으로 시작합니다. 사장이 아닌 경우 경영진은 사인을해야합니다. 경영진은 귀하의 선택이 지금 그것을 개발하거나 후속 조치를 취하는 것이라는 점을 인식해야하며,이를 수행하는 데 필요한 경영진의 지원이 필요합니다.
코드 리뷰 및 페어 프로그래밍은 훌륭한 아이디어입니다.그들은 "중학교 학생들 만위한 것이 아니기"때문에 특히 좋습니다. – 나는 가까운 동료 중 한 사람과 둘 다합니다. 함께 우리는 거의 100 세이며 70 년 이상의 프로그래밍 경험을 가지고 있습니다 :-)
여기에는 더 큰 문제가 있습니다. 가장 효과적인 방법 (YAGNI + 리팩토링)은 효과적이지 않습니다 너의 후배 파트너. 제 경험으로 YAGNI의 장점을 배우는 데 수년이 걸리므로 일을하는 방식을 배우기를 기대한다면 실망에 빠지게됩니다.
나는 당신이 당신의 후배 파트너에게 유용 할 것이라고 생각되는 방법론을 밝히길 권장합니다. 특별한 방법론은 아마도 중요하지 않습니다 (이단!); 나는 복합/구조 설계, 객체 기반 설계, 대수적 명세 (!) 및 극단적 프로그래밍을 통해 성공을 거두었습니다. 그러나
은 후배 학습에 자부심을 가지고 할 수있는, 이름과 헌신 약간의 문학을 가지고 뭔가를 선택 마십시오, 그것은 그들이 미래의 프로젝트를 수행 할 수있는 기술이다.
맛이 좋다는 것을 표시하기 위해 개밥을 직접 먹어야 할 수도 있습니다. 함께 살 수있는 물건을 골라 내십시오.
후배를 면밀히 관찰하고 안내를 요청해야하는시기를 식별하는 데 사용할 수있는 결정 절차를 가르칩니다.
행운을 빈다.
주니어 개발자는 명확한 인터페이스 또는 코드 작성을위한 단위 테스트를 통해 가장 잘 학습합니다. 자신이 직접 얻는 것보다 완성 된 코딩을 통해 좋은 코딩 방법을 배우는 것이 훨씬 쉽습니다. –
저는 코드 리뷰와 강의를 위해 모두 노력하고 있습니다.하지만 미래 지향적 디자인도 중요하다고 생각합니다. 어쩌면 당신은 API를 디자인하는 관점과 API를 사용하는 중학교 개발자들과 관련하여 생각할 수 있습니다. 이런 식으로 당신은 시간을 생산적으로 사용하지 않는 모든 쓸데없는 일을하면서 (중복 된 코드를 식별하고 제거하는) 고생을하는 사람입니다.
물론 이것은 중급 개발자 기술을 개발할 필요성과 균형을 이루어야합니다. 방정식의 어느 쪽도 무시 될 수 있습니다.
YAGNI를 보는 또 다른 방법은 코드의 변경 사항을 정당화해야한다는 것입니다.
커밋이 필요한 단위 테스트 (또는 BDD 사용자 이야기, 독약 선택)가 필요하면 도움이 될 수 있습니까? 귀하의 의도를 전달하는 데 도움이됩니다 (사람들이 왜이 기능을 추가하는지 생각하게하고). 회귀 테스트를 무료로 받으십시오.
모듈성에 대해 생각하기 시작하려면 noobs를 가져오고 (나중에 코드를 테스트 할 수 있어야합니다) 나중에 리팩터링해야하는 경우 많은 도움이됩니다.
그들이 할 일을 찾아내는 것이 도움이 될지도 모릅니다. 그러면 실제로 마음에 드는 판단력을 구축하는 데 도움이됩니다. 페어링은 하나의 옵션이지만, 많은 시간을 할애 할 수 없다면 일종의 "체크 포인트"를 사용하여 어떻게하는지보고 잘못된 경로로 내려 가지 않도록 할 수 있습니다.
+1하지만 신중한 개발자는 상황이 어려워지는 시점을 항상 인식하지 않습니다. 일부에게는 어려움이 정상입니다. –