[번역]더 나은 소프트웨어 개발자가되는 방법
Howto Become a Better Software Developer
How to Become a Better Software Developer
원본 URL : https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e
더 나은 소프트웨어 개발자가되는 방법
오늘 저는 소프트웨어 개발자가 자신의 전문 기술을 향상시키고 자신의 업무에서 더 나아질 수있는 방법에 대해 몇 가지 생각을 나누고 싶습니다. 여기에서 제기 된 주제는 보편적이며 모든 기술 스택에 국한되지 않습니다. 그 중 대부분은 IT에만 국한되지 않습니다. 이들은 개인의 특성을 개발하고 동료 및 고객과의 협력을 개선하며 소프트웨어 개발자로서 경력을 향상시키는 방법에 대한 일반적인 조언입니다.
이 기사의 일부 내용은 주관적이며 내 개인적인 경험을 반영하는 반면, 다른 것들은 다른 사람들에 의해 채택되고 성공적으로 사용되었습니다.
프로세스 끝에서 끝까지 이해
많은 개발자들은 소프트웨어 개발이 코딩에 관한 것이라고 생각하며, 다른 모든 것들은 귀찮은 시간을 낭비하고 소중한 시간을 낭비하려는 사람들입니다. 이것은 진실에서 멀리 떨어져있을 수 없습니다. 소프트웨어를 코딩하기 전에 모호한 아이디어에서 구현 준비가 된 신중하게 설계된 솔루션으로 변환하는 과정을 거칩니다. 그리고 여러분이 최신 변경을 Git에 푸시 한 후에는 소프트웨어가 테스트, 배치, 모니터링, 분석 및 개선되고 있습니다. 코딩은 프로세스의 많은 단계 중 하나 일뿐입니다.
그런데 왜 이런 일이 일어 났습니까? 특히 대규모 조직에서 근무하는 경우 프로젝트의 여러 단계가 여러 팀 또는 부서에서 처리되는 경우가 빈번합니다. 모두 비즈니스 분석가로 시작하여 요구 사항을 수집합니다. 요구 사항은 개발자를위한 모형을 제작하는 디자이너에게 전달됩니다. 개발자는 코드를 작성하여 QA 엔지니어에게 결과를 제공합니다. 모든 것이 정상이면 이슈는 최종 사용자에게 전달하는 운영 팀으로 전송됩니다. 이 프로세스는 피드백없이 개별 단계로 처리됩니다. 부서 간의 의사 소통이 부족하기 때문에 담당자는 종종 다른 사람의 목표를 실제로 이해하지 못하기 때문에 오해와 갈등이 발생합니다.
흔히 소프트웨어 개발 프로세스는 피드백이없는 일련의 개별 단계로 취급됩니다.
요즘 사람들은 너무 과장 해 보일 수도 있습니다. 민첩한 방법론의 등장과 함께, 더 많은 기업들이 혼합 된 전문 분야의 사람들로 구성된 소규모 팀으로 이러한 까다로운 접근 방식을 벗어납니다. 그러나 그때조차도 우리는 사람들이 다른 사람들의 일을 정말로 이해하려고 시도하지 않는다는 것을 알게됩니다. 너무 많은 시간을 소비하는 사용자 정의 확인란을 구현하기를 원하기 때문에 디자이너에게 얼마나 자주 자극을 받았습니까? 그리고 그 반대도 올바른 글꼴을 사용하는 것을 잊었 기 때문에 비판을 받았습니다.
이러한 많은 차이점은 다른 사람들의 일에주의를 기울임으로써 극복 될 수 있습니다. 디자이너와 함께 앉아서 사용자 정의 확인란을 구현하는 데 시간이 좀 걸리며 재사용 할 수있는 다른 유사한 확인란을 제공하는 라이브러리가 있다는 것을 설명합니다. 대신 타이포그래피의 기본 사항을 배우고 올바른 글꼴을 선택하는 것이 왜 효과가 있는지 이해하십시오. 관리자, 비즈니스 분석가, QA 엔지니어, 지원 및 마케팅 전문가에 대해 동일한 태도를 개발하십시오. 인용 T. Huxley :
모든 것에 대해 무언가를 배우고 무언가에 관해 모든 것을 배우십시오.
모든 사람으로부터 무언가를 배우면 자신의 필요를 예측하고 피드백 루프를 단축하며 더 자주 전달할 수 있습니다. 게다가 그것은 당신에게 많은 사랑과 존경을받을 것입니다.
고객의 요구 사항 이해
고객에 대해 이해해야 할 중요한 사항 중 하나는 고객이 수행하는 대부분의 작업을 이해하지 못하는 것입니다. 민첩하고 기능적인 프로그래밍 또는 비 관계형 데이터베이스는 모두 어둠의 마법입니다. 당신의 일을 밀접하게 따르고 진실로 관심이있는 사람조차도 여전히 대부분 어둠 속에 있습니다. 이것은 몇 가지 결과가 있습니다.
소프트웨어 개발자와 이야기 할 때 대부분의 고객의 얼굴.
소프트웨어 개발자를 채용하려면 어느 정도의 신뢰가 필요합니다. 사람들은 종종 이해하지 못하는 것에 많은 돈을 지불해야한다는 불편 함을 느끼는 경향이 있습니다. 마지막으로 익숙하지 않은 자동차 수리 서비스에 들어갔을 때 당신이 타고 다니는 것을 믿을 수 있는지 확신 할 수 없었던 것을 기억하십니까? 당신의 고객들도 같은 느낌을 가지고 있습니다. 자동차가 없다는 것을 제외하고는, 제품과 수익으로 어떻게 든 구체화되어야하는 추상적 인 비 유형 개념 만 있습니다. 신규 고객과 협력 할 때 신뢰를 얻는 것이 중요합니다. 그들이 어떻게 작전을하는지 이해하고 작지만 자주 반복되는 결과를 제공하는 것을 목표로 삼아야합니다. 그렇게하면 작업 진행 상황을보고 중간 결과를 평가하고 피드백을 제공 할 수 있습니다.
종종 고객은 문제를 공유하는 대신 자신의 솔루션을 생각해내는 경향이 있습니다. 그들은 당신의 능력에 대해 거의 알지 못하기 때문에 그들의 해결책은 종종 과소 평가되거나 지나치게 과소 평가됩니다. 헨리 포드 (Henry Ford)의 옛날 견적서를 기억하십시오 :
내가 원하는 것을 사람들에게 물어 본다면 그들은 더 빠른 말을했을 것입니다.
흐름을 따라 가고 클라이언트가 원하는 것을 자동으로 구현하는 대신, 우선 그들을 뒤로 물러나고 그들이 처음에 해결하고자하는 문제에 대해 토론하도록 초대하는 것이 유용합니다. 도메인 지식과 전문 지식을 결합하면 더 나은 솔루션을 얻을 수 있습니다.
모든 사람들이 자신의 아이디어에 의문을 제기하는 것을 좋아하는 것은 아니며,이 전술을 사용하면 고객의 눈에 확신을 줄 수 있습니다. 또한 문제를 이해하고 더 나은 해결책을 제시 할 수 있도록 편안한 지역을 떠나 자신의 사업에 몰입해야합니다. 금융 또는 건강 관리와 같은 복잡한 산업 분야에서 일하면서 어려울 수 있습니다. 그러나 이것을 한 번 해내면 다음에 클라이언트가 더 열린 마음으로 돌아올 것입니다.
직업에 적합한 도구 선택
당신이 가진 것이 모두 망치라면, 모든 것이 못처럼 보입니다.
어떤 플랫폼이나 장치가 지원해야합니까?
이러한 질문에 대답하면 머리에있는 옵션을 구조화하고 후보자 후보 목록을 좁히는 데 도움이됩니다.
안전하게 실험하기
그래서 당신이 아는 것들 중 어느 것도 당신의 경우에 특히 잘 맞지 않고 새로운 것을 시도하고 싶다면 어떻게 될까요? 당신이 무언가를 경험하지 않는다는 사실은 자동적으로 문제가 없다는 것을 의미하지는 않습니다. 단지 몇 가지 추가 사항을 고려해야한다는 의미입니다.
준비 시간이 충분합니까?
프로젝트의 타임 라인이 스트레스가되지 않으면 구현을 시작하기 전에 가능한 한 많이 배울 수 있습니다.
또는 적어도 " 당신이 그것을 만들 때까지 가짜"접근법을 채택하고 당신이하고있는 것을 당신이 알고 있다고 고객에게 확신시킵니다.
먼저 테스트해야하는 항목을 식별하십시오.
"실패 빠른"접근법을 취하고 실험을 끝내기 전에 평가해야 할 중요한 것들을 확인하십시오. 시스템 성능에 의문이 있습니까? 최소한의 프로토 타입을 만들고 부하 테스트를 실행하십시오. 특정 도서관 또는 외부 서비스와의 통합에 대한 불확실성? 별도로 구현 한 다음 나머지는 빌드하십시오.
이 도로를 내려가는 것은 귀하와 귀하의 고객 모두에게 여전히 위험한 일이며 위험과 잠재적 이익을 인식하고 있어야합니다. 어쨌든 장기간에 걸쳐 수개월의 노력을 경감 할 수있는 2 주간의 조사는 꽤 좋은 것 같습니다. 실험이 실패하더라도 2 주 밖에 잃지 않습니다. 고객과의 신뢰가 높을수록 더 많은 사람들이 이와 같은 것에 동의하게됩니다.
자이언트의 어깨에 건설하십시오
자전거를 재 활성화하면 종종 이상한 결과가 발생합니다.
제 3 자 솔루션을 배우는 것보다 직접 구현하는 것이 더 쉽습니다. 이것이 완전한 타당한 이유 일지 모르지만, 당면 과제를 지나치게 단순화하지 않는 것이 중요합니다. 때로는 무언가가 처음에는 단순 해 보이지만 진보로 인해 훨씬 어려워지는 경우가 종종 있습니다. 결국 누군가가 당신을 위해 처리 할 수있는 버그 및 가장자리 사건을 처리하는 데 많은 시간을 소비하게 될 수 있습니다.
재 구현을 통한 학습
이 이야기의 또 다른면이 있습니다. 실제로 뭔가를 다시 구현하는 것은 실제로 좋은 방법입니다. 프로덕션 프로젝트를위한 고유 한 프레임 워크를 작성하는 것은 거의 항상 나쁜 생각이며, 학습 연습으로 생성하면 매우 가치가 있습니다. 동일한 문제를 해결함으로써 해결할 수있는 문제에 익숙해지는 더 좋은 방법. 토끼 구멍에 너무 깊숙이 들어가지 마십시오. 단순한 원유 구현으로 상황을 이해하는 데 충분합니다.
당신이 그것에있는 동안, 비슷한 프로젝트의 출처를 들여다 보지 마십시오. 오픈 소스 프로젝트의 코드를 연구하면 노련한 개발자의 경험을 활용할 수 있습니다.
일하는 방식에 대한 작업
팀 및 프로젝트 관리 방법론.
대부분의 사람들이 팀으로 일하기 때문에 협업을 개선하고 모두에게 공통된 업무 리듬을 수립하는 프로세스를 채택하는 것이 중요합니다. 소프트웨어 개발의 민첩한 움직임은 스크럼 (Scrum)이나 칸반 (Kanban) 과 같이 널리 채택 된 많은 방법론을 탄생 시켰습니다. 그것들은 전반적인 업무 구조를 조직하는데 도움이되지만 모든 것을 다루지는 않습니다. 견적을 작성하고, 문제의 우선 순위를 정하고, 의사 소통을 개선하는 데 도움이되는 다른 방법론이 있습니다. 어려움을 겪고있는 분야를 파악하고 자신의 어려움을 해결하는 모범 사례를 찾아야합니다.
개인적인 프로세스.
오케스트라와 마찬가지로 효과적인 팀은 동일한 리듬을 가져야하지만 모두가 똑같은 방식으로 작업해야한다는 의미는 아닙니다. 각 개인은 자신의 취향을 가지고 있으며 생산성을 향상시키는 방식으로 작업해야합니다. 예를 들어, 많은 사람들이 코딩 작업을 몇 시간 동안 방해 받고 싶지 않지만, 개인적으로는 짧은 1-2 시간의 파열로 중간에 휴식을 취하고 싶습니다 (덜 엄격한 pomodoro 기술). 나는 또한 가정에서 산만 함을 피하기 위해 집에서 일하는 것을 좋아하지 않으며 사무실이나 카페에서 일하는 것을 더 좋아한다. 무엇이 효과가 있는지 알아보고 그것에 충실하면서 습관이 다른 팀원에게 문제가되지 않도록하십시오.
공학 실습 .
많은 기법들이 기술과 방법론의 경계에 놓이고 실제 개발 프로세스를 개선하는 데 중점을 둡니다. 예를 들어, 테스트 중심 개발 및 행동 중심 개발 은 코드 기반을 잘 구조화하고 테스트하는 데 도움이됩니다. 코드 검토 는 코드의 결함을 줄이고 팀의 지식을 확산하는 데 도움이됩니다. 지속적인 통합 및 지속적인 제공 으로보다 쉽고 안전한 배포 프로세스를 보장합니다. 최상의 결과를 얻으려면 다른 조직 방법론과 함께 이러한 방법을 사용하십시오.
모든 사람들을 위해 작동 할 수있는 프로세스가 없다는 것을 기억하십시오. 자신의 환경에서 시험해 볼 필요가 있습니다. 또한 프로세스를 완전히 이해하고 올바르게 구현하는지 확인하십시오. 프로세스를 이미 거친 경험이있는 팀의 조언을 구하십시오. 프로세스를 채택하는 데 도움이되는 소프트웨어 및 재료 도구를 게을리하지 마십시오. 진정한 Kanban 보드와 지속적인 배송을위한 최신 플랫폼을 확보하십시오. 새로운 프로세스를 도입하는 데는 노력이 필요하며 단기 생산성 손실로 이어질 수도 있습니다. 시간을 좀주고 상황이 개선되었는지 여부를 평가하십시오.
장애물 제거
장애물을 해결할 때 별도의 사항을 말해야합니다. 중요한 것으로 보이지 않지만 실제로 작업에 독성 영향을 미칠 수있는 작은 불쾌 함을 무시하는 것은 일반적인 실수입니다. 제품 디자이너가 별도의 공간이나 건물에 앉아 있습니까? 즉, 다시 와서 대화를 나누고 몇 가지 사항을 논의하지 않을 것이라는 의미입니다. 새로운 테스트를 작성하는 것이 어렵습니까? 그러면 많은 일이 시험되지 않을 것입니다.
이러한 것들은 그 자체로 특별히 위험하지 않지만, 쌓여서 심각한 결과를 초래하는 경향이 있습니다. 더러운 것은 이미 너무 늦을 때까지주의를 기울이지 않는 것입니다. 특히 더 심각한 문제가 발생할 때 특히 그렇습니다. 끓는 개구리 와 정상적으로 들어온다 는 개념에 관한 우화를 기억하십시오 .
그들이 당신에게 가기 전에 경계를 유지하고 뿌리에서 이러한 것들을 싸워라.
기초에 중점을 둡니다.
기본 개념은 경력의 기본 요소입니다.
IT는 매우 빠르게 진행되는 산업입니다. 매주 새로운 도구가 출시됩니다. 나는 이미 이전 게시물에서 악명 높은 " JavaScript fatigue "증후군을 언급했다 . 많은 개발자들이 새로운 프로젝트마다 JS 기술 스택을 재평가해야한다는 압박감을 느꼈습니다. 실제로 항상 최첨단에 도전하는 것은 어려울 수 있지만 더 쉽게 만들 수있는 몇 가지 아이디어가 있습니다.
우선, 펀더멘털에 중점을 둡니다. 새로운 기술이 자주 등장하지만 새로운 기본 개념은 훨씬 드물다. 새로운 것을 배울 때이 구현으로 이어지는 기본 아이디어를 이해해야합니다. 이 아이디어는 다른 프로젝트에서도 사용됩니다. 그리고 비슷한 것을 만나면 쉽게 이해할 수 있습니다. 예를 들어, 최신 JavaScript UI 프레임 워크는 구성 요소를 기반으로하며, React를 사용하여 구성 요소 지향 응용 프로그램을 구조화하는 방법을 이해하면 각도로 작업 할 때이 경험을 사용할 수 있습니다. 비슷한 방식으로 Redux의 아이디어가 Angular로 변하고 Angular의 반응 상태 관리가 React as MobX로 구현되었습니다.
M. Fowler의 " Enterprise Integration Patterns "또는 Gang of Four 의 유명한 " 디자인 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소 "와 같은 소프트웨어 개발의 공통 패턴 주제에 관한 고전 서적을 숙지하십시오 . . 책에 설명되어있는 내용 중 일부는 구식 일 수 있지만 패턴을 사용하여 오늘날까지 패턴이 어떻게 발전했는지를 알 수 있습니다.
둘째로, 거기에있는 모든 새로운 것에 대해 배우기 위해 서두르지 마십시오. Hacker News에 나오는 모든 새로운 내용을 따르는 것이 유감 스럽지만이 중 많은 부분은 잡음에 불과합니다. 오히려 커뮤니티에서 지금 당장 돌아 다니며 초기 토론의 과장 이상으로 성숙한 것에 눈을 떼지 마십시오. FOMO에 포기하지 마십시오 . 무슨 일이 일어나고 있는지 적어도 약간의주의를 기울이면 중요한 일이 눈에 띄지 않게됩니다.
보너스 팁
우리는 이미이 기사에서 많은 것을 이야기했지만, 마무리하기 전에 강조하고 싶은 몇 가지 다른 점이 있습니다. 이 몇 가지 팁은 전문가가 아닌 개인의 특성에 더 중점을 둡니다. 그러나 나는 여전히 그들이 직장 생활에 큰 영향을 미친다고 믿습니다.
지식 공유
종종 사람들은 소중한 지식을 쌓아 두는 것이 필수적이라고 생각합니다. 이러한 사람들이 팀원이되어 " 버스 요인 "에 빠지면 그러한 사람이 프로젝트를 떠날 경우 힘든 자리에 앉힐 수 있습니다. 당신이이 사람들 중 하나 인 경우, 당신을 필수로 만드는 것 외에도, 당신의 전문성은 또한 당신을 돌이킬 수없고 "unvacationable"하게 만듭니다. 이 역할에 묶여 있기 때문에 조직의 다른 직업 기회를 놓칠 수도 있습니다. 대신 동료와 지식을 공유하십시오. 가능한 경우 작업의 일부를 담당자에게 위임하고이 공동 작업을 사용하여 작업 시간에 더 큰 것을 구축하십시오.
자신이나 다른 사람을 탓하지 마십시오.
저는 오랫동안 실수로 한 프로젝트에 사건이있었습니다. 우리는 사건을 아주 빨리 복구 할 수 있었고 고객이 저에게 말하고있는 것을 기억합니다 :
당신은 계획대로 계획대로 진행될 때 팀이 수행하는 방식으로 팀을 판단하지 않고, 팬이 히트 할 때 팀이 어떻게 운영되는지를 판단합니다.
아무리 좋은 사람 일지라도 때로는 일이 잘못 될 수 있습니다. 그런 순간에는 냉정을 유지하고 품위와 상호 존중으로 상황을 처리하는 것이 중요합니다. 불을 끈 후에는 희생양을 찾는데 집중하지 마십시오. 이것은 미래에 실수를 피하는 데 도움이되지 않지만, 회사 전체에 대한 두려움과 의심을 불러 일으킬 것입니다. 대신, 영향을받은 당사자들과 함께 모여 공통의 사후 부검을하십시오. 문제의 원인에 초점을 맞추고, 왜 그런 일이 발생했는지 파악하고 향후이 문제를 피하기 위해 시스템이나 워크 플로를 개선 할 수있는 방법에 대해 의견을 나눕니다.
멍청이가되지 마.
개발자 커뮤니티는 재미있는 일입니다. 한 편에는 오픈 소스 프로젝트를 진행하고 컨퍼런스 나 연설에서 연설을함으로써 지역 사회에 기여하는 많은 열린 열린 사람들을 봅니다. 다른면에서 우리는 새로운 아이디어를 트롤하고 신참을 무시하며 주변 사람들에게 무례한 행동을 보여주는 사람들을 만난다. 그 사람들 중 하나가되지 마십시오. 멋지고 사랑을 전파하십시오.
많은 전문적인 조언이 단지 네 단어로 요약 될 수 있습니다.
포장하기
우리의 작업에서 가장 좋은 점은 제한이 없다는 것입니다. 여행 할 용의 새로운 길과 용을 쓰는 용이 항상 있습니다. . 여행 초반이든 경험이 풍부한 전문가이든이 점을 명심하십시오. 그들은 당신이 당신의 길을 찾고 각 단계를 취할 때 더 나은 개발자가되도록 도와야합니다.
다른 사람들과 나누기 위해 다른 조언이 있습니까? 의견에 게시하고 토론을 시작하십시오!
