방금 rails new를 입력했습니다. 당신의 다음 프로젝트에. 이제 뭐? 어디서 시작합니까? 단일 앱에서 모든 것을 작성합니까, 아니면 서비스 지향 아키텍처를 사용합니까? 지금이 RSpec을 배우기에 좋은 시기인가요? 모든 데이터 모델 구축을 시작해야 합니까, 아니면 몇 가지 작업을 엔드 투 엔드로 실행해야 합니까? 미리 결정해야 할 결정 사항이 많이 있으며 길을 잃고 미루고 좌절하며 앱을 끝내지 않기 쉽습니다.
이 문제는 매우 일반적입니다. 이는 정보에 입각한 결정을 내리는 데 필요한 정보가 가장 적은 상황에서 너무 많은 선택을 미리 해야 하는 데서 비롯됩니다.
의사결정에 대한 협약
구성보다 규칙은 내가 가장 좋아하는 Rails 원칙입니다. Rails를 사용하기 전에는 파일을 어디에 둘지, 데이터베이스 테이블의 이름을 무엇으로 지정할지, 객체에 매핑하는 방법, 기타 사소한 무의미한 결정을 하는 데 어려움을 겪었습니다. 나중에 내가 틀렸다는 것을 알게 된다면 생각을 바꾸는 데 걸리는 시간보다 방향을 선택하는 데 더 많은 시간을 할애할 것입니다.
새로운 프로젝트를 시작할 때 직면하는 많은 결정은 다음과 같습니다. 그러나 협약을 차용하면 이러한 결정을 대체할 수 있습니다. 책, 블로그 또는 스타일 가이드에서. 그리고 많은 시간, 스트레스, 의미 없는 토론을 절약할 수 있습니다.
다음은 새 앱을 시작할 때 따르는 몇 가지 규칙입니다.
-
몇 가지 전체 기능으로 시작하세요.
앱에서 바로 생각할 수 있는 모든 작업을 수행할 필요는 없습니다. 작게 시작하고 간단하게 시작하십시오. 없이는 살 수 없는 한두 가지 기능을 파악하고 먼저 그 기능에 모든 관심을 집중하세요. 정말 잘 만드세요. 필요한 경우 나중에 다른 항목을 추가할 수 있습니다. 하지만 아마, YAGNI. (그리고 보통 당신이 귀하가 필요로 하는 것이 귀하의 고객과 완전히 다르다고 생각하는 경우 필요하다고 생각하세요).
-
단일 앱으로 시작하세요.
모노레일 건설을 피하고 싶은 거 알아요. 그리고 6개의 RailsConf에서 SOA가 Rails 앱을 장기적으로 유지 관리할 수 있는 가장 좋은 방법인 방법에 대해 이야기합니다. 앱의 어떤 부분이 독립적일 수 있는지 파악하고 각 부분에 대한 서비스를 구축해야 하지 않겠습니까?
SOA는 크고 복잡한 앱을 분리하는 좋은 방법입니다. 하지만 톤이 추가됩니다. 그리고 서비스 구축, 유지 관리 및 모니터링의 고통이 모놀리식 Rails 앱 작업의 고통보다 크지 않다면 할 가치가 없습니다. 시작하지 않은 경우 아직 앱을 작성하고 있지만 고통을 느끼지는 않습니다. 하나의 앱으로 시작하세요.
-
이전에 사용한 스택으로 시작합니다.
스택을 아직 모르면 Omakase 스택을 사용하십시오. 그러나 어느 쪽이든 이전에 한 번도 사용하지 않은 테스트 프레임워크를 Rails와 통합하는 데 반나절을 보내고 싶지는 않습니다. VCR과 WebMock 간의 버전 충돌과 싸우고 싶지 않습니다. 테스트 충돌이 당신의 잘못인지 resque_unit의 잘못인지 파악하고 싶지 않을 것입니다. 새로운 라이브러리를 사용해보고 싶다면 언제든지 나중에 추가할 수 있습니다(또는 장난감 프로젝트에서 사용해 보세요).
배송이 어렵습니다. 앱을 완성하려면 얻을 수 있는 모든 이점을 긁어모아야 합니다. 그러니 작게 시작하고, 간단하게 시작하고, 알고 있는 것부터 시작하십시오.
대회가 항상 완벽하지는 않지만 시작하는 데 도움이 될 것입니다. 그리고 시작하는 것이 가장 어려운 부분입니다.
다음은 무엇입니까?
프로젝트에서 어떤 규칙을 따르나요? 그리고 시작해야 할 기능이나 테스트를 어떻게 결정합니까? 다음에 제 생각을 말씀드리겠지만 여러분의 의견을 듣고 싶습니다.