1C——善與惡。 1C 左右霍利瓦爾點的排列

朋友、同事們，最近關於 Habré 仇恨 1C 作為開發平台的文章及其維護者的言論越來越多。這些文章指出了一個嚴重的問題：大多數情況下，1C的批評者是從「不掌握它」的立場來批評它的，責罵事實上很容易解決的問題，相反，沒有觸及真正重要、值得的問題。我認為對1C平台進行冷靜、平衡的審查是有意義的。它能做什麼，不能做什麼，它應該做什麼但不做什麼，還有，作為甜點，它會做什麼，而你的 %technology_name% 的開發人員會做一百年，然後把它扔掉超過一份年度預算。

因此，作為經理或架構師，您將能夠清楚地了解哪些任務對您使用 1C 有利，以及哪些地方需要用熱熨斗燒掉。作為「非 1C」世界中的開發人員，您將能夠看到 1C 中存在哪些問題。而身為 1C 開發者，你將能夠將你的系統與其他語言的生態系統進行比較，了解你在軟體開發座標系中的位置。

在剪輯之下，有很多對 1C、對 1C 的批評者、對 Java、.NET 以及一般情況的猛烈攻擊……粉絲已滿，歡迎！

關於我

大約從 2004 年開始，我就熟悉了對話的主題。我大概從 6 歲起就開始編程了，從我收到一本關於 Fortran 教授的書以及關於貓、麻雀和毛毛蟲的漫畫的那一刻起。我根據書中的圖片分析了貓寫的程序，看看它們做了什麼。是的，我當時沒有一台真正的電腦，但是書上有一張圖畫，我誠實地按下了紙質按鈕，輸入了我在貓 X 上監視到的命令。

然後學校裡有BK0011和BASIC，大學裡有C++和彙編，然後是1C，然後還有很多我懶得記的東西。在過去的 15 年裡，我主要參與 1C，不僅是編碼方面，而且是 1C 的整體。在這裡設定任務、管理和開發。在過去的 5 年裡，我一直致力於為其他 1C 用戶開發開發和自動化工具、撰寫文章和書籍等對社會有用的活動。

讓我們決定討論的主題

首先，讓我們定義一下我們要討論的內容，因為字母「1C」可以意味著很多東西。在這種情況下，字母“1C”僅指現代第八版本的開發框架“1C：Enterprise”。我們不會過多談論製造商及其政策（但我們必須做一點）我們不會討論使用此框架編寫的具體應用程式。技術是獨立的，應用程式（即配置）也是獨立的。

高層架構1C：企業

我提到「框架」這個詞並不是無緣無故的。從開發者的角度來看，1C平台恰恰是一個框架。你需要像對待框架一樣對待它。將其視為由某個執行時間（分別為 JVM 或 CLR）執行的 Spring 或 ASP.NET。碰巧的是，在傳統程式設計（「不是 1C」）的世界中，框架、虛擬機器和特定應用程式的分割是很自然的，因為這些元件通常是由不同的製造商開發的。在1C世界中，並沒有明確區分開發框架和運行時本身的習慣；此外，使用框架編寫的特定應用程式也主要由1C本身開發。結果，出現了一些混亂。因此，在本文的框架內，我們必須同時從多個方面考慮1C，並沿著多個座標軸對其進行分類。在每個座標軸上我們都會放一把棕色物質鏟子，看看現有解決方案的特性、優點和缺點。

對1C的觀點

買家1C

買家購買一套自動化系統，快速解決自己業務的自動化問題。企業可以是一個小攤位，也可以是大型控股公司。顯然，這些業務的需求是不同的，但兩者都由單一平台程式碼庫支援。

對於 1C 買家來說，這是一個快速的上市時間。快速地。比 Java、C# 或 JS 更快。平均的。醫院週邊。顯然，使用 React 的名片網站效果會更好，但 WMS 系統的後端在 1C 上啟動速度會更快。

1C作為工具

每種技術解決方案都有適用性的限制。 1C 不是一種通用語言；它不能脫離其框架而存在。當您需要以下情況時，建議使用 1C：

• 伺服器應用程式
• 出現財務的應用程式
• 具有現成的 UI、ORM、報告、XML/JSON/COM/PDF/YourDataTransferingFormat
• 支援後台進程和作業
• 具有基於角色的安全性
• 具有可編寫腳本的業務邏輯
• 能夠快速創建原型並縮短上市時間

如果您想要以下內容，則不需要 1C：

• 機器學習
• GPU運算
• 電腦圖像
• 數學計算
• CAD系統
• 訊號處理（聲音、視訊）
• 具有數十萬 rps 的高負載 http 調用

1C 作為製造公司

值得了解1C作為軟體廠商的業務是什麼。 1C 公司透過自動化銷售業務問題的解決方案。不同的企業，無論大小，但這就是她銷售的產品。實現這目標的手段就是業務應用。對於會計、工資核算等。專為這些相同業務應用程式的常見任務量身定制：

• 財務會計
• 輕鬆自訂業務邏輯
• 異質 IT 環境中的廣泛整合可能性

身為製造商，1C相信這才是讓您與合作夥伴、客戶共贏的策略。您可以對此提出異議，但這大致就是該公司宣傳自己的方式：針對業務問題提供現成的解決方案，可以由合作夥伴快速自訂並整合到任何 IT 環境中。

所有以 1C 作為框架的主張或願望都應該透過這個稜鏡來看。 「我們希望 1C 中的 OOP，」開發人員說。 「在平台上支援 OOP 需要花費多少錢，這會幫助我們增加盒子的銷售嗎？」1C 說。打開他銷售業務問題解決方案的「棱鏡」：

- 嘿，生意人，你想在你的 1C 中使用 OOP 嗎？
- 這能幫助我解決我的問題嗎？
- 誰知道...
——那就沒必要了

這種方法可能好也可能壞，這取決於誰在看它，但事實就是如此。談到 1C 中沒有功能 X 的事實，您需要明白它的存在不是有原因的，而是在「實施成本與利潤金額」選擇的背景下。

技術分類

「事實上，Odinesniks 盡最大努力使用 1C 平台的方法學家和開發人員精心挑選的最佳模式。
當您為簡單的託管表單編寫愚蠢的程式碼時，實際上您正在使用 模型視圖控制器 с 雙向資料綁定 в 三層數據應用引擎, 調味 高階物件關係映射 在基地 聲明性元資料描述有自己的 獨立於平台的查詢語言，C 聲明性資料驅動的使用者介面、完全透明的序列化和麵向領域的程式語言.

1C 開發人員與西方同事的不同之處在於公關。他們喜歡給任何廢話冠以大名，然後像一個髒袋子一樣帶著它到處跑。
A·奧列夫科夫

1C 平台具有經典的三層架構，其中心是應用伺服器（或對於小店主來說花費很少的錢進行模擬）。使用 MS SQL 或 Postgres 作為 DBMS。也支援 Oracle 和 IBM DB3，但這相當深奧；沒有人知道如果在中高負載下在這些資料庫上實施 2C 會發生什麼。我相信1C自己也不知道這一點。

客戶端部分可以是安裝在使用者電腦上的瘦客戶端，也可以是 Web 用戶端。關鍵特徵是程式設計師不會編寫兩種不同的程式碼，他們用一種語言編寫一個應用程序，如果有願望或需要，您可以將其顯示在瀏覽器中。誰想要一個真正的完整堆疊以及前端和後端的單一語言，node.js？直到最後他們都沒有做到完全相同的事。真正的完整堆疊是存在的，但你必須用 2C 來寫它。命運的諷刺，就是這樣:)

雲端 SaaS 解決方案 1C:Fresh 也可以在瀏覽器模式下運行，在瀏覽器模式下，您不能購買 1C，但可以租用小型資料庫並追蹤那裡的沙威瑪銷售情況。只需在瀏覽器中，無需安裝或配置任何內容。

此外，還有一個遺留客戶端，在 1C 中稱為「常規應用程式」。遺產就是遺產，歡迎來到 2002 年的應用程式世界，但我們仍在談論生態系統的當前狀態。

1C伺服器部分支援叢集並透過向叢集新增機器來擴展。這裡有相當多的副本已經被破壞，文章中將有一個單獨的部分來討論這一點。簡而言之，這與在 HAProxy 後面添加幾個完全相同的實例並不完全相同。

應用程式開發框架使用自己的程式語言，大致類似於翻譯成俄語的稍微改進的VB6。對於那些討厭俄語的人，不相信“if”被翻譯為“if”的人，提供了第二種語法選項。那些。如果你願意，你可以用 1C 來寫它，使其與 VB 沒有區別。

這種程式語言是 1C 暱稱對其平台憎恨的主要原因。讓我們面對現實吧，這並非沒有道理。該語言的構思盡可能簡單，旨在至少在獨聯體國家中實現「開發者，開發者」的口號。在我看來，這種解決方案的商業本質是顯而易見的：更多的開發者，更大的市場覆蓋範圍。根據從 45% 到 95% 的各種估計，這一點成為了現實。我馬上就會說，用你認為的語言寫作確實比較容易。而且我了解相當多的程式語言。

讓我們從語言開始。

1C程式語言

同時系統的優點和缺點。提供輕鬆的輸入和可讀性。另一方面，它自8年發布第2002版以來就沒有更新過，在道德上已經過時了。有人會說“主要缺點是沒有 OOP”，他們錯了。首先，巴解組織不僅不喜歡努拉利耶夫家族，也不喜歡托瓦爾茲家族。其次，OOP 仍然存在。

從開發人員的角度來看，他擁有一個框架，其中基類顯示在 DBMS 上。開發人員可以採用基底類別“Directory”並從中繼承“Clients”目錄。它可以向其中添加新的類別字段，例如 INN 和 Address，並且如果需要，它還可以重寫（覆蓋）基類的方法，例如 OnWrite/AtRecord 方法。

該框架的設計方式很少需要更深層的繼承，在我看來，OOP 中的限制是有道理的。 1C 專注於領域驅動開發，讓您先思考正在開發的解決方案的主題領域，這很好。不僅沒有誘惑，也不需要僅僅為了在某處顯示來自域的一些資料而編寫 10 個不同的 DTO 和 ViewModel。 1C 開發人員總是使用一個實體來操作，而不會用十幾個具有相似名稱的類別（代表同一實體，但來自不同的方面）來混淆感知上下文。例如，任何 .NET 應用程式都必須包含五個或兩個 ViewModel 和 DTO，用於序列化為 JSON 以及從客戶端到伺服器的資料傳輸。大約 10-15% 的應用程式程式碼將用於使用筆或拐杖（如 AutoMapper）將資料從一個類別傳輸到另一個類別。必須編寫此程式碼，並且必須付費給程式設計師來創建和維護它。

事實證明，1C語言如果不複雜到主流語言的層次就很難開發，因此失去了簡單性的優勢。供應商的任務本質上要解決什麼：發布一個標準解決方案，任何在街上遇到的學生都可以根據所需的品質水準進行客製化（即完成從攤位到大型工廠的案例）。如果你是攤子，就帶一個學生；如果你是工廠，就帶一個實施夥伴的大師。事實上，實施夥伴以大師的價格出售學生並不是該框架的問題。從架構上來說，框架必須解決這兩個問題，標準配置的程式碼（我們賣給企業並承諾客製化）應該能夠被學生理解，而大師應該能夠理解你想要的任何東西。

在我看來，這種語言真正缺少的是什麼，迫使你寫得超出你能力範圍的東西，就是浪費了客戶付出的時間。

• 在層級上打字的可能性，例如 TypeScript（因此，IDE 中的程式碼分析工具更加發達，重構，更少的攻擊性門框）
  函數作為第一類物件的可用性。概念稍微複雜一些，但典型樣板程式碼的數量可以大幅減少。恕我直言，由於數量的減少，學生對程式碼的理解甚至會增加
• 通用集合文字、初始值設定項。同樣的事情 - 減少需要編寫和/或用眼睛查看的程式碼量。填充集合佔用了 9000C 程式時間的 1% 以上。在沒有語法糖的情況下編寫此程式碼是很長、昂貴且容易出錯的。一般來說，與可用的開放框架以及所有企業 Java 的總和相比，1C 解決方案中的 LOC 數量超出了所有可以想像的限制。語言很冗長，這會退化為資料量、記憶體、IDE 煞車、時間、金錢...
• 最後的結構我有一個假設，由於他們沒有找到將其成功翻譯成俄語的事實，因此該結構丟失了:)
• 自己的資料類型（無 OOP），類似於 VB6 中的 Type。它將允許您不使用 BSP 中的註解和構造這些結構的魔術方法來鍵入結構。我們得到：更少的程式碼、通過點的提示、更快的問題解決方案、更少的由於拼字錯誤和缺少結構屬性而導致的錯誤。現在，使用者結構的類型完全取決於標準子系統庫的開發團隊，值得讚揚的是，該團隊仔細地對傳遞的參數結構的預期屬性編寫了註釋。
• 在 Web 用戶端上處理非同步呼叫時沒有任何糖分。以ProcessingNotifications形式出現的callback-hell是主要瀏覽器API的突然變化所導致的臨時拐杖，但你不能一直這樣生活；非同步程式碼的「學生理解」優勢正在喪失；越來越多。如果主 IDE 不支援這種範例，情況會變得更糟。

這是緊迫的問題之一，很明顯這個清單可能會更大，但我們不能忘記這仍然不是通用語言，它不需要多執行緒、lambda 函數、存取 GPU 和快速浮點運算。這是一種業務邏輯腳本語言。

一個已經經常使用這種語言工作的程式設計師，研究 js 或 c#，會對這種語言的框架感到厭倦。這是事實。他需要發展。對供應商來說，天秤的另一面是實施指定功能的成本與實施後收入的增加。在這裡我沒有任何關於公司目前認為什麼是重要的資訊。

開發環境

這裡的事情進展也不順利。有兩種開發環境。第一個是交付中包含的配置器。二是企業開發工具環境，簡稱EDT，是在Eclipse基礎上開發的。

此配置器提供全方位的開發任務，支援所有功能，是市場上的主要環境。據傳言，由於其本身存在大量技術債務，它在道德上也已經過時，沒有發展。這種情況可以透過開放內部API（以與 雪人 A. Orefkova 或獨立的基礎上），但事實並非如此。實踐表明，社區會在IDE中編寫自己的功能，只要供應商不干涉。但我們有我們所擁有的。配置器在 2004-2005 年很棒，很讓人想起那個時代的 Visual Studio，在某些地方甚至更酷，但它停留在那個時代。

此外，從那時起，平均標準解決方案的體積已經增長了數倍，而今天的 IDE 根本無法應付所輸入的程式碼量。可用性和重構能力甚至不是零，它們處於虧損狀態。所有這些並沒有增加開發人員的熱情，他們夢想轉移到其他生態系統並繼續在那裡編寫程式碼，但在一個愉快的環境中，其行為不會向你吐口水。

作為替代方案，我們提供了一個基於 Eclipse 建置的從頭開始編寫的 IDE。與其他軟體一樣，原始碼以文字檔案的形式存在，儲存在 GIT、拉取請求分支等。不利的一面是，它多年來一直沒有離開測試版狀態，儘管每次發布都變得越來越好。我不會寫 EDT 的缺點，今天它是一個減號，明天它是一個固定功能。這種描述的相關性很快就會消失。如今，可以在 EDT 中進行開發，但這並不常見；您需要為一定數量的 IDE 錯誤做好準備。

如果透過前面提到的「1C棱鏡」來看情況，你會得到這樣的結論：新IDE的發布並不會增加盒子的銷量，但開發者的流出可能會減少。很難說生態系統在開發者舒適度方面會發生什麼，但微軟已經因為太晚向行動開發者提供服務而搞砸了。

開發管理

這裡的一切都比編寫程式碼要好得多，尤其是最近，當社群的努力揭示了管理自動化的問題時，推出了原型，要求將 1C 儲存庫扔進垃圾堆並使用 git、快速指責、程式碼審查、靜態分析、自動部署等。該平台添加了許多功能，提高了開發任務的自動化程度。然而，所有這些功能都是專門為我們自己的大型產品的開發而添加的，當時很明顯我們離不開自動化。有自動合併、與 KDiff 的三向比較等等。在Github上發布 git轉換器，坦白說，他在意識形態上被拖離了該項目 gitsync，但進行了修改以適應供應商公司的流程。感謝開源領域頑固的人們，1C 的開發自動化取得了進展。恕我直言，配置器的開放 API 也將改變主要 IDE 的道德落後。

如今，將 1C 原始碼儲存在 git 中，並在 Jira 中儲存與問題相關的提交、Crucible 中的評論、Jenkins 的按鈕以及關於 1C 中程式碼測試的 Allure 報告，甚至 SonarQube 中的靜態分析 - 這遠不是新聞，而是大量進行 1C 開發的公司的主流。

管理

這裡有很多話要說。首先，這當然是一台伺服器（1C伺服器叢集）。這是一件美妙的事情，但由於它是一個完全黑盒子，並且以特定的方式記錄了足夠的細節 - 掌握在多台服務器上以高負載模式啟動不間斷操作是少數穿著獎章上刻有“技術問題專家”字樣。值得注意的是，原則上，管理 1C 伺服器與管理任何其他伺服器沒有什麼不同。它是一個基於網路的多線程應用程序，消耗記憶體、CPU 和磁碟資源。為遙測收集和診斷提供充足的機會。

這裡的問題是供應商沒有為這個診斷提供任何特殊的現成解決方案。是的，有1C：儀表和控制中心，它們甚至相當不錯，但它們非常昂貴，並不是每個人都有。社區中有許多用於連接 Grafana、Zabbix、ELK 和標準管理集中的其他事物的開發，但沒有一個解決方案適合大多數人。任務等待著它的英雄。如果您是一家計劃在 1C 叢集上啟動的企業，那麼您需要專家。你自己的內部或外部，但你需要它。有一個單獨的角色具有伺服器操作的權限是很正常的，並不是每個 1C 使用者都應該知道這一點，您只需要了解需要這樣的角色。我們以 SAP 為例。在那裡，如果要求程式設計師在應用程式伺服器上配置某些內容，他很可能甚至不會從椅子上站起來。他可能只是愚蠢，他不會感到羞恥。在 SAP 方法中，為此有一個單獨的員工角色。由於某種原因，在 1C 行業中，人們認為這應該合併在一名員工身上，並獲得相同的薪水。這是一個錯覺。

1C伺服器的缺點

只有一個缺點——可靠性。或者，如果你願意的話，也可以說是不可預測性。伺服器突然出現的奇怪行為已經成為人們談論的話題。專家手冊中甚至描述了一種通用的補救措施 - 停止伺服器並清除所有快取 - 甚至建議使用批次手冊來執行此操作。如果您的 1C 系統開始執行理論上不應該執行的操作，則需要清除會話資料快取。據我估計，全國祇有三個人知道如何在沒有這個程式的情況下操作1C伺服器，並且他們不分享秘密，因為...他們以此為生。也許他們的秘密是他們清理會話數據，但他們不會告訴任何人，夥計。

除此之外，1C 伺服器與任何其他應用程式都是相同的應用程序，並且透過閱讀文件和敲擊手鼓以大致相同的方式進行管理。

碼頭工人

在生產中使用容器化 1C 伺服器的實用性尚未得到證實。伺服器不是透過簡單地在均衡器後面添加節點來叢集的，這將生產容器化的好處降到了最低，並且在高負載模式下在容器中成功運行的實踐尚未建立。因此，只有開發人員使用Docker+1C來建構測試環境。它非常有用、實用，可以讓您使用現代技術並從配置器的沮喪中休息一下。

商業組件

從投資的角度來看，1C 可以幫助您解決由於應用程式類別的廣泛功能而快速啟動業務想法的問題。開箱即用的 1C 提供了非常不錯的報告、與任何內容的整合、Web 用戶端、行動用戶端、行動應用程式、對各種 DBMS 的支持，包括。免費、跨平台的伺服器和已安裝的客戶端部分。是的，應用程式的 UI 會是黃色的，有時這是一個缺點，但並非總是如此。
透過選擇 1C，企業可以獲得一套軟體解決方案，使他們能夠建立非常廣泛的應用程序，並且市場上有許多開發人員想要比 Javaists 更少的錢，同時更快地產生結果。

例如，向客戶發送 PDF 發票的任務可以在學生工作一小時內解決。 .NET 中的相同問題可以透過購買專有函式庫或由嚴肅的大鬍子開發人員進行幾天或幾週的編碼來解決。有時，兩者會同時發生。是的，我只是談論 PDF 生成。我們還沒有說這筆帳單將來自哪裡。 Web 前端必須建立一個表單，操作員將在其中輸入數據，後端必須創建用於傳輸 JSON 的 dto 模型、用於儲存在資料庫中的模型、資料庫本身的結構、遷移到資料庫、形成圖形顯示這個帳戶，然後才顯示- PDF。在 1C 上，整個任務從頭開始，恰好在一小時內完成。

一個完整的會計系統，適用於一個小攤位，只需3 小時即可完成購買/銷售的業務流程，包括銷售報告、按購買和銷售價格進行​​的貨物會計、按倉庫細分、訪問權限控制、網絡客戶端和行動應用程式。好吧，我忘了申請了，申請不是三小時後，而是六小時後。

.NET 開發人員從在乾淨的電腦上安裝 Visual Studio 到向客戶示範任務需要多長時間？開發成本又如何呢？一樣。

1C 作為平台的優勢

1C之所以強大，並不是因為它有什麼特定的東西是世界上最好的。相反，在每個單獨的子系統中，您都可以在世界軟體中找到更有趣的類似物。然而，綜合多種因素，我並沒有看到類似1C的平台。這就是商業成功之所在。該平台的優點分散在整個平台中，當您看到其他平台是如何實現這一點時，這些優點最為明顯。基本上，這些甚至不是功能，而是相反 - 拒絕支援某種特定範例的功能。舉幾個例子：

1. 統一碼。到底還有什麼可以更簡單呢？ 2019 年沒有必要使用單字節 ASCII 編碼（除了與古老遺留編碼的整合）。絕不。但不是。無論如何，某些表中的某人使用單字節 varchar 並且應用程式將出現編碼問題。 2015 年，由於編碼工作不正確，gitlab 的 LDAP 授權失敗；JetBrains IDE 仍然無法在所有檔案名稱中使用西里爾字母。 1C 提供應用程式程式碼與資料庫層的高品質隔離。在那裡不可能在低級別上鍵入表格，並且在那裡也不可能出現資料庫級別無能的初級人員。是的，無能的後輩可能還會出現其他問題，但問題的種類要少得多。現在您將告訴我您的應用程式設計正確，並且資料庫存取層已按照應有的方式隔離。再看看您的企業自訂 Java 應用程式。密切而誠實。你的良心困擾嗎？那我為你感到高興。
2. 文件/參考書的編號。在1C中它絕對不是最靈活的也不是最好的。但他們在銀行軟體和自行編寫的會計系統中所做的事情——嗯，這只是黑暗。要么身份被卡住（然後“哦，為什麼我們有漏洞”），要么相反，他們將製作一個與 DBMS 級別的鎖定一起工作的生成器（並將成為瓶頸）。事實上，完成這個看似簡單的任務是相當困難的——一個端到端的實體枚舉器，具有基於一組特定鍵的唯一性部分、前綴，以便在並行資料輸入期間不會阻塞資料庫。
3. 資料庫中記錄的標識符。 1C 做出了一個意志堅定的決定－所有連結標識符都是絕對合成的，僅此而已。而且分散式資料庫和交易所也不存在問題。其他系統的開發人員固執地創建類似身份的東西（它更短！），將它們拖到 GUI 中，直到需要創建幾個相關實例（然後它們就會被發現）。你沒有這個嗎？誠實地？
4. 列表。 1C 具有相當成功的機制來對（大）列表進行分頁和導航。讓我立即預訂 - 並正確使用該機制！總的來說，這個主題相當令人不愉快，無法理想地解決：它要么直觀且簡單（但客戶端存在巨大記錄集的風險），要么分頁有這樣或那樣的彎曲。那些做傳呼的人常常做得歪歪扭扭。那些製作誠實滾動條的人添加了資料庫、通道和客戶端。
5. 託管表格。毫無疑問，在網路客戶端中，介面不能完美運作。但它有效。但對於許多其他會計和銀行系統來說，創建遠端工作場所是一個企業級專案。免責聲明：幸運的是，對於那些最初在網路上製作的人來說，這不會產生影響。
6. 行動應用。最近，您也可以在同一生態系統中編寫行動應用程式。這裡比網頁用戶端稍微複雜一些；設備的具體情況迫使您專門為它們編寫，但是，您不需要雇用單獨的行動開發人員團隊。如果您需要一個應用程式來滿足公司的內部需求（當公司問題的行動解決方案比黃色 UI 設計更重要時），您只需使用開箱即用的相同平台即可。
7. 報告。我所說的這個詞並不是指具有大數據和 ETL 流程滯後的 BI 系統。這是指營運人員報告，可讓您評估此時此地的會計狀況。餘額、相互結算、重新評級等1C 隨附一個開箱即用的報告系統，可在用戶端進行靈活的分組、篩選器和視覺化設定。是的，市場上有更酷的類似物。但不在一體化解決方案的框架內，而且價格有時比一體化解決方案更高。更常見的是，情況甚至相反：僅報告，但比整個平台更昂貴，而且品質更差。
8. 可列印的表格。那麼，使用.NET來解決透過電子郵件向員工發送PDF格式的薪資單的問題。現在是列印發票的任務。將它們的副本保存到同一個 PDF 中怎麼樣？對於 1C 暱稱來說，將任何佈局輸出到 PDF 都是 +1 行程式碼。這意味著 + 40 秒的工作時間，而不是使用其他語言的幾天或幾週。 1C 中的列印表單佈局非常容易開發，且功能強大，足以與付費同行競爭。是的，1C 電子表格文件中可能沒有太多互動機會；您無法使用 OpenGL 快速獲得具有縮放功能的 3D 圖表。但這真的有必要嗎？

這些只是少數幾個示例，其中限制功能或實施妥協被證明是未來的重要架構優勢。即使是妥協或不是最有效的選擇 - 它已經在盒子裡並被認為是理所當然的。它的獨立實現要么是不可能的（因為這樣的決定必須在專案開始時做出，而沒有時間這樣做，也根本沒有架構師），要么需要多次昂貴的迭代。在列出的每個點（這不是架構解決方案的完整清單）中，您可能會搞砸並引入阻礙擴展的限制。無論如何，作為一名商人，您需要確保您的程式設計師在「從頭開始建立系統」時能夠直接處理微妙的系統問題。

是的，與任何其他複雜系統一樣，1C 本身也有在某些方面阻礙擴展的解決方案。然而，我再說一遍，基於綜合因素、擁有成本以及已經提前解決的問題數量，我在市場上看不到值得競爭的競爭對手。以相同的價格，您可以獲得一個財務應用程式框架、一個叢集平衡伺服器、一個 UI 和 Web 介面、一個行動應用程式、報告、整合和許多其他功能。在 Java 世界中，您需要聘請前端和後端團隊，調試大量自製伺服器程式碼，並分別為 2 個行動作業系統的 2 個行動應用程式付費。

我並不是說 1C 可以解決所有情況，但是對於內部企業應用程式來說，當不需要對 UI 進行品牌化時 - 還需要什麼？

美中不足

您可能有這樣的印象：1C 將拯救世界，所有其他編寫公司係統的方法都是錯誤的。根本不是那樣的。從商人的角度來看，如果選擇1C，那麼除了上市時間快之外，還必須考慮到以下缺點：

• 伺服器可靠性。需要真正高素質的專家來確保其不間斷運作。我不知道供應商是否有針對此類專家的現成培訓計劃。有一些課程可以為專家考試做準備，但在我看來，這還不夠。
• 支持。請參閱上一點。要獲得供應商的支持，您需要購買它。由於某種原因，這在 1C 行業中不被接受。對於 SAP，它幾乎是必須購買的，而且不會打擾任何人。如果沒有公司的支持，也沒有專家的員工，您可能會遇到 1C 故障。
• 不過，您並不能用 1C 完成所有事情。這是一個工具，與其他工具一樣，它也有適用性的限制。在 1C 領域，非常需要有一個「非 1C」系統架構師。
• 好的 1C 暱稱並不比其他語言的好的程式設計師便宜。儘管如此，僱用糟糕的程式設計師的成本很高，無論他們用什麼語言編寫。

讓我們點點滴滴

• 1C 是一個以業務為導向的快速應用程式開發 (RAD) 框架，就是為此而設計的。
• 三層鏈接，支援主要 DBMS、客戶端 UI、非常好的 ORM 和報告
• 與系統整合的廣泛可能性，可以完成 1C 無法完成的任務。如果你想要機器學習，使用Python並透過http或RabbitMQ將結果送到1C
• 沒有必要努力用1C來做所有的事情，你需要了解它的優勢並將其用於你自己的目的
• 那些傾向於深入研究技術框架小工具並每 N 年重新設計一個新引擎的開發人員對 1C 感到厭倦。那裡的一切都非常保守。
• 開發人員也感到無聊，因為製造商很少關心他們。語言枯燥，IDE 弱。他們需要現代化。
• 另一方面，無法透過使用和學習他們喜歡的另一種技術來找到樂趣的開發人員是糟糕的開發人員。他們會抱怨並轉移到另一個生態系統。
• 不允許 1C 暱稱用 Python 寫東西的雇主是糟糕的雇主。他們將失去好奇的員工，取而代之的是猴子編碼員，他們在同意一切的同時，會將企業軟體拖入沼澤。它仍然需要重寫，所以也許早一點在Python上投入一點會更好？
• 1C是一家商業公司，其功能的實現完全基於其自身的利益和權宜之計。這不能怪她，做生意必須考慮利潤，這就是人生
• 1C 透過銷售業務問題的解決方案來賺錢，而不是 Vasya 的開發人員問題。這兩個概念是相關的，但優先順序正是我所說的。當開發者 Vasya 準備支付 1C: Resharper 的個人許可證時，它很快就會出現，A. Orefkova 的「Resharper」就是證明。如果供應商支持它，並且不反對它，那麼就會出現一個面向開發人員的軟體市場。現在這個市場上有一個半玩家的結果值得懷疑，而這一切都是因為與 IDE 的整合是負面的，而且一切都是拄著拐杖完成的。
• 多機操作員的做法將被遺忘。現代應用程式太大，無論從程式碼方面還是從業務使用方面都難以記住。 1C 伺服器也變得更加複雜；一名員工不可能掌握所有類型的專業知識。這應該會帶來對專家的需求，這意味著1C職業的吸引力和薪資的增加。如果說以前瓦斯亞是三合一，薪水一份，那麼現在你需要雇用兩個瓦斯亞，瓦斯亞之間的競爭可以促進他們水準的整體提升。

結論

1C是一款非常值得的產品。在我的價格範圍內，我根本不知道任何類似的東西，如果有的話請在評論中寫下。然而，開發者從生態系統中流出的現象越來越明顯，無論怎麼看，這都是一種「人才流失」。該行業渴望現代化。
如果你是開發人員，不要沉迷於 1C，也不要認為其他語言的一切都很神奇。當你還是個大三學生的時候，也許吧。一旦需要解決更大的問題，就必須更長時間地尋找現成的解決方案並更集中地完成。就建造解決方案的「區塊」的品質而言，1C 非常非常好。

還有一件事 - 如果您來僱用 1C 暱稱，那麼 1C 暱稱可以安全地被任命為首席分析師的職位。他們對任務、主題領域和分解技能的理解非常出色。我確信這正是由於1C開發中強制使用DDD所造成的。該人員經過培訓，首先思考任務的意義，思考主題領域的對象之間的聯繫，同時具有整合技術和資料交換格式的技術背景。

請注意，理想的框架並不存在，請照顧好自己。
對所有人都好！

PS：非常感謝 斯佩蘇里克 尋求文章準備的協助。

只有註冊用戶才能參與調查。 登入， 請。

您的企業有1C嗎？

• 13,3%一點也不。

• 30,3%有，但僅限於會計部門的某個地方。其他平台上的核心系統162

• 41,4%是的，主要業務流程均在其上運行221

• 15,0%1C必須死，未來屬於%technology_name%80

534 位用戶投票。 99 名用戶棄權。

來源： www.habr.com