Force.com 플랫폼의 단점 [닫기]

https://stackoverflow.com/questions/1664503

12-09-2019
|

문제

우리는 현재 포스닷컴 플랫폼을 우리의 개발 플랫폼으로 삼고 영업사원과 force.com 웹사이트에는 이것이 세계 최고의 플랫폼인 이유가 가득합니다.하지만 내가 찾고 있는 것은 그러한 플랫폼을 사용할 때의 몇 가지 실제 단점입니다.

해결책

시작하기위한 10은 다음과 같습니다.

정점은 독점 언어입니다. Force.com Eclipse 플러그인 이외에도 리팩토링, 코드 분석 등과 같은 툴링이 거의 없거나 전혀 없습니다.
Apex는 Java 5에서 모델링되었으며 다른 언어보다 뒤떨어지는 것으로 간주되며 툴링없이 ( #1 참조) 상당히 번거로울 수 있습니다.
배포는 여전히 많은 gotchas 및 수동 단계가있는 상당히 수동입니다. 이 상황은 시간이 지남에 따라 천천히 향상되지만 자동 배포가있는 데 익숙해지면 실망하게됩니다.
Apex에는 패키지/네임 스페이스가 없습니다. 모든 클래스, 인터페이스 등은 서버의 한 폴더에 거주합니다. 이로 인해 코드는 훨씬 덜 구성되어 있으며 클래스/인터페이스 이름은 이름 충돌을 피하고 컨텍스트를 제공하기 위해 반드시 길어집니다. 이것은 나의 가장 큰 불만 중 하나이며, 나는이 이유만으로 Force.com을 자유롭게 구축하기로 선택하지 않을 것입니다.
AKA Force.com Eclipse 플러그인 인 "Force.com IDE"는 매우 느립니다. 클래스 파일, 텍스트 파일 등에 관계없이 파일을 저장하는 것은 일반적으로 조직에있는 개체, 데이터 유형, 클래스 파일 등에 따라 5 초 이상, 때로는 30 초가 걸립니다. 저장은 또한 차단 조치이며, 컴파일뿐만 아니라 서버와 로컬 프로젝트의 전체 동기화가 필요합니다. Java 또는 .NET보다 느린 순서.
온라인 개발자 커뮤니티는 매우 건강 해 보이지 않습니다. 포럼 게시물이 많이 답변되지 않거나 해결되지 않은 것으로 나타났습니다. 포럼 소프트웨어 Salesforce.com이 사용하는 포럼 소프트웨어와 관련이있을 수 있다고 생각합니다.
Apex의 Data Access DSL은 원하는 것이 많습니다. (N) 최대 절전 모드, JPA 등과 같은 원격으로 경쟁하지도 않습니다.
Apex/Visualforce에서 앱을 개발하는 것은 주지사 Limits Engineering의 연습입니다. 프로그래머 시간의 절반은 수많은 주지사 한도 및 Visualforce View State 한계와 같은 다른 Gotchas를 피하기 위해 최적화하는 데 소비됩니다. 당신이 시작하기 위해 효율적인 코드를 작성하면이 문제가 발생하지 않을 것이라고 주장 할 수 있습니다. 그러나 세션에서 X 쿼리 이상을 만들거나 X 레코드 이상을 통해 반복해야 할 유효한 이유가 여러 번 있습니다.
저장-> compile-> run 사이클은 매우 느립니다. 사소한 CSS 또는 JavaScript 변경과 같은 작업을 수행하기 위해 전체 정적 리소스 번들을 지핑하고 업로드하는 경우.
일반적으로, 오픈 소스라는 이점이없는 젊고 신생 플랫폼의 고통. 플랫폼에서 버그를 검증 및/또는 수정할 방법이 없습니다. 그들은 그것을 그들의 아이디어 교환에 게시한다고 말합니다. 그래, 행운을 빕니다.

면책 조항/공개 : Force.com과 같은 호스팅 플랫폼에는 많은 이점이 있습니다. Force.com은 정기적으로 플랫폼을 향상시킵니다. 내가 좋아하는 것들이 많이 있습니다. 나는 Force.com에 돈을 버는데

다른 팁

나는 당신이 몇 가지 답을 얻었지만, 플랫폼의 다양한 주지사 한도를 둘러싼 시간이 얼마나 낭비되는지를 반복하고 싶습니다. 특정 수준의 플랫폼을 좋아하는 한, 나는 일반적인 응용 프로그램 개발 플랫폼으로서 매우 강력하고 강조 할 것입니다. 원하는 것이라면 슈퍼 구성 가능하고 확장 가능한 CRM 응용 프로그램으로 좋습니다. 그들의 마케팅은 Force.com의 일반적인 개발 플랫폼으로 추진하는 데 탁월하지만 아직 원격으로 가까운 것은 아닙니다.

안정적인 플랫폼을 갖고 큰 성능 및 안정성 문제를 피하는 효율성은 사람들이 언급 한 한계를 중심으로 코딩하려고 할 때 쉽게 낭비됩니다. 플랫폼에는 너무 많은 한계가있어 완전히 화가납니다. 이러한 한계는 사용자가 많으면 치르는 고급 한도가 아닙니다.

일반적으로 주변을 둘러싼 기술이 있지만 실제 응용 프로그램의 비즈니스 논리를 개발하려고하는 동안 피하는 전략을 찾기가 매우 어렵습니다.

개발자가 환경이 얼마나 친숙하지 않은지에 대한 간단한 감각을 제공하기 위해 위에서 언급 한 "디버깅 환경 부족"을 취하십시오. 그보다 나쁘다. 디버그 로그에서 서버에 대한 최신 요청의 최대 20 개만 볼 수 있습니다. 따라서 애플리케이션 내부를 개발할 때 "새"디버그 요청을 만들고 이름을 선택하고 "저장"을 누르고 앱으로 다시 전환하고 페이지를 새로 고치고 디버그 탭으로 다시 클릭하십시오. 디버그 로그를 수용 할 요청은 "찾기"를 누르면 원하는 텍스트를 검색합니다. 디버그 출력을 보는 것은 10 번의 클릭과 같습니다. 그것은 사소한 것처럼 보일지 모르지만, 그것은 개발자의 경험에 대한 보살핌과 고려가 얼마나 적은지의 예일뿐입니다.

개발 플랫폼에 관한 모든 것은 그라프 팅 애프터로 생각합니다. 그것이 무엇인지에 대해서는 놀랍지 만 대부분의 경우 총 피타입니다. 당신이 무엇을하고 있는지 정확히 알지 못하면 (인증을 받고 Apex에 대한 매우 친밀한 이해와 마찬가지로) 다른 환경에서해야 할 시간을 쉽게 10-20x 이상으로 이동할 수 있습니다. 당신이 전혀 성공할 수 있다면 말도 안되는 단순한 것 같아요.

주지사 한도는 실제로 그렇게 나쁘다. 다양한 제한 (데이터베이스 쿼리, 행 반환, "스크립트 문", 향후 통화, 콜 아웃 등)의 조합이 있으며 알아야합니다. 바로 그거죠 당신이 이것들을 피하기 위해하고있는 일. 예를 들어, 객체에 계산 된 롤업 "공식"필드가 있고 자식 객체에 트리거가있는 경우 부모 객체 트리거를 실행하고 한계에 대해 계산됩니다. 당신이 시도하고 실패하는 고통스러운 과정을 겪을 때까지 그런 것들은 분명하지 않습니다.

한계를 피하기 위해 한 가지를 시도하고 "한계를 잡지 못한 게임"에서 다른 한도를 맞이할 것입니다. 이 과정에서 전체 앱과 접근 방식을 크게 재건하고 모든 테스트 코드를 다시 작성해야합니다. 너 ~ 해야 하다 생산에 75%의 테스트 코드 적용 범위를 배포 할 수있는 테스트 코드 커버리지가 실제로 매우 좋지만 다른 모든 한도와 결합하면 매우 부담입니다. 실제로 일반 사용자 시나리오에서는 나오지 않는 테스트 코드를 작성하는 주지사 제한에 실제로 적용되지 않습니다.

그것은 다른 많은 다른 문제들에게는 말할 것도 없습니다. 포장은 당신이 기대하는 것이 아닙니다. ORG 관리자 측면에서 상당한 사용자 개입 및 구성없이 앱을 포장하여 사용자에게 전달할 수 없습니다. AppExChange는 총 농담이며 앱을 나열하기 위해 5K를 충전하기 시작했습니다. 데이터 로더로 가져 오는 것은 특히 트리거가있는 경우 짜증납니다. 한 단계로 모든 데이터를 한 단계로 내보내는 모든 데이터를 한 단계 (예 : DEV 조직)로 다른 조직에 쉽게 다시 인상 할 수있는 방식으로 관계를 포함하는 한 단계로 내보낼 수 없습니다. 생산에서 한 달에 한 번만 샌드 박스를 새로 고칠 수 있으며 예외는 없으며, 해당 기능을 잠금 해제하기 위해 계정 경영진에게 전화를 걸지 않으면 기본적으로 데이터를 기본적으로 포함시킬 수 없습니다. 사용자 정의 객체에서 데이터를 삭제할 수 없습니다. 패키지 이름을 변경할 수 없습니다. 어떤 것들은 수많은 걸릴 수 있습니다 날 앱을 배포하기 전에 데이터 백업과 같이 요청한 후 완료하려면 진행 상황을 따라 진행 보고서가없고 정확히 내보내기가 발생한시기에 대한 감각이 많지 않습니다. 데이터 간의 관계가있는 경우 데이터의 동기성 문제가 있기 때문에 단일 단계에서 수많은 객체를 내보낼 수있는 "트랜잭션"과 같은 것이 없다는 점에서 심각한 데이터 무결성 문제가 있습니다. 이 중 일부를 용이하게하기위한 상용 도구가있을 수 있지만, 이는 예산이 크지 않은 일반 개발자에게는 도달하지 못합니다.

다른 사람들이 여기서 말한 다른 모든 것은 사실입니다. 파일을 저장하는 데 때때로 5 초에서 1 분이 걸릴 수 있습니다.

플랫폼이 어떤면에서는 매우 시원하고 다른 사람이하지 않는 다중 테넌트 환경에서 일을하려고 노력하기 때문에 그렇게 부정적이라는 의미는 아닙니다. 그것은 매우 혁신적인 환경이며 일부 수준에서 강력하지만 (실제로는 Visualforce를 많이 좋아하지만) 1 년 또는 2 년을 더합니다. 그들은 vmware와 파트너 관계를 맺고있을 것입니다. 아마도 개발자에게 감옥에서 일하기보다는 약간의 플레이 펜을 제공 할 것입니다.

다음은 지난 2 주일에 플랫폼에서 발전하는 데 약간의 시간을 소비 한 후 여러분에게 줄 수있는 몇 가지 사항입니다.

편안한 API가 없습니다. 그들은 당신이 전화 할 수있는 비누 기반 API를 가지고 있지만, 진정한 편안한 전화를 걸 수있는 방법은 없습니다.
Sobject를 가져 와서 JSON 객체로 변환하는 간단한 방법은 없습니다.
시각적 힘 페이지는 사용자 정의하고 싶을 때까지 괜찮습니다. 그런 다음 통증의 전 세계입니다.
Visual Force 페이지는 Sobjects에 묶여 있어야합니다. 그렇지 않으면 DatePicker 또는 SELECT LIST와 같은 표준 입력 필드를 얻을 수있는 방법이 없습니다.
Eclipse 플러그인은 직접 작업하고 싶다면 괜찮지 만 Eclipse 플러그인을 사용하여 대형 팀에서 일하고 싶다면 잊어 버립니다. 서버와의 동기화를 처리하지 않고 충돌하며 실제로 도움이되지 않습니다.
디버거가 없습니다! 디버그를 원한다면 System.Debug 문자가 문자 그대로 디버깅됩니다. 이것은 아마도 내가 찾은 가장 큰 문제 일 것입니다
그들의 "MVC"모델은 실제로 MVC가 아닙니다. ASP.NET WebForms에 훨씬 가깝습니다. 귀하의 뷰는 모델뿐만 아니라 컨트롤러와 밀접하게 연결되어 있습니다.
많은 수의 문서를 저장하는 것은 불가능합니다. 우리는 100GB 이상의 문서를 저장해야하며 어리석은 인물을 인용했습니다. Amazons S3 인프라에서 문서 스토리지를 구현하기로 결정했습니다.
언어는 자바 기반이지만 자바가 아닙니다. 외부 패키지 나 라이브러리를 가져올 수 없습니다. 또한 사용 가능한 기본 라이브러리는 심각하게 제한되어있어 외부 적으로 많은 물건을 구현 한 다음 Force.com에서 호출되는 서비스로 그 비트를 노출했습니다.
외부 비누 또는 REST 기반 서비스를 호출 할 수 있지만 메시지 본문은 100KB로 제한되므로 호출 할 수있는 것이 매우 제한적입니다.

모든 정직함에 따르면, Force.com 플랫폼과 같은 것을 개발하는 데 잠재적 인 이점이 있지만, 나에게는 True Enterprise Level 앱에 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로만 삭제하려고한다고 언급했습니다. 세부 사항이 무엇인지 잘 모르겠습니다. 그들은 조기 접근을위한 휴식 API를 가지고 있으며, 클라우드에서 루비 개발 인 Heroku를 구입했습니다. Database.com을 사용하여 데이터베이스를 분할하므로 모든 웹 개발 및 Database.com을 사용하여 DB 호출을 수행 할 수 있습니다.

나는 그들이 가능한 한 불가지론 적으로 만들려고 노력하고 있다고 생각합니다. 그러나 지금 당장 이들은 모든 공지 사항과 조기 접근이므로 안전한 항구 진술은 현재의 말에 대해서만 구매하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow