Teman dan kolega, baru-baru ini tentang artikel Habré dengan topi menentang 1C, sebagai platform untuk pengembangan, dan pidato para pendukungnya menjadi lebih sering. Artikel-artikel ini menyoroti satu masalah serius: paling sering, kritik 1C mengkritiknya dari sudut pandang "tidak menguasainya", mengkritik masalah yang pada kenyataannya mudah diselesaikan, dan, sebaliknya, tanpa menyentuh masalah yang benar-benar penting, ada diskusi dan tidak diselesaikan oleh vendor. . Saya percaya bahwa masuk akal untuk melakukan tinjauan yang sadar dan seimbang dari platform 1C. Apa yang dia tahu, apa yang dia tidak tahu, apa yang harus dia lakukan, tetapi tidak dilakukan, dan, di sisi manisnya, apa yang dia lakukan dengan ledakan, dan pengembang Anda pada% technology_name% akan melakukan seratus tahun, membuang lebih dari satu anggaran tahunan.
Sebagai hasilnya, Anda, sebagai pemimpin atau arsitek, akan dapat memperoleh pemahaman yang jelas - untuk tugas apa akan menguntungkan bagi Anda untuk mengambil 1C, dan di mana harus dibakar dengan besi panas. Sebagai pengembang dari dunia "bukan 1C", Anda dapat melihat apa yang ada di 1C karena apa masalahnya. Dan sebagai pengembang 1C, Anda dapat membandingkan sistem Anda dengan ekosistem dari bahasa lain dan memahami lokasi Anda dalam sistem koordinat pengembangan perangkat lunak.
Di bawah potongan - banyak sketsa tebal untuk 1C, untuk kritik 1C, untuk Java, .NET, dan secara umum ... Kipas sedang berjalan, selamat datang!
Tentang diri saya
Saya sudah akrab dengan subjek sejak sekitar 2004. Saya mungkin pemrograman sejak saya berusia 6 tahun, sejak saat saya mendapatkan buku tentang Profesor Fortran dengan komik tentang kucing, burung gereja, dan ulat. Saya membongkar program-program yang ditulis kucing dari gambar-gambar di buku dan mencari tahu apa yang mereka lakukan. Dan ya, saya tidak memiliki komputer sungguhan pada waktu itu, tetapi saya tertarik pada halaman itu dan saya dengan jujur menekan tombol kertas, memasukkan perintah yang diawasi oleh kucing X.
Lalu ada BK0011 dan BASIC di sekolah, C ++ dan perakit di universitas, lalu 1C, dan kemudian terlalu malas untuk mengingat. Selama 15 tahun terakhir, saya terutama terlibat dalam 1C, tidak hanya dalam hal pengkodean, tetapi secara umum 1C. Menetapkan tujuan, administrasi, dan devops di sini. Selama 5 tahun terakhir saya telah terlibat dalam kegiatan yang bermanfaat secara sosial dalam hal pengembangan alat pengembangan dan otomatisasi untuk nama panggilan 1C lainnya, saya menulis artikel dan buku.
Tentukan subjek diskusi
Pertama-tama, mari kita putuskan apa yang akan dibahas, karena huruf "1C" dapat memahami banyak hal. Dalam hal ini, dengan huruf "1C" yang kami maksudkan secara eksklusif adalah kerangka pengembangan "1C: Enterprise" dari versi kedelapan yang modern. Kami tidak akan berbicara banyak tentang perusahaan manufaktur dan kebijakannya (tetapi harus sedikit) Kami tidak akan membahas aplikasi spesifik yang ditulis menggunakan kerangka kerja ini. Teknologi terpisah, alias aplikasi konfigurasi - secara terpisah.
Arsitektur tingkat tinggi 1C: Perusahaan
Saya sengaja menyebutkan kata "framework." Dari sudut pandang pengembang, platform 1C adalah kerangka yang tepat. Dan Anda perlu memperlakukannya seperti kerangka kerja. Pertimbangkan itu Spring atau ASP.NET dieksekusi oleh beberapa runtime (JVM atau CLR, masing-masing). Kebetulan di dunia pemrograman biasa ("bukan 1C"), pemisahan ke dalam kerangka kerja, mesin virtual, dan aplikasi spesifik adalah alami, karena fakta bahwa komponen ini biasanya dikembangkan oleh produsen yang berbeda. Dalam dunia 1C, tidak lazim untuk secara eksplisit mengalokasikan kerangka pengembangan dan sebenarnya runtime, di samping itu, aplikasi spesifik yang ditulis menggunakan kerangka kerja pada dasarnya juga dikembangkan oleh 1C itu sendiri. Akibatnya, beberapa kebingungan muncul. Oleh karena itu, dalam kerangka artikel, kita harus mempertimbangkan 1C dari beberapa sisi sekaligus dan mengklasifikasikannya berdasarkan beberapa sumbu koordinat. Dan di setiap sumbu koordinat kita letakkan sekop zat cokelat pertimbangkan fitur, kelebihan dan kekurangan dari solusi yang ada.
Sudut pandang 1C
1C untuk pembeli
Pembeli memperoleh sistem otomasi di mana ia dapat dengan cepat menyelesaikan masalah mengotomatisasi bisnisnya sendiri. Sebuah bisnis bisa menjadi warung kecil, atau bisa juga bisnis besar. Jelas bahwa kebutuhan bisnis ini berbeda, tetapi keduanya didukung oleh basis kode tunggal platform.
Bagi pembeli, 1C adalah waktu cepat ke pasar. Cepat Lebih cepat dari Java, C # atau JS. Rata-rata Di rumah sakit. Jelas bahwa situs kartu nama pada reaksi akan menjadi lebih baik, tetapi backend dari sistem WMS akan mulai lebih cepat pada 1C.
1C sebagai alat
Setiap solusi teknologi memiliki batasan penerapan. 1C bukan bahasa tujuan umum, ia tidak hidup secara terpisah dari kerangka kerjanya. 1C disarankan untuk diterapkan saat Anda membutuhkan:
- aplikasi server
- aplikasi keuangan
- dengan UI siap, ORM, Pelaporan, XML / JSON / COM / PDF / YourDataTransferingFormat
- dengan dukungan untuk proses latar belakang dan pekerjaan
- dengan keamanan berbasis peran
- dengan logika bisnis skrip
- dengan prototipe cepat dan waktu ke pasar rendah
1C Anda tidak perlu jika Anda ingin:
- pembelajaran mesin
- Perhitungan GPU
- grafik komputer
- perhitungan matematika
- Sistem CAD
- pemrosesan sinyal (suara, video)
- panggilan http tinggi dengan ratusan ribu rps
1C sebagai perusahaan manufaktur
Perlu memahami apa bisnis 1C, sebagai produsen perangkat lunak. Perusahaan 1C menjual solusi untuk masalah bisnis melalui otomatisasi. Bisnis yang berbeda, besar atau kecil, tetapi hanya menjualnya saja. Cara untuk mencapai ini adalah aplikasi bisnis. Untuk akuntansi, akuntansi penggajian, dll. Untuk menulis aplikasi ini, perusahaan menggunakan platform sendiri untuk mengembangkan aplikasi bisnis. Khusus dirancang untuk tugas-tugas umum dari aplikasi bisnis yang sama:
- akuntansi keuangan
- kustomisasi logika bisnis yang mudah
- peluang integrasi luas dalam lanskap IT yang heterogen
Sebagai produsen, 1C percaya bahwa ini adalah strategi yang memungkinkan Anda untuk bekerja dengan mitra dan klien dalam mode win-win. Anda dapat berdebat dengan ini, tetapi sesuatu seperti ini yang dipromosikan perusahaan itu sendiri: solusi siap pakai untuk masalah bisnis yang dapat dengan cepat disesuaikan oleh mitra dan dibangun ke dalam lanskap TI apa pun.
Semua klaim atau Wishlist untuk 1C, sebagai kerangka kerja, harus dipertimbangkan secara eksklusif melalui prisma ini. "Kami ingin OOP dalam 1C" kata pengembang. "Berapa biayanya untuk mendukung OOP di platform, akankah ini membantu kami meningkatkan penjualan kotak?" Ucap 1C. Membuka "prisma" dalam menjual solusi bisnis:
"Hei, bisnis, apakah Anda ingin OOP di 1C Anda?"
"Apakah itu akan membantu saya menyelesaikan masalah saya?"
- Bagaimana cara mengetahui ...
- Maka tidak perlu
Pendekatan ini mungkin baik atau buruk, tergantung pada siapa yang melihatnya, tetapi hanya itu saja. Berbicara tentang fakta bahwa tidak ada fitur X di 1C, Anda perlu memahami bahwa itu tidak ada karena suatu alasan, tetapi dalam konteks memilih "biaya implementasi vs ukuran keuntungan".
Klasifikasi teknologi
"Faktanya, odnosnik menggunakan pola terbaik, dipilih dengan cermat oleh para ahli metodologi dan pengembang platform 1C yang peduli.
Saat Anda menulis kode bodoh untuk formulir sederhana dan mudah dikelola, Anda sebenarnya menggunakan model-view-controller dengan pengikatan data dua arah dalam engine aplikasi tiga-lapis-data , dibumbui dengan pemetaan hubungan-objek tingkat tinggi berdasarkan metadata deklaratif deskripsi , yang memiliki bahasa query platform-independen , dengan antarmuka pengguna berbasis data deklaratif, serialisasi transparan lengkap dan bahasa program berorientasi domain .
Perbedaan pengembang 1C dari mitra Barat mereka adalah dalam PR. Mereka suka memberi nama besar untuk semua omong kosong dan bergegas dengan itu seperti dengan karung tertulis. "
A. Orefkov
Platform 1C memiliki arsitektur 3-tier klasik, di pusatnya adalah server aplikasi (atau emulasi untuk sedikit uang bagi pemilik toko kecil). Sebagai DBMS, MS SQL atau Postgres digunakan. Ada juga dukungan untuk Oracle dan IBM DB2, tetapi ini lebih bersifat esoteris, tidak ada yang tahu apa yang akan terjadi jika Anda menerapkan 1C pada pangkalan-pangkalan ini di bawah beban sedang dan tinggi. Saya percaya bahwa perusahaan 1C sendiri tidak mengetahui hal ini.
Bagian klien adalah klien tipis yang diinstal pada mesin pengguna atau klien web. Fitur utamanya adalah pemrogram tidak menulis 2 kode yang berbeda, mereka menulis satu aplikasi, dalam satu bahasa, dan Anda dapat mengaturnya di browser jika ada keinginan atau kebutuhan. Siapa yang ingin setumpuk penuh otentik dan satu bahasa untuk bagian depan dan belakang, node.js? Mereka tidak berhasil melakukan hal yang persis sama sampai akhir. Tumpukan penuh nyata ada, tetapi Anda harus menulis dalam 1C. Ironi nasib, hal-hal seperti itu :)
Dalam mode peramban, solusi 1C: SaaS cloud segar juga berfungsi, di mana Anda tidak dapat membeli 1C, tetapi menyewa basis kecil dan menyimpan catatan penjualan shawarma di sana. Hanya di peramban, tanpa menginstal atau mengonfigurasi apa pun untuk Anda sendiri.
Selain itu, ada klien Legacy, yang dalam 1C disebut "aplikasi reguler." Legacy, itu adalah Legacy, selamat datang di dunia aplikasi pada tahun 2002, tetapi kita masih berbicara tentang keadaan ekosistem saat ini.
Sisi server 1C mendukung pengelompokan dan skala dengan menambahkan mesin baru ke kluster. Di sini beberapa salinan rusak, dan tentang ini akan ada bagian terpisah dalam artikel. Singkatnya, ini tidak persis sama dengan menambahkan beberapa contoh yang persis sama di belakang HAProxy.
Kerangka pengembangan aplikasi menggunakan bahasa pemrogramannya sendiri, yang secara kasar menyerupai VB6 yang sedikit ditingkatkan, diterjemahkan ke dalam bahasa Rusia. Untuk orang-orang benci semuanya rusia yang tidak percaya bahwa "jika" diterjemahkan sebagai "jika" sebuah sintaks kedua disarankan. Yaitu jika diinginkan, 1C dapat ditulis sehingga tampilannya tidak berbeda dari VB.
Bahasa pemrograman ini adalah alasan utama topi 1C-nickname menuju platformnya. Terus terang, bukan tanpa alasan. Bahasa itu dipahami sesederhana mungkin, dirancang untuk memenuhi mantra "DEVELOPERS, DEVELOPERS" pada skala CIS setidaknya. Esensi komersial dari solusi semacam itu, menurut saya, jelas terlihat: lebih banyak pengembang, lebih banyak cakupan pasar. Menurut berbagai perkiraan, ini menjadi kenyataan dari 45% hingga 95%. Saya harus segera mengatakan bahwa menulis dalam bahasa yang menurut Anda sangat mudah. Dan saya tahu banyak bahasa pemrograman.
Kami akan mulai dengan bahasa.
Bahasa pemrograman 1C
Pada saat yang sama, poin kuat dan lemah dari sistem. Memberikan entri yang mudah, mudah dibaca. Di sisi lain, itu belum diperbarui sejak rilis versi 8 pada tahun 2002 dan sudah usang. Seseorang akan berkata "cacat utama - tidak ada OOP" dan itu akan salah. Pertama, PLO tidak hanya menyukai Nuraliev, tetapi juga Torvalds. Dan kedua, OOP masih ada.
Dari sudut pandang pengembang, ia memiliki kerangka kerja dengan kelas dasar yang ditampilkan pada DBMS. Pengembang dapat mengambil kelas dasar "Direktori" dan mewarisi darinya direktori "Klien". Itu dapat menambahkan bidang kelas baru ke dalamnya, misalnya, TIN dan Alamat, dan juga, jika perlu, dapat menimpa metode kelas dasar, misalnya, metode OnWrite / Prizapisi.
Kerangka kerja dirancang sedemikian rupa sehingga warisan yang lebih dalam jarang diperlukan, dan batasan dalam OOP, menurut saya, masuk akal. 1C berfokus pada Pengembangan Berbasis Domain dan membuat Anda berpikir, pertama-tama, tentang bidang subjek dari solusi yang sedang dikembangkan, dan ini bagus. Tidak hanya godaan, tetapi juga kebutuhan untuk menulis 10 DTO dan ViewModel yang berbeda hanya untuk menunjukkan beberapa data dari domain di suatu tempat. Pengembang 1C selalu beroperasi dengan satu entitas, tanpa menyumbat konteks persepsi dengan puluhan kelas dengan nama yang sama mewakili entitas yang sama, tetapi dari sisi lain. Setiap aplikasi .NET, misalnya, harus mengandung lima atau dua ViewModel dan DTO untuk serialisasi di JSON dan transfer data dari klien ke server. Dan sekitar 10-15% kode dalam aplikasi Anda akan menggeser data dari satu kelas ke kelas lain dengan pena atau kruk seperti AutoMapper. Kode ini perlu ditulis dan programmer harus membayar untuk pembuatan dan pemeliharaannya.
Ternyata bahasa 1C sulit untuk dikembangkan tanpa menyulitkannya ke tingkat bahasa utama, sehingga kehilangan keuntungan dari kesederhanaan. Apa, pada kenyataannya, tugas vendor diselesaikan: untuk mengeluarkan solusi standar yang dapat disesuaikan oleh setiap siswa yang tertangkap di jalan dengan tingkat kualitas yang tepat (mis. Kasus cakupan dari kios ke pabrik besar dilakukan). Jika Anda adalah sebuah kios - ambil seorang siswa, jika Anda seorang pabrik - ambil seorang guru dari mitra pelaksana. Fakta bahwa mitra pelaksana menjual siswa dengan harga guru bukanlah masalah kerangka kerja. Secara arsitektur, kerangka kerja harus menyelesaikan masalah keduanya, kode konfigurasi tipikal (yang kami jual ke bisnis dengan janji penyesuaian) harus dipahami oleh siswa, dan guru akan mengerti apa yang Anda inginkan.
Apa, menurut pendapat saya, benar-benar kurang dalam bahasa, yang memaksa saya untuk menulis lebih dari yang saya bisa, kemudian membakar melalui waktu yang dibayarkan oleh pelanggan.
- Kemungkinan mengetik di tingkat, misalnya, TypeScript (sebagai akibatnya, lebih banyak sarana analisis kode dalam IDE, refactoring, jambs yang kurang ofensif)
Kehadiran fungsi sebagai objek kelas satu. Konsep yang sedikit lebih kompleks, tetapi jumlah kode boilerplate dari yang standar dapat sangat dikurangi. Memahami kode oleh seorang siswa, IMHO, bahkan akan meningkat karena pengurangan volume - Literal koleksi universal, inisialisasi. Hal yang sama - mengurangi jumlah kode yang perlu ditulis dan / atau dilihat melalui mata. Mengisi koleksi lebih dari 9000% dari waktu pemrograman untuk 1C. Menulisnya tanpa gula sintaksis itu panjang, mahal, dan rawan kesalahan. Secara umum, jumlah LOC dalam solusi 1C melebihi semua batas yang dapat dibayangkan dibandingkan dengan kerangka kerja terbuka yang tersedia dan, secara umum, semua Java perusahaan Anda digabungkan. Bahasa ini verbose, dan merosot menjadi volume data, memori, rem IDE, waktu, uang ....
- akhirnya konstruksi saya punya hipotesis bahwa konstruksi ini hilang karena fakta bahwa mereka tidak mengambil terjemahan yang sukses ke dalam bahasa Rusia :)
- Jenis data sendiri (tanpa OOP), Ketikkan analog dari VB6. Memungkinkan Anda untuk tidak mengetik struktur menggunakan komentar di BSP dan metode ajaib yang membangun struktur ini. Kami mendapatkan: kode lebih sedikit, petunjuk melalui titik, solusi lebih cepat untuk masalah ini, lebih sedikit kesalahan pada kesalahan ketik dan hilang struktur properti. Sekarang tipifikasi struktur pengguna sepenuhnya terletak pada tim pengembangan Library of Standard Subsystems, yang, menurut saya, dengan cermat menulis komentar tentang properti yang diharapkan dari struktur parameter yang ditransfer.
- Kekurangan gula saat bekerja dengan panggilan asinkron di klien web. Callback-hell dalam bentuk Alert Processing adalah kruk sementara yang disebabkan oleh perubahan tiba-tiba API dari browser utama, tetapi Anda tidak bisa hidup seperti itu setiap saat, keuntungan dari "memahami oleh siswa" dari kode asinkron kehilangan lebih banyak dan lebih banyak. Tambahkan dukungan apa pun untuk paradigma ini di IDE utama di sini dan keadaan akan menjadi lebih buruk.
Ini adalah masalah yang mendesak, jelas bahwa daftarnya bisa jauh lebih besar, tetapi orang tidak boleh lupa bahwa itu masih bukan bahasa tujuan umum, tidak perlu multithreading, fungsi lambda, akses ke GPU dan perhitungan titik mengambang cepat. Ini adalah bahasa skrip logika bisnis.
Seorang programmer yang telah banyak bekerja dengan bahasa ini telah melihat js atau c # mulai bosan dengan bahasa ini. Ini fakta. Dia butuh pengembangan. Di sisi lain skala, vendor memiliki biaya penjualan fitur-fitur ini vs peningkatan pendapatan setelah penerapannya. Di sini saya tidak memiliki informasi tentang apa yang melebihi mata perusahaan saat ini.
Lingkungan pengembangan
Semuanya di sini juga tidak mulus. Ada dua lingkungan pengembangan. Yang pertama adalah Configurator yang termasuk dalam pengiriman. Yang kedua adalah lingkungan Enterprise Development Tools, yang dikembangkan atas dasar Eclipse, disingkat EDT.
Configurator menyediakan berbagai tugas pengembangan, mendukung semua fitur dan merupakan lingkungan utama di pasar. Secara moral juga ketinggalan zaman, tidak berkembang, menurut rumor - karena volume utang teknis dalam dirinya sendiri. Pembukaan API internal dapat meningkatkan situasi (dalam bentuk persahabatan dengan Snegopat A. Orefkov atau secara independen), tetapi ini tidak. Praktek telah menunjukkan bahwa komunitas akan mengajukan sendiri fitur dalam IDE, jika saja vendor tidak ikut campur. Tetapi kita memiliki apa yang kita miliki. Configurator itu indah pada 2004-2005, sangat mirip dengan Visual Studio pada waktu itu, di tempat-tempat itu bahkan lebih dingin, tetapi macet pada waktu itu.
Selain itu, volume solusi standar rata-rata telah tumbuh beberapa kali sejak saat itu dan hari ini IDE bodoh tidak mengatasi jumlah kode yang diumpankan. Kegunaan dan kemampuan refactoring bahkan tidak di nol, mereka berada di merah. Semua ini tidak menambah antusiasme bagi para pengembang dan mereka bermimpi membuangnya di ekosistem lain dan terus buang air di sana, tetapi di lingkungan yang menyenangkan yang tidak meludahi wajah dengan perilakunya.
Sebagai alternatif, IDE berbasis Eclipse yang ditulis dari awal diusulkan. Di sana, sumber, seperti pada perangkat lunak lain, hidup dalam bentuk file teks, disimpan dalam GIT, cabang tarik-permintaan, semua ini. Dari minus - selama bertahun-tahun sekarang belum keluar dari status beta, meskipun dengan setiap rilis semuanya semakin baik. Saya tidak akan menulis tentang kontra EDT, yang hari ini minus, besok fitur tetap. Relevansi deskripsi seperti itu akan cepat memudar. Hari ini dimungkinkan untuk berkembang di EDT, tetapi tidak biasa, Anda harus siap untuk sejumlah bug IDE.
Jika Anda melihat situasi melalui "prisma 1C" yang disebutkan, Anda mendapatkan sesuatu seperti ini: pelepasan IDE baru tidak meningkatkan penjualan kotak, tetapi aliran DEVELOPERS dapat dikurangi. Sulit untuk mengatakan apa yang menanti ekosistem dari sudut pandang kenyamanan pengembang, tetapi Microsoft sudah pernah membuat profil pengembang seluler dengan menawarkan layanan mereka kepada mereka terlambat.
Manajemen pengembangan
, , , , , 1 git, blame, code-review, , etc. , . , , , . -, KDiff- . gitconverter , , , gitsync , -. open-source 1 . API , , IDE.
, 1 git Jira, Crucible, Allure 1 SonarQube — , , , 1.
Administrasi
. -, , - ( 1). , , , , — highload — , " ". , , 1 - . , , . .
, . , 1: , , . , , ELK , , — . . , 1 — . , . , , , 1- , , . SAP. , , , - . . SAP . - 1 , . Ini adalah kekeliruan.
1
— . , , . . — , . 1 , — . , , 1 — , .. . , , , , .
, 1 , , .
Docker
1 . , , highload — . , +1 . , , .
— 1 - . 1 Reporting, , -, , , , .. , , . , UI , , .
1, , , , .
, PDF . .NET , . , . , PDF. , . - , , dto- JSON, , , , — PDF. 1, , .
- / 3. , , , , - . , , 3 , .
.NET visual studio ? ? - .
1 - . , . , 1. . , , . -, , — . :
- Unicode. , , ? 2019 ASCII ( legacy). . . - - varchar . 2015 gitlab LDAP- - , JetBrains IDE . 1 . . , , . , - . Java- . . ? .
- /. 1 . — . identity ( ", "), , , ( ). , , , — , , , .
- . 1 — . . - identity ( !), GUI, ( ). ? ?
- . 1 () . — ! , : ( ), . , . , — , .
- . , - . . — . : , .
- . , . , -, , , — . ( UI) — .
- Reporting. BI- ETL-. , . , , .. 1 , , . , . -- , --. : reporting, , , .
- . - .NET PDF . . PDF? 1- PDF +1 . + 40 , . 1 , . , , 1 , 3D OpenGL. ?
Semua ini hanyalah beberapa contoh ketika membatasi fungsionalitas atau mengimplementasikan dengan kompromi adalah keuntungan arsitektur yang penting di masa depan. Bahkan kompromi atau bukan pilihan yang paling efektif - sudah ada di dalam kotak dan diterima begitu saja. Implementasi independennya akan mustahil (karena keputusan seperti itu harus dibuat pada awal proyek, dan tidak ada sebelumnya, dan secara umum tidak ada arsitek), atau beberapa iterasi mahal. Dalam setiap item ini (dan ini bukan daftar lengkap solusi arsitektur), Anda dapat nakosyachit dan meletakkan batasan yang memblokir penskalaan. Bagaimanapun, Anda, sebagai pengusaha, perlu memastikan bahwa programmer Anda, membuat "sistem dari awal", memiliki lengan lurus dan akan melakukan momen sistem dengan baik segera.
Ya, seperti pada sistem kompleks lainnya, 1C sendiri memiliki solusi yang memblokir penskalaan dengan satu atau lain cara. Namun, saya ulangi, dengan kombinasi faktor, oleh biaya kepemilikan, dengan jumlah masalah yang sudah diselesaikan sebelumnya - saya tidak melihat pesaing yang layak di pasar. Untuk harga yang sama, Anda mendapatkan kerangka kerja aplikasi keuangan, server seimbang berkerumun, dengan UI dan moncong web, dengan aplikasi seluler, dengan pelaporan, integrasi, dan banyak lagi. Di dunia Java, Anda menyewa tim front-end, back-end, men-debug jambs tingkat rendah dari kode server yang ditulis sendiri dan membayar secara terpisah untuk 2 aplikasi mobile untuk 2 OS mobile.
Saya tidak mengatakan bahwa 1C akan menyelesaikan semua kasus, tetapi untuk aplikasi internal perusahaan, ketika Anda tidak perlu merek UI, apa lagi yang diperlukan?
Terbang di salep
Mungkin, tampaknya 1C akan menyelamatkan dunia dan semua cara lain untuk menulis sistem perusahaan salah. Ini sama sekali tidak benar. Dari sudut pandang seorang pengusaha, jika Anda memilih 1C, maka selain waktu cepat ke pasar, Anda harus memperhitungkan kerugian berikut:
- Keandalan Server Ini membutuhkan spesialis yang benar-benar berkualitas tinggi, yang mampu memastikan kelancaran operasinya. Saya tidak tahu program pelatihan yang sudah selesai untuk spesialis dari vendor. Ada kursus untuk mempersiapkan lulus ujian "Pakar", tetapi ini, menurut saya, tidak cukup.
- Dukungan Lihat paragraf sebelumnya. Untuk mendapatkan dukungan dari vendor, Anda harus membelinya. Untuk beberapa alasan, ini tidak diterima di industri 1C. Dan dengan SAP, hampir perlu untuk membeli dan itu tidak mengganggu siapa pun. Tanpa dukungan perusahaan dan tanpa ahli di negara bagian - dengan gangguan 1C Anda dapat tetap berhadapan muka.
- Namun, pada 1C Anda tidak dapat melakukan apa pun. Ini adalah alat dan seperti setiap alat itu memiliki batas penerapan. Dalam lanskap dengan 1C, sangat diinginkan untuk memiliki arsitek sistem "bukan 1C-nut".
- Julukan 1C yang bagus tidak lebih murah daripada programmer yang bagus dalam bahasa lain. Meskipun, programmer buruk mahal untuk disewa terlepas dari bahasa yang mereka tulis.
Mari dot
- 1C adalah kerangka kerja untuk pengembangan aplikasi cepat (RAD) untuk bisnis dan dirancang untuk ini.
- Tiga tautan dengan dukungan untuk DBMS utama, UI klien, ORM dan pelaporan yang cukup baik
- Peluang yang cukup untuk integrasi dengan sistem yang dapat melakukan apa yang tidak dilakukan 1C. Jika Anda ingin pembelajaran mesin, dapatkan Python, dan gabungkan hasilnya menjadi 1C melalui http atau RabbitMQ
- Jangan berusaha melakukan semuanya dalam 1C, Anda harus memahami kekuatannya dan menggunakannya untuk tujuan Anda sendiri
- Pengembang yang cenderung menggali kerangka kerja teknologi-gadget, dan untuk mengulang setiap N tahun pada mesin baru - bosan dalam 1C. Semuanya sangat konservatif di sana.
- Para pengembang bosan karena sangat sedikit perhatian terhadap mereka dari produsen. Bahasa yang membosankan, IDE yang lemah. Mereka membutuhkan modernisasi.
- Di sisi lain, pengembang yang tidak dapat menemukan hiburan melalui aplikasi dan mempelajari teknologi lain yang mereka sukai adalah pengembang yang buruk. Mereka akan merengek dan pergi ke ekosistem lain.
- Pengusaha yang tidak mengizinkan nama panggilan 1C mereka untuk menyumbat sesuatu dengan Python adalah majikan yang buruk. Mereka akan kehilangan karyawan dengan pikiran yang ingin tahu, dan para pembuat kode monyet akan menggantikan mereka, yang, setelah setuju dengan segalanya, akan menyeret perangkat lunak perusahaan ke rawa. Anda masih harus menulis ulang, jadi mungkin akan lebih baik untuk berinvestasi sedikit lebih awal di Python?
- 1C adalah perusahaan komersial dan menerapkan fitur semata-mata berdasarkan kepentingan dan kepentingannya sendiri. Dia tidak dapat disalahkan untuk ini, bisnis harus memikirkan keuntungan, seperti hidup
- 1C menghasilkan uang dengan menjual solusi untuk masalah bisnis, bukan masalah pengembang Vasya. Kedua konsep ini berkorelasi, tetapi prioritasnya persis sama dengan yang saya katakan. Ketika pengembang Vasya akan siap untuk membayar lisensi pribadi untuk 1C: Resharper - ia akan muncul dengan cepat, "Resharper" A. Konfirmasi Orefkova ini. Jika vendor mendukungnya, tetapi tidak berkelahi dengannya, Anda akan melihat akan ada pasar perangkat lunak untuk pengembang. Sekarang ada satu setengah pemain di pasar ini dengan hasil yang meragukan, dan semua karena integrasi dengan IDE negatif dan semuanya dilakukan pada tongkat penyangga.
- Praktik spesialis multi-alat akan dilupakan. Aplikasi modern terlalu banyak untuk mengingatnya dari sisi kode dan dari sisi penggunaan bisnis. Server 1C juga menjadi lebih rumit, tidak mungkin untuk mempertahankan semua jenis keahlian dalam satu karyawan. Ini harus mencakup permintaan akan spesialis, yang berarti daya tarik profesi 1C-nick dan kenaikan gaji. Jika sebelum Vasya bekerja tiga-dalam-satu untuk satu gaji, sekarang Anda perlu menyewa dua Vasya dan persaingan di antara Vasya dapat memacu pertumbuhan umum level mereka.
Kesimpulan
1C adalah produk yang sangat layak. Dalam kisaran harga saya, saya tidak tahu analog sama sekali, tulis di komentar jika ada. Namun, arus keluar pengembang dari ekosistem menjadi lebih nyata, dan ini adalah "saluran otak". Industri ini bersemangat untuk modernisasi.
Jika Anda seorang pengembang - jangan berputar dalam siklus 1C dan jangan berpikir bahwa dalam bahasa lain semuanya ajaib. Saat Anda Juni - mungkin. Segera setelah Anda perlu memecahkan sesuatu yang lebih besar, Anda harus mencari solusi yang sudah jadi lebih lama dan menyelesaikan lebih intensif. Dengan tingkat kualitas "kubus" dari mana Anda dapat membangun solusi - 1C sangat, sangat bagus.
Namun - jika Anda datang untuk menyewa nama panggilan 1C, maka nama panggilan 1C dapat disimpan dengan aman di analis utama. Memahami tugas, bidang studi, keterampilan dekomposisi yang telah mereka kembangkan dengan sempurna. Saya yakin ini justru karena penggunaan paksa DDD dalam pengembangan 1C. Seseorang dilatih untuk memikirkan arti tugas di tempat pertama, tentang koneksi antara objek dari area subjek, dan memiliki latar belakang teknis tentang teknologi integrasi dan format pertukaran data.
Sadarilah bahwa kerangka kerja ideal tidak ada dan jaga diri Anda.
Baik untuk semua!
PS: terima kasih banyak speshurik untuk membantu artikel ini.