[번역] 스타트업 SW 엔지니어가 첫 해 배운 것
테크 회사의 비기술 파트 사람들을 위한 공익광고
수태 (다시). 한 기능이 다른 모든 파일을 수정하지 않도록하십시오. 그리고 모든 수정의 영향을 예상합니다.
이는 진행중인 프로세스이며, 우리가 함께 일하는 방식을 개선하기 위해 정기적으로 도전하고 있습니다.
팀 과 긴밀히 협력하는 것은 쉬운 일이 아니며 혼자 코드를 작성하는 것보다 어려울 수 있습니다. 그러나 또한 보람이 있으며 시작 실행에 실제 영향을 미칠 수 있습니다.
What I learned in my first year as a Software Engineer in a startup
Startup의 소프트웨어 엔지니어로서 첫해에 배운 것은 무엇입니까?
저는 1 년 전 파리 신생 기업 Foxintelligence 의 소프트웨어 엔지니어로 일했습니다. 이전에는 IT 부서의 프로젝트 관리자로서 2 번 경험을 쌓았 으므로 소프트웨어를 만드는 방법에 대한 아이디어가 있었습니다. 그러나 나는 개발자가되어 많은 새로운 것들을 배웠다. 여기에 몇 가지 있습니다.
작동하는 코드 작성은 쉽습니다.
처음으로 소프트웨어 엔지니어링 작업을 신청하기 전에 필자는 몇 가지 온라인 교육 (주로 프리 코드 캠프 )을 제안했습니다. 나는 동기를 보여주고 싶었고, 2 주 만에 배울 수있는 것을 보여주고 싶었습니다.새로운 직업을 시작했을 때 가장 먼저해야 할 일은 작동하는 코드를 작성하는 것이 었습니다. 이것은 실제로 스펙이 말하는 것을 수행하는 코드를 의미합니다. 거의 모든 것이 새 것이 었습니다. "JWT , Node.js로 데이터베이스에 연결하는 방법, Vue.js 프레임 워크가 어떻게 작동하는지, 그리고 이와 같은 기술적 인 요소 에 대해 배웠습니다 .
하지만 작동하는 코드를 작성한 지 2 개월이 지난 후에 이것이 가장 어려운 부분이 아니라는 것을 깨달았습니다. 가장 어려운 부분은 다른 사람들이 이해할 수있는 코드를 작성하는 것입니다.
어떤 바보도 컴퓨터가 이해할 수있는 코드를 작성할 수 있습니다. 좋은 프로그래머는 인간이 이해할 수있는 코드를 작성합니다.
마틴 파울러 (Martin Fowler), 2008.
그래서 다음 과제는 읽기 쉽고 유지 보수가 쉬운 코드를 작성하는 것이 었습니다! 다른 개발자가 내가 혼자서 시작한 프로젝트에 참여한 것도 바로 그 때였습니다. 내가 이해할 수있는 유일한 부분이었던 모든 부분을 설명하고 정리해야했습니다.
좋은 코드를 작성하는 것이 더 어렵습니다.
그렇다면 훌륭한 코드를 어떻게 작성합니까?
우선 좋은 코드는 무엇입니까? 나에게 좋은 코드를 고려하는 데 도움이되는 몇 가지 요소.
그것의 이해
좋은 코드는 동료 (현재와 미래)와 미래의 자아가 이해할 수 있습니다. 주어진 시간에 한 명 이상의 사람이 프로그램이하는 것을 이해할 수 있다면 모든 것이 더 쉬울 것입니다.
예를 들어, 변수, 함수 또는 오류 의 이름을 가장 명확하게 지정할 수있는 시간 을 들여 시작할 수 있습니다. 쉽게 들리지만 기능이 잘 명명 된 경우 ( get , data , id 는 금지되어야 함) 시간이 엄청나게 절약됩니다 . 너무 일반적인 것보다 더 나쁜 것은 함수가 그 이름이 제안하는 것과 다른 것을합니다. getSomething 함수 는 내부에 무언가를 설정하여 부작용이 있습니다.
또 다른 측면은 효과적인 코드 아키텍처로 , 파일별로 분리되어 있습니다. 사람들이 찾고있는 것을 검색 할 수 있습니다. 또한 잘 분리되어 있고 독립적으로 테스트 할 수있는 기능을 가지고 있다면 단위 테스트에 도움이 됩니다.
오류가 발견되었습니다.
오류가 발생할 때마다 코드가 깨지지 않으면 코드가 좋습니다. 좋은 오류 처리 가 있음을 의미 합니다. 실제로 오류는 소프트웨어의 일부이며 많은 다른 요소에서 비롯 될 수 있습니다. 사용자가 디자인하지 않은 방식으로 소프트웨어를 사용하는 경우. 사용자 입력, API 변경 등을 통해 예상 한 형식과 다른 형식의 데이터입니다. 개발 모드 나 네트워크 오류가없는 동시 사용자 수입니다.
어떤 경우든지 오류 로그를 남깁니다.
그러나 모든 오류를 체계적으로 포착해서는 안됩니다. 문제의 실제 원인을 삼켜서는 안되며 관련 오류를 던질 필요가 있습니다.
문서화되어있다.
왜냐하면 너는 영원히 여기에 있지 않기 때문이다. 또한 같은 질문에 계속해서 답하는 시간을 절약하고 싶습니다. 일을 어떻게 쓰는지 시간을내어 쓰는것이 더 쉽습니다 . 뭔가 (일반적인 조언을 설명하는 것입니다 명확하지 않을 때 좋은 시작은 코드 날짜에 대한 추가 정보까지, 아키텍처 다이어그램과 의견을 데 이유 가 아닌 방법 ).
유지 보수 가능하다.
즉, 제품을 발전 시키거나 기능을 추가하거나 모든 것을 해치지 않고 리팩터링에 너무 많은 시간을 들이지 않고 제품의 일부분을 향상시킬 수 있습니다. 그것은 반복적으로 (기술적 부채를 도입하는) 반복적으로 진행되는 미묘한 기술이며 , 진화를 위해 충분히 장래성있는 미래에 대한 생각 을 발전시킵니다.
좋은 코드를 작성하는 방법?
좋은 코드가 어떻게 생겼는지에 대한 아이디어가 생기면 사람들이 그 원칙을 적용하는 것을 돕는 방법?
나에게 두 가지 주요 메커니즘 (선의와 개발자의 지식을 제외하고) : 개념 과 코드 리뷰 .
범위 (Conception)
프로젝트 매니저로서 저의 첫 번째 책임은 제가 작업하고 있는 프로젝트 의 범위 를 정의하는 것이 었습니다. 나머지는 범위에 따라 달라 지므로 범위에 정렬 된 모든 사람이 필요합니다. 범위에 대해 명확하지 않은 경우 예산, 계획, 위험 및 프로젝트 리소스에 관해 논의 할 수 없습니다.
개발자는 똑같습니다. 기술 개념에 대해 생각하기 전에 먼저해야 할 일은 기능 의 범위 를 정의하는 것 입니다. 일반적으로 민첩한 조직의 제품 소유자 / 관리자와 함께합니다.
이 부분은 스프린트에 포함 되었습니까? 스프린트가 끝날 때 범위를 축소하여 (심지어 완벽하지는 않은) 작업 할 수 있습니까? 이 기능의 핵심 부분입니까, 아니면 좋은 부분입니까?
명확한 범위를 확보하면 기술 개념을 시작할 수 있습니다 . 구성 요소 이름, API 경로, 데이터 형식 및 코드베이스의 어떤 부분이 예를 들어 영향을 받는지 논의 할 수 있습니다. 모든 구현 세부 사항을 토의하거나 함수 이름을 논의하는 데 많은 시간을 할애 할 필요가 없습니다. 그러나 전반적인 아키텍처 와 응용 프로그램의 다른 부분이 어떻게 연결되는지 생각해보십시오 . 이는 한 사람이 내리는 주관적인 결정을 줄여서 코드 의 가독성 과 품질 을 향상시킵니다 .
코드 리뷰
기존의 "git 플로우 에서는 모든 새로운 기능이 기능 브랜치에서 개발되었으며, 작업을 메인 브랜치 중 하나에 병합하기 전에 풀 요청이 이루어진다. 코드 리뷰는 코드에 대한 모든 변경 사항을 확인하는 프로세스입니다 (git diff라고 함). 사람들은 무언가가 명확하지 않거나 최적화되지 않았는지 논의 할 수 있습니다 (가독성을 위해). 처음에는 힘들었고 시간이 오래 걸렸지 만 장기적으로 더 많은 시간을 절약 할 수 있습니다.
읽을 수 있고 깨끗 하며 유지 보수가 쉬운 코드에 대한 이러한 모험 은 결코 끝나지 않습니다. 나는 대부분의 수석 개발자가 24/7 완벽한 코드를 작성한다고 생각하지 않는다. 그러나 코드를 검토하고 검토하게하면 커리어 초기에 도움이됩니다.
그럼 다음은 뭐니? 좋은 코드 작성보다 어려울 수있는 것은 무엇입니까?
개발자 팀과 효율적으로 협업하는 것이 당면 과제입니다.
훌륭한 개발자가 있으면 깨끗하고 유지 보수가 가능한 코드를 작성할 수 있습니다. 똑같은 좋은 개발자를 선택하십시오. 이제는 같은 프로젝트에서 함께 작업하십시오. 좋은 개발자 팀이 있다는 것은 분명하지 않습니다 .
어떻게 조직합니까? 너는 어떻게 일을 쪼개는거야? 어떻게 겹치지 않니? 병합 충돌을 피하는 방법은 무엇입니까? 다른 사람에 의해 차단 된 사람들을 어떻게 피합니까?
여기에는 몇 가지 방법이 있습니다.
# 일을 프로젝트 앞쪽에서 나누어 수행합니다. 스프린트 중에 한 사람에 한 부분에 집중할 수 있도록 합니다.
# 한 기능이 다른 모든 파일을 수정하지 않도록 해야 합니다. 그리고 모든 수정에 대해서 영향도를 예상합니다.
# 개발 소스에 자주 방문하고 작으 반복을 권합니다.
# mock 데이터를 활용하라
