Kekurangan dari platform Force.com [ditutup]

Saat ini kami sedang menggunakan platform Force.com sebagai platform pengembangan kami dan staf penjualan serta situs web force.com penuh dengan alasan mengapa ini adalah platform terbaik di dunia. Apa yang saya cari, bagaimanapun, adalah beberapa kerugian nyata menggunakan platform semacam itu.

Berikut 10 hal untuk Anda mulai.

1. Apex adalah bahasa berpemilik. Selain plugin force.com Eclipse, ada sedikit atau tidak ada perkakas yang tersedia seperti pemfaktoran ulang, analisis kode, dll.
2. Apex dimodelkan pada Java 5, yang dianggap tertinggal dari bahasa lain, dan tanpa perkakas (lihat # 1), bisa sangat merepotkan.
3. Deployment masih cukup manual dengan banyak gotcha dan langkah manual. Situasi ini perlahan-lahan membaik dari waktu ke waktu, tetapi Anda akan kecewa jika terbiasa memiliki penerapan otomatis.
4. Apex tidak memiliki paket / ruang nama. Semua kelas, antarmuka, dll. Anda tinggal dalam satu folder di server. Hal ini membuat kode menjadi kurang terorganisir dan nama kelas / antarmuka perlu panjang untuk menghindari bentrokan nama dan untuk memberikan konteks. Ini adalah salah satu keluhan terbesar saya, dan saya tidak akan dengan bebas memilih untuk membangun force.com hanya karena alasan ini.
5. "Force.com IDE", alias plugin eclipse force.com, sangat lambat. Menyimpan file apa pun, apakah itu file kelas, file teks, dll., Biasanya membutuhkan waktu setidaknya 5 detik dan terkadang hingga 30 detik tergantung pada berapa banyak objek, tipe data, file kelas, dll. Yang ada di organisasi Anda. Menyimpan juga merupakan tindakan pemblokiran, yang tidak hanya membutuhkan kompilasi, tetapi juga sinkronisasi penuh proyek lokal Anda dengan server. Urutan besarnya lebih lambat dari Java atau .NET.
6. Komunitas pengembang online tampaknya tidak terlalu sehat. Saya melihat banyak posting forum tidak terjawab atau tidak terpecahkan. Saya pikir ini mungkin ada hubungannya dengan perangkat lunak forum yang digunakan salesforce.com, yang tampaknya menyedot cukup keras.
7. Akses data DSL di Apex meninggalkan banyak hal yang diinginkan. Ini bahkan tidak bersaing dengan orang-orang seperti (N) Hibernate, JPA, dll.
8. Mengembangkan aplikasi di Apex / VisualForce adalah latihan dalam rekayasa batas gubernur. Setengah dari waktu programmer dengan mudah dihabiskan untuk mencoba mengoptimalkan untuk menghindari banyak batas gubernur dan masalah lain seperti batas status tampilan gaya visual. Dapat dikatakan bahwa jika Anda menulis kode yang efisien untuk memulai, Anda tidak akan memiliki masalah ini, yang sampai batas tertentu benar. Namun ada banyak kali Anda memiliki alasan yang valid untuk membuat lebih dari x kueri dalam satu sesi, atau mengulang melalui lebih dari x rekaman, dll.
9. Siklus save-> compile-> run sangat lambat, esp. ketika itu melibatkan pembuatan zip dan pengunggahan seluruh paket sumber daya statis hanya untuk melakukan sesuatu seperti menguji perubahan kecil CSS atau javascript.
10. Secara umum, rasa sakit dari platform muda dan pemula tanpa manfaat dari itu menjadi open source. Anda tidak memiliki cara untuk memvalidasi dan / atau memperbaiki bug di platform. Mereka mengatakan untuk mempostingnya ke IdeaExchange mereka. Ya, semoga berhasil.

Penafian / Pengungkapan: Ada banyak manfaat untuk platform yang dihosting seperti force.com. Force.com secara teratur meningkatkan platform. Ada banyak hal yang saya suka. Saya menghasilkan uang dari force.com

Saya melihat Anda mendapatkan beberapa jawaban, tetapi saya ingin menegaskan kembali berapa banyak waktu yang terbuang untuk mengatasi berbagai batasan gubernur di platform. Sebanyak saya suka platform pada level tertentu, saya akan sangat, sangat, dengan tegas merekomendasikan untuk tidak menggunakannya sebagai platform pengembangan aplikasi umum. Ini bagus sebagai aplikasi CRM yang sangat dapat dikonfigurasi dan diperluas jika itu yang Anda inginkan. Sementara pemasaran mereka luar biasa dalam mendorong gagasan Force.com sebagai platform pengembangan umum, itu bahkan belum mendekati.

Efisiensi dari memiliki platform yang stabil dan menghindari masalah kinerja dan stabilitas yang besar dengan mudah terbuang percuma dalam mencoba membuat kode di sekitar batasan yang dirujuk orang. Ada begitu banyak batasan pada platform, itu menjadi sangat menjengkelkan. Batasan ini bukanlah batas kelas atas yang akan Anda capai setelah Anda memiliki banyak pengguna, Anda akan segera mencapai batas tersebut.

Meskipun biasanya ada teknik untuk menyiasatinya, sangat sulit untuk menemukan strategi untuk menghindarinya saat Anda juga mencoba mengembangkan logika bisnis dari aplikasi Anda yang sebenarnya.

Untuk memberi Anda gambaran sederhana tentang bagaimana pengembang tidak ramah lingkungan, lihat "kurangnya lingkungan debugging" yang dirujuk di atas. Lebih buruk dari itu. Anda hanya dapat melihat hingga 20 permintaan terbaru ke server di log debug. Jadi, saat Anda mengembangkan aplikasi, Anda harus membuat permintaan debug "Baru", pilih nama Anda, tekan "Simpan", beralih kembali ke aplikasi Anda, segarkan halaman, klik kembali ke tab debug, coba temukan permintaan yang akan menampung log debug Anda, tekan "temukan" untuk mencari teks yang Anda cari. Ini seperti sepuluh klik untuk melihat keluaran debug. Meskipun mungkin tampak sepele, itu hanya contoh betapa sedikit perhatian dan pertimbangan telah diberikan kepada pengalaman pengembang.

Segala sesuatu tentang platform pengembangan adalah renungan yang dicangkokkan. Sungguh luar biasa untuk apa itu, tetapi sebagian besar PITA total. Jika Anda tidak tahu persis apa yang Anda lakukan (seperti Anda bersertifikat dan memiliki pemahaman yang sangat mendalam tentang Apex), itu akan dengan mudah membawa Anda lebih dari 10-20x jumlah waktu yang diperlukan di lingkungan lain untuk melakukannya. sesuatu yang tampaknya akan sangat sederhana, jika Anda bahkan bisa berhasil sama sekali.

Batasan gubernur memang seburuk itu. Anda memiliki kombinasi berbagai batasan (kueri database, baris yang dikembalikan, "pernyataan skrip", panggilan mendatang, info, dll.) Dan Anda harus tahu persis apa yang Anda lakukan untuk menghindarinya. Misalnya, jika Anda memiliki rollup "rumus" bidang terhitung pada sebuah objek dan Anda memiliki pemicu pada objek turunan, itu akan mengeksekusi pemicu objek induk dan menghitungnya terhadap batas Anda. Hal-hal seperti itu tidak jelas sampai Anda melalui proses yang menyakitkan dalam mencoba dan gagal.

Anda akan mencoba satu hal untuk menghindari satu batasan, dan mencapai yang lain dalam permainan "whack a limit" yang tidak pernah berakhir. Dalam prosesnya, Anda harus merancang ulang secara drastis seluruh aplikasi dan pendekatan Anda, serta menulis ulang semua kode pengujian Anda. Anda harus memiliki 75% cakupan kode pengujian untuk diterapkan ke produksi, yang sebenarnya sangat bagus, tetapi dikombinasikan dengan semua batasan lainnya, ini sangat memberatkan. Anda benar-benar akan mencapai batas gubernur menulis kode pengujian Anda yang tidak akan muncul dalam skenario pengguna normal, tetapi itu akan mencegah Anda mencapai cakupan.

Belum lagi sejumlah besar masalah lainnya. Pengemasan bukanlah yang Anda harapkan. Anda tidak dapat mengemas aplikasi Anda dan mengirimkannya ke pengguna tanpa intervensi dan konfigurasi pengguna yang signifikan di pihak administrator organisasi. AppExchange benar-benar lelucon, dan mereka bahkan mulai menagih 5K hanya agar aplikasi Anda terdaftar. Mengimpor dengan pemuat data menyebalkan, terutama jika Anda memiliki pemicu apa pun. Anda tidak dapat mengekspor semua data Anda dalam satu langkah yang menyertakan hubungan Anda sedemikian rupa sehingga dapat dengan mudah diimpor kembali ke organisasi lain dalam satu langkah (misalnya sebuah organisasi pengembang). Anda hanya dapat menyegarkan kotak pasir sebulan sekali dari produksi, tanpa pengecualian, dan Anda tidak dapat menyertakan data Anda dalam penyegaran secara default kecuali Anda telah memanggil eksekutif akun Anda untuk membuka kunci fitur itu. Kamu bisa' t menghapus data secara massal di objek kustom. Anda tidak dapat mengubah nama paket Anda. Hal-hal tertentu bisa memakan banyak waktuhari untuk diselesaikan setelah Anda memintanya, seperti pencadangan data sebelum Anda ingin menerapkan aplikasi, tanpa laporan kemajuan selama proses dan tidak tahu kapan tepatnya ekspor terjadi. Mengingat bahwa ada masalah sinkronisitas data jika ada hubungan antara data, ada masalah integritas data yang serius karena tidak ada "transaksi" yang dapat mengekspor banyak objek dalam satu langkah. Mungkin ada beberapa alat komersial untuk memfasilitasi beberapa hal ini, tetapi ini tidak dapat dijangkau oleh pengembang normal yang mungkin tidak memiliki anggaran yang besar.

Semua hal lain yang dikatakan orang lain di sini adalah benar. Terkadang diperlukan waktu mulai dari lima detik hingga satu menit untuk menyimpan file.

Saya tidak bermaksud begitu negatif karena platformnya sangat keren dalam beberapa hal dan mereka mencoba melakukan berbagai hal dalam lingkungan multi-tenant yang tidak dilakukan orang lain. Ini adalah lingkungan yang sangat inovatif dan kuat pada beberapa level (saya sebenarnya sangat menyukai VisualForce), tetapi berikan satu atau dua tahun lagi. Mereka bermitra dengan VMware, mungkin itu akan memberikan pengembang sedikit lebih banyak playpen daripada sel penjara untuk bekerja.

Berikut adalah beberapa hal yang dapat saya berikan kepada Anda setelah menghabiskan sedikit waktu untuk mengembangkan platform dalam dua minggu terakhir ini:

1. Tidak ada API RESTful. Mereka memiliki API berbasis sabun yang dapat Anda panggil, tetapi tidak ada cara untuk membuat panggilan yang benar-benar tenang

2. Tidak ada cara sederhana untuk mengambil SObject mereka dan mengubahnya menjadi objek JSON.

3. Halaman gaya visual baik-baik saja sampai Anda ingin menyesuaikannya dan kemudian itu adalah dunia yang menyakitkan.

4. Halaman gaya visual harus terikat ke SObjects jika tidak, tidak ada cara untuk mendapatkan field input standar seperti datepicker atau daftar pilih untuk bekerja.

5. Plugin eclipse tidak masalah jika Anda ingin bekerja sendiri, tetapi jika Anda ingin bekerja dalam tim besar dengan plugin eclipse lupakan saja. Itu tidak menangani sinkronisasi ke dan dari server, itu macet dan itu tidak terlalu membantu sama sekali.

6. TIDAK ADA DEBUGGER! Jika Anda ingin men-debug, itu benar-benar di-debug oleh pernyataan system.debug. Ini mungkin masalah terbesar yang saya temukan

7. Model "MVC" mereka sebenarnya bukan MVC. Ini jauh lebih dekat dengan ASP.NET Webforms. Pandangan Anda terkait erat tidak hanya dengan model tetapi juga pengontrolnya.

8. Menyimpan dokumen dalam jumlah besar tidak memungkinkan. Kami perlu menyimpan lebih dari 100 GB dokumen dan kami dikutip beberapa tokoh konyol. Kami telah memutuskan untuk mengimplementasikan penyimpanan dokumen kami pada infrastruktur S3 amazon

9. Meskipun bahasanya berbasis java, itu bukan java. Anda tidak dapat mengimpor paket atau pustaka eksternal apa pun. Juga, pustaka dasar yang tersedia sangat terbatas sehingga kami mendapati diri kami menerapkan banyak hal secara eksternal dan kemudian mengekspos bit tersebut sebagai layanan yang dipanggil oleh force.com

10. Anda dapat memanggil layanan berbasis SOAP atau REST eksternal tetapi isi pesan dibatasi hingga 100kb sehingga sangat membatasi dalam apa yang dapat Anda panggil.

Sejujurnya, meskipun ada manfaat potensial untuk mengembangkan sesuatu seperti platform force.com, bagi saya, Anda tidak dapat menggunakan platform force.com untuk aplikasi tingkat perusahaan yang sebenarnya. Paling-paling Anda bisa menulis beberapa aplikasi gaya kasar dasar tetapi begitu Anda pindah ke sesuatu yang agak rumit, saya akan menghindarinya seperti wabah.

Wow- ada banyak hal di sini yang bahkan saya tidak tahu adalah batasannya - setelah bekerja di platform selama beberapa tahun.

Tetapi hanya untuk menambahkan beberapa hal lain ...

Alasan Anda tidak memiliki debugger baris demi baris justru karena ini adalah platform multi-tenant. Setidaknya itulah yang dikatakan SFDC - sepertinya di era pemrograman kaya thread ini, itu bukan alasan yang banyak, tapi tampaknya itulah alasannya. Jika Anda harus menulis kode, Anda memiliki "System.debug (String)" sebagai debugger Anda - Saya ingat memiliki alat debugging server yang lebih canggih di Java 1.2 sekitar 12 tahun yang lalu.

Hal lain yang sangat saya benci tentang sistem ini adalah kontrol versi. Framework Spring tidak digunakan untuk tujuan Spring biasanya - ini lebih merupakan fitur konfigurasi di SFDC daripada kontrol versi. SFDC menyediakan kontrol versi NOL.

Anda dapat menemukan diri Anda terhenti selama berhari-hari melakukan sesuatu yang seharusnya tampak sangat mudah, seperti, katakanlah, menjadwalkan laporan SFDC untuk diekspor ke file CSV dan email ke daftar penerima ... Nah, tentang cara termudah untuk melakukannya adalah buat objek kustom dengan bidang kustom, dengan aturan alur kerja dan template email Visualforce ... lalu untuk kode Anda perlu menulis komponen Visualforce yang mengalirkan data laporan ke template email Visualforce sebagai lampiran dan Anda menulis APEX anonim kode jadwal pembaruan bidang objek khusus ... Untuk pengembang SFDC, ini hampir merupakan tugas harian ... mencoba menggabungkan sekitar lima teknologi berbeda untuk melakukan tugas yang tampak begitu sederhana .... Dan ini dapat menyebabkan sakit kepala manajemen dan ketegangan juga - Biasanya, Anda akan mengetahui hal ini setelah mendapat saran untuk melakukan sesuatu yangt bekerja di komunitas pengguna (seperti yang sudah dikatakan seseorang), lalu mencoba banyak hal yang, setelah Anda mengembangkannya, Anda akan menemukan bahwa mereka tidak berfungsi karena alasan yang aneh - seperti "Anda tidak dapat menjadwalkan VisualForce page ", atau" Anda tidak dapat memanggil getContent dari konteks yang dapat dijadwalkan "atau alasan misterius lainnya.

Ada begitu banyak, banyak gotcha kecil yang menjengkelkan di platform SFDC, yang begitu Anda tahu MENGAPA mereka ada di sana, itu masuk akal ... tetapi batasan itu masih sangat buruk yang membuat Anda tidak melakukan apa yang perlu Anda lakukan. Ini beberapa milik saya;

1. Anda tidak bisa mendapatkan informasi pemilik rekaman "di luar kotak" pada hampir semua jenis rekaman - Anda harus menulis pemicu yang menautkan pemilik saat membuat rekaman ke rekaman yang Anda masukkan. Mengapa? Jawaban singkat karena pemilik dapat berupa "orang" atau "antrean", dan keduanya merupakan entitas yang sangat berbeda ... Masuk akal, tetapi secara harfiah dapat menjungkirbalikkan proyek.

2. Model keamanan yang menjengkelkan. Contoh: izin "Kelola Laporan Publik" sangat berbeda dari "Buat dan Ubahsuaikan Laporan" dan pada dasarnya berlaku untuk semua yang ada di platform ... terutama folder apa pun.

3. Seperti yang disebutkan, dukungan pada dasarnya tidak ada. Jika Anda adalah individu yang sangat mandiri, atau memiliki banyak sumber daya SFDC, atau memiliki banyak waktu dan / atau manajer yang sangat pemaaf, atau bertanggung jawab atas sistem SFDC yang berfungsi dengan baik, Anda cukup baik bentuk. Jika Anda tidak berada dalam salah satu posisi ini, Anda dapat menemukan diri Anda dalam masalah besar.

SFDC adalah proposisi bisnis yang sangat menggoda ... tanpa jejak peralatan, keamanan yang cukup bagus, harga tetap, tidak ada infrastruktur, DAN Anda mendapatkan CRM berbasis web dengan pemrosesan batchable, dan dapat dijadwalkan ... Tapi seperti yang dikatakan poster lain, itu benar-benar peningkatan dalam pembelajaran pengembangan, dan jika Anda mengikuti konsultasi, menurut saya harga terendah yang pernah saya lihat adalah $ 200 / jam.

Salesforce cenderung berintegrasi dengan hal-hal lain bertahun-tahun setelah beberapa teknologi menjadi tempat umum - JSON dan jquery muncul dalam pikiran ... dan jika Anda memiliki infrastruktur umum lain yang ingin Anda integrasikan, seperti JIRA, perkirakan untuk membayar lebih banyak, dan mereka bisa sangat bermasalah.

Dan seperti yang disebutkan salah satu poster lain, Anda terus-menerus melawan batasan gubernur yang bisa membuat Anda gila ... lampiran TIDAK boleh> 5MB. Titik. Dan terkadang <3MB (jika base64 dikodekan). Sepuluh keterangan HTTP di satu kelas. Titik. Ada lusinan batasan gubernur yang diterbitkan, dan banyak di antaranya yang tidak diragukan lagi akan Anda temukan dan hanya ingin kehabisan kantor.

Saya benar-benar, BENAR-BENAR suka platform, tapi percayalah - itu bisa menjadi nyonya yang sangat kejam.

Namun dalam keadilan bagi SFDC, saya akan mengatakan ini: masalah terbesar yang saya temukan dengan platform bukanlah platform itu sendiri, tetapi ekspektasi besar yang dimiliki oleh hampir semua orang yang melihat platform, tetapi belum mengembangkannya .... dan orang-orang itu cenderung memiliki otoritas besar dalam organisasi bisnis; pemasaran, penjualan, manajemen, dll. Terjadi pemutusan hubungan yang besar dan kepala bergulir, atau terancam bergulir setiap hari - semua karena ada platform hebat di luar sana dengan gotcha aneh dan ribuan orang yang berjuang setiap hari untuk memahami mengapa hal-hal seharusnya berfungsi saat mereka hanya tidak dan tidak mau.

EDIT:
Hanya untuk menambah komentar lomaxx tentang MVC; Dalam terminologi SFDC, ini terkait erat dengan apa yang dikenal sebagai "kondisi tampilan" - dan dapat benar-benar bermasalah, karena apa yang ada di laman VF bukanlah yang ada di kelas pengontrol untuk laman tersebut. Jadi, Anda harus melalui perputaran aneh untuk menyinkronkan apa yang ada di halaman dengan apa yang akan ditulis pengontrol ke SF ketika Anda mengklik tombol "simpan" (atau buat keterangan HTTP Anda atau apa pun) .... man, itu mengganggu .

Saya pikir orang lain telah menutupi kerugiannya secara lebih mendalam tetapi bagi saya, tampaknya tidak menggunakan paradigma MVC atau mendukung banyak cara penggunaan ulang kode sama sekali. Untuk melakukan apa pun di luar aplikasi sederhana adalah latihan frustrasi dibandingkan mengembangkan aplikasi menggunakan sesuatu seperti ASP.Net MVC.

Selain itu, alat, lapisan data, dan rasa frustrasi saat mencoba memfaktor ulang kode atau mengganti nama bidang selama proses pengembangan tidak membantu.

Saya pikir sebagai CMS itu cukup keren tetapi sebagai platform untuk aplikasi non CMS, itu tidak masuk akal bagi saya.

Model keamanan juga sangat ketat ... tetapi ini bukan yang terburuk. Saat ini Anda tidak dapat menegaskan apakah pengguna memiliki kemampuan untuk melakukan tindakan tertentu.

Anda dapat memeriksa untuk melihat apa peran mereka, tetapi Anda tidak dapat memeriksa apakah peran itu memiliki izin untuk melakukan tindakan saat ini.

Lebih buruk lagi adalah tanggapan dari dukungan teknis untuk "mencoba tindakan dan jika ada pengecualian, tangkap"

Mengingat Force.com adalah platform "cloud", kemampuannya untuk bertindak sebagai klien untuk layanan eksternal yang ditentukan WSDL cukup mengecewakan. Lihat http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ untuk mengetahui apa yang mungkin harus Anda lakukan.

Untuk semua di atas, saya penasaran bagaimana rilis VMforce, yang memungkinkan programmer Java untuk menulis kode untuk Force.com, mengubah kerugian di atas?

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

Saya kira mereka mencoba untuk mengatasi masalah ini. Di dreamforce mereka menyebutkan bahwa kami mencoba menurunkan batas Gubernur menjadi hanya 4. Saya tidak yakin apa detailnya. Mereka memiliki REST API untuk akses awal, dan mereka membeli heroku yang merupakan pengembangan ruby ​​di cloud. Mereka memisahkan database, dengan database.com sehingga Anda dapat melakukan semua pengembangan web dan panggilan db Anda menggunakan database.com.

Saya kira mereka mencoba membuatnya seagnostik mungkin. Tapi sekarang ini semua adalah pengumuman dan akses awal jadi seperti pernyataan Safe Harbor mereka tidak membeli apa yang mereka katakan, hanya pada apa yang mereka miliki saat ini.