우리는 현재 Force.com 플랫폼을 개발 플랫폼으로 사용하고 있으며 영업 담당자와 force.com 웹 사이트는 왜 이것이 세계 최고의 플랫폼인지에 대한 이유로 가득 차 있습니다. 하지만 제가 찾고있는 것은 그러한 플랫폼을 사용하는 데있어 몇 가지 실질적인 단점입니다.
답변:
시작하는 데 필요한 10 가지 정보가 있습니다.
고지 사항 / 공개 : force.com과 같은 호스팅 플랫폼에는 많은 이점이 있습니다. Force.com은 정기적으로 플랫폼을 향상시킵니다. 내가 좋아하는 것들이 많이 있습니다. force.com에서 돈을 벌어
몇 가지 답변을 받았지만 플랫폼의 다양한 주지사 한계를 극복하는 데 얼마나 많은 시간이 낭비되는지 반복하고 싶습니다. 특정 수준의 플랫폼을 좋아하는만큼 일반적인 응용 프로그램 개발 플랫폼으로 강력하고 강력하게 반대 할 것을 강력히 권장합니다. 원하는 경우 매우 구성 가능하고 확장 가능한 CRM 응용 프로그램으로 좋습니다. 그들의 마케팅은 Force.com의 아이디어를 일반 개발 플랫폼으로 추진하는 데 탁월하지만 아직 멀리 떨어져 있지도 않습니다.
사람들이 언급하는 한계를 기준으로 코드를 작성하는 데있어 안정적인 플랫폼을 보유하고 큰 성능 및 안정성 문제를 피하는 효율성은 쉽게 낭비됩니다. 플랫폼에는 너무 많은 한계가있어서 완전히 미쳐 버립니다. 이러한 제한은 사용자가 많을 때 적용되는 최고 수준의 제한이 아니며 거의 즉시 적용됩니다.
일반적으로 이러한 문제를 해결할 수있는 기술이 있지만 실제 애플리케이션의 비즈니스 논리를 개발하는 동안에도이를 방지하기위한 전략을 파악하는 것은 매우 어렵습니다.
개발자가 환경에 얼마나 비 친화적인지 간단하게 이해하려면 위에서 언급 한 "디버깅 환경 부족"을 고려하십시오. 그것보다 더 나쁩니다. 디버그 로그에서 서버에 대한 최근 요청을 최대 20 개까지만 볼 수 있습니다. 따라서 응용 프로그램 내부에서 개발할 때 "새로 만들기"디버그 요청을 만들고 이름을 선택하고 "저장"을 누른 다음 앱으로 다시 전환하고 페이지를 새로 고치고 디버그 탭으로 돌아가서 찾아야합니다. 디버그 로그를 저장할 요청에서 "찾기"를 눌러 찾고있는 텍스트를 검색하십시오. 디버그 출력을보기 위해 10 번 클릭하는 것과 같습니다. 사소 해 보일지 모르지만 개발자의 경험에 대한 관심과 고려가 얼마나 적은지를 보여주는 예일뿐입니다.
개발 플랫폼에 대한 모든 것은 나중에 접목 된 것입니다. 그것이 무엇인지에 대해 놀랍지 만 대부분의 경우 전체 PITA입니다. 자신이 무엇을하고 있는지 정확히 알지 못하는 경우 (인증을 받았으며 Apex에 대해 매우 친밀한 이해가있는 경우) 다른 환경에서 수행하는 데 걸리는 시간의 10 ~ 20 배 이상이 쉽게 걸립니다. 당신이 전혀 성공할 수 있다면 말도 안되게 간단 할 것 같은 무언가.
주지사 한계는 실제로 그렇게 나쁩니다. 다양한 제한 (데이터베이스 쿼리, 반환 된 행, "스크립트 문", 향후 호출, 콜 아웃 등)의 조합 이 있으며이를 방지하기 위해 수행중인 작업을 정확히 알아야 합니다 . 예를 들어 개체에 계산 된 롤업 "수식"필드가 있고 하위 개체에 대한 트리거가있는 경우 상위 개체 트리거를 실행하고 제한에 대해 계산합니다. 그런 것들은 당신이 시도하고 실패하는 고통스러운 과정을 거치기 전까지는 분명하지 않습니다.
당신은 하나의 제한을 피하기 위해 한 가지 시도를하고 "한계를 깨뜨리기"라는 끝이없는 게임에서 다른 것을 치게 될 것입니다. 이 과정에서 전체 앱 및 접근 방식을 대폭 재구성하고 모든 테스트 코드를 다시 작성해야합니다. 당신은 있어야합니다 실제로 매우 좋은 일이지만, 다른 기준을 모두 결합 생산에 배포하는 75 %의 테스트 코드 범위를 가지고, 그것은 부담이 매우이다. 실제로 일반 사용자 시나리오에서는 나오지 않는 테스트 코드를 작성하는 거버너 제한에 도달하지만 이로 인해 적용 범위를 달성 할 수 없습니다.
그것은 다른 많은 문제를 언급하지 않습니다. 포장은 당신이 기대하는 것이 아닙니다. 조직 관리자의 상당한 사용자 개입 및 구성 없이는 앱을 패키징하여 사용자에게 전달할 수 없습니다. AppExchange는 완전히 농담이며 앱을 나열하기 위해 5K를 충전하기 시작했습니다. 특히 트리거가있는 경우 데이터 로더를 사용하여 가져 오기가 어렵습니다. 한 단계에서 다른 조직 (예 : 개발 조직)으로 쉽게 다시 가져올 수있는 방식으로 관계를 포함하는 모든 데이터를 한 단계로 내보낼 수는 없습니다. 프로덕션에서 한 달에 한 번만 샌드 박스를 새로 고칠 수 있으며 예외는 없으며 계정 관리자에게 전화하여 해당 기능을 잠금 해제하지 않는 한 기본적으로 새로 고침에 데이터를 포함 할 수 없습니다. 당신은 할 수 있습니다 t 사용자 지정 개체의 데이터를 대량 삭제합니다. 패키지 이름은 변경할 수 없습니다. 어떤 것들은 수많은앱을 배포하기 전에 데이터 백업과 같이 요청한 후 완료해야하는 일. 진행률 보고서가없고 정확히 언제 내보내기가 발생했는지 알지 못합니다. 데이터간에 관계가있는 경우 데이터의 동시성 문제가 있다는 점을 감안할 때 여러 개체를 한 번에 내보낼 수있는 "트랜잭션"과 같은 것이 없다는 점에서 심각한 데이터 무결성 문제가 있습니다. 이 중 일부를 용이하게하는 몇 가지 상용 도구가있을 수 있지만 이러한 도구는 막대한 예산이 없을 수도있는 일반 개발자가 사용할 수 없습니다.
다른 사람들이 여기서 말한 다른 모든 것은 사실입니다. 파일을 저장하는 데 5 초에서 1 분까지 걸릴 수 있습니다.
플랫폼이 어떤면에서 매우 멋지고 다른 사람이하지 않는 멀티 테넌트 환경에서 일을하려고하기 때문에 그렇게 부정적이라는 뜻은 아닙니다. 매우 혁신적인 환경이며 일부 수준에서는 강력하지만 (실제로 VisualForce를 많이 좋아합니다) 1 ~ 2 년 더 기다려주세요. 그들은 VMware와 파트너 관계를 맺고 있습니다. 아마도 개발자에게 감옥이 아닌 플레이 펜을 더 많이 제공 할 것입니다.
지난 2 주 동안 플랫폼 개발에 상당한 시간을 투자 한 후 제가 드릴 수있는 몇 가지 사항은 다음과 같습니다.
RESTful API가 없습니다. 호출 할 수있는 SOAP 기반 API가 있지만 진정으로 편안한 호출을 할 수있는 방법은 없습니다.
SObject를 가져 와서 JSON 객체로 변환하는 간단한 방법은 없습니다.
비주얼 포스 페이지는 사용자 정의하고 싶을 때까지 괜찮습니다.
Visual force 페이지는 SObject에 바인딩되어야합니다. 그렇지 않으면 datepicker 또는 선택 목록과 같은 표준 입력 필드를 가져올 수있는 방법이 없습니다.
혼자서 작업하고 싶다면 eclipse 플러그인은 괜찮지 만 eclipse 플러그인으로 대규모 팀에서 작업하려면 잊어 버리세요. 서버와의 동기화를 처리하지 않으며 충돌이 발생하며 전혀 도움이되지 않습니다.
디버거가 없습니다! 디버그하려면 말 그대로 system.debug 문에 의해 디버그됩니다. 이것은 아마도 제가 발견 한 가장 큰 문제 일 것입니다
그들의 "MVC"모델은 실제로 MVC가 아닙니다. ASP.NET Webforms에 훨씬 더 가깝습니다. 뷰는 모델뿐만 아니라 컨트롤러에도 밀접하게 연결됩니다.
많은 수의 문서를 저장하는 것은 불가능합니다. 100GB가 넘는 문서를 저장해야하는데 말도 안되는 수치를 인용했습니다. Amazon S3 인프라에 문서 스토리지를 구현하기로 결정했습니다.
심지어 언어가 자바 기반이지만 자바가 아닙니다. 외부 패키지 또는 라이브러리를 가져올 수 없습니다. 또한 사용 가능한 기본 라이브러리는 엄격하게 제한되어 있으므로 외부에서 많은 것을 구현 한 다음 이러한 비트를 force.com에서 호출하는 서비스로 노출했습니다.
외부 SOAP 또는 REST 기반 서비스를 호출 할 수 있지만 메시지 본문은 100kb로 제한되므로 호출 할 수있는 항목이 매우 제한적입니다.
솔직히 말해서 force.com 플랫폼과 같은 것을 개발하면 잠재적 인 이점이 있지만, 진정한 엔터프라이즈 수준 앱에는 force.com 플랫폼을 사용할 수 없었습니다. 기껏해야 기본적인 crud 스타일 응용 프로그램을 작성할 수 있지만 원격으로 복잡한 작업으로 이동하면 전염병처럼 피할 수 있습니다.
와우-여기에는 몇 년 동안 플랫폼에서 작업 한 후 한계라는 사실조차 몰랐던 많은 것들이 있습니다.
하지만 다른 것들을 추가하기 위해 ...
라인 별 디버거가없는 이유는 멀티 테넌트 플랫폼이기 때문입니다. 적어도 그것이 SFDC가 말한 것입니다. 스레드가 풍부한 프로그래밍 시대에 그렇게 보이지만 그게 변명 거리는 아니지만 그 이유가 분명합니다. 코드를 작성해야하는 경우 디버거로 "System.debug (String)"가 있습니다. 약 12 년 전에 Java 1.2에서보다 정교한 서버 디버깅 도구를 사용했던 것을 기억합니다.
시스템에 대해 제가 정말 싫어하는 또 다른 점은 버전 관리입니다. Spring 프레임 워크는 Spring이 일반적으로 사용되는 용도로 사용되지 않습니다. 실제로 버전 제어가 아닌 SFDC의 구성 도구에 더 가깝습니다. SFDC는 ZERO 버전 제어를 제공합니다.
예를 들어 SFDC 보고서를 CSV 파일로 내보내고 수신자 목록에 이메일을 보내도록 예약하는 것과 같이 엄청나게 쉬운 일을 며칠 동안 꼼짝 못하게 할 수 있습니다 ... 음, 가장 쉬운 방법은 다음과 같습니다. 워크 플로 규칙 및 Visualforce 이메일 템플릿을 사용하여 사용자 정의 필드로 사용자 정의 개체를 생성 한 다음 코드의 경우 보고서 데이터를 Visualforce 이메일 템플릿에 첨부 파일로 스트리밍하는 Visualforce 구성 요소를 작성하고 익명 APEX를 작성해야합니다. 사용자 정의 개체의 코드 일정 필드 업데이트 ... SFDC 개발자에게 이것은 거의 일상적인 작업입니다 ... 약 5 개의 다른 기술을 결합하여 간단 해 보이는 작업을 수행하려고합니다 .... 그리고 이로 인해 관리 문제가 발생할 수 있습니다. 그리고 긴장도-일반적으로, 당신은 무언가를하라는 제안을받은 후에 이것을 알게 될 것입니다.사용자 커뮤니티 (누군가가 이미 말한 것처럼)에서 일하고, 개발 한 후에는 이상한 이유로 작동하지 않는다는 것을 알게되는 많은 일을 시도합니다. VisualForce 페이지 "또는"예약 가능한 컨텍스트에서 getContent를 호출 할 수 없습니다 "또는 기타 신비한 이유.
SFDC 플랫폼에는 미친 짓거리가 너무 많아서 그들이 왜 거기에 있는지 알면 의미가 있습니다 ...하지만 여전히해야 할 일을하지 못하게하는 매우 나쁜 한계입니다. 여기 내 일부가 있습니다.
거의 모든 종류의 레코드에 대해서는 레코드 소유자 정보를 "즉시"얻을 수 없습니다. 레코드를 만들 때 소유자를 삽입하는 레코드에 연결하는 트리거를 작성해야합니다. 왜? 소유자는 "사람"또는 "대기열"일 수 있고 두 개체는 완전히 다른 개체이기 때문에 짧은 대답입니다. 말이 되겠지만 말 그대로 프로젝트를 뒤집을 수 있습니다.
미친 보안 모델. 예 : "공개 보고서 관리"권한은 "보고서 작성 및 사용자 지정"과는 크게 다르며 기본적으로 플랫폼의 모든 항목, 특히 모든 종류의 폴더에 적용됩니다.
언급했듯이 지원은 기본적으로 존재하지 않습니다. 매우 자급 자족하거나 SFDC 리소스가 많거나 시간 및 / 또는 매우 관대 한 관리자가 있거나 잘 작동하는 SFDC 시스템을 담당하고 있다면 꽤 괜찮은 것입니다. 모양. 이러한 위치에 있지 않으면 심각한 문제에 처할 수 있습니다.
SFDC는 매우 매혹적인 비즈니스 제안입니다. 장비 설치 공간이없고, 보안이 우수하고, 고정 가격, 인프라가 없으며, 배치 가능하고 예약 가능한 처리 기능을 갖춘 웹 기반 CRM을 얻을 수 있습니다.하지만 다른 포스터에서 말했듯이 실제로는 개발 학습이 상당히 증가했고 컨설팅을 받으면 제가 본 최저 가격은 시간당 200 달러라고 생각합니다.
Salesforce는 일부 기술이 일반화되고 몇 년 후에 다른 것들과 통합되는 경향이 있습니다. JSON 및 jquery가 떠오르면 ... JIRA와 같이 통합하려는 다른 공통 인프라가있는 경우 추가 비용이 많이 듭니다. 그리고 그들은 아주 버그가있을 수 있습니다.
그리고 언급 된 다른 포스터 중 하나가 당신을 미치게 만들 수있는 주지사 한계와 끊임없이 싸우고 있습니다. 첨부 파일은 5MB를 초과 할 수 없습니다. 기간. 때로는 <3MB (base64로 인코딩 된 경우). 한 클래스에 10 개의 HTTP 콜 아웃. 기간. 수십 개의 게시 된 주지사 제한이 있으며, 의심 할 여지없이 찾을 수 없으며 비명을 지르며 사무실에서 벗어나고 싶어하는 제한이 많습니다.
나는 정말로 플랫폼을 정말 좋아하지만 나를 믿습니다. 정말 잔인한 여주인이 될 수 있습니다.
그러나 SFDC에 대해 공정하게 말하자면, 플랫폼에서 내가 발견 한 가장 큰 문제는 플랫폼 자체가 아니라 플랫폼을보고 개발하지 않은 거의 모든 사람들이 가지고있는 엄청난 기대입니다 .... 그리고 그 사람들은 비즈니스 조직에서 큰 권위를 가진 위치에있는 경향이 있습니다. 마케팅, 영업, 관리 등. 엄청난 단절이 발생하고 머리가 굴러 가거나 매일 굴러가 겠다는 위협을 받고 있습니다.이 모든 것이 이상한 문제와 수천 명의 사람들이 매일 일이 제대로 작동해야하는 이유를 파악하기 위해 고군분투하는이 훌륭한 플랫폼이 있기 때문입니다. 그들은하지 않고하지 않을 것입니다.
편집 :
MVC에 대한 lomaxx의 의견에 추가하기 위해; SFDC 용어에서 이것은 "viewstate"라고 알려진 것과 밀접한 관련이 있습니다. 그리고 VF 페이지에있는 것이 페이지 의 컨트롤러 클래스에있는 것이 아니라는 점에서 실제로 버그가있을 수 있습니다 . 따라서 "저장"버튼을 클릭 할 때 (또는 HTTP 콜 아웃 등을 만들 때) 컨트롤러가 SF에 기록 할 내용과 페이지에있는 내용을 동기화하려면 이상한 회전을 거쳐야합니다. .
다른 사람들이 단점을 더 깊이 다루었다고 생각하지만 나에게는 MVC 패러다임을 사용하지 않거나 코드 재사용 방식을 많이 지원하지 않는 것 같습니다. 단순한 응용 프로그램 이외의 작업을 수행하는 것은 ASP.Net MVC와 같은 것을 사용하여 응용 프로그램을 개발하는 것에 비해 실망스러운 일입니다.
또한 도구, 데이터 레이어 및 개발 프로세스 중에 코드를 리팩터링하거나 필드 이름을 변경하려는 좌절감도 도움이되지 않습니다.
나는 CMS로서 그것은 꽤 멋지다고 생각하지만 비 CMS 응용 프로그램을위한 플랫폼 으로서는 나에게 의미가 없습니다.
Force.com이 "클라우드"플랫폼이라는 점을 고려할 때 외부 WSDL 정의 서비스에 대한 클라이언트 역할을 수행하는 기능은 상당히 압도적입니다. 해야 할 일에 대해서는 http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ 를 참조 하십시오 .
위의 모든 것에 대해 저는 Java 프로그래머가 Force.com에 대한 코드를 작성할 수있는 VMforce 릴리스가 위의 단점을 어떻게 변경하는지 궁금합니다.
http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071
나는 그들이 이러한 문제를 해결하려고 노력하고 있다고 생각합니다. dreamforce에서 그들은 우리가 주지사 한도를 4로만 낮추려고한다고 언급했습니다. 세부 사항이 무엇인지 잘 모르겠습니다. 그들은 조기 액세스를위한 REST API를 가지고 있으며 클라우드에서 루비 개발 인 heroku를 구입했습니다. 그들은 database.com을 사용하여 데이터베이스를 분할하므로 database.com을 사용하여 모든 웹 개발과 db 호출을 수행 할 수 있습니다.
나는 그들이 그것을 가능한 한 불가지론 적으로 만들려고 노력하고 있다고 생각합니다. 하지만 지금은이 모든 것이 발표 및 조기 액세스이므로 세이프 하버 성명은 그들이 말하는 것을 구매하지 않고 현재 가지고있는 것에 대해서만 구매합니다.