ruby - 내가 잘못 이해할 때 어떻게하면 좋을까요?




web-services api (5)

개인 프로젝트를 완료하는 유일한 방법이 있다는 것을 알았습니다.

스마트하게 코드를 작성하고 나중에 계획하십시오. 프로토 타입을 개발하되 하나의 조각을 제거하고 다른 조각으로 교체 할 수 있도록 디자인하십시오.

언어 선택이 루비라면, 예를 들어 절대로 깨지지 않는 잘 정의 된 인터페이스를 갖도록 클래스를 빌드하십시오. 옳은 일을 "하고"있는 각 기능에 대해 걱정하고 실제로 어떻게하는지 신경 쓰지 않습니다.

그런 다음 모듈 식으로 제작 된 프로토 타입으로 돌아가서 한 번에 하나씩 수정하십시오.

배경

저는 약 5 년 동안 건설하려고 노력해 온 개인 프로젝트를 가지고 있습니다. 본질적으로 온라인 게임 인 웹 응용 프로그램입니다. "돈을 벌는 사람"이 아니라, 내가 정말로 만들고 싶어하는 것입니다. 그래서 숙련 된 팀을 고용 할 자금을 찾는 것은 거의 불가능합니다.

필자는 수년 동안 개념 / 사용자 테스트 측면에서 성공적이었던 두 가지 완전한 기능을 갖춘 프로토 타입을 만들었지 만 건축 적 관점에서 볼 때 두 번의 장황한 실패를 경험했습니다. 코드는 혼란스럽고, 유지 보수가 안되거나 더 발전 할 수 없어 버려 져야했습니다.

클라이언트를 구축하는 데 필요한 기술을 습득하는 데는 2 ~ 3 년이 걸렸습니다. 이는 풍부한 / 상태가 있고 매우 복잡합니다. 나는 발전 분열의이 측면으로 나의 경력과 연구를 조정했다. 나는 마침내 6 개월이 지나면 성장할 수 있고 정교하게 설계되고 정교한 클라이언트를 구축 할 수있는 시점에 있습니다. 저 앞에 할 일이 많이 있지만, 적어도 나는 그것을 할 수 있고 그것을 합리적으로 잘 할 수 있다는 것을 알고 있습니다. 백 엔드는 또 다른 이야기입니다.

지금까지 PHP, SQL, Ruby, CouchDB, MongoDB, FriendlyORM, NodeJS 등의 다양한 조합으로 백엔드를 적어도 11 회 이상 재구성했습니다. 접근 및 시작 : RPC to REST, 관계형 문서 기반. 조숙 한 최적화가 모든 악의 근원이라는 것을 잘 알고 있지만, 애플리케이션은 빠르게 움직이고 동적 인 데이터에 크게 의존합니다. RESTful API 디자인, 스케일링, 샤딩, 캐싱, 인증, 복제 - 나는 이것에 대한 많은 경험이 없으며, 언제든지 원격으로 괜찮은 모습을 기대할 수 없다. 이러한 것들은 수년간의 연구와 경험이 필요합니다.

이 분야의 전문가를 찾는 것이 더 합리적입니다.하지만 자금이 없으면 적절한 인재를 유치하기 위해 다른 프로토 타입을 성공적으로 배포해야한다고 생각합니다. 그래서 가능한 한 최선을 다해야합니다.

질문

그러나 내가 구축한다고 가정하면 백엔드 아키텍처가 잘못되어 다시 빌드해야 할 것입니다. 클라이언트 응용 프로그램의 개발을 계속할 수있을 정도로 "충분한"빌드를 진행하는 가장 좋은 방법은 무엇입니까? 심한 경우에도 JSON 웹 서비스를 "함께 사용"할 수있는 방법이 있습니까? Sinatra와 MongoDB의 루비? 장고? Out-o-the-box 웹 서비스 빌더가 있습니까? 프레젠테이션 레이어가 없기 때문에 전체 스택 웹 프레임 워크가 필요하지 않습니다. 모든 조언을 크게 주시면 감사하겠습니다.


깨끗하고 모듈화 된 코드로 느리게 작동하도록하십시오.

모듈화 된 것이라면 전체를 스크랩하지 않고 한두 레이어를 대체 할 수 있습니다.

모듈 방식을 제공하는 반면 웹 서비스는 조심해야합니다. REST는 속도가 느려지므로 조심해야합니다. 예를 들어 각 연결마다 많은 오버 헤드가 있습니다.


이런 유형의 크고 복잡한 응용 프로그램, 특히 상호 의존성이 많은 국가 별 조건 및 호환되지 않는 언어를 사용해야하는 클라이언트 / 서버 구분을 작성하는 것은 사용자가 응용 프로그램에 접근하는 방법과 상관없이 매우 어렵습니다. 이런 종류의 다른 프로젝트에 대한 내 경험에 비추어 볼 때, 얼마나 조심스럽게 할지라도 첫 번째 시도에서 실패 할 운명입니다. 그 트릭은 실패를 성공의 길에 따라 피할 수없는 발걸음으로 받아들이고 애플리케이션을 빌드 할 때 모든 작은 일들에 대해 소란스럽지 않게하는 것입니다.

첫 번째 임무는 가능한 한 적은 프로그래밍으로 "작동"시켜서 원하는대로 효과를 얻으려는 것입니다. 매우 대략적이라 할지라도 모든 것이 어떻게 잘 맞는지 확인할 수 있습니다. 큰 문제를 일련의 작은 문제로 분해하여 해결할 수 있다면, 하나의 요소로 성공을 거둘 수 있으며 더 크거나 다른 문제를 해결할 동기가 될 수 있습니다.

유용한 전략은 응용 프로그램의 요소를 느슨하게 결합 된 상태로 유지하여 엄격하게 요구되는 경우를 제외하고는 상호 의존성을 피하기위한 것이며 결과적으로 변경 사항이 발생하지 않고 전체 부분을 교체하거나 개선 할 수 있습니다. 예를 들어, 네트워크 코드는 상태의 본질을 신경 쓰지 않고 클라이언트와 서버간에 상태 변경을 전송할 수 있지만 상태 관리 코드는 상태가 전송되는 방식에 신경을 쓰지 않고 단지 그렇게 할 수 있습니다.

잡초를 놓치지 않도록 응용 프로그램의 전체 아키텍처를 처리하는 것도 유용합니다. 높은 수준의 관점에서 보면, 단순한, 모듈화 된, 그리고 작성하기 쉬운 코드로 다른 방법으로 코드를 정리하는 데 도움이되는 기본 디자인 패턴 을 잘 알고있을 수 있습니다.

프레임 워크와 언어에 관해서는 너무 자주 전환하지 않도록하십시오. 새로운 언어를 탐색하여 특정 문제에 도움이 될 수있는 기능을 확인하는 것은 교육적이지만, 일부 기능을 수행하기가 어려울지라도 지키면 생산성이 향상됩니다. 언어에 더 잘 맞도록 접근 방식을 향상시킵니다. 하스켈은 어떤 문제에 더 잘 어울릴 수 있지만, 평범한 구형 PHP조차도 충분한 결심으로 똑같은 일을하도록 코칭 될 수 있습니다.

새로운 일을 시도하고, 작업의 범위를 확장하여 "올바르게 수행"하고, 새로운 기능을 구축 할 수 있도록 유혹을 느끼지 만, 프로젝트를 계속 유지하려면 규율을 유지해야합니다 객관적으로 받아 들여지는 이러한 비싸고 혼란스러운 활동을 피하기 위해 프로젝트의 전반적인 상태를 감안할 때 공상 또는 조기 비행 만하십시오.

질문에 구체적으로 대답하려면 가장 친숙한 프레임 워크에서 강점을 위치 시키십시오. 그리고 유용한 결과를 만들어내는 작은 단위로 수행하십시오. 어쩌면 클라이언트 디스플레이 엔진, 네트워킹 구성 요소 또는 백엔드 상태 전환이 될 수도 있지만, 그것이 무엇이든 관계없이 다른 구성 요소를 연결하기에 "충분한"상태 여야합니다.

10 개의 작은 문제를 해결하는 것은 지루하고 시간이 오래 걸릴 수 있지만, 하나의 거대한 문제를 해결하는 것보다 훨씬 쉽습니다.


조니 G는 원래 질문에 대한 그의 말로 꽤 많이 못 박았습니다. 당신이 묘사하는 상황은 심지어 행운 500의 믿거 나 말거나에 발생합니다. 3 개월마다 가장 새롭고 멋진 테크놀로지를 선택하고 버리기 전에 프로젝트를 통해 구축 / 성취하려는 것을 계획해야합니다.

나는이 기사를 유선으로, 듀크 누크의 실패에 대해 "배울 수있는 방법"을 영원히 간파하는 것이 내가 할 수있는 것보다 더 잘 설명 할 것이라고 생각한다.

http://www.wired.com/magazine/2009/12/fail_duke_nukem/

(꽤 재미 있고 유익한 읽기에도 관계 없음)


프로젝트가 짜증나고 아무도 그것을 사용하지 않는다면 얼마나 최적화되어 있어야할까요? 엔드 투 엔드 (end-to-end) 버전을 구하십시오. 아직 고려하지 않은 다른 많은 문제를 발견하게 될 것입니다.





architecture