"미래에 대비 한"웹앱에 대한 두려움

저는 소규모 로컬 SaaS 웹 애플리케이션의 웹 개발자입니다. 현재 약 6 명의 고객이 있습니다.

응용 프로그램을 계속 디자인할수록 시작 단계에서 발생한 프로젝트에 시간을 투자하도록 설득하기가 점점 어려워지고 있습니다. 프로젝트와 이미 작성한 코드에 연결되면서 커밋 된 모든 추가 작업이 비즈니스가 성장함에 따라 앱이 확장되지 않는 것으로 판명 될 때 가까운 미래에 전복 될까 봐 두렵습니다.

인턴쉽을 신청하는 대학생 인 저는 인터뷰 중에 웹 프레임 워크를 사용하지 않을 때 고용주가 내 선택에 의문을 갖게되었으며, 그 결과 이전의 일에 대해 더 의심하게되었습니다. 나는 단순히 웹 프레임 워크를 모르고 사용할 프레임 워크를 모른다.

저는 1 월에 풀 스택 개발자로 인턴쉽을 시작했습니다. 거기서 프론트 엔드 프레임 워크를 배우기 시작하지만 앱을 끝내야하는 압박이 가중되고 있으며 앱을 완전히 폐기하고 다시 시작하는 것을 고려하고 있습니다. 그것은 내가 전에 한 일입니다. 이 앱은 현재 PHP 및 jQuery (AJAX 호출 용)로 구축되었으며 데이터베이스에 MySQL을 사용합니다. 이 정신 차단을 극복하고 앱의 확장 성을 보장하는 방법에 대한 생각이 있습니까? 미리 감사드립니다.

완전은 선의 적입니다.

또는 다른 방법을 사용하여 오늘 걱정하지 마십시오. 앱이 필요한 작업을 수행하면 문제가 없습니다. 그건 아니 더 선 아래로 소프트웨어의 일부를 다시 작성하는 나쁜 것; 그 시점까지 당신은 1) 당신이 만들고자하는 것을 더 명확하게 알고 2) 실제로 어떤 병목 현상인지 알 수 있습니다. 백만 명의 사용자로 확장 할 수있는 앱을 작성하는 데 엄청난 시간을 할애 할 수 있지만 현재 보유한 고객보다 현재 6 명의 고객에게는 더 나을 것이 없습니다 .

이 정신 차단을 극복하고 앱의 확장 성을 보장하는 방법에 대한 생각이 있습니까?

이 문제의 핵심은 확장 성이 아닙니다. 문제의 핵심은 당신이 처음에 올바르게 얻을 것이라고 생각하고 있습니다 .

깨끗한 코드 작성에 집중해야합니다. 깨끗한 코드는 미래에 무언가를 변경해야 할 때 편의성을 극대화하기 때문에. 그리고 이것이 당신이 가져야 할 진정한 목표입니다.

지금하려는 것은 완벽한 코드를 작성하는 것입니다. 그러나 그렇게 할지라도 요구 사항이 변경되지 않을 것이라고 누가 말하거나 잘못된 정보 또는 잘못된 통신을 기반으로 결정을 내릴 수 있습니까?

잘못이 아니더라도 실수를 피할 수 없습니다. 나중에 변경하지 않아도되는 코드를 작성하는 대신 나중에 변경하기 쉬운 코드 작성에 집중하십시오.

프로젝트와 이미 작성한 코드에 연결되어 성장하면서

나는이 감정에 절대적으로 동정한다. 그러나 작성한 코드에 첨부하는 것은 문제가됩니다.

일정해야하는 유일한 것은 특정 문제를 해결하려는 당신의 소망 입니다. 이 문제를 해결하는 방법은 부차적 인 문제 일뿐입니다.

내일 코드베이스를 80 % 줄이는 새로운 도구가 출시되면 코드가 더 이상 사용되지 않는다고 화를 낼 것입니까? 아니면 코드베이스가 더 작고 더 깨끗하고 관리하기 쉬워 졌다는 것이 기쁠까요?

전자의 경우 문제가있는 경우 : 코드 솔루션 이 표시 되지 않습니다 . 즉, 코드에 집중하고 더 큰 그림 (제공하려는 솔루션)을 보지 않습니다.

비즈니스가 성장함에 따라 앱이 확장되지 않는 것으로 판명되면 가까운 미래에 내가 저지른 모든 추가 작업이 전복 될까봐 두려운 일입니다.

그것은 다른 날에 다른 문제입니다.

먼저, 당신은 작동하는 것을 구축합니다. 두 번째로 , 여전히 나타날 수있는 결함을 수정하기 위해 코드를 개선합니다. 현재하고있는 일은 두 번째 작업을 수행해야한다는 두려움에서 첫 번째 작업을 보류하는 것입니다.

그러나 다른 옵션은 무엇입니까? 당신은 미래를 말할 수 없습니다 . 미래의 가능성을 생각하면서 시간을 보내면 어쨌든 추측하게 될 것입니다. 추측은 항상 틀렸다는 경향이 있습니다.

대신 응용 프로그램을 빌드하고 실제로 문제가 있음 을 증명하십시오 . 문제가 해결되면 문제를 해결하기 시작합니다.

달리 말하면, Henry Ford는 2018 표준 / 예상을 준수하는 자동차를 결코 만들지 않았습니다. 그러나 그가 현대 표준에 의해 결함이있는 자동차 인 Model T를 만들지 않았다면, 아무도 자동차를 사용하지 않았을 것이고, 자동차 산업도 없었을 것이고, 아무도 개선을 시도 할 수있는 차를 가지고 있지 않았을 것입니다.

인터뷰에서 웹 프레임 워크를 사용하지 않을 때 고용주가 내 선택에 의문을 갖게되었으며, 이는 이전 작업에 대한 의구심을 심어주었습니다.

여기서 중요한 부분은 사용하고있는 프레임 워크가 아닙니다 (귀하를 판단하는 고용주가 자신의 업무를 제대로 수행하지 않는 것임). 여기서 중요한 부분은 자신이하는 일과 왜 하는지를 아는 것 입니다.

예를 들어, 프레임 워크가 어려운 이유 부터 먼저 배우 면서 왜 유용한 지 알고 싶기 때문에 기존 프레임 워크를 피할 수 있습니다 . 또는 자신의 프레임 워크를 만들려고 할 수도 있습니다.

여기에 유일하게 나쁜 대답은 "알지 못한다"입니다. 정보에 근거한 결정을 내릴 수 없기 때문입니다. 즉 이다 고용주를위한 붉은 깃발.

나는 단순히 웹 프레임 워크를 모르고 사용할 프레임 워크를 모른다.

여기에서도 같은 문제가 발생합니다. 해결책은 더 생각하는 것이 아니라 행동하는 것입니다.

• 완벽한 답변을 숙고하십시오 .
• 프레임 워크를 선택하십시오. 선호 사항이 없다면 무작위로 선택하십시오. 다트 판을 사용하고, 주사위를 굴리고, 동전을 뒤집고, 카드를 선택하십시오.
• 그걸 써.
• 당신은 그것을 사용하기 좋아했습니까? 성가신 것을 발견 한 것이 있습니까?
• 이러한 나쁜 요소를 방지하는 방법을 찾으십시오. 프레임 워크를 잘못 사용 했습니까? 아니면 프레임 워크가 어떻게 작동해야합니까?
• 마음에 드는지 여부에 관계없이 프레임 워크를 파악했다면 새 프레임 워크를 선택하고주기를 반복하십시오.

이에 대한 자세한 내용을 보려면 행동하는 사고> 사고 사고를 읽으십시오 . 저자는 내가 할 수있는 것보다 더 잘 설명합니다.

그러나 앱을 끝내야하는 압력이 높아지고 있으며 앱을 완전히 폐기하고 다시 시작하는 것을 고려하고 있습니다.

현재 코드베이스가 절대적으로 유지 관리 할 수없는 혼란이 아니라면; 당신은 반대 결정을 내립니다.
개발자는 종종 물건을 버리는 것이 더 나은 선택이라고 생각합니다. 매우 일반적인 느낌입니다. 그러나 올바른 선택은 거의 없습니다.

코드를 버리고 처음부터 다시 시작하는 것은 출근길에 교통 체증에 빠지는 것과 같이, 늦게 일 할까 걱정하고 (마감일을 놓치게 됨) 집으로 운전해서 같은 길을 다시 운전 해보십시오. 말이되지 않습니다. 교통 체증에 갇혀있을 수 있지만 집에있을 때보 다 직장에 더 가까이 있습니다.

Facebook과 Google이 다른 방법으로 귀하를 설득하기 위해 마케팅에 쏟아 부은 막대한 금액에도 불구하고, 프론트 엔드 프레임 워크는 다음 두 가지 이유로 존재합니다.

• 첫째, 클라이언트에 상태와 논리를 넣는 방식으로 하드웨어 / 네트워크 요구를 클라이언트 측 작업에 오프로드
• 둘째, 첫 번째 요점을 지원하는 데 필요한 추가 클라이언트 논리와 관련하여 격리 된 실행 컨텍스트를 제공하므로 다른 사람의 코드를 페이지에 넣을 수 있습니다.

클라이언트가 저장하는 애플리케이션 상태의 양이 상당히 복잡한 경우, 네트워크 대기 시간이 나쁜 많은 클라이언트가 예상되는 경우 (모바일, 또는 서버와 멀리 떨어져있는 경우) 또는 특히 고급 CSS 또는 동적 요소 생성을 지원해야하는 강력한 비즈니스 요구가있는 경우

프레임 워크 마케팅은 특별한 아키텍처 방법이 개발 속도를 높이고 유지 관리를 더 쉽게한다고 믿기를 원합니다. 간단한 프로젝트를 수행하는 소규모 팀에게는 이것이 사실이 아닙니다. 코드를 분리하고 수입을 정리하면 대규모 팀이 제품을보다 빨리 시장에 출시 할 수 있습니다. 이미 기능을 갖춘 프로젝트를 수행하는 한 사람의 개발 팀에게는 훨씬 적습니다.

실제로 기능을 구현하는 것보다 기존의 기능적 코드를 프레임 워크에 맞추는 방법을 배우는 데 더 많은 시간을 할애 할 수 있으며, 누군가가 무언가를 업데이트 할 가능성이 매우 높으며 해당 프레임 워크로 작성된 코드는 18 개월 이내에 작동하지 않습니다. 누군가 그것을 지속적으로 유지해야합니다.

바닐라 JS와 JQuery는 그다지 크지 않지만 JQuery는 이러한 문제를 겪지 않습니다. 주목할만한 예외가 있지만 JQuery + AJAX 응용 프로그램은 브라우저 별 동작에 의존하지 않고 외부의 의존성이 현명한 경우 원래 약간 사소한 변경으로 작성된 후 10-15 년 동안 계속 작동합니다.

프레임 워크는 지속적이고 복잡한 공개 웹 애플리케이션을 지원하는 일반적인 신생 기업에 적합합니다. 이를 통해 대규모 팀이 잘 조정하고 공급 업체와 프레임 워크를 추가 할 수 있으며 화려한 새 위젯과 디자인 패러다임을 지원하여 경쟁력을 유지할 수 있습니다.

포기하려는 고정 대상이있는 소규모 소프트웨어 도구에는 해당되지 않습니다. 프레임 워크를 사용하면 새로운 패러다임에 적응할 때 개발 속도가 느려지고 불필요한 호환성 위험이 발생합니다. 클라이언트 측 코드를 단순하게 유지하고 (이상적으로 자체 호스팅) 유지하면 호환성 위험의 표면적이 크게 떨어집니다. 브라우저가 변경되고 CDN URL이 작동을 멈추고 종속성이 만료됩니다. 그러나 아무도 해당 서버를 만지지 않으며 계속 작동합니다.

오늘날의 특정 아키텍처 문제를 해결하거나 곧 예측할 수있는 경우가 아니라면 프레임 워크를 채택하지 말고 다른 방법으로 문제를 해결하는 것이 좋습니다.

앱을 "미래 증명"하기 위해 할 수있는 최선의 방법은 시스템 디자인의 모범 사례를 따라 문제의 느슨한 결합 및 분리를 최대화하는 것입니다. 앱에서 더 이상 사용되지 않는 부분은 없지만 X에 의해 영향을받을 필요 가없는 코드에서 X가 더 이상 사용되지 않는 코드를 분리하기 위해 할 수있는 일은 많이 있습니다.

그러나 귀하의 우려가 귀하의 경험과 역량의 성장률보다 앱의 성장 / 확장성에 대해 적어야한다고 주장합니다. 당신이 묘사하는 정신적 블록은 정체를 배우는 전략이나 도구를 사용하지 않고 알려지지 않은 많은 알려진 미지의 지식을 배우는 것처럼 들립니다.

프레임 워크는 "미래 방지"과제를 해결하는 데 특히 적합하지 않지만 일반적으로 MVC와 같은 고급 디자인 패턴을 통해 경험이없는 사람들에게 관련 초기 지침을 제공 할 수 있습니다 . 오히려 강력한 응집력을 제공하고 종종 더 긴밀한 결합을 희생 하여 개발을 가속화하는 방법으로 더 유용합니다 . 예를 들어, 앱 전체에서 프레임 워크 제공 객체 관계형 매핑 시스템을 사용하여 캐싱 시스템 통합이 완료된 데이터베이스와 상호 작용한다고 가정합니다. 나중에 비 관계형 데이터 저장소로 전환해야하고 이제 데이터 를 사용하는 모든 것이 영향을받습니다.

지금 당신이 사용한 혼란은 당신 이 사용한 것에서 온 것이 아니라 어디에서 사용 했는지 (백엔드의 거의 모든 곳에서)입니다. 페이지를 렌더링하는 코드가 렌더링하는 데이터를 가져 오지 않는 경우 훨씬 더 나을 것입니다.

제대로 작동하려면 추가 스크립트와 리소스가 필요한 작은 위젯을 페이지에 추가한다고 가정합니다. 프레임 워크를 사용하는 경우 "이 문제에 대한 페이지에 종속성을 추가하려면 어떻게해야합니까?" 그렇지 않다면 질문은 더 개방적입니다. "어떻게 만져 져야 할 기술적 문제가 있습니까?" 이 질문에 대답하는 데 더 많은 경험이 필요하지만 힌트는 다음과 같습니다.

• 내일 모든 정적 리소스 (스크립트, 이미지 등)를 별도의 서버, 콘텐츠 전송 네트워크 등으로 옮기거나 성능을 향상시키기 위해 모두 함께 패키지하려고 시도하면 어떻게됩니까?
• 이 위젯을 다른 페이지에 배치하거나 동일한 페이지에 여러 개의 인스턴스를 배치하면 어떻게됩니까?
• 다른 버전의 위젯에서 AB 테스트를 어떻게 시작할 수 있습니까?

이 중 어느 것이 압도적으로 들린다면, 지금은 앱을 위해서가 아니라 자신의 개인적 성장을 위해 프레임 워크를 사용해야한다고 제안합니다 . 반드시 다시 시작하지 않아도됩니다. 대신 프레임 워크를 커리큘럼으로 사용하여 앱의 진화를 안내하십시오.

배우는 방법은 두 가지뿐입니다. 하나는 시행 착오에 의한 것이고, 다른 하나는 다른 사람들의 경험으로부터 배우는 것입니다. 시험 및 오류를 제거 할 수 없습니다. 소프트웨어 개발은 ​​본질적으로 지속적인 학습 분야이며, 새롭거나 다른 것을하지 않는 코드는 정의상 불필요합니다. (대신 이미 작성된 코드를 사용하십시오.)

비결은 개발 프로세스의 모든 단계에서 기존 지식 (전략, 모범 사례 및 코드 / 라이브러리 / 프레임 워크)을 적극적으로 찾아서이를 최소화하여 지속적으로 휠을 재발 명하지 않도록하는 것입니다.

그러나 현재 작성중인 응용 프로그램의 경우 첫 번째 관심사는 최소한의 평범한 노력 (코드 냄새와 비슷하지만 개발 과정)으로 끝내는 것입니다 . 인간 학습의 본질을 고려할 때 고품질을 달성하는 가장 빠른 방법은 무언가 로 시작하는 것 입니다. 이미 가지고있는 것을 비판하여 목표를 세울 수있을 때 목표를 이해하는 것이 훨씬 쉽습니다.

작성하는 많은 코드가 일회용 학습 프로세스이고 좋은 디자인 을 찾는 데 필요하다는 사실을 받아 들일 수 있다면이 를 유지하는 데 도움이됩니다. 결국, 소프트웨어 개발에 참여하게하는 것은 문제 해결의 도전이며, 현재하고있는 일이 가치가 있다면 그 도전은 항상 존재합니다 (위의 "지속적인 학습"진술 참조).

무엇보다도 "일을 긁어 내고 다시 시작하는 것" 은 결코 선택 의 여지 가 없습니다 ... 결국, 당신은 "십여명의 고객 이 있다고 말하지 않았 습니까?" 아직 무엇을 고려하는 일시 중지 그들은 그들이 지금은 (아마도)임을 감안하여 선언의 생각 "당신의 일에 완벽하게 행복!"

다음은 내가 사용하고 싶은 비유입니다.

• "제 직업은 사람들이 살기위한 집을 짓고 사람들이 사업을하는 등의 일을하는 것입니다." 저의 임무는 유용한 일을하기 위해 " 어쩌면 아주 작고 영광스러운 모래 조각" 을 만드는 것입니다. (건축업자가 석고 벽판, 도기 타일, 콘크리트 블록 및 2x4로 집을 짓는 것처럼)

• 그러나 집 빌더 정말 이백년에 많이 변경되지 않은 사용하는은 "손톱"반면 ( "라운드" "광장"까지 갈 제외하고 공압 못 박는 - 기계 유용 만들 수), 기술 우리가 사용하는 것은 끊임없이 변하고 때로는 매우 중대한 변화를 겪습니다. ( "그렇습니다.")

• 그럼에도 불구하고, 한 번에 지어진 각 집은 영원히 살 것이다 .” 당신은 그들을 퇴거시킬 수 없습니다. 일단 당신이 그것을 만들고 열쇠를 넘겨 주면 "더 이상 '당신의'집이 아닙니다." 그것은 바로 현재의 것이며, 매우 오랫동안 지속될 것입니다.

요즘 내 사업의 큰 부분은 클라이언트가 그 당시에 존재했던 기술은 "최첨단"을 사용하여, 삼십 년 이상 전에, 20, 열 내장 된 소프트웨어에 대처하는 데 도움이하는 것입니다 - 에헴 (그리고, 나는 기억한다) – 그리고 오늘도 여전히 봉사하고있다 (!).

미래의 증거를 보장하는 것은 거의 불가능합니다. 앱이 확장 가능한지 확인하는 것은 그리 어렵지 않습니다. 앱에 대한 성능 테스트를 작성하고 처리 할 수있는 클라이언트 수를 확인하면됩니다. 테스트를 작성하면 더 많은 변경 사항을 구현 한 후 앱의 작동 방식을 측정 할 수 있기 때문에 앱의 미래를 더욱 확실하게 증명할 수 있습니다.

wrt 프레임 워크, 나는 현명하게 성능 / 확장 성을 걱정하지 않을 것입니다. 이것은 쉽게 확인하고 해결할 수있는 것입니다. 더 큰 문제는 보안입니다. 웹 프레임 워크는 일반적으로 적절한 인증 코드, 쿠키, CSRF 보호 등을 작성하는 데 도움이됩니다. 특히 경험이 부족하면 해당 영역에 더 집중할 수 있습니다.

나는 학습 프레임 워크에 대한 의견을 쓰기 시작했지만 결국 답변과 비슷한 것으로 바뀌 었습니다.

어떤 프레임 워크를 모르는 것은 문제처럼 보입니다. 기본적으로 모든 webdev 작업에서 일부 프레임 워크 로 작업해야합니다 . 하나를 알고 나면 다른 프레임 워크를 배우는 것이 큰 문제는 아니지만 첫 번째 프레임 워크를 배우는 데 시간이 걸릴 수 있습니다. 프레임 워크를 피한다는 것은 여기서 비현실적인 접근 방식 인 증후군을 발명하지 않았 음을 나타낼 수 있습니다 .

첫 번째 프레임 워크를 아는 주요 요점은 공통 언어를 배우는 것입니다. 동료들 사이에서 인기있는 것을 배우십시오. 프레임 워크로 작성된 간단한 프로젝트를 수정 해 볼 수도 있습니다. 모르는 프레임 워크에서 프로젝트를 처음부터 시작하는 것은 매우 비효율적 인 학습 방법입니다.

실제 질문은 특정 프로젝트에 관한 것이며 프레임 워크로 포팅하는 것입니다. 그에 대한 대답은 다음과 같습니다. 그것은 달려 있으며 실제로 우리는 당신에게 말할 수 없습니다. 그러나, 당신이 모르는 프레임 워크에 물건을 포팅하는 것은 거의 확실하게 나쁜 생각 은 의미가 있는지조차 알 수 없다 . 따라서 일단 프레임 워크를 알고 좋아하면이 결정을 그대로 유지하고 어느 시점에서이 결정을 다시 검토해야합니다. 다른 답변에는 그러한 결정을 내릴 때 찾아야 할 것에 대한 좋은 점이 포함되어 있습니다.

이 기사는 2.5 년 전 Hacker News에서 많은 주목을 받았습니다 . 쉽게 확장 할 수없는 코드를 작성하십시오. 이 관점은 현재 코드베이스를 다루는 데 도움이 될 수도 있고 아닐 수도 있지만, 앞으로는 완벽주의 / 과잉 엔지니어링으로 인한 좌절을 방지하는 데 도움이 될 수 있습니다.

'코드 라인'을 '라인 사용'으로 표시하면 코드 라인을 삭제하면 유지 관리 비용이 절감됩니다. 재사용 가능한 소프트웨어를 구축하는 대신 일회용 소프트웨어를 구축해야합니다.

코드를 삭제하는 것이 코드를 작성하는 것보다 재미 있다고 말할 필요는 없습니다.

(강조 광산)

Hacker News 의 기사 스레드 도 읽을 가치가 있습니다.

미래의 증거를 만들고 규모 및 프레임 워크 원칙을 적용하는 한, 스스로 취해야 할 중요한 과제입니다. 아마 걱정하지 않아도 될 것입니다.

코드를 깨끗하게 유지하고 SOLID, DRY 원칙> Google을 따르십시오.

가능한 빨리로드 밸런서를 적용하십시오.

최소한 두 개의 웹 서버를 세우고 코드에서로드 밸런싱 시나리오를 처리하십시오.

마지막으로 LAMP보다 백만 명의 사용자를 처리하는 데 더 나은 스택이 있지만 완전히 가능하다고 확신합니다.

사례와 요점은 다음을 참조 하십시오 : https : //.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade 시험 대상으로.