1C - 선과 악. 1세기경 성전에 포인트 배치

친구, 동료 여러분, 최근 하브르에서는 1C를 개발 플랫폼으로 보는 것에 대한 증오 기사와 이를 옹호하는 사람들의 연설이 점점 더 많아지고 있습니다. 이러한 기사에서는 심각한 문제 하나를 지적했습니다. 1C를 ​​비판하는 사람들은 대개 "완벽하게 이해하지 못했다"는 입장에서 사실상 쉽게 해결되는 문제를 꾸짖고, 반대로 정말 중요하고 논의할 가치가 있으며 공급업체에서 해결하지 못하는 문제는 다루지 않습니다. 저는 1C 플랫폼에 대해 냉정하고 균형 잡힌 검토를 실시하는 것이 합리적이라고 믿습니다. 이 기술이 할 수 있는 것, 할 수 없는 것, 해야 하지만 하지 않는 것, 그리고 마지막으로 이 기술이 훌륭한 성과를 거두면 %technology_name%의 개발자들은 XNUMX년 동안 그 기술을 사용하면서 연간 예산을 낭비하게 될 것입니다.

그 결과, 관리자나 건축가인 당신은 어떤 작업에 1C를 사용하는 것이 유익한지, 그리고 뜨거운 다리미로 어디를 태워야 하는지 명확하게 이해할 수 있을 것입니다. "1C가 아닌" 세계의 개발자라면 1C가 왜 이렇게 큰 소란을 피우는지 알 수 있을 것입니다. 1C 개발자로서 여러분은 자신의 시스템을 다른 언어의 생태계와 비교하고 소프트웨어 개발 좌표계에서 자신의 위치를 ​​이해할 수 있을 것입니다.

아래에는 1C, 1C 비평가, Java, .NET 및 기타 전반에 대한 많은 공격이 있습니다. 팬이 가득 찼습니다. 환영합니다!

성명서

저는 2004년경부터 이 주제에 대해 이야기하기 시작했습니다. 아마 6살 때부터 프로그래밍을 시작했는데, 고양이, 참새, 애벌레에 대한 만화가 실린 포트란 교수에 대한 책을 받은 순간부터였습니다. 나는 책 속의 그림을 보고 고양이가 작성한 프로그램을 분해하여 그 프로그램이 무엇을 하는지 알아냈다. 그렇죠. 그 당시에는 실제 컴퓨터가 없었지만, 책 페이지에 컴퓨터 그림이 있었고, 저는 솔직히 종이 버튼을 눌러서 고양이 X에게 배운 명령어를 입력했습니다.

그런 다음 학교에서는 BK0011과 Basic을 배웠고, 대학에서는 C++과 어셈블러를 배웠고, 그다음에는 1C를 배웠고, 그 이후로는 기억하기 너무 귀찮은 것들이 너무 많습니다. 지난 15년 동안 저는 주로 1C에 관여해 왔습니다. 코딩 측면뿐만 아니라 1C 전반에 걸쳐 관여했습니다. 여기에는 작업 설정, 관리 및 DevOps도 포함됩니다. 지난 5년 동안 저는 다른 1C 사용자를 위한 개발 및 자동화 도구를 개발하고, 논문과 책을 쓰는 등 사회적으로 유용한 활동에 참여해 왔습니다.

토론 주제를 정하자

먼저, "1C"라는 글자가 여러 가지 의미를 가질 수 있으므로, 우리가 무슨 말을 하는지 정의해 보겠습니다. 이 경우, "1C"라는 문자는 최신 1번째 버전의 개발 프레임워크인 "XNUMXC: 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를 포함하는 highload http 호출

1C는 제조 회사로서

1C가 소프트웨어 제조업체로서 어떤 사업을 하는지 이해하는 것은 가치가 있습니다. 1C 회사는 자동화를 통해 비즈니스 문제에 대한 솔루션을 판매합니다. 크고 작은 다양한 사업이 있지만, 그녀가 판매하는 것은 바로 이것입니다. 이 목표를 달성하는 수단은 비즈니스 애플리케이션입니다. 회계, 급여 회계 등을 위해 회사에서는 자체 비즈니스 애플리케이션 개발 플랫폼을 사용하여 이러한 애플리케이션을 작성합니다. 다음과 같은 비즈니스 애플리케이션의 일반적인 작업에 맞게 특별히 제작되었습니다.

• 재무 회계
• 비즈니스 로직의 쉬운 사용자 정의
• 이기종 IT 환경에서의 광범위한 통합 가능성

제조업체로서 1C는 이 전략을 통해 파트너와 고객 모두가 이익을 얻는 방식으로 협력할 수 있다고 믿습니다. 이에 대해 이의를 제기할 수도 있겠지만, 회사가 스스로를 홍보하는 방식은 대략 이렇습니다. 파트너가 신속하게 사용자 정의하고 모든 IT 환경에 통합할 수 있는 비즈니스 문제에 대한 기성 솔루션입니다.

1C라는 틀에 대한 모든 주장이나 희망은 오로지 이러한 관점을 통해서만 고려되어야 합니다. 개발자들은 "우리는 1C에서 OOP를 원합니다"라고 말합니다. "플랫폼에서 OOP를 지원하는 데 비용이 얼마나 들까요? 박스 판매를 늘리는 데 도움이 될까요?" 1C라고 합니다. 비즈니스 문제에 대한 솔루션을 판매하는 "프리즘"을 공개합니다.

- 안녕하세요, 사업체 여러분, 1C에 OOP를 적용하시겠습니까?
- 이것이 내 문제를 해결하는 데 도움이 될까요?
- 누가 알겠나...
- 그럼 필요가 없습니다.

이런 접근 방식은 보는 사람에 따라 좋을 수도 나쁠 수도 있지만, 사실은 그렇습니다. 1C에 X라는 기능이 없다는 사실을 말할 때, 그것이 아무 이유 없이 있는 것이 아니라는 점을 이해해야 합니다. 하지만 이는 "구현 비용 대 수익 규모"라는 선택의 맥락에서 이루어져야 합니다.

기술 분류

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

1C 개발자가 서양 개발자와 다른 점은 홍보입니다. 그들은 어떤 쓰레기에도 큰 이름을 붙여서 마치 자기 눈동자처럼 소중히 여기는 걸 좋아해요."
A. 오레프코프

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

클라이언트 부분은 사용자의 컴퓨터에 설치된 씬 클라이언트이거나 웹 클라이언트입니다. 가장 중요한 특징은 프로그래머가 두 개의 다른 코드를 작성하지 않고, 하나의 언어로 하나의 애플리케이션을 작성하고, 필요나 요구가 있을 경우 브라우저에 표시할 수 있다는 것입니다. 프런트엔드와 백엔드를 위한 진정한 풀스택과 단일 언어인 Node.js를 원하는 사람은 누구일까요? 그들은 결코 정확히 같은 방식으로 그것을 해내지 못했습니다. 실제 풀스택은 존재하지만, 2C에 작성해야 합니다. 운명의 아이러니, 모든 게 다 그렇죠 :)

1C:Fresh 클라우드 SaaS 솔루션은 브라우저 모드에서도 작동합니다. 즉, 1C를 구매할 필요가 없고, 작은 데이터베이스를 임대하여 해당 데이터베이스에서 샤와르마 판매 내역을 추적할 수 있습니다. 아무것도 설치하거나 구성할 필요 없이 브라우저에서만 가능합니다.

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

1C의 서버 부분은 클러스터링을 지원하며 클러스터에 새로운 머신을 추가하여 확장할 수 있습니다. 여기서는 꽤 많은 창이 부러졌고, 이에 대해서는 이 기사에서 별도 섹션으로 다루겠습니다. 간단히 말해서, HAProxy 뒤에 정확히 동일한 인스턴스를 몇 개 추가하는 것과는 다릅니다.

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

바로 이 프로그래밍 언어가 1C 개발자들이 자신의 플랫폼을 싫어하는 주된 이유입니다. 솔직히 말해서, 이유가 없는 것은 아닙니다. 이 언어는 가능한 한 단순하게 구상되었으며, 최소한 CIS 규모에서 "개발자, 개발자"라는 구호를 실현하도록 설계되었습니다. 제 생각에 이러한 결정의 상업적 본질은 분명히 드러납니다. 개발자가 많을수록 시장 적용 범위가 넓어집니다. 다양한 추산에 따르면 이는 45%에서 95%까지 실현되었습니다. 제가 바로 말씀드리고 싶은 건, 생각하는 언어로 글을 쓰는 게 실제로 더 쉽다는 겁니다. 그리고 저는 꽤 많은 프로그래밍 언어를 알고 있어요.

우선 언어부터 시작해 볼까요.

1C 프로그래밍 언어

동시에, 시스템의 강점이자 약점이기도 합니다. 쉽게 입력하고 읽을 수 있습니다. 반면, 8년에 버전 2002이 출시된 이후로 업데이트가 되지 않아 도덕적으로 시대에 뒤떨어진 셈입니다. 누군가는 "가장 큰 단점은 객체 지향 프로그래밍(OOP)이 부족하다는 것"이라고 말할 수 있는데, 그 말은 틀렸습니다. 첫째, PLO는 누랄리예프뿐만 아니라 토르발스도 좋아하지 않습니다. 두 번째로, OOP는 존재합니다.

개발자 관점에서 볼 때, 그는 DBMS에 매핑된 기본 클래스를 갖춘 프레임워크를 사용할 수 있습니다. 개발자는 기본 클래스 "디렉토리"를 가져와서 여기에서 "클라이언트" 디렉토리를 상속할 수 있습니다. 예를 들어 납세자 식별 번호 및 주소와 같은 새로운 클래스 필드를 추가할 수 있으며, 필요한 경우 OnWrite 메서드와 같이 기본 클래스의 메서드를 재정의할 수 있습니다.

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

1C 언어는 주류 언어 수준으로 복잡하게 만들지 않고는 개발하기 어렵고, 단순함이라는 장점을 잃는다는 것이 밝혀졌습니다. 공급업체의 과제는 본질적으로 무엇을 해결하려는 것인가: 거리에서 발견된 모든 학생이 필요한 수준의 품질을 갖춘 표준 솔루션을 제공하는 것이다(즉, 키오스크에서 대형 공장까지 적용 범위가 충족되는 경우). 만약 당신이 노점상이라면, 학생을 데려가세요; 여러분이 공장이라면, 구현 파트너로부터 전문가의 조언을 받으세요. 구현 파트너가 학생을 전문가 가격으로 판매한다는 사실은 프레임워크 문제가 아닙니다. 구조적으로 프레임워크는 두 가지 문제를 모두 해결해야 합니다. 일반적인 구성의 코드(맞춤형을 약속하며 기업에 판매한 코드)는 학생도 이해할 수 있어야 하고, 전문가라면 여러분이 원하는 것이 무엇이든 이해할 수 있어야 합니다.

제 생각에 언어에서 정말 부족한 것은 무엇인가? 사람이 할 수 있는 것보다 더 많이 쓰게 만드는 것은 무엇인가? 고객이 지불한 시간을 낭비하게 만드는 것은 무엇인가?

• 예를 들어 TypeScript 수준의 타이핑이 가능해짐(결과적으로 IDE에서 보다 진보된 코드 분석 도구, 리팩토링, 성가신 버그 감소)
  일급 객체로서의 함수의 존재. 조금 더 복잡한 개념이지만, 전형적인 상용구 코드의 양을 크게 줄일 수 있습니다. 제 생각에는 볼륨 감소로 인해 학생들의 코드 이해도가 더욱 높아질 것입니다.
• 유니버설 컬렉션 리터럴, 초기화 프로그램. 동일한 내용입니다. 작성 및/또는 검토해야 하는 코드의 양을 줄이는 것입니다. 9000C에서는 컬렉션을 채우는 데 프로그래밍 시간의 1% 이상이 소요됩니다. 구문적 간결성 없이 이런 내용을 쓰면 길고, 비용이 많이 들고, 오류가 발생하기 쉽습니다. 일반적으로 1C 솔루션의 LOC 수는 사용 가능한 오픈 프레임워크와 비교했을 때, 그리고 일반적으로 모든 엔터프라이즈 Java를 합친 것과 비교했을 때 상상할 수 있는 모든 한계를 초과합니다. 언어가 장황하고, 이는 데이터 양, 메모리, IDE 속도 저하, 시간, 비용 등의 문제로 이어집니다.
• 마지막으로 구문에 대한 가설이 있습니다. 이 구문은 러시아어로 제대로 번역되지 않았기 때문에 누락되었을 것이라는 것입니다 :)
• VB6의 Type과 유사한 기본 데이터 유형(OOP 없음). 이를 통해 BSP의 주석과 이러한 구조를 구성하는 매직 메서드를 사용하여 구조를 유형화하는 것을 피할 수 있습니다. 우리가 얻는 것은 코드 감소, 점을 통한 힌트, 문제에 대한 더 빠른 해결책, 오타 및 구조 속성 누락으로 인한 오류 감소입니다. 현재, 사용자 구조의 타이핑은 전적으로 표준 하위 시스템 라이브러리 개발 팀에서 담당하고 있으며, 이 팀은 전달된 매개변수 구조의 예상 속성에 대한 주석을 주의 깊게 작성한다는 점에서 칭찬할 만합니다.
• 웹 클라이언트에서 비동기 호출을 사용할 때는 설탕을 사용하지 마세요. NotificationProcessing 형태의 콜백 헬은 주요 브라우저의 API가 갑자기 변경되어 발생한 임시방편이지만, 항상 이런 식으로만 살 수는 없으며, 비동기 코드에 대한 "학생의 이해"라는 이점이 점점 사라지고 있습니다. 여기에 메인 IDE에서 이 패러다임을 지원하지 않는다는 점을 더하면 상황은 더욱 악화됩니다.

이것들은 시급한 문제 중 일부이며, 목록은 훨씬 더 길어질 수 있음은 분명하지만, 이것이 범용 언어가 아니라는 점, 멀티스레딩, 람다 함수, GPU 액세스 및 빠른 부동 소수점 계산이 필요하지 않다는 점을 잊지 말아야 합니다. 이는 비즈니스 로직 스크립팅 언어입니다.

이미 이 언어로 많은 작업을 한 프로그래머가 js나 c#을 살펴보고 이 언어의 프레임워크 안에서 지루함을 느끼는 경우도 있습니다. 이는 사실입니다. 그는 발전이 필요합니다. 반면에 공급업체는 특정 기능을 구현하는 데 드는 비용과 구현 후 발생하는 수익 증가를 비교합니다. 현재 회사가 어떤 입장을 취하고 있는지에 대한 정보는 없습니다.

개발 환경

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

구성기는 광범위한 개발 작업을 제공하고 모든 기능을 지원하며 시장의 주요 환경입니다. 소문에 따르면, 기술 부채의 규모로 인해 도덕적으로 시대에 뒤떨어졌고 발전하지 못하고 있다고 합니다. 내부 API를 개방하면(친구 관계의 형태로) 상황이 개선될 수 있습니다. 강설량 (A. 오레프코바 또는 독립적으로) 그러나 이는 사실이 아닙니다. 경험에 따르면 공급업체가 간섭하지 않는 한 커뮤니티가 IDE에서 자체 기능을 만들 수 있습니다. 하지만 우리는 우리가 가진 것을 가지고 있습니다. 구성기는 2004~2005년에 훌륭했습니다. 당시의 Visual Studio를 많이 연상시킵니다. 어떤 부분은 더 멋졌지만, 그 시대에 갇혔습니다.

게다가 그 이후로 일반적인 솔루션의 크기도 몇 배나 커졌고, 오늘날 IDE는 공급되는 코드 양을 감당할 수 없게 되었습니다. 사용성과 리팩토링 기능은 0이 아니라 마이너스 수준입니다. 이 모든 것은 개발자들에게 열정을 불어넣지 못하며, 그들은 다른 생태계로 옮겨가서 거기서도 엉터리 코드를 계속 작성하고 싶어하지만, 그 행동으로 얼굴에 침을 뱉지 않는 즐거운 환경에서만 코드를 작성하고 싶어합니다.

대안으로, Eclipse 기반으로 처음부터 작성된 IDE가 제공됩니다. 다른 소프트웨어와 마찬가지로 소스 코드는 텍스트 파일 형태로 GIT, 브랜치, 풀 리퀘스트 등에 저장됩니다. 단점은 베타 상태를 몇 년 동안 벗어나지 않았다는 점인데, 릴리스할 때마다 개선되고 있습니다. 저는 EDT의 단점에 대해서는 쓰지 않을 겁니다. 오늘의 단점이 내일이면 고정된 특징이 될 테니까요. 그런 설명의 관련성은 금세 사라질 것이다. 오늘날 EDT로 개발하는 것은 가능하지만, 드문 일이며, 일정 수의 IDE 버그에 대비해야 합니다.

앞서 언급한 "1C 프리즘"을 통해 상황을 살펴보면 다음과 같은 결과가 나옵니다. 새로운 IDE가 출시되어도 박스 판매량은 늘어나지 않지만, 개발자 유출은 줄어들 수 있습니다. 개발자 편의성 측면에서 이 생태계가 어떻게 될지는 말하기 어렵지만, Microsoft는 이미 모바일 개발자에게 서비스를 너무 늦게 제공함으로써 그들을 속인 적이 있습니다.

개발 관리

특히 최근 커뮤니티의 노력으로 관리 자동화의 문제점이 드러나고 1C 스토리지를 버리고 git, 빠른 비난, 코드 검토, 정적 분석, 자동 배포 등을 사용하는 프로토타입이 출시되면서 코드를 작성하는 것보다 모든 것이 훨씬 나아졌습니다. 개발 작업의 자동화 수준을 높이기 위해 플랫폼에 많은 기능이 추가되었습니다. 그러나 자동화 없이는 불가능하다는 것이 분명해지자, 이러한 모든 기능은 자체 대형 제품을 개발하기 위해서만 독점적으로 추가되었습니다. 자동 병합, KDiff를 통한 XNUMX방향 비교 등이 등장했습니다. GitHub에서 출시됨 git컨버터솔직히 말해서 이념적으로 프로젝트에서 제외된 사람 gitsync그러나 공급업체의 프로세스에 맞게 수정되었습니다. 오픈소스의 열광적인 사람들 덕분에 1C의 개발 자동화가 중심에서 벗어나게 되었습니다. 제 생각에는 구성기를 위한 개방형 API가 있으면 기본 IDE의 도덕적 낙후성도 바뀔 것입니다.

오늘날 Jira의 작업에 연결된 커밋을 사용하여 git에 1C 소스 코드를 저장하고, Crucible에서 검토하고, Jenkins의 버튼을 사용하여 롤아웃하고, Allure에서 1C의 코드 테스트에 대한 보고서를 작성합니다. SonarQube의 정적 분석 — 이는 더 이상 뉴스가 아니지만 1C를 많이 개발하는 회사에서는 주류가 되었습니다.

관리

여기에는 말할 것이 많습니다. 첫째, 물론 서버(1C 서버 클러스터)입니다. 정말 놀라운 일이지만, 완전히 블랙박스라는 사실 때문에, 충분한 세부 사항으로 문서화되어 있지만, 특정한 방식으로 문서화되어 있습니다. 즉, 여러 서버에서 고부하 모드에서 중단 없는 운영을 시작하는 방법을 마스터하는 것은 "기술 문제 전문가"라는 문구가 새겨진 메달을 달고 있는 선택받은 자들의 몫입니다. 원칙적으로 1C 서버를 관리하는 것은 다른 서버를 관리하는 것과 다르지 않습니다. 이는 메모리, CPU, 디스크 리소스를 소모하는 네트워크 기반의 멀티스레드 애플리케이션입니다. 원격 측정 데이터 수집 및 진단을 위한 광범위한 기능을 제공합니다.

여기서 문제는 공급업체가 이러한 진단을 위한 기성 솔루션 측면에서 특별한 것을 아무것도 제공하지 않는다는 것입니다. 네, 1C가 있습니다: KIP와 TsUP는 나쁘지는 않지만 급여가 매우 높고 누구나 가지고 있는 것은 아닙니다. 커뮤니티에서는 Grafana, Zabbix, ELK 및 표준 관리 세트의 다른 항목을 연결하는 데 있어 다양한 개발이 진행되고 있지만, 대다수를 만족시킬 수 있는 단일 솔루션은 없습니다. 그 임무는 영웅을 기다리고 있다. 1C 클러스터에서 사업을 시작하려는 경우 전문가가 필요합니다. 내부에서든 외부에서든 필요합니다. 서버 운영에 대한 역량을 갖춘 별도의 역할이 있는 것은 일반적입니다. 모든 1C 전문가가 이를 알 필요는 없지만, 그러한 역할이 필요하다는 점만 이해하면 됩니다. 예를 들어 SAP를 살펴보겠습니다. 프로그래머는 애플리케이션 서버에서 무언가를 구성해 달라는 요청을 받더라도 의자에서 일어나지 않을 가능성이 큽니다. 그는 단순히 방법을 모를 수도 있고 부끄러워하지 않을 수도 있습니다. SAP 방법론에서는 이에 대한 별도의 직원 역할이 있습니다. 어떤 이유에서인지, 1C 산업에서는 이것이 동일한 급여를 주는 한 직원에게 결합되어야 한다고 믿어집니다. 이는 오해입니다.

1C 서버의 단점

단 하나의 단점이 있는데, 바로 신뢰성입니다. 혹은 예측 불가능성을 선호한다면요. 서버의 갑작스러운 이상한 동작이 이미 화제가 되고 있습니다. 전문가 핸드북에는 서버를 멈추고 모든 캐시를 지우는 보편적인 해결책이 설명되어 있으며, 이를 위한 배치 파일도 권장됩니다. 1C가 이론적으로는 해서는 안 될 일을 하기 시작했다면 세션 데이터 캐시를 지워야 할 때입니다. 제 생각에, 이 절차 없이 1C 서버를 운영하는 방법을 아는 사람은 전국에 겨우 세 명뿐이고, 그들은 자신의 비밀을 공유하지 않습니다. 왜냐하면... 그것이 그들이 먹고 사는 것이기 때문입니다. 아마도 그들의 비밀은 세션 데이터를 지우고 아무에게도 말하지 않는다는 것일 수도 있겠네요. ㅎㅎ

그 외에는 1C 서버는 다른 서버와 동일한 애플리케이션이며, 문서를 읽고 드럼을 두드리는 것과 같은 방식으로 거의 동일하게 관리됩니다.

도커

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

상업적 구성 요소

투자 관점에서 볼 때, 1C는 애플리케이션 클래스의 폭넓은 기능 덕분에 사업 아이디어를 신속하게 출시하는 작업을 마무리할 수 있습니다. 1C는 기본적으로 매우 괜찮은 보고 기능, 모든 것과의 통합, 웹 클라이언트, 모바일 클라이언트, 모바일 애플리케이션, 다양한 DBMS에 대한 지원을 제공합니다. 서버와 설치된 클라이언트 부분 모두 무료이며 크로스 플랫폼입니다. 네, 애플리케이션의 UI는 노란색입니다. 때로는 이것이 단점이 되기도 하지만 항상 그런 것은 아닙니다.
1C를 선택하면 기업은 매우 광범위한 애플리케이션을 구축할 수 있는 소프트웨어 솔루션 세트를 얻을 수 있으며, Java 개발자보다 적은 비용으로도 더 빠르게 결과를 제공할 수 있는 많은 개발자를 시장에 확보할 수 있습니다.

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

3개의 구매/판매 비즈니스 프로세스가 있는 소규모 키오스크에 대한 본격적인 회계 시스템을 3시간 만에 구축합니다. 판매 보고, 창고별로 구분된 구매 및 판매 가격에 따른 상품 회계, 접근 권한 제어, 웹 클라이언트 및 모바일 애플리케이션이 제공됩니다. 알겠습니다. 앱을 너무 과하게 사용했네요. 앱을 사용하면 XNUMX시간이 아니라 XNUMX시간이 걸립니다.

.NET 개발자가 깨끗한 컴퓨터에 Visual Studio를 설치한 순간부터 고객에게 시연할 때까지 이 작업을 수행하는 데 얼마나 걸릴까요? 개발 비용은 어떻게 되나요? 정확히.

플랫폼으로서 1C의 강점

1C가 강한 것은 세계 최고라는 구체적인 무언가를 가지고 있기 때문이 아닙니다. 그와 반대로, 각각의 하위 시스템에서는 세계 소프트웨어에서 더욱 흥미로운 유추를 찾을 수 있습니다. 하지만 여러 요소를 종합해 볼 때, 1C와 비슷한 플랫폼은 없다고 봅니다. 상업적인 성공은 바로 여기에 있습니다. 이 플랫폼의 장점은 곳곳에 산재해 있으며, 다른 플랫폼에서 어떻게 이루어지는지 살펴보면 가장 확실하게 드러납니다. 기본적으로 이것들은 특징이라고 할 수도 없고, 오히려 특정 패러다임 하나를 선호하여 특징을 거부하는 것입니다. 몇 가지 예:

1. 유니코드. 이보다 더 간단할 수가 있을까? 2019년에는 단일 바이트 ASCII 인코딩을 사용할 필요가 없습니다(기존 인코딩과의 통합은 제외). 안 돼요. 하지만 그렇지 않아요. 어쨌든, 어떤 테이블의 누군가가 단일 바이트 varchar를 사용하고 있고 애플리케이션은 인코딩과 관련하여 문제를 겪을 것입니다. 2015년에는 인코딩을 잘못 처리하여 gitlab의 LDAP 인증이 실패했고, JetBrains IDE는 여전히 파일 이름에 키릴 문자가 포함된 경우 제대로 작동하지 않는 경우가 있습니다. 1C는 데이터베이스 작업 계층으로부터 애플리케이션 코드를 고품질로 격리합니다. 그곳에서는 낮은 수준에서 표를 입력할 수 없고, DB 수준에서 무능한 주니어가 실수하는 것도 불가능합니다. 물론, 무능한 후배들이 저지르는 실수는 더 많을지 몰라도, 문제의 종류는 훨씬 적습니다. 이제 귀하의 애플리케이션이 올바르게 설계되었고 데이터베이스 액세스 계층이 제대로 격리되어 있다고 말씀해 주시겠습니까? 회사의 맞춤형 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 및 웹 인터페이스, 모바일 애플리케이션, 보고, 통합 및 기타 여러 기능을 갖춘 금융 애플리케이션 프레임워크, 클러스터링된 균형 잡힌 서버를 얻을 수 있습니다. 자바 세계에서는 프런트엔드 팀, 백엔드 팀을 고용하고, 사용자 정의 서버 코드에서 저수준 버그를 디버깅하고, 2개의 모바일 OS에 대한 2개의 모바일 애플리케이션에 대해 별도로 비용을 지불합니다.

1C가 모든 문제를 해결할 수 있다고 말하는 것은 아니지만, 기업 내부 애플리케이션의 경우 UI 브랜딩이 필요하지 않다면 무엇이 더 필요할까요?

옥에 티

아마도 1C가 세상을 구할 것이고 기업 시스템을 작성하는 다른 모든 방법은 틀렸다는 생각이 들었을 것입니다. 이는 전혀 사실이 아닙니다. 사업가의 관점에서 볼 때 1C를 선택한다면, 빠른 출시 기간 외에도 다음과 같은 단점도 고려해야 합니다.

• 서버 안정성. 우리에게는 원활한 운영을 보장할 수 있는 진정한 고품질 전문가가 필요합니다. 저는 해당 공급업체가 이런 전문가를 대상으로 이미 준비한 교육 프로그램을 갖고 있다는 사실을 알지 못합니다. 전문가 시험을 준비하기 위한 과정은 있지만, 제 생각에는 이것만으로는 충분하지 않습니다.
• 지원하다. 이전 항목을 참조하세요. 공급업체의 지원을 받으려면 구매해야 합니다. 어떤 이유에서인지 1C 산업에서는 이런 방식이 받아들여지지 않습니다. 하지만 SAP를 사용하면 구매가 거의 필수적이어서 아무도 신경 쓰지 않습니다. 기업 지원이 없고, 직원 중에 전문가가 없다면 1C 오류에 홀로 남겨질 수 있습니다.
• 결국 1C에서 모든 것을 완벽하게 할 수는 없습니다. 이것은 도구이며, 다른 도구와 마찬가지로 적용에는 한계가 있습니다. 1C 환경에서는 "비 1C" 시스템 아키텍트를 갖는 것이 매우 바람직합니다.
• 뛰어난 1C 전문가는 다른 언어의 뛰어난 프로그래머보다 저렴하지 않습니다. 하지만 어떤 언어로 작성하든, 실력 없는 프로그래머를 고용하는 데는 비용이 많이 듭니다.

점을 찍어보자

• 1C는 비즈니스를 위한 신속한 애플리케이션 개발(RAD) 프레임워크로, 이러한 목적에 맞춰 제작되었습니다.
• 주요 DBMS, 클라이언트 UI, 매우 우수한 ORM 및 보고 기능을 지원하는 3계층
• 1C가 할 수 없는 작업을 수행할 수 있는 시스템과의 통합 가능성이 넓습니다. 머신 러닝을 원하시면 Python을 사용하고 http나 RabbitMQ를 통해 결과를 1C로 병합하세요.
• 1C로 모든 것을 할 필요는 없습니다. XNUMXC의 장점을 이해하고 자신의 목적에 맞게 활용해야 합니다.
• 기술적 프레임워크(가젯)를 탐구하고, N년마다 새로운 엔진을 출시하기 위해 이를 다시 만드는 데 끌리는 개발자들은 1C에서는 지루함을 느낍니다. 그곳은 모든 것이 매우 보수적입니다.
• 개발자들 역시 제조업체가 그들에게 별로 관심을 두지 않기 때문에 지루함을 느낀다. 지루한 언어, 약한 IDE. 현대화가 필요합니다.
• 반면, 자신이 즐기는 다른 기술을 사용하고 배우는 데서 즐거움을 찾을 수 없는 개발자는 나쁜 개발자입니다. 그들은 징징거리며 다른 생태계로 이동할 것이다.
• 1C 전문가가 Python으로 뭔가를 작성하는 것을 허용하지 않는 고용주는 나쁜 고용주입니다. 그들은 호기심이 많은 직원들을 잃게 될 것이고, 그 자리에는 모든 것에 동의하는 멍청한 코더들이 들어와서 회사 소프트웨어를 늪으로 끌어들일 것입니다. 어차피 다시 작성해야 할 테니, 조금 더 일찍 파이썬에 투자하는 게 나았을지도 몰라요?
• 1C는 상업 회사이며, 오로지 자사의 이익과 편의에 따라 기능을 구현합니다. 그녀를 비난할 수는 없습니다. 사업은 이윤을 생각해야 합니다. 그것이 인생이니까요.
• 1C는 개발자 바샤의 문제가 아닌, 비즈니스 문제에 대한 솔루션을 판매하여 수익을 창출합니다. 이 두 개념은 서로 연관이 있지만, 우선순위는 제가 말한 것과 똑같습니다. 개발자 바샤가 1C: Resharper의 개인 라이선스 비용을 지불할 준비가 되면 그는 곧 등장할 것입니다. A. 오레프코프의 "Resharper"가 그 증거입니다. 공급업체가 이에 맞서기보다는 지원한다면 개발자를 위한 소프트웨어 시장이 생겨날 것입니다. 현재 이 시장에는 성과가 의심스러운 업체가 XNUMX개 있으며, 그 이유는 IDE와의 통합이 부정적이며 모든 것이 지팡이에 의지해 이루어지기 때문입니다.
• 멀티태스킹 전문가의 관행은 과거의 유물이 될 것입니다. 최신 애플리케이션은 코드 측면과 비즈니스 사용 측면 모두에서 기억하기에는 너무 큽니다. 1C 서버도 점점 더 복잡해지고 있습니다. 한 직원으로 모든 유형의 전문 지식을 갖추는 것은 불가능합니다. 이로 인해 전문가에 대한 수요가 증가하고, 따라서 1C 전문가 직업에 대한 매력도가 높아지며 급여도 인상될 것입니다. 이전에는 바샤 XNUMX인 XNUMX조가 한 급여로 일했지만, 지금은 바샤 XNUMX명을 고용해야 하며, 바샤 간의 경쟁을 통해 전반적인 수준 향상을 촉진할 수 있습니다.

결론

1C는 매우 가치 있는 제품입니다. 제 가격대에 맞는 유사 제품이 전혀 없는 것 같습니다. 유사 제품이 있다면 댓글로 알려주세요. 하지만 개발자들이 생태계에서 유출되는 현상이 점점 더 눈에 띄게 나타나고 있으며, 이는 어떻게 보든 '두뇌 유출' 현상입니다. 업계는 현대화를 갈망하고 있습니다.
개발자라면 1C에 너무 집착하지 말고, 다른 언어에서는 모든 것이 마법 같다고 생각하지 마세요. 아마 아직 1학년일 때일 거예요. 더 큰 문제를 해결해야 할 경우, 기존의 해결책을 더 오랫동안 찾아야 하며, 이를 더욱 집중적으로 개선해야 합니다. 솔루션을 구축할 수 있는 "큐브"의 품질 측면에서 XNUMXC는 매우 매우 좋습니다.

그리고 한 가지 더 말씀드리자면, 1C 전문가가 일을 위해 당신을 찾아왔다면, 당신은 그 1C 전문가를 수석 분석가 자리에 안전하게 배치할 수 있습니다. 그들은 업무, 과목 분야, 분해 기술에 대한 이해력이 매우 뛰어납니다. 저는 이것이 1C 개발에서 DDD를 강제로 사용한 데 기인한다고 확신합니다. 사람들은 기술적 배경을 통합 기술과 데이터 교환 형식에 두고, 무엇보다도 업무의 의미, 즉 주제 분야의 객체 간의 연결에 대해 생각하도록 훈련받습니다.

완벽한 프레임워크는 없다는 사실을 명심하고 자신을 잘 돌보세요.
모든 좋은!

추신: 정말 감사합니다 스페슈릭 기사 작성에 도움을 주세요.

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

귀하의 회사에 1C가 있나요?

• 13,3%전혀 아닙니다.71

• 30,3%있긴 한데 회계부서 어딘가에만 있을 뿐이에요. 다른 플랫폼의 핵심 시스템162

• 41,4%네, 주요 비즈니스 프로세스가 it221에서 실행됩니다.

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

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

출처 : habr.com