동료가 극도로 복잡하고 추상화되는 것을 방지하는 방법은 무엇입니까?

동료가 전시하는 것처럼 보이기 때문에 매우 어려운 시간을 보내고 있습니다

1. 조기 / 불필요한 최적화 노력
2. 의심스러운 추상화
   를 통한 조기 중복 제거 예를 들어 수정 된 VIPER 아키텍처를 사용합니다. 그는 다른 라우터에서 정확히 무엇이 복제 될지 모르면서 첫 번째 바이퍼 스택을 구현하는 과정에서 라우터 구성 요소 (제네릭 사용)의 기본 클래스를 도입했습니다. 이제 UseCase유스 케이스를 보유한 유형을 제공 해야하지만 대부분의 라우터에는 여러 유스 케이스가 없으며 하나만 있습니다.
3. 예측 가능한 미래의 기능을위한 범용 솔루션 개발
   예를 들어, 앱에 화면이 두 개 밖에 안되었을 때 정적 셀 테이블 뷰를 채우는 관리자를 작성했으며 디자인이 지루한 세로 형식에서 더 사용자 지정으로 이동하는 것을 알지 못했습니다. UI는 관리자가 쓸모가 없습니다.
4. 부수적 인 복잡성 선택

영어를 많이 사용하는 언어 장벽을 가지고있을 때 어떻게 싸울 수 있습니까?

귀하의 설명은 1990 년대에 제가 한 코딩과 같습니다. 현대 세계에 적절하게 수행하는 것은 쉽지 않습니다. 다음 요소에 중점을 둘 것을 권장합니다.

• 편성. 두 눈 세트는 한 사람을 위대하지만 복잡한 구현으로부터 보호 할 수 있습니다.
• 코드 검토. 현대 상점은 여러 사람이 작성한 모든 코드 변경 사항을 100 % 검토합니다.
• 테스트 범위. 간단한 테스트가 있는지 확인하십시오. 지나치게 복잡한 테스트는 지나치게 복잡한 코드를 반영 할 수 있습니다
• 가능한 최소 제품에 대한 많은 토론. 기능을 가능한 가장 작은 구성 요소로 분류하십시오. 데이터베이스를 변경하기위한 티켓 하나와 참조 테이블을 채우는 티켓 하나, UI (최종 사용자에게 실제로 표시 될 부분)를 업데이트하기위한 세 번째 티켓이 있으면 좋지만 저항이 가장 먼저 반 직관적으로 느껴질 것입니다. 아마도.
• 더 작은 티켓과 변경 사항을 갖는 방법에 대한 빈번한 토론.
• 복잡성 및 접근 방식에 대한 토론을 시작하기 위해 팀 전체의 스토리 포인트 투표.
• 교육. 사람들이 좋은 습관과 좋은 이유에 노출 될 수 있도록 점심 및 학습, 교육 세션 등을 준비하십시오.

위의 두 가지 중점은 코드 검토와 작은 이야기입니다.

하루가 끝날 무렵에는 기존 행동을 바꾸는 최선의 해결책은 변화를 이끌고있는 헌신적 인 사람을 갖는 것입니다. 민첩한 조직 (오늘날 대부분의 조직)에서는 스크럼 마스터와 같은 전담 인력이 지속적으로 올바른 질문을하고 개발 방식을 안내해야합니다. 저의 마지막 조직에는 각 팀마다 하나씩 12 가지가있었습니다. 따라서 한 팀원 개발자가 다른 사람들에게 '그들의 방법이 옳다'라고 설득 할 필요가 없으며, 이는 종종 위험한 교환과 나쁜 혈액으로 이어질 수 있습니다.