클라이언트 작업에 적합한 기술 스택을 선택하기위한 기본 안내서

Unsplash에 Robert Anasch의 사진

올바른 기술 스택을 선택하는 데 따른 영향을 이해하는 것은 프리랜서 개발자에게 큰 성공 요소입니다. 이 가이드는 고객의 응용 프로그램 또는 웹 사이트에 가장 적합한 기술을 선택할 때 대답해야 할 주요 질문에 대해 설명합니다. 최신 자바 스크립트 프레임 워크를 부주의하게 뛰어 넘기 전에 읽어 보시기 바랍니다.

약간의 경험이있는 대부분의 개발자가 알고 있듯이 소프트웨어를 전문적으로 구축하는 것은 즉시 배송하는 것만이 아닙니다. 또한 유지 관리 성, 확장 성 및 보안을 최적화하는 데 관한 것이며 각각의 수준은 고객의 비즈니스에 달려 있습니다.

프로젝트를 올바르게 분석하면 다른 기술이 아닌 어떤 기술을 사용해야하는지 결정할 수 있습니다. 이 간단한 원칙은 훌륭하고 장기적인 비즈니스 관계를 조성 할 것입니다.

HR에서 재무, 경영에서 마케팅에 이르기까지 거의 모든 비즈니스 계층에서 기술 선택의 영향을 느낄 수 있습니다. 비전이 없으면 명성을 떨어 뜨릴 수 있습니다. 프리랜서가 타협해서는 안되는 자산입니다.

다음 목록을 작성하기 위해 수석 프리랜서 개발자와 한 줄의 코드를 작성하기 전에 스스로 질문하는 중요한 질문에 대해 인터뷰했습니다. 결과를 프로젝트 이해 (비즈니스 관점), 스택 선택 (기술적 관점) 및 토치 전달 (HR 관점)의 3 가지 블록으로 나누었습니다.

시작하자.

프로젝트 이해

제품 비전, 고객의 비즈니스 및 프로젝트 기간을 이해해야합니다.

프로젝트의 범위, 예산 및 기간은 무엇입니까?

고객이 생존하기 위해 2 주 안에 배송 된 모든 것이 필요합니까, 아니면 견고성과 최대의 유지 보수성을 요구하는 장기 프로젝트입니까?

당신은 알아야합니다 :

  • 언제 배달해야합니까?
  • 그들은 몇 시간을 지불 할 수 있습니까?
  • 예상되는 결과는 무엇입니까?

답은 다음 질문에 대한 대략적인 틀을 정의합니다. 또한 시작하기 전에 고객이 현실적인 기대치를 가지고 있는지 알 수있는 아주 좋은 방법입니다 (끔찍한 고객을 식별하기위한 신호에 대한 자세한 내용은이 게시물을 참조하십시오).

일회성 또는 장기 프로젝트입니까?

이벤트 나 특정 이정표 이후에 즉시 폐기되는 단기 프로젝트는 10 년 동안 지속 된 프로젝트로 접근해서는 안됩니다.

프로토 타입 아키텍처를 과도하게 엔지니어링 할 필요는 없습니다. 소중한 예산을 낭비하는 좋은 방법 일뿐입니다. 반면에 고객이 향후 5 년간 20 명의 개발자를 고용하여 코드베이스를 반복 할 계획이라면 광범위하게 테스트 된 기술에 대한 강력한 기반을 구축해야합니다.

기술 부채를 처리 할 수 ​​있습니까?

수익을 창출하라는 압력을받는 고객은 시장에 최대한 빨리 도달하기 위해 약간의 기술적 부채를 용납 할 것입니다. 마케팅 데이터 수집이 주요 목표라면 지속적인 통합 및 테스트 범위의 백분율에 신경 쓰지 않습니다. 비즈니스 목표 첫째, 기술 목표 두 번째.

여기서 약간의 교육이 필요할 수 있습니다. 기술 부채가 장기적으로 누적되는 결과를 이해하게하는 것은 귀하의 책임입니다. 그러한 예지력을 입증하는 것은 신뢰성을 구축하는 좋은 방법입니다.

얼마나 안전해야합니까?

이제 고객의 활동 분야에 대해 잠시 생각해보십시오. 데이터의 감도가 다를 수 있습니까? 여러분이 선택할 기술은이 독특한 현실을 반영해야합니다. 지역 축제 웹 사이트에 4096 비트 RSA 및 DDoS 보호가 필요하지 않습니다.

그러나 재무 정보를 호스팅하는 앱의 알려진 익스플로잇과 실험 플러그인을 통합합니까? 조금 위험 해, 친구

그러나 보안에 집착하는 클라이언트에게는 여전히 스레드가 필요합니다. 그들 중 일부는 밤에 그들을 유지하는 맥락에서 벗어난 공포 이야기를 듣습니다.

"하지만 TV에서 본 러시아 해커가 식당의 메일 링리스트를 훔칠 것이라고 확신합니다."

아니요, 친애하는 고객입니다. 아마 아닐 것입니다.

프로젝트를 처리 할 수 ​​있습니까?

기술 수준보다 높은 프로젝트를 선택하면 거의 혼란에 빠질 것입니다.

교육받지 않은 선택은 워크 플로에 부담이되고 마일스톤이 누락됩니다. 고객의 돈으로 무모하지 마십시오. 법적 결과는 결코 멀지 않습니다.

프로젝트 제공 능력에 대해 의문이있는 경우, 탑승하기 전에 조사를 수행해야합니다.

올바른 스택 따기

이제 프로젝트 관리 문제에서 넘어 갑시다. 실제로 중요한 점에 대해 이야기 해 봅시다 : 스택. 약간의 경험과 구축해야 할 것에 대한 명확한 비전이 있다면 올바른 기술을 고르는 것이 자연스럽게 이루어져야합니다.

어떻게 코딩 할 수 없습니까?

활발한 개발자 커뮤니티에서 수백 개의 프레임 워크와 수천 개의 플러그인을 관리합니다. 수년에 걸쳐 이미 다듬어 진 무언가를 재개발하는 소중한 시간을 낭비하지 마십시오.

서버가 필요 없을 수도 있습니다! 관대하고 열정적 인 사람들이 자신의 일을 더 쉽게하기 위해 노력하고 있습니다. 노력을 무시하지 마십시오. 바퀴를 재창조하는 것은 바보입니다.

개발 시간은 항상 프로젝트를 독특하게 만드는 것, 즉 맞춤형 비즈니스 로직에 중점을 두어야합니다. 한 줄의 코드를 작성하기 전에 프로젝트에 가치를 추가해야합니다.

과잉 또는 저전력입니까?

고객이 소규모 전자 상거래를 통해 현지 고객에게 맞춤형 티셔츠를 판매 할 계획입니까? 백만 명의 동시 고객을 지원할 수 있도록 준비된 고 가용성,로드 밸런싱, 클러스터링, SQL이없는 프런트 엔드 캐싱 메커니즘이 필요하지 않습니다. 이것은 화물선으로 아파트 밖으로 나가는 것과 같습니다.

반면에 새총으로 황소를 쓰러 뜨리는 것은 그리 효과적이지 않습니다. 매일 수천 개의 품목을 판매 할 계획 인 고객은 저렴한 인스턴스에 배포 된 무료 CMS 솔루션을 선택하라는 메시지를 보내 게됩니다.

작업에 적합한 도구를 선택하십시오.

이러한 기술은 잘 문서화되고 지원됩니까?

비전 플러그인이 갑자기 작동을 멈추기 때문에 주석이없는 일본어 코드베이스를 파는 것이 밤을 보내는 가장 좋은 방법은 아닙니다. 선택한 각 기술에 대해 활발한 커뮤니티가 있는지 확인하십시오. 마지막 리포지토리 업데이트가 4 년 전에 이루어진 경우 걱정하십시오.

고객이 전화로 비명을 지르면 기술적 인 질문에 대해 3 가지 쓸모없는 Google 결과가 3 번 나올 때 무력감이 심해집니다.

새로운 기술과 관련된 위험을 이해합니까?

HackerNews의 트렌드 프레임 워크는 제대로 테스트되지 않았을 것입니다. 프로덕션 프로젝트의 중심 기둥으로 사용하기에는 초초 한 느낌이 들지 만 불필요한 외부 위험이 많이 발생한다는 것을 알고 있습니다.

그래도 부주의하다고 생각되면 최소한 고객의 사용 사례를 지원하는지 충분히 알아 봅니다. 중요한 이정표 전날 프레임 워크를 변경해야한다면 프레임 워크에 300 개의 투표를하는 것에 신경 쓰지 않을 것입니다.

횃불을 통과 : 이것은 당신에 대한 것이 아닙니다

출처

이런 식으로 분해하기는 싫지만 고객이 당신에게 영원히 의존하고 싶지는 않습니다. 물론, 스택은 강력하고 잘 문서화되어 있고 안전하며 매우 빠릅니다.

그러나 전 세계의 소규모 개발자 커뮤니티에서만 작동하는 방법을 알고 있다면 교착 상태가 발생합니다. 고객은 교착 상태를 싫어합니다.

스택으로 작업 할 개발자를 찾을 수 있습니까?

더 이상 그들과 함께 일할 수 없거나 팀을 확장하고 싶거나 개발 노력을 본국으로 송환하고 싶기 때문일 수 있습니다. 그러나 결국 클라이언트는 코드를 코드베이스에 푸시하기 위해 다른 개발자가 필요합니다.

특정 전문 지식을 가진 단일 개발자를 찾기 위해 전 세계의 모든 작업 보드를 거쳐야한다면 누가 책임을 져야할까요?

그런 개발자들을 위해 돈을 지불 할 것인가?

지나치게 복잡한 기술 스택에서 일하기 위해 고용 할 수있는 유일한 사람들이 20 년의 경험을 가진 비싼 전문가라면 다른 사람이 주류 기술로 모든 것을 다시 수행하도록하는 것이 더 비용 효율적일 수 있습니다.

개발 노력에 비전을 부여하지 마십시오. 그것은 단지 당신에 관한 것이 아닙니다.

결론

이 짧은 기사가 공포 이야기, 스트레스가 많은 밤 및 어색한 토론을 피하는 데 도움이되기를 바랍니다. 핵심 질문에 대답하기 전에 기술 결정을 서두르더라도 장기적으로 시간을 절약 할 수는 없습니다. 이것은 이야기 경험입니다.

IDE 또는 코드 편집기를 이미 열고 싶은 경우에도 상황을 올바르게 평가하십시오.

행복한 고객 = 반복 / 추천 사업 = 적은 Bizdev 노력 = 더 많은 시간을 개발했습니다.

참고 :이 게시물은 저의 좋은 친구 인 필립 바클레이 (Philip Barclay)와의 긴밀한 협력으로 제작되었습니다. Phil은 수년간 디지털 제품을 제작 해 왔으며 현재 Mirego and Picks에서 멋진 제품을 제작하고 있습니다.

의견에서 중요한 질문을 놓친 경우 알려주십시오!

Snipcart 블로그에 처음 게시되어 뉴스 레터에서 공유되었습니다.