1C - 선과 악. 1C 주변 홀리바르의 점 배열

친구와 동료 여러분, 최근 Habré에 대한 개발 플랫폼으로서의 1C에 대한 증오와 옹호자의 연설이 더 자주 등장했습니다. 이 기사는 하나의 심각한 문제를 식별했습니다. 대부분의 경우 1C의 비평가는 "마스터하지 않음"이라는 입장에서 이를 비판하고 사실상 쉽게 해결되는 문제를 꾸짖으며 반대로 정말 중요하고 가치 있는 문제를 다루지 않습니다. 논의하고 공급업체가 해결하지 않습니다. 1C 플랫폼에 대해 냉정하고 균형 잡힌 검토를 수행하는 것이 합리적이라고 생각합니다. 무엇을 할 수 있는지, 무엇을 할 수 없는지, 무엇을 해야 하지만 하지 않는지, 그리고 후식으로는 굉장한 일을 하며 %technology_name%의 개발자는 XNUMX년 동안 그것을 버릴 것입니다. 하나 이상의 연간 예산.

결과적으로 관리자 또는 건축가로서 귀하는 1C를 사용하는 것이 어떤 작업에 도움이 될지, 뜨거운 인두로 태워야 할 부분을 명확하게 이해할 수 있습니다. "1C가 아닌" 세계의 개발자로서 귀하는 1C에 소란을 일으키는 것이 무엇인지 확인할 수 있습니다. 그리고 1C 개발자로서 귀하는 귀하의 시스템을 다른 언어의 생태계와 비교하고 소프트웨어 개발 좌표계에서 귀하의 위치를 ​​이해할 수 있습니다.

컷 아래에는 1C, 1C 비판자, Java, .NET 및 일반에 대한 두꺼운 공격이 많이 있습니다. 팬이 가득 찼습니다. 환영합니다!

성명서

나는 대략 2004년부터 대화 주제에 익숙해졌습니다. 나는 아마도 6살 때부터 프로그래밍을 해왔을 것입니다. 포트란 교수에 관한 책과 고양이, 참새, 애벌레에 관한 만화를 접한 바로 그 순간부터 말이죠. 책 속 그림을 보고 고양이가 쓴 프로그램을 분석해 어떤 일을 하는지 알아봤습니다. 그리고 네, 그 당시에는 실제 컴퓨터가 없었지만 책의 펼쳐진 부분에 그림이 있었고 솔직히 종이 버튼을 눌러 고양이 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를 원합니다"라고 말합니다. 1C는 "플랫폼에서 OOP를 지원하는 데 비용이 얼마나 들까요? 이것이 박스 판매를 늘리는 데 도움이 될까요?"라고 말합니다. 비즈니스 문제에 대한 솔루션을 판매하는 "프리즘"을 엽니다.

- 안녕하십니까, 1C에 OOP를 원하시나요?
- 이것이 내 문제를 해결하는 데 도움이 될까요?
- 누가 알아...
- 그럼 필요없어

이 접근 방식은 보는 사람에 따라 좋을 수도 있고 나쁠 수도 있지만 실제로는 그렇습니다. 1C에 기능 X가 없다는 사실에 대해 말하면 이유가 있는 것이 아니라 "구현 비용 대 이익 금액"을 선택하는 맥락에서 기능 X가 있다는 것을 이해해야 합니다.

기술 분류

“실제로 Odinesniks는 1C 플랫폼의 방법론자와 개발자가 신중하게 선택한 최고의 패턴을 사용하기 위해 최선을 다합니다.
간단한 관리 양식에 대한 어리석은 코드를 작성할 때 실제로는 다음을 사용하고 있습니다. 모델 뷰 컨트롤러 с 양방향 데이터 바인딩 в XNUMX계층 데이터 앱 엔진, 맛이 나는 높은 수준의 객체 관계 매핑 기지에 선언적 메타데이터 설명자신의 것을 가지고 플랫폼 독립적인 쿼리 언어, C 선언적 데이터 기반 사용자 인터페이스, 완전하고 투명한 직렬화 및 도메인 지향 프로그램 언어.

1C 개발자가 서구 동료와 다른 점은 PR입니다. 그들은 헛소리에 큰 이름을 붙이고 더러운 가방처럼 뛰어다니는 것을 좋아합니다.”
A. 오레프코프

1C 플랫폼은 고전적인 3계층 아키텍처를 가지고 있으며 그 중심에는 애플리케이션 서버(또는 소규모 상점 주인을 위한 적은 비용의 에뮬레이션)가 있습니다. DBMS로는 MS SQL 또는 Postgres를 사용합니다. Oracle 및 IBM DB2에 대한 지원도 있지만 이것은 다소 난해합니다. 중간 및 높은 부하에서 이러한 데이터베이스에 1C를 구현하면 어떤 일이 일어날지 아무도 모릅니다. 나는 1C 자체가 이것을 모른다고 믿습니다.

클라이언트 부분은 사용자 컴퓨터에 설치된 씬 클라이언트이거나 웹 클라이언트입니다. 핵심 기능은 프로그래머가 2개의 다른 코드를 작성하는 것이 아니라 하나의 애플리케이션, 하나의 언어로 작성하고 원하거나 필요한 경우 브라우저에 표시할 수 있다는 것입니다. 프론트엔드와 백엔드를 위한 진정한 풀스택과 단일 언어인 node.js를 누가 원했습니까? 그들은 끝까지 똑같은 일을 해내지 못했습니다. 실제 풀스택이 존재하지만 1C로 작성해야 합니다. 운명의 아이러니란 이런 것 :)

클라우드 SaaS 솔루션 1C:Fresh는 1C를 구매할 수 없지만 소규모 데이터베이스를 임대하고 그곳에서 shawarma 판매를 추적하는 브라우저 모드에서도 작동합니다. 아무것도 설치하거나 구성하지 않고 브라우저에서 바로 가능합니다.

또한 1C에서는 "일반 응용 프로그램"이라고 불리는 레거시 클라이언트가 있습니다. 레거시는 레거시입니다. 2002년 애플리케이션의 세계에 오신 것을 환영합니다. 하지만 우리는 여전히 생태계의 현재 상태에 대해 이야기하고 있습니다.

1C 서버 부분은 클러스터에 새 시스템을 추가하여 클러스터링 및 확장을 지원합니다. 여기에서는 꽤 많은 사본이 손상되었으며 이에 대한 기사의 별도 섹션이 있을 것입니다. 간단히 말해서 이는 HAProxy 뒤에 정확히 동일한 인스턴스 몇 개를 추가하는 것과 완전히 동일하지 않습니다.

애플리케이션 개발 프레임워크는 러시아어로 번역된 약간 개선된 VB6과 대략 유사한 자체 프로그래밍 언어를 사용합니다. 러시아어를 모두 싫어하고 "if"가 "if"로 번역된다는 것을 믿지 않는 사람들을 위해 두 번째 구문 옵션이 제공됩니다. 저것들. 원한다면 VB와 구별되지 않는 방식으로 1C로 작성할 수 있습니다.

바로 이 프로그래밍 언어가 플랫폼에 대한 1C 별명을 싫어하는 주된 이유입니다. 이유 없이는 아니지만 현실을 직시합시다. 언어는 최소한 CIS에서 "개발자, 개발자"라는 만트라를 충족하도록 설계되었으며 최대한 단순하게 고안되었습니다. 제 생각에는 그러한 솔루션의 상업적 본질은 더 많은 개발자, 더 넓은 시장 범위라는 점에서 분명하게 드러납니다. 다양한 추정에 따르면 이는 45%에서 95%까지 실현되었습니다. 당신이 생각하는 언어로 글을 쓰는 것이 정말 쉽다고 바로 말씀드리겠습니다. 그리고 저는 꽤 많은 프로그래밍 언어를 알고 있습니다.

언어부터 시작해 보겠습니다.

1C 프로그래밍 언어

동시에 시스템의 강점과 약점. 쉬운 입력과 가독성을 제공합니다. 반면, 8년 버전 2002이 출시된 이후 업데이트가 되지 않아 도덕적으로 시대에 뒤떨어진 버전이다. 어떤 사람은 "가장 큰 단점은 OOP가 없다는 것입니다"라고 말하지만 그들은 틀릴 것입니다. 첫째, PLO는 Nuraliev뿐만 아니라 Torvalds도 좋아하지 않습니다. 둘째, OOP는 여전히 존재합니다.

개발자의 관점에서 볼 때 그는 DBMS에 표시되는 기본 클래스가 있는 프레임워크를 마음대로 사용할 수 있습니다. 개발자는 기본 클래스 "Directory"를 가져와서 "Clients" 디렉터리를 상속받을 수 있습니다. INN 및 Address와 같은 새 클래스 필드를 추가할 수 있으며, 필요한 경우 OnWrite/AtRecord 메서드와 같은 기본 클래스의 메서드를 재정의(재정의)할 수도 있습니다.

프레임워크는 더 깊은 상속이 거의 필요하지 않은 방식으로 설계되었으며 제 생각에는 OOP의 제한이 합리적입니다. 1C는 Domain Driven Development에 초점을 맞춰서 무엇보다 개발 중인 솔루션의 주제 영역에 대해 생각하게 해주는데 좋은 것 같아요. 유혹이 없을 뿐만 아니라 도메인 어딘가의 일부 데이터를 표시하기 위해 10개의 서로 다른 DTO 및 ViewModel을 작성할 필요도 없습니다. 1C 개발자는 동일한 엔터티를 나타내지만 다른 측면에서 유사한 이름을 가진 10개의 클래스로 인식의 맥락을 어지럽히지 않고 항상 하나의 엔터티로 작업합니다. 예를 들어 모든 .NET 애플리케이션에는 JSON으로 직렬화하고 클라이언트에서 서버로 데이터를 전송하기 위해 반드시 15~XNUMX개의 ViewModel과 DTO가 포함됩니다. 그리고 애플리케이션 코드의 약 XNUMX-XNUMX%는 AutoMapper와 같은 펜이나 ​​목발을 사용하여 한 클래스에서 다른 클래스로 데이터를 전송하는 데 사용됩니다. 이 코드는 작성되어야 하며 프로그래머는 코드를 작성하고 유지하는 데 대한 대가를 받아야 합니다.

1C 언어는 주류 언어 수준으로 복잡하지 않으면 개발하기가 어렵기 때문에 단순성의 이점을 잃는 것으로 나타났습니다. 근본적으로 해결해야 할 공급업체의 임무는 무엇입니까? 거리에서 잡힌 모든 학생이 필요한 품질 수준으로 맞춤화할 수 있는 표준 솔루션을 발행하는 것입니다(즉, 매점에서 대형 공장까지 커버하는 케이스가 완성됨). 당신이 노점이라면 학생을 데려가고, 공장이라면 구현 파트너로부터 전문가를 데려오세요. 구현 파트너가 전문가의 가격으로 학생들을 판매한다는 사실은 프레임워크에 문제가 되지 않습니다. 구조적으로 프레임워크는 두 가지 문제를 모두 해결해야 합니다. 표준 구성 코드(사용자 정의를 약속하며 기업에 판매함)는 학생이 이해할 수 있어야 하고 전문가는 사용자가 원하는 모든 것을 이해할 수 있어야 합니다.

제 생각에는 언어에 정말 부족한 점, 할 수 있는 것보다 더 많이 쓰도록 강요하는 점은 고객이 지불한 시간을 낭비하는 점입니다.

• TypeScript와 같은 수준에서 입력 가능성(결과적으로 IDE에서 더욱 발전된 코드 분석 도구, 리팩토링, 공격적인 잼 감소)
  일급 객체로서의 기능 가용성. 약간 더 복잡한 개념이지만 일반적인 상용구 코드의 양은 크게 줄어들 수 있습니다. 볼륨 감소로 인해 IMHO 코드에 대한 학생의 이해도가 높아질 것입니다.
• 범용 컬렉션 리터럴, 이니셜라이저. 마찬가지입니다. 작성하고 눈으로 보아야 하는 코드의 양을 줄이는 것입니다. 컬렉션 채우기는 9000C 프로그래밍 시간의 1% 이상을 차지합니다. 문법적 설탕 없이 이것을 작성하는 것은 길고, 비용이 많이 들고, 오류가 발생하기 쉽습니다. 일반적으로 1C 솔루션의 LOC 양은 사용 가능한 개방형 프레임워크 및 일반적으로 모든 엔터프라이즈 Java를 결합한 것과 비교할 때 가능한 모든 제한을 초과합니다. 언어는 장황하며 이는 데이터, 메모리, IDE 브레이크, 시간, 돈의 양으로 변질됩니다.
• 마지막으로 구성 나는 이 구성이 러시아어로 성공적으로 번역되지 않았기 때문에 누락되었다는 가설을 가지고 있습니다. :)
• 자체 데이터 유형(OOP 없음), VB6의 유형과 유사합니다. 이는 BSP의 주석과 이러한 구조를 구성하는 매직 메소드를 사용하여 구조를 입력하지 않도록 허용합니다. 우리는 더 적은 코드, 점을 통한 힌트, 더 빠른 문제 해결, 오타 및 구조 속성 누락으로 인한 오류 감소를 얻습니다. 이제 사용자 구조의 타이핑은 전달된 매개변수 구조의 예상 속성에 대한 주석을 신중하게 작성하는 표준 하위 시스템 라이브러리의 개발 팀에 전적으로 달려 있습니다.
• 웹 클라이언트에서 비동기 호출 작업을 할 때 설탕이 필요하지 않습니다. ProcessNotifications 형태의 callback-hell은 메인 브라우저 API의 갑작스러운 변경으로 인한 임시 버팀목이지만 항상 이렇게 살 수는 없으며 비동기 코드에 대한 "학생의 이해"라는 이점이 상실됩니다. 점점 더. 기본 IDE에서 이 패러다임에 대한 지원을 추가하지 않으면 상황은 더욱 악화됩니다.

이것은 시급한 문제 중 하나입니다. 목록이 훨씬 더 클 수 있다는 것은 분명합니다. 그러나 이것이 여전히 범용 언어가 아니며 멀티스레딩, 람다 기능, GPU에 대한 액세스 및 빠른 속도가 필요하지 않다는 점을 잊지 말아야 합니다. 부동 소수점 계산. 이것은 비즈니스 로직 스크립팅 언어입니다.

이미 이 언어로 많은 작업을 해본 프로그래머는 js나 C#을 살펴보면 이 언어의 틀 안에서 지루해집니다. 그것은 사실이다. 그는 개발이 필요합니다. 공급업체의 또 다른 측면에는 지정된 기능을 구현하는 데 드는 비용과 구현 후 수익 증가가 있습니다. 여기에는 현재 회사의 관점에서 무엇이 더 중요한지에 대한 정보가 없습니다.

개발 환경

여기서도 일이 순조롭게 진행되지 않습니다. 개발 환경은 두 가지가 있습니다. 첫 번째는 배송에 포함된 구성자입니다. 두 번째는 Eclipse를 기반으로 개발된 Enterprise Development Tools 환경, 줄여서 EDT입니다.

구성기는 전체 범위의 개발 작업을 제공하고 모든 기능을 지원하며 시장의 주요 환경입니다. 또한 소문에 따르면 기술 부채의 양으로 인해 개발되지 않고 도덕적으로 쓸모가 없습니다. 내부 API를 공개하면 상황이 개선될 수 있습니다. 눈사람 A. Orefkova 또는 독립적으로) 그러나 그렇지 않습니다. 실습에 따르면 공급업체가 방해하지 않는 한 커뮤니티는 IDE에 자체 기능을 작성합니다. 그러나 우리는 우리가 가진 것을 가지고 있습니다. 구성자는 2004~2005년에 훌륭했고 그 당시의 Visual Studio를 매우 연상시켰으며 어떤 곳에서는 훨씬 더 멋졌으나 그 당시에 멈춰 있었습니다.

또한 그 이후로 평균 표준 솔루션의 양이 여러 번 증가했으며 현재 IDE는 공급되는 코드의 양을 감당할 수 없습니다. 유용성과 리팩토링 기능은 XNUMX도 아니고 빨간색입니다. 이 모든 것이 개발자에게 열정을 더해주는 것이 아니며 그들은 다른 생태계로 이동하여 그곳에서 계속해서 코드를 작성하는 것을 꿈꾸지만 그 행동으로 인해 얼굴에 침을 뱉지 않는 쾌적한 환경에서 이루어집니다.

대안으로 Eclipse를 기반으로 처음부터 작성된 IDE가 제공됩니다. 다른 소프트웨어와 마찬가지로 소스는 텍스트 파일 형식으로 존재하며 GIT, 풀 요청 분기 등에 저장됩니다. 단점은 출시될 때마다 점점 좋아지고 있지만 수년 동안 베타 상태를 유지하지 못했다는 점입니다. EDT의 단점에 대해서는 쓰지 않겠습니다. 오늘은 마이너스이고 내일은 고정된 기능입니다. 그러한 설명의 관련성은 빠르게 사라질 것입니다. 현재는 EDT에서 개발이 가능하지만 이는 드문 일이며 특정 수의 IDE 버그에 대비해야 합니다.

앞서 언급한 '1C 프리즘'을 통해 상황을 살펴보면 다음과 같다. 새로운 IDE 출시로 박스 판매량이 늘어나지는 않지만 DEVELOPERS 유출이 줄어들 수 있다는 것이다. 개발자 편의성 측면에서 생태계를 기다리는 것이 무엇인지 말하기는 어렵지만 Microsoft는 이미 모바일 개발자에게 서비스를 너무 늦게 제공하여 망쳐 놓았습니다.

개발관리

여기의 모든 것은 코드를 작성하는 것보다 훨씬 낫습니다. 특히 최근 커뮤니티의 노력으로 관리 자동화 문제가 밝혀지고 1C 저장소를 휴지통에 버리고 git, 빠른 비난, 코드 검토를 사용하도록 요구하는 프로토타입을 출시했을 때 더욱 그렇습니다. , 정적 분석, 자동 배포 등 개발 작업의 자동화 수준을 높이는 많은 기능이 플랫폼에 추가되었습니다. 그러나 이러한 모든 기능은 자동화 없이는 할 수 없다는 것이 분명해졌을 때 자체 대형 제품 개발을 위해서만 추가되었습니다. 자동 병합, KDiff와의 XNUMX방향 비교 등이 있었습니다. Github에서 출시됨 gitconverter, 솔직히 이념적으로 프로젝트에서 끌려 나간 사람 깃싱크, 그러나 공급업체의 프로세스에 맞게 수정되었습니다. 오픈 소스의 완고한 사람들 덕분에 1C의 개발 자동화가 시작되었습니다. 구성자 IMHO용 공개 API는 또한 기본 IDE의 도덕적 후진성을 변화시킬 것입니다.

오늘날 Jira의 문제와 연결된 커밋, Crucible의 리뷰, Jenkins의 푸시 버튼 및 1C의 코드 테스트에 대한 Allure 보고서와 함께 git에 1C 소스를 저장합니다. SonarQube의 정적 분석 -이것은 뉴스와는 거리가 멀지만 오히려 1C 개발이 많은 회사의 주류입니다.

관리

여기서 할 말이 많습니다. 첫째, 이것은 물론 서버 (1C 서버 클러스터)입니다. 놀라운 일이지만 완전히 블랙박스이기 때문에 충분히 자세하게 문서화되어 있지만 특정 방식으로 여러 서버에서 하이로드 모드로 중단 없이 작동을 시작하는 방법을 익히는 것은 선택받은 소수만이 착용할 수 있습니다. "기술 문제 전문가"라는 문구가 새겨진 메달. 원칙적으로 1C 서버 관리는 다른 서버 관리와 다르지 않다는 점은 주목할 가치가 있습니다. 메모리, CPU 및 디스크 리소스를 소비하는 네트워크 기반 다중 스레드 애플리케이션입니다. 원격 측정 수집 및 진단을 위한 충분한 기회를 제공합니다.

여기서 문제는 공급업체가 바로 이 진단을 위해 기성 솔루션 측면에서 특별한 것을 제공하지 않는다는 것입니다. 예, 1C: 계측 및 제어 센터가 있습니다. 꽤 훌륭하지만 가격이 비싸고 모든 사람이 갖고 있는 것은 아닙니다. 커뮤니티에는 Grafana, Zabbix, ELK 및 기타 표준 관리자 세트를 연결하기 위한 여러 가지 아이디어가 있지만 대다수에게 적합한 단일 솔루션은 없습니다. 임무는 영웅을 기다립니다. 1C 클러스터에서 출시하려는 기업이라면 전문가가 필요합니다. 내부 또는 외부에서 자신의 것이 필요하지만 필요합니다. 서버 운영 역량을 갖춘 별도의 역할이 있는 것이 일반적입니다. 모든 1C 사용자가 이를 알아야 하는 것은 아니며 그러한 역할이 필요하다는 점만 이해하면 됩니다. SAP를 예로 들어보겠습니다. 프로그래머는 응용 프로그램 서버에서 무언가를 구성하라는 요청을 받으면 의자에서 일어나지 않을 것입니다. 그는 단지 어리석을 수도 있고 부끄러워하지 않을 것입니다. SAP 방법론에는 이를 위한 별도의 직원 역할이 있습니다. 어떤 이유로 1C 업계에서는 동일한 급여를 위해 한 명의 직원으로 결합되어야한다고 믿어집니다. 그것은 망상입니다.

1C 서버의 단점

신뢰성이라는 마이너스가 정확히 하나 있습니다. 또는 원하는 경우 예측 불가능성입니다. 서버의 갑작스러운 이상한 행동은 이미 온 동네에서 화제가 됐다. 서버를 중지하고 모든 캐시를 지우는 보편적인 해결 방법은 전문가 핸드북에도 설명되어 있으며 이를 수행하는 일괄 책도 권장됩니다. 1C 시스템이 이론적으로 수행해서는 안되는 작업을 시작하면 이제 세션 데이터 캐시를 지워야 할 때입니다. 내 추정에 따르면 이 절차 없이 1C 서버를 운영하는 방법을 알고 있고 비밀을 공유하지 않는 사람은 전국에서 단 XNUMX명뿐입니다. 왜냐하면... 그들은 이것으로 산다. 아마도 그들의 비밀은 세션 데이터를 정리하지만 그것에 대해 아무에게도 말하지 않는다는 것입니다.

그렇지 않으면 1C 서버는 다른 응용 프로그램과 동일한 응용 프로그램이며 문서를 읽고 탬버린을 두드리는 방식으로 거의 동일한 방식으로 관리됩니다.

도커

프로덕션에서 컨테이너화된 1C 서버를 사용하는 것의 유용성은 아직 입증되지 않았습니다. 단순히 밸런서 뒤에 노드를 추가하는 방식으로 서버를 클러스터링하는 것이 아니기 때문에 프로덕션 컨테이너화의 이점이 최소한으로 줄어들고, 하이로드 모드의 컨테이너에서 성공적인 운영 사례가 확립되지 않았습니다. 결과적으로 개발자만이 Docker+1C를 사용하여 테스트 환경을 설정합니다. 매우 유용하고 사용되며 현대 기술을 사용하고 구성자의 낙담에서 벗어날 수 있습니다.

상업용 부품

투자 관점에서 1C를 사용하면 애플리케이션 클래스의 광범위한 기능으로 인해 비즈니스 아이디어를 빠르게 실행하는 문제를 해결할 수 있습니다. 즉시 사용 가능한 1C는 매우 괜찮은 보고, 웹 클라이언트, 모바일 클라이언트, 모바일 애플리케이션과의 통합, 다양한 DBMS 지원 등을 제공합니다. 서버와 설치된 클라이언트 부분 모두 무료이며 크로스 플랫폼입니다. 예, 애플리케이션의 UI는 노란색입니다. 때로는 마이너스이지만 항상 그런 것은 아닙니다.
1C를 선택함으로써 기업은 매우 광범위한 애플리케이션을 구축할 수 있는 소프트웨어 솔루션 세트뿐만 아니라 Javaist보다 적은 비용을 원하는 동시에 더 빠른 결과를 생성하는 시장의 많은 개발자를 얻게 됩니다.

예를 들어, 고객에게 PDF 송장을 보내는 작업은 학생 작업 한 시간 안에 해결할 수 있습니다. .NET의 동일한 문제는 독점 라이브러리를 구입하거나 엄격한 수염을 기른 ​​개발자가 며칠 또는 몇 주 동안 코딩하면 해결할 수 있습니다. 때로는 동시에 둘 다. 그리고 그렇습니다. 저는 PDF 생성에 대해서만 이야기하고 있었습니다. 우리는 이 법안이 어디서 나올지 말하지 않았습니다. 웹 프론트엔더는 운영자가 데이터를 입력할 양식을 생성해야 하며, 백엔더는 JSON 전송을 위한 dto 모델, 데이터베이스에 저장하기 위한 모델, 데이터베이스 자체의 구조, 데이터베이스로의 마이그레이션, 그래픽 구성을 생성해야 합니다. 바로 이 계정을 표시한 다음에만 PDF를 표시합니다. 1C에서는 처음부터 전체 작업이 정확히 XNUMX시간 안에 완료됩니다.

판매보고, 창고별 물품 매매가격 정산, 접근권한 관리, 웹클라이언트, 모바일 어플리케이션을 통해 소규모 매점에 대한 본격적인 회계시스템을 매매 3개의 업무프로세스로 3시간만에 완료합니다. . 좋아, 신청을 잊어버렸는데 신청이 XNUMX시간이 아니라 XNUMX시간 안에 끝났어.

이 작업을 수행하려면 .NET 개발자가 깨끗한 컴퓨터에 Visual Studio를 설치하고 이를 고객에게 시연하기까지 얼마나 걸리나요? 개발 비용은 어떻게 되나요? 같은 것.

플랫폼으로서의 1C의 강점

1C가 강한 이유는 1C에 세계 최고라는 특정한 무언가가 있기 때문이 아닙니다. 반대로 각 개별 하위 시스템에서는 전 세계 소프트웨어에서 더 흥미로운 유사점을 찾을 수 있습니다. 그러나 여러 요인의 조합으로 볼 때 XNUMXC와 유사한 플랫폼은 보이지 않습니다. 여기에 상업적인 성공이 있습니다. 플랫폼의 장점은 플랫폼 전체에 흩어져 있으며 이것이 다른 플랫폼에서 어떻게 수행되는지 볼 때 가장 명확하게 드러납니다. 기본적으로 이것은 기능조차도 아니지만 반대로 하나의 특정 패러다임을 선호하는 기능을 거부합니다. 몇 가지 예:

1. 유니코드. 도대체 이보다 더 간단한 게 어디 있겠습니까? 2019년에는 단일 바이트 ASCII 인코딩을 사용할 필요가 없습니다(고대 레거시 인코딩과의 통합 제외). 절대. 하지만. 어쨌든 일부 테이블의 누군가가 단일 바이트 varchar를 사용하면 응용 프로그램에 인코딩 문제가 발생합니다. 2015년에는 잘못된 인코딩 작업으로 인해 gitlab의 LDAP 인증이 실패했습니다. JetBrains IDE는 여전히 모든 곳에서 파일 이름의 키릴 문자를 사용하지 않습니다. 1C는 데이터베이스 계층에서 애플리케이션 코드를 고품질로 격리합니다. 낮은 수준에서는 테이블을 입력하는 것이 불가능하고 데이터베이스 수준에서는 무능한 후배의 잼이 불가능합니다. 네, 무능력한 후배들에게는 다른 문제도 있을 수 있지만 문제의 다양성은 훨씬 적습니다. 이제 애플리케이션이 올바르게 설계되었으며 데이터베이스 액세스 계층이 격리되어 있음을 알 수 있습니다. 기업 맞춤형 Java 애플리케이션을 다시 살펴보세요. 긴밀하고 솔직하게. 양심이 당신을 괴롭히나요? 그렇다면 나는 당신을 기쁘게 생각합니다.
2. 문서/참고 도서의 번호 매기기. 1C에서는 확실히 가장 유연하지도 않고 최고도 아닙니다. 그러나 은행 소프트웨어와 자체 작성 회계 시스템에서 그들이 하는 일은 음, 그저 어둠일 뿐입니다. ID가 꼼짝 못하게 되거나(그리고 "아, 왜 구멍이 있는 거죠?"), 반대로 DBMS 수준에서 잠금과 함께 작동하는 생성기를 만들 것입니다(그리고 병목 현상이 발생합니다). 실제로, 병렬 데이터 입력 중에 데이터베이스를 차단하지 않도록 특정 키 세트, 접두사를 기반으로 하는 고유성 섹션을 사용하여 엔터티의 엔드투엔드 열거자처럼 겉으로는 단순해 보이는 이 작업을 수행하는 것은 매우 어렵습니다. .
3. 데이터베이스의 레코드 식별자입니다. 1C는 강력한 의지로 결정을 내렸습니다. 모든 링크 식별자는 완전히 합성되었으며 그게 전부입니다. 그리고 분산 데이터베이스와 교환에는 문제가 없습니다. 다른 시스템의 개발자는 ID와 같은 것을 고집스럽게 생성하고(더 짧습니다!) 여러 관련 인스턴스를 생성할 때가 될 때까지 이를 GUI로 끌어다 놓습니다(그런 다음 발견됩니다). 이거 없나요? 솔직히?
4. 기울기. 1C에는 (큰) 목록을 페이징하고 탐색하는 데 매우 성공적인 메커니즘이 있습니다. 메커니즘을 올바르게 사용하여 즉시 예약하겠습니다! 일반적으로 주제는 매우 불쾌하며 이상적으로 해결할 수 없습니다. 직관적이고 단순하거나(그러나 클라이언트에 거대한 레코드 세트가 발생할 위험이 있음) 페이징이 다소 비뚤어져 있습니다. 페이징을 하시는 분들은 삐딱하게 하시는 경우가 많습니다. 정직한 스크롤바를 만드는 사람들은 데이터베이스, 채널 및 클라이언트를 추가합니다.
5. 관리되는 양식. 의심할 바 없이 웹 클라이언트에서는 인터페이스가 완벽하게 작동하지 않습니다. 하지만 작동합니다. 그러나 다른 많은 회계 및 금융 시스템의 경우 원격 작업 공간을 만드는 것은 기업 수준의 프로젝트입니다. 면책 조항: 다행스럽게도 원래 웹에서 만든 사람들에게는 영향을 미치지 않습니다.
6. 모바일 앱. 최근에는 동일한 생태계에서 모바일 애플리케이션을 작성할 수도 있습니다. 여기서는 웹 클라이언트보다 조금 더 복잡합니다. 장치의 특성으로 인해 특별히 작성해야 하지만 그럼에도 불구하고 별도의 모바일 개발자 팀을 고용하지는 않습니다. 회사 내부 요구에 맞는 애플리케이션이 필요한 경우(기업 문제에 대한 모바일 솔루션이 노란색 UI 디자인보다 더 중요한 경우) 기본적으로 동일한 플랫폼을 사용하면 됩니다.
7. 보고. 이 단어는 빅 데이터가 있고 ETL 프로세스가 지연되는 BI 시스템을 의미하지 않습니다. 이는 지금 여기에서 회계 상태를 평가할 수 있는 운영 직원 보고서를 나타냅니다. 잔액, 상호정산, 재등급화 등 1C는 사용자 측의 그룹화, 필터 및 시각화를 위한 유연한 설정을 갖춘 보고 시스템과 함께 기본적으로 제공됩니다. 예, 시장에는 더 멋진 유사품이 있습니다. 그러나 올인원 솔루션의 틀 안에 있지 않으며 때로는 올인원 솔루션보다 가격이 더 높습니다. 그리고 그 반대인 경우가 더 많습니다. 보고만 하지만 전체 플랫폼보다 비용이 많이 들고 품질이 더 나쁩니다.
8. 인쇄 가능한 양식. 글쎄, .NET을 사용하면 급여 명세서를 PDF로 직원에게 이메일로 보내는 문제를 해결할 수 있습니다. 이제 송장을 인쇄하는 작업입니다. 복사본을 동일한 PDF에 저장하는 것은 어떻습니까? 1C 닉네임의 경우 모든 레이아웃을 PDF로 출력하는 데는 +1줄의 코드가 필요합니다. 이는 다른 언어에서는 며칠 또는 몇 주가 아닌 + 40초의 작업 시간을 의미합니다. 1C의 인쇄된 양식 레이아웃은 개발하기가 매우 쉽고 유료 레이아웃과 경쟁할 수 있을 만큼 강력합니다. 예, 아마도 1C 스프레드시트 문서에는 대화형 기회가 많지 않기 때문에 OpenGL을 사용하여 크기 조정이 가능한 3D 다이어그램을 빠르게 얻을 수 없습니다. 하지만 정말 필요한가요?

이는 기능을 제한하거나 절충안을 구현하는 것이 향후 중요한 아키텍처 이점이 될 수 있는 몇 가지 예일 뿐입니다. 타협이든 가장 효과적인 옵션이 아니든 간에 이는 이미 기본 설정에 포함되어 있으며 당연한 것으로 간주됩니다. 독립적인 구현은 불가능하거나(그러한 결정은 프로젝트 초기에 이루어져야 하고 그럴 시간도 없고 설계자가 전혀 없기 때문에) 비용이 많이 드는 여러 번의 반복이 필요합니다. 나열된 각 항목(아키텍처 솔루션의 전체 목록은 아님)에서 확장을 차단하는 제한 사항을 적용하고 도입할 수 있습니다. 어쨌든, 사업가로서 당신은 프로그래머가 "처음부터 시스템"을 만들 때 손이 곧고 미묘한 시스템 문제를 즉시 잘 처리할 수 있는지 확인해야 합니다.

예, 다른 복잡한 시스템과 마찬가지로 1C 자체에도 특정 측면에서 확장을 차단하는 솔루션이 있습니다. 그러나 여러 요인, 소유 비용, 이미 해결된 문제의 수를 고려하면 시장에서 가치 있는 경쟁자가 보이지 않는다는 점을 다시 한번 말씀드립니다. 동일한 가격으로 금융 애플리케이션 프레임워크, UI 및 웹 인터페이스, 모바일 애플리케이션, 보고, 통합 및 기타 다양한 기능을 갖춘 균형 잡힌 클러스터형 서버를 얻을 수 있습니다. Java 세계에서는 프런트엔드 및 백엔드 팀을 고용하고, 집에서 작성한 서버 코드의 하위 수준 떼를 디버그하고, 2개의 모바일 OS에 대해 2개의 모바일 애플리케이션에 대해 별도로 비용을 지불합니다.

1C가 모든 경우를 해결할 것이라고 말하는 것은 아니지만 내부 기업 애플리케이션의 경우 UI를 브랜딩할 필요가 없는 경우 무엇이 더 필요합니까?

옥에 티

아마도 1C가 세상을 구할 것이며 기업 시스템을 작성하는 다른 모든 방법이 잘못되었다는 인상을 받았을 것입니다. 전혀 그렇지 않습니다. 사업가의 관점에서 1C를 선택하면 빠른 출시 시간 외에도 다음과 같은 단점을 고려해야 합니다.

• 서버 안정성. 중단 없는 운영을 보장할 수 있는 고품질 전문가가 필요합니다. 나는 공급업체에서 그러한 전문가를 위해 미리 준비된 교육 프로그램을 알지 못합니다. 전문가 시험을 준비하는 과정이 있지만 이것만으로는 충분하지 않다고 생각합니다.
• 지원하다. 이전 항목을 참조하세요. 공급업체의 지원을 받으려면 해당 공급업체를 구입해야 합니다. 어떤 이유로 이것은 1C 업계에서는 허용되지 않습니다. 그리고 SAP를 사용하면 거의 필수 구매가 되어 누구에게도 방해가 되지 않습니다. 기업의 지원이 없고 직원의 전문가가 없으면 1C 결함으로 홀로 남겨질 수 있습니다.
• 하지만 1C로 모든 것을 완벽하게 할 수는 없습니다. 이것은 도구이며 모든 도구와 마찬가지로 적용 가능성에 한계가 있습니다. 1C 환경에서는 "1C가 아닌" 시스템 설계자를 갖는 것이 매우 바람직합니다.
• 좋은 1C 별명은 다른 언어의 좋은 프로그래머보다 저렴하지 않습니다. 하지만 나쁜 프로그래머는 작성하는 언어에 관계없이 고용하는 데 비용이 많이 듭니다.

점을 찍자

• 1C는 비즈니스를 위한 RAD(신속한 애플리케이션 개발) 프레임워크이며 이에 맞게 맞춤화되었습니다.
• 주요 DBMS, 클라이언트 UI, 매우 우수한 ORM 및 보고 기능을 지원하는 XNUMX계층 링크
• 1C가 할 수 없는 작업을 수행할 수 있는 시스템과의 통합 가능성이 넓습니다. 기계 학습을 원한다면 Python을 사용하여 http 또는 RabbitMQ를 통해 결과를 1C로 보내십시오.
• 1C를 사용하여 모든 것을 하려고 노력할 필요는 없으며, XNUMXC의 장점을 이해하고 자신의 목적에 맞게 사용해야 합니다.
• 기술 프레임워크 장치를 파헤치고 N년마다 새로운 엔진으로 재설계하는 데 끌리는 개발자는 1C에 지루합니다. 그곳은 모든 것이 매우 보수적입니다.
• 개발자 역시 제조업체의 관심이 거의 없기 때문에 지루해합니다. 지루한 언어, 약한 IDE. 현대화가 필요합니다.
• 반면에 자신이 즐기는 다른 기술을 사용하고 학습하면서 재미를 찾지 못하는 개발자는 나쁜 개발자입니다. 그들은 징징거리며 다른 생태계로 이동할 것입니다.
• 1C 닉네임으로 Python으로 무언가를 작성하는 것을 허용하지 않는 고용주는 나쁜 고용주입니다. 그들은 호기심이 많은 직원을 잃을 것이고 그 자리에는 모든 것에 동의하면서도 기업 소프트웨어를 늪으로 끌어들이는 원숭이 코더가 올 것입니다. 아직 다시 작성해야 하므로 조금 더 일찍 Python에 조금 투자하는 것이 낫지 않을까요?
• 1C는 상업 회사이며 자체 이익과 편의에 따라 기능을 구현합니다. 그녀를 비난할 수는 없어, 사업은 이익을 생각해야 해, 그게 인생이야
• 1C는 Vasya의 개발자 문제가 아닌 비즈니스 문제에 대한 솔루션을 판매하여 수익을 창출합니다. 이 두 개념은 서로 연관되어 있지만 우선순위는 제가 말한 것과 정확히 같습니다. 개발자 Vasya가 1C: Resharper에 대한 개인 라이센스 비용을 지불할 준비가 되면 매우 빠르게 나타날 것입니다. A. Orefkova의 "Resharper"가 이에 대한 증거입니다. 벤더가 이를 지지하고 반대하지 않는다면 개발자를 위한 소프트웨어 시장이 나타날 것입니다. 이제 이 시장에는 의심스러운 결과를 보이는 XNUMX명의 플레이어가 있습니다. 이는 모두 IDE와의 통합이 부정적이고 모든 것이 목발로 이루어지기 때문입니다.
• 다중 기계 운영자의 관행은 망각으로 사라질 것입니다. 최신 애플리케이션은 코드 측면과 비즈니스 사용 측면 모두에서 기억하기에는 너무 큽니다. 1C 서버도 더욱 복잡해지고 있어 한 직원이 모든 유형의 전문 지식을 보유하는 것은 불가능합니다. 이는 전문가에 대한 수요를 수반해야 하며 이는 1C 직업의 매력과 급여 인상을 의미합니다. 이전에 Vasya가 한 급여에 XNUMX인 XNUMX조로 일했다면 이제는 두 명의 Vasya를 고용해야 하며 Vasya 간의 경쟁은 전반적인 레벨 성장을 촉진할 수 있습니다.

결론

1C는 매우 가치있는 제품입니다. 내 가격대에는 유사점이 전혀 없습니다. 있으면 의견을 적어주세요. 그러나 생태계에서 개발자의 유출이 점점 눈에 띄고 있으며, 이는 어떻게 보아도 '두뇌 유출'이다. 업계는 현대화에 목말라 있습니다.
개발자라면 1C에 매달리지 말고 다른 언어에서는 모든 것이 마술적이라고 생각하지 마십시오. 당신이 주니어라면 아마도. 더 큰 문제를 해결해야 하는 즉시 기성 솔루션을 더 오랫동안 찾고 더 집중적으로 완료해야 합니다. 솔루션을 구축할 수 있는 "블록"의 품질 측면에서 1C는 매우 좋습니다.

그리고 한 가지 더-1C 닉네임이 고용을 위해 오면 1C 닉네임이 수석 분석가의 위치에 안전하게 임명될 수 있습니다. 업무에 대한 이해도, 주제영역, 분해능력이 뛰어납니다. 나는 이것이 바로 1C 개발에서 DDD를 강제로 사용했기 때문이라고 확신합니다. 그 사람은 우선 작업의 의미, 주제 영역의 개체 간의 연결에 대해 생각하도록 훈련받는 동시에 통합 기술 및 데이터 교환 형식에 대한 기술적 배경을 가지고 있습니다.

이상적인 프레임워크가 존재하지 않는다는 점을 인식하고 스스로 관리하세요.
모든 좋은!

PS: 정말 감사합니다 스페슈릭의 기사 준비에 도움을 요청합니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

귀하의 기업에 1C가 있습니까?

• 13,3%전혀 그렇지 않습니다.71

• 30,3%있지만 회계 부서 어딘가에만 있습니다. 다른 플랫폼의 핵심 시스템162

• 41,4%예, 주요 비즈니스 프로세스는 it221에서 작동합니다.

• 15,0%1C는 죽어야 합니다. 미래는 %technology_name%80의 것입니다

534명의 사용자가 투표했습니다. 99명의 사용자가 기권했습니다.

출처 : habr.com