웹 개발 분야에서 수십 년 동안 일해온 저는이 사업을 둘러 보았습니다. 저는 3-4 명으로 이루어진 팀과 50 명 이상의 팀으로 구성된 분산 및 교차 기능 프로젝트에 참여했습니다. 최근 요점에서는 프런트 엔드 “배관공”의 기능을 수행해야했습니다. 기본적으로 문제가 발생하면 기본적으로 문제가 발생합니다. 누적 된 사례를보고 작동 시키려고 노력하면서, 나는 스스로에게 “이 프로세스를 단순화하는 방법”이라고 자발적으로 질문했습니다. 고통과 다른 사소한 단계의 결과로 저는 소위 “웹 개발 로드맵”을 만들었습니다.
내 손에 뭐가 들었나?
내 개인적인 경험에 따르면, 우선 다루어야 할 코드 “우수성”의 수준을 이해하는 것부터 시작해야합니다. 세련된 비즈니스 프로세스를 갖춘 프로젝트가 있지만 여전히 제대로 작동하지 않았습니다. 시간이 지남에 따라 기술 스택, 아키텍처 및 기타 멋진 것들로 프로젝트를 평가하는 것이 최적이 아니 었음이 분명했습니다. 나는 당신이 지금 내가 쓰고있는 말도 안되는 것을 생각하기 시작했다고 가정한다. 그러나 설명 된 모든 사례는 내 개인적인 경험이므로 공유하되 계정에 반영할지 여부는 귀하에게 달려 있습니다. 실제로 코드를 분석하려면 다음 단계부터 시작하는 것이 좋습니다.
1. 저장소를 확인하십시오. 유형 (SVN, Git 또는 Mercurial)은 개인적인 취향에 달려 있습니다. 주로 저장소와 누가 권한을 부여 받았는지에 대한 액세스에주의를 기울여야합니다. 우선, 저장소에 “유령”이 없는지 확인하십시오. 보안 침해 일뿐만 아니라 프로젝트가 제대로 유지되지 않았기 때문에 발견 된 것은 괜찮은 것입니다.
2. 프로젝트의 분기 수를 계산합니다. GitFlow를 잘못 사용하면 5-7 개 이상의 분기 (dev, test, uat, prod 등)가 발생합니다. 그러나 이는 궁극적 인 진리는 아니며 이는 프로젝트 버전 관리 (릴리스)를 위해 이러한 분기가 도입되었음을 의미하기도합니다. 이 경우 사용 여부를 이해해야합니다. 가지가 6 개월 이상 동안 만지지 않으면 그 필요가 없습니다.
3. 프로젝트에서 의견을 읽고 그들이 말하는 것을 분석하십시오. “수업에 100 명이 넘는 사람들이 있다면, 개인적으로 사과하러 올거야.”또는 “왜 여기 있는지는 모르겠지만, 모든 것이 단지 그것 없이는 효과가 없을 것”과 같은 코멘트를 보거나 “이것은 장황한 해결 방법이지만 우리는 그것을 피할 수 없습니다”또는 가장 자주 사용되는 “삭제”를 한 다음 커다란 코드 주석을 사용합니까? 그렇다면, 정말 유감입니다. 그러한 프로젝트에서 코드 검토를 기대하지 마십시오. 프로젝트 논평에서 저주와 가벼운 어휘는 거래를 의미합니다. 전문 개발자는 그렇게하지 않으며 다른 개발자로부터 받아 들일 수 없습니다. console.log 및 디버거 (있는 경우)에주의를 기울이는 것이 좋습니다. console.log의 존재는 콘솔에 스팸 메일을 보내기 때문에 그 자체가 너무 무섭지 않습니다. 항상 클라이언트에 열려 있어야합니다. 디버거가 있는지 여부에 따라 오류가 발생하거나 악화되는 경우가 있습니다. 전체 애플리케이션의 비 작동 성입니다.
4. 코드 스타일을 탐색하십시오. 나는 Angular로 작성된 프로젝트를 만들었는데, 이것은 첫눈에 꽤 잘 어울렸다. 더 깊게 본 후 React guideline에 따라 프로젝트가 작성되었지만 솔직히 고통 스러웠습니다. 여러분 중 일부는 질문 할 수 있습니다. 무엇이 문제입니까? 실제로 “그것은 아무것도 아닙니다.”하지만 모든 프레임 워크는 프레임 워크이기 때문에 표준을 가지고 있으며 제작자가 이유를 가지고 개발했습니다.
5. 프로젝트 빌드 구성을 확인하십시오. 먼저 모든 지점에서 동일한 지 또는 약간의 차이가 있는지 알아야합니다. 디버그 코드가 생산에 들어가기 때문에 동일하면 좋지 않습니다.
6. 외부 라이브러리 사용 및 라이브러리와의 관계를 확인하십시오. 무엇이 사용되고 왜 사용되는지 명확하게 이해하는 것이 바람직합니다. 프로젝트가 크고 많은 제 3 자 종속성이있는 경우 내 의견으로는 완벽하지 않습니다. 이는 분명히 업데이트 문제와 모든 종류의 충돌을 수반하기 때문입니다. 내 경험에 따르면 더 큰 프로젝트의 외부 라이브러리에 의존하지 않는 개별 구성 요소를 작성하는 것이 좋습니다. 일반적으로 외부 라이브러리에는 두 가지 유형이 있습니다. 첫 번째 것들, 소위 보조 도구는 lodash, ramda, moment 등을 포함합니다. 두 번째는 소위 제한된 기능의 라이브러리입니다. 여기에는 캘린더, 드롭 다운 등이 포함되며 향후 원인을 알릴 수 있습니다.
7. 자동화를 사용하기 위해 프로젝트를 점검하십시오. 빌드를 만들고이를 수동 모드로 배포하는 것은 이상한 일임을 모두 알고 있습니다. Jenkins 및 GitLab과 같은 도구가 많이있어 요즘 시장에서 자동화 된 작업을 수행 할 수 있습니다. 테스트 분기에서 오래된 빌드의 문제점을 제거하고 항상 최신 빌드가 있는지 확인합니다.
8. 테스트 가용성은 모두 중요하지는 않기 때문에 중요하지 않습니다. 필자가 생각하기에, 통합 테스트가 있다면 그것은 멋지다. 그러나 그들이 결석하면, 왜 그것에 대해 어떻게해야하는지 이해하는 것이 좋습니다.
나열된 포인트를 확인한 후에는 추가 개발 전략을 정의 할 수 있습니다.
무엇부터 시작해야할까요?
팀 내 상호 작용을 구축하려면 누가 무엇을 담당하는지 파악해야합니다. 프로젝트의 일부분을 이끌어 가야한다면 나머지 프로젝트 리더들을 만나기 시작하는 것이 좋습니다. 당신은 중요한 부분이 될 것이기 때문에 일반적으로 프로젝트에서 진행되고있는 것을 이해해야합니다. 큰 프로젝트가 있다고 가정 해보십시오. 당신은 프론트 엔드 개발의 리더가되며, 백엔드 개발, QA 및 분석의 세 가지 리더를 알게됩니다. 이것은 단지 하나의 예일뿐입니다.하지만 동료에게 물어볼 사항은 다음과 같습니다.
1) 문제 및 병목 현상에 대해 알아보십시오. 이것은 당신이 당신의 일을 계획 할 때 같은 제한을 뛰어 넘지 않을 것입니다.
2) 그들의 계획을 찾으십시오. 궁극적 인 프로젝트 목표를 달성하기 위해 동일한 방향으로 움직이는 경우 시너지 효과를 창출 할 수 있습니다. 예를 들어 FULL REST API로 전환하려면 백엔드 지원이 필요하거나 일반적으로 훌륭한 제품을 개발하려면 품질 보증 팀과 신뢰 관계를 구축해야합니다.
3) 팀에서 무엇을 받고 싶습니다. 즉, 그 뒤에 소원과 근거를 수집하십시오. 이렇게하면 전체 팀의 성과를 높이기 위해 커뮤니케이션 및 비즈니스 프로세스를 변경하는 방법을 알 수 있습니다.
4) 프로젝트의 대략적인 기한을 계산하십시오. 이렇게하면 우선 순위를 올바르게 설정하는 데 도움이됩니다.
이제 네가 뭘하고 있는지 알아야 해. 필요한 모든 작업을 계획 할 수 있습니다.
침착하고 코드를 유지하십시오.
처음에는 작업을 설정하고 결과를 얻는 투명한 프로세스를 수립해야합니다. 진행하고 주요 프로젝트 목표를 달성하려면 다음 규칙을 따라야합니다. 완벽하게 작동하지 않을 수도 있지만 작동하지 않을 수 있습니다. 결과에 초점을 맞추고 뉘앙스를 뛰어 넘지 않는 것이 좋습니다. 그렇지 않으면, 불필요한 행동으로 허물어 질 수 있으며, 노력에도 불구하고 결과를 얻지 못할 수 있습니다.
아래는 나의 개인적인 계획이다. 나는 그것을 고집하려고 노력한다. 당신은 다른 순서의 포인트로 자신의 계획을 세울 수 있지만 포인트는 같을 것입니다.
1. 과도한 분기를 모두 삭제하십시오. 이렇게하면 신입 사원이 새 프로젝트와 혼동하지 않도록하고, 너무 많은 다른 것을 염두에두면 귀하도 마찬가지입니다.
2. 빌드 및 배포 자동화를 설정합니다. 이렇게하면 분기를 수동으로 업데이트하는 데 시간을 낭비하지 않아도됩니다. 한번만.
3. 다른 분기에 대한 빌드 구성을 설정하십시오. 예를 들어 프로덕션의 경우 주석, 콘솔 및 디버그와 같은 불필요한 요소를 삭제해야합니다.
4. 관련이없는 계정이 있으면 삭제하십시오.
5. 코드를 표준화하기위한 linters를 설정하십시오.
6. 커밋 된 내용을보고 필요한 수정을 할 수있는 코드 검토를 도입하십시오.
7. 당신의 버그 추적기 (Jira, Redmine)와 저장소를 연결하여 각 작업에서 수행 된 작업과 그 작업과 관련된 커밋을 확인하십시오.
이것들은 일의 기초가 될 수있는 첫 걸음입니다. 일상 업무를 설정 한 후에 프로젝트 작업에 대한 보고서를 작성, 실행 및 수집하는 프로세스를 구축해야합니다. 나는 다음과 같은 계획을 고수한다 :
1. 아무 작업도 – 커밋하지 않고, 커밋은 작업을 지정하지 않고서는 금지된다. 하나의 커밋에 여러 작업을 포함하는 것도 금지되어 있습니다.
2. 모든 작업은 자신의 라이프 사이클을 거쳐야합니다.
- 마감일 추정과 우선 순위를 포함하는 창작
- 개발자에게 배정
- 작업 시작
- 코드 검토로 보내기
- 품질 보증에 보내기
- 테스트
- 작업을 다시 열거 나 닫는 중입니다.
3. 모든 작업은 처음에는 작업 부하를 배포 할 팀장에게만 할당되어야합니다. 팀장은 프로젝트의 현재 상태를 알아야하고 개발자가 코딩을 혼란스럽게하지 않으면 서 프로젝트에 대해보고 할 수 있어야하므로 중요합니다.
4. 태스크 라이프 사이클을 빌드하는 동안, 새 태스크 요구 사항이 발생하거나이 태스크를 테스트하는 동안 버그가 발견 될 경우에만 태스크가 다시 열리는 것을 모니터하는 것이 중요합니다. 버그가 재현되거나 일부 요구 사항이 처음 고려되지 않았기 때문에 작업을 다시 열지 않는 것이 중요합니다. 이 기능을 계속 사용하려면 QA 팀 단장에게 이야기하고이 규칙을 부하 직원에게 설명해야 할 필요성을 설명해야합니다. (나는 그러한 합의가 항상 CC의 프로젝트 매니저와 함께 편지에 의해 지원되어야한다는 것을 모두 알고 있기를 바랍니다.) 이것은 당신이 당신의 직원들의 성과를 효과적으로 추적 할 수있게 해줄 것입니다.
이러한 간단한 단계를 통해 명확하고 체계적인 작업을 수행 할 수 있지만 이는 끝나지 않았습니다.
항상 개선의 여지가 있습니다.
따라서 “완벽한”레거시 코드가 아직 프로젝트에 남아 있지만 불필요한 산만 함없이 효율적으로 작업을 완료 할 수있는 일관된 워크 플로가 있습니다. 프로젝트 품질을 개선하고 작업 효율을 높이는 문제를 해결하려면 해당 코드에 정확히 무엇이 잘못된 것인지 파악해야합니다. 이 목적을 위해 다음 단계를 수행합니다.
1. Sonar와 같은 일부 코드 분석기를 사용합니다. 프로젝트에 얼마나 많은 복사 – 붙여 넣기 및 기타 휴지통이 있는지 보여줍니다.
2. 복사 – 붙여 넣기를 개별 모듈이나 구성 요소로 이동하십시오. 이러한 문제를 해결하기에 충분한 지식이 없다면 Technical Lead (기술 전문가)의 조언을 구하는 것이 좋습니다.
3. 백엔드 팀 리더가 예를 들어 프로젝트에서 아직 활용되지 않았다면이를 통합하는 것에 동의하십시오. 이 도구를 사용하면 API 메소드를 테스트하고 자신의 코드를 디버깅하는 생산성을 높일 수 있습니다.
4. 프로젝트 아키텍처를 분석하고 병목 현상을 찾아냅니다. 인접 부서의 동료들은 그러한 작업에 매우 도움이 될 수 있습니다.
5. 외부 라이브러리와 기술 스택의 관련성을 전반적으로 평가하십시오. 타사 종속성을 제거하는 데 얼마나 많은 노력이 필요하며 업데이트 프로세스가 얼마나 어려운지 알아야합니다.
6.로드 테스트 W 성능 테스트를 실행하십시오. 이 절차를 통해 어떤 코드가 최적으로 작성되지 않았고 어떤 리팩토링이 필요한지 알 수 있습니다.
7. 통합 테스트가 필요한 요소를 식별하십시오. 이렇게하면 개발 과정에서 오해를 피할 수 있습니다.
이러한 쉬운 작업을 통해 응용 프로그램의 올바른 업데이트 및 최적화를 얻을 수 있습니다. 위에서 설명한 모든 것은 순수한 계획이며 많은 작업이 필요하지 않습니다. 프로젝트에 대한 세부 정보를 수집하면 기술 및 코드 측면에서 프로젝트의 복잡성과 개발 및 유지 보수를 추정하는 데 도움이됩니다.
결론
이 권장 사항은 보일 수 있듯이 많은 시간을 소비하지 않습니다. 내 경험에 따르면, 이것은 단 한 달 만에 소개 될 수 있습니다 (물론 예측할 수없는 장애물이있을 수 있음). 필자는 의도적으로 기술 지정 및 / 또는 특정 솔루션 설명을 피했습니다. 모든 프로젝트에는 고유 한 특성과 마감 기한이 있지만 위의 세부 사항은 어느 정도 존재합니다. 나는 프론트 엔드 개발 여정을 시작하고 올바른 방향으로 그들을 가리킬 곳을 막연하게 상상하는 사람들을 지원하기 위해이 기사를 작성했습니다.