코볼은 여전히 ​​배울 가치가 있습니까? [닫은]

코볼을 배우는 것이 여전히 타당합니까?

COBOL이 여전히 유지되는 틈새 시장에 있지 않는 한 그렇게 생각하지 않습니다.

물론 아닙니다. 코볼은 결국 죽은 언어입니다. 아니면?

이러한 견해의 문제점은 이와 같은 사이트의 프로그래머는 일반적으로 첨단 기술, 빠른 실행 (및 동일하게 빠른 소각) 회사와 협력한다는 것입니다. 그들에게 코볼은 죽은 언어입니다. 한동안은 없었습니다.

그러나 COBOL은 그들을위한 것이 아닙니다. 이보다 소프트웨어 산업에는 더 많은 것이 있습니다. 컴퓨터를 구식으로 항상 업그레이드하고 교체해야하는 비합리적인 요구를 가진 사람들에게는 컴퓨터가 발명되지 않았습니다. 그들은 사업 목적으로 만들어졌습니다.

COBOL을보고 싶으십니까? 급여를 처리하거나 상품 운송 또는 운송 (선박에서와 같이)을 처리하거나 은행 계좌를 처리하는 회사로 이동하십시오. 사용자에게는 실제로 보이지 않는 거대한 보이지 않는 코드 시스템이 있으며, 대부분의 방식으로 매일 또는 다른 방식으로 코드를 접하더라도 생각하지 않습니다.

아니, 죽지 않았어 그러나 그것은 확실히 "레거시"입니까?

다시, 당신이 그것을 보는 방법에 달려 있습니다. 요즘 많은 사람들이 COBOL 대신 Java, C 또는 다른 것을 사용하여 처음부터 다시 작성하여 자연스럽게 새로운 버그를 도입합니다. COBOL에 버그가없고 기발한 것은 아닙니다. 그것은 다음 언어만큼 그렇습니다. 물론 그렇습니다. 그러나 "COBOL 시대"에서 평소 (보험, 은행)보다 버그를 더 심각하게 고려한 회사는 특수 품질 서비스 그룹에서 더 높은 품질의 코드를 생성하는 경향이있었습니다. 오늘날, 시간과 예산이 항상 품질을 능가하는 마감일이 있습니다. 또한,이 시스템은 원래 그 당시의 시스템과 비교하여 오랜 기간 동안 개발되었습니다.

일부 소프트웨어가 30 년 이상 작동 한 경우 전환 유인은 어디에 있습니까? "전체가 깨지지 않으면 고치지 마십시오" 라는 옛 속담을 무시했기 때문에 회사 전체가 사업을 중단했습니다. 많은 사람들이 그 일을 다시 쓰려고 노력했습니다 ... 첫 번째 다시 쓰려면 많은 비용이 들었고 두 번째 것에는 더 많은 비용이 들었습니다 ... 새롭고 개선 된 어느 것도 그것을 대체 할 수 없었습니다. 내가 말했듯이,이 산업은 빠르게 구워지고 있으며 또한 빨리 잊는 경향이 있습니다.

70 년대에 COBOL이 곧 죽거나 죽어 가면서 C / C ++가 지배 할 것입니다. 그런 다음 80 년대 초 파스칼이 다시 인수되었습니다. 그리고 90 년대에 그것은 언어로서의 자바였습니다 ...

Unisys Mapper, dBase, Clipper, Cold fusion 등을 생각해보십시오. 그들 각각은 COBOL의 무덤이 될 것입니다.

이를 고려하면, 대량의 트랜잭션 처리, 배치 처리 또는 레코드 / 트랜잭션 지향 처리에 유용하며 관리 형 COBOL 코드 및 호출로 30 년 된 서브 루틴을 컴파일 (오류없이) 할 수 있다는 사실 관리되는 COBOL.NET에서 Windows와 .NET으로 가고 싶다면 적절한 대체물을 찾는 데 어려움을 겪고 있습니다. (또한 10 년 이상 지속 된 Microsoft 기술을 찾는 데 어려움을 겪고 있습니다.)

예, 새로운 COBOL 코드가 오늘 작성되고 있습니다. 어디를보아야하는지 알아야합니다.

코볼, IMHO를 비웃는 사람들에게는 이집트 피라미드를 비웃는 것과 같으며, 5000 년이 지난 지금도 5000 년이 지나도 여전히있을 것입니다. 오늘날 24 개의 통제가 필요한 "hello world"주택은 삭제 될 것입니다. 다음 달에 잊혀진

그렇다면 코볼 프로그래머들은 어디에 있습니까?

아, 여기에 문지름이 있습니다. 문제는 많은 컴퓨터 과학 지식이 없다는 것입니다. 그들 중 다수는 전문 프로그래머가 아닙니다 (CS / SE 프로그램을 졸업 한 대학 졸업자와 마찬가지로). 대부분의 경우, 그들은 전문 지식의 모든 분야에서 30 대 후반에서 30 대 후반의 사람들로, 해당 직무를 위해 회사가 전적으로 훈련했습니다. 따라서 그들은 "COBOL 프로그래머"가 아닙니다. 그들이받은 훈련은 내부에서 많이 홍보하는 회사에 한정된 것입니다. 그리고 그것은 그것들을 거의 보이지 않게 만듭니다.

자신을 COBOL 프로그래머로 볼 수 있다면 그렇게하십시오. 유지 보수가 필요한 COBOL로 작성된 수십억 줄이 여전히 있습니다.

실제로 불필요한 지식과 같은 것은 없으므로 지식을 넓히고 기회를 넓힐 수 있습니다.

그것을 배우는 것이 의미가 있습니까?
글쎄, 그것은 틈새 시장이며 유지 보수가 필요하고 재 작성 할 수없는 수많은 작동하는 레거시 코드가 있습니다. 따라서 실제로 모든 프로그래머에게 엄청난 옵션은 아니지만 개인의 꾸준한 수입에 대한 관점입니다.

그러나 수십 년 전부터 개선 된 솔루션을 천천히 개선하기보다는 새로운 솔루션을 만드는 데 관심이 있다면 COBOL이 올바른 언어가 아닐 수 있습니다.

많은 유럽 기업들이 여전히 z / vse 및 코볼 프로그램과 같은 메인 프레임에 크게 의존하고 있습니다. 숙련 된 코볼 프로그래머에 대한 수요가 있으며, 시장을 가득 채울 것이라고 생각하는 사람은 아무도 없습니다.

문제는 "코볼을 사용하여 새로운 것을 개발할 것인가?" 거의 모든 것이 기존 미션 크리티컬 한 것들의 유지 보수 또는 변형이기 때문입니다.

저는 COBOL 및 PL / I 코드가 매일 작성된 IBM에서 일했습니다. 또한 초당 수천 건의 거래가 필요한 많은 은행과 같이 IBM 메인 프레임에 의존하는 대기업의 경우 이러한 언어가 여전히 많이 사용됩니다.

그런 곳에서 일하고 싶지 않다면 (그 때문에 6 개월 동안 방금 일한 이유입니다) 그런 언어를 배우는 것을 생각조차하지 마십시오.

우리는 매일 새로운 Cobol 코드를 작성하고 있으며 새로운 프로그래머를 지속적으로 찾고 있습니다. 공급이 너무 적습니다.

COBOL 프로그래머로 일하고 싶으면 계속해서 배우십시오.

다른 이유로, 현대적인 프로그래밍 기술에 도움이 될 수있는 유용한 것을 배우려고하는 것과 같이, 귀찮게하지 마십시오.

2000 년에 나는 다른 모든 언어를 결합한 것보다 더 많은 코볼이 작성되었다는 통계를 읽었습니다.
또한 모든 MVS 시스템에서 컴파일 된 모든 TEXT 데크 (객체 코드)가 모든 MVS 시스템에서 실행 가능하며 태양이 비추는 한 COBOL 프로그래밍이 보장 될 것임을 IBM이 보증합니다.

나는 어떻게 그것을 "학습"했는지 말할 수있다.
나는 그것에 대해 어떤 단서도 얻지 않고 밤새 그것을 배우는 데 어려움이 없었으며, 그것으로 일하는 데 고용되었다.

따라서 필요한 경우 배울 수 있습니다. 쓸데없는 지식으로 자신을 과부하 할 필요가 없습니다. 실제적으로 필요한 경우가 아니면 흥미 롭거나 흥미로운 것은 없습니다.

일반적인 대답 : 특정 구현 (언어 등)이 아닌 코딩 원칙을 배우십시오.

나는 그것에 시간을 보내지 않을 것입니다.
어쨌든, COBOL은 20 ~ 30 년 전에 시작된 여러 대기업에 미션 크리티컬 한 많은 레거시 응용 프로그램의 빌딩 블록입니다.
따라서 COBOL에서 핵심 비즈니스의 일부인 회사에 고용 된 경우이를 배우기 시작해야 할 가능성이 있습니다.

결국 일이 작동하는 방식 (또는 작동하던 방식)이 나쁜 것이 아니라는 점을 알고 있다면 배우십시오.

그러나 이력서에서 COBOL 기술을 지나치게 강조하지 않는 것이 좋습니다.

이력서에 COBOL이있는 곳 (예 : 내가 사는 실리콘 밸리)에서는 책임이 있습니다. 물론 여기저기서 전문 지식이 필요한 장소를 찾은 경우에는 해당 장소에만 광고하십시오 . 그러나 일반적으로 자신에게 호의를 베풀고 COBOL을 알고 있다는 것을 언급하는 것을 잊지 마십시오.

네, 궁금하다면 배우십시오. 아무에게도 말하지 마십시오.

직장 시장의 관점에서 볼 때 가치가 없을 수도 있지만 "좋은 하루에"일이 어떻게 이루어 졌는지 느낌을 얻기 위해 살펴볼 수도 있습니다. ^^

개인적 관점에서 볼 때 먼저 배우는 것이 더 좋습니다. 그러나 많은 대기업은 COBOL 코드베이스에 대한 투자가 매우 커서 결코 뒤쳐 질 수 없을 것이므로 COBOL 프로그래머가 코드베이스를 유지하고 새 코드를 작성하는 산업을 만듭니다. 내가 일하는 회사는 대규모 금융 회사이며 개발자를위한 기술 분할은 대략 30 % COBOL, 40 % Java 및 30 % C #입니다.

방금 호주 최대의 취업 웹 사이트에서 "코볼"을 검색했습니다. 87 개의 결과를 반환했으며 (빠른 탈락으로) 대부분 은행과 금융 기관의 기존 유지 관리 위치 인 것 같습니다. 아마도 Cobol 경험의 희귀 성 때문에 아마도 "현대적인"언어 기반의 직업보다 현저히 더 나은 임금을받습니다.

예, 1) 레거시 유지 관리를 신경 쓰지 않고 2) 더 이상 소수의 사람들이 배우는 것이기 때문에 돈이 많이 들고 경쟁이 치열한 틈새 시장에 들어가기를 원한다면 Cobol이 배울 가치가있는 것처럼 보입니다.

(코볼 시장은 대부분의 일차 세계 경제에서 비슷하지만 잘못 될 수 있다고 가정합니다.)

작업하려는 문제 도메인의 종류를 생각해보십시오. 일반적으로 이러한 도메인에는 일반적으로 목적에 사용되는 언어 세트가 있습니다. COBOL이 일치하면 계속 진행하십시오.

코볼이나 10 피트 극으로 많이 사용하는 문제 영역을 만질 방법이 없습니다. 차라리 버거를 뒤집고 싶어요.

또한 언어가 프로그래밍 능력 / 개념에 약간의 보너스 / 개선을 제공하는지 고려하십시오. COBOL이 더 잘 수행되지 않거나 다른 언어로 더 잘 보여 질 수있는 / 구현 / 기능을 생각할 수 없습니다.

당신과 다른 사람들은 다르게 느낄 수 있습니다.

COBOL로 작성된 레거시 시스템이 여전히 많이 있습니다. 이를 유지 보수하든 다른 프로그래밍 언어로 이식하든 COBOL을 배우는 것이 좋습니다.

그것이 무엇이든 관계없이, 여러 프로그래밍 언어에 대한 일부 지식은 당신이 가진 지식이 다른 프로젝트 요구에 대한 프로그래밍 언어 또는 접근 방식을 선택할 수 있기 때문에 더해집니다. 프로그래밍 언어에 대한 지식을 활용하여 더 좋고 깨끗하며 효율적인 코드를 구성하고 함정을 피할 수 있습니다.