Rails가 그렇게 빠르게 인기를 얻은 이유는 무엇입니까?
특히 Java, XML, Enterprise 세계에서 온 경우 단순함이 도움이 되었습니다. 그것은 또한 믿을 수 없을 정도로 잘 팔렸습니다. 하지만 그게 다가 아닙니다.
신생 기업에서 Rails의 많은 성공은 단순한 사실에서 비롯되었습니다. 기업이 겪는 문제는 그렇게 독특하지 않다는 것입니다. Rails는 유연성을 유지하면서 CRUD 사이트를 만드는 데 탁월했습니다. 정말 톤입니다. 기업이 필요합니다. 특히 초반에.
그러나 이것은 기업에만 해당되는 것은 아닙니다. 소프트웨어 개발자로서 직면하는 많은 문제는 변하지 않습니다. 물론, 우리의 솔루션은 진화합니다. 그들은 순환합니다. 우리는 나아진다. 그러나 마지막 세대의 개발자들이 발견한 동일한 솔루션이 오늘날에도 여전히 도움이 될 수 있습니다.
그렇다면 앞으로 직면하게 될 문제에 대한 답을 알고 싶으십니까? 당신이 할 수 있는 최선은 과거를 돌아보는 것입니다.
과거 살펴보기
Martin Fowler는 자신의 웹사이트에서 일반적인 문제에 대한 믿을 수 없는 훌륭한 솔루션 모음을 보유하고 있습니다. . 개발자가 이벤트 소싱에 대해 이야기하는 것을 들어본 적이 있습니까? 그는 10년 전에 이에 대한 확실한 기사를 썼습니다. 새로운 REST API 또는 서비스 지향 아키텍처로 성능 및 안정성 문제를 찾고 계십니까? 15년 전의 그의 첫 번째 분산 객체 법칙입니다.
Avdi Grimm은 "기술 곡선을 주도하고 싶다면 Martin Fowler가 약 10년 전에 썼던 것이 무엇이든 조사를 시작하십시오."라고 말했습니다. 사실입니다. 그의 웹사이트에서 패턴을 읽는 데 보내는 시간은 프로그래밍의 미래에 큰 투자가 될 것입니다. 리팩토링 패턴은 언급조차 하지 않았습니다.
더 나아가 Agile Manifesto의 저자가 작성한 거의 모든 책이나 기사는 읽을 가치가 있습니다. 15년 전 그들은 오늘날 우리가 직면한 동일한 소프트웨어 아키텍처 문제를 겪고 있었습니다.
C2 Wiki에서 많은 토론을 찾을 수 있습니다. . TDD가 가장 합리적인 시점에 대한 논쟁은 무엇입니까? 모두 있습니다. 그리고 그들은 되었습니다 거기. Wiki는 나온 지 얼마 되지 않았지만 여전히 훌륭한 리소스입니다.
90년대 후반에서 2000년대 초반의 책도 도움이 됩니다. Smalltalk Best Practice Patterns and Patterns of Enterprise Application Architecture(Rails에 큰 영향을 미쳤습니다)를 통해 내내 미소를 지었습니다. 그들이 너무나 잘 겪었던 문제를 설명했기 때문입니다. .
디자인 패션과 마찬가지로 소프트웨어 개발 관행도 순환합니다. 분산에서 중앙 집중식으로, 클라이언트 측에서 서버 측으로, 동적에서 정적으로.
앞으로 나아가고 미래를 이해하고 운전하고 싶습니까? 다음에 오는 것은 무엇입니까? 과거를 봐. 현재 솔루션이 야기할 문제에 대한 솔루션을 연구합니다. 그리고 마지막 세대의 소프트웨어 개발자들의 모범 사례를 다음 세대로 가져오는 데 도움을 주십시오.