새로운 소프트웨어 제작이 일반적으로 대부분의 프로그래밍 작업의 주요 부분입니까? [닫은]

저는 10 년 넘게 소프트웨어 개발 분야에서 일해 왔으며 "새로운"것을 거의 만들지 못하고 있습니다. "신규"는 모호한 용어라는 것을 알고 있지만, 명백한 새로운 대규모 프로젝트에서 기존 프로젝트의 새로운 큰 특징 (디자인에 대해 약간의 생각이 필요할 수있는 것)으로 정의 할 수 있습니다. 완료하는 데 2 ​​주 이상이 소요됩니다. 대략적인 지침은 서면 사양이 필요한 경우 새로운 것일 수 있습니다. 나는 대부분의 프로그래머가 내가 말하는 것을 알고 있다고 생각합니다. 당신은 그 영역에 있고 많은 양의 코드를 빠른 속도로 작성합니다.

어쨌든, 내가 한 일을 되돌아 보면, 10 % 미만의 시간이 "새로운"작업에 소비되는 것으로 추정됩니다. "이 새로운 시스템에서 작동하도록이 기존 시스템을 적응시키는 것"과 같은 것들이 있습니다. 확실히 많은 계획이 필요하지만 실제 코딩과 "새로운 것"은 코드 전체의 여러 곳에서 작은 변화를 가져옵니다. 작은 기능 요청의 경우와 마찬가지로-수행해야 할 작업을 알고 있으면 한 시간 안에 완료 될 수 있으며 그렇지 않은 경우 코드를 많이 읽고 수행해야 할 작업을 파악합니다 (배우기 때문에 실망 스럽습니다) 읽는 것이 아니라 훨씬 잘하는 것).

일반적으로 나는 대부분의 시간 동안 아무것도 만들지 않는 것처럼 느낍니다. 나는 이것이 대부분의 경우에 해당한다고 생각했다. 새로운 제품은 오히려 빨리 나오고 그 시점에서 모든 사람들이 흥분하고 코드를 빠른 속도로 낼 수 있지만 일단 작동하면 유지 관리 모드로 이동합니다. 후속 변경 중 일부는 "신규 및 창조적"으로 간주됩니다.

내가 잘못? 대부분의 프로그래밍 작업을 정확하게 설명하고 있습니까, 아니면 대부분의 프로그래머가 종종 새로운 것을 만드는 것처럼 느끼십니까?

많은 소프트웨어 작업이 유지 관리입니다. 물론 채용 관리자는 실제로 당신에게 이것을 말하지는 않지만 확실히 사실입니다.

네, 당신의 인식은 정확합니다. 새로운 시스템을 만드는 것보다 시스템을 유지하는 데 훨씬 많은 시간과 돈과 노력이 소비된다는 것은 절대적인 사실입니다. 따라서 대부분의 프로그래머의 시간 할당은이를 반영 할 것입니다.

그 이유 중 하나는 많은 사람들이 "새롭고 창조적 인"일을 할 때 시스템을 유지하기가 어려워서 시스템을 유지 관리하는 것이 어렵다는 것입니다. 소규모 그린 필드 프로젝트를 지속적으로 수행 한 사람은 실제로 유능하다고 주장 할 수 없습니다).

또 다른 (아마도 더 큰) 이유는 대부분의 시스템이 일회성 이벤트가 아니라 지속적으로 유용하도록 설계 되었기 때문입니다. 그래서 그들은 그것들을 개발하는 데 걸리는 것보다 훨씬 더 오랫동안 익숙해졌습니다. 그러나 그 기간 동안 법, 시장, 연구, 사용자 등의 변경으로 인해 요구 사항이 변경되고 추가됩니다. 그리고 그것은 유지 보수 작업을 의미합니다.

레거시 시스템은 성공적인 시스템입니다. 프로젝트의 50 %가 실패한 초기 개발 프로세스에서 성공했습니다 (성공이 재정의 된 후에도). 그들은 변화하는 비즈니스 환경에서 살아 남았습니다. 그들은 아마도 어린 순진한 프로그래머들이 자바 나 그 당시 유행했던 모든 것을 다시 쓰기위한 약 10 건의 제안에서 살아 남았을 것입니다. 그들은 소프트웨어를 제공하는 부서, 회사 또는 대행사가 다양한 예산 삭감, 재구성, 합병 등에서 살아 남았을 정도로 운이 좋았습니다.

아마도 10 년이 지난 후에도 작성된 소프트웨어의 5 % 미만이 여전히 실행될 것입니다.

그래서 이것에 대해 신음하는 것이 아니라, 그러한 다윈의 성공 스토리를 다루는 특권과 실제 세계에서 무엇이 효과가 있으며 왜 그런지 배울 수있는 기회로 보아라.

오래된 개발에 의존하지 않는 새로운 프로젝트에 종종 사용되는 용어는 greenfield project 입니다. 때로는 직업 목록에이 용어가 표시 될 수 있습니다. 다른 사람의 실패한 노력을 물려받는 것이 아니라 처음부터 시작해야한다는 사실을 알면 직업을 더 매력적으로 만들 수 있습니다.

성공적인 소프트웨어 프로젝트는 일반적으로 새로운 프로젝트로 구축되는 것보다 유지 보수에 더 많은 시간을 소비하므로, 완전히 "새로운"작업을 많이하지 않는 것은 놀라운 일이 아닙니다.

또한 완전히 새로운 것을 만드는 것은 많은 작업입니다. 그린 필드 프로젝트에서도 플랫폼, 컴파일러, 프레임 워크, 라이브러리 등과 같은 여러 도구를 선택하게 될 것입니다. 이러한 선택을하면 프로젝트에 특정 제약 조건이 적용됩니다. 그것은 당신이 더 이상 새로운 일을하고 있지 않다는 것을 말하는 것이 아니라, "새로운 것"만이 여기서 상대적인 용어입니다. 그린 필드 프로젝트라고 부르지 않더라도 기존 프로젝트에 기능이나 모듈을 "신규"로 추가하는 것은 그리 쉬운 일이 아닙니다.

그것은 당신이 찾는 일에 달려 있습니다.

저는 소규모 스타트 업 팀에서 단일 금도금 응용 프로그램을 작업 한 순수한 소프트웨어 제품 회사에서 단 한 번만 일했습니다.

그렇지 않으면 내부 R & D 또는 외부 제품을 지원하기 위해 소프트웨어가 필요한 기술 회사에서 근무했습니다.

단점은 완전한 시작 완료 제품을 구축하고 원하는 것을 거의 구축한다는 것입니다. 때로는 기존 시장을 선도하는 응용 프로그램에 기능을 추가하는 것보다 최신 기술을 시도 할 수도 있습니다.

단점은 제품의 일부가 아니라 비용의 일부라는 것입니다. '우리는 소프트웨어를하지 않고있다'/ '소프트웨어는 핵심 비즈니스가 아니다'라는 이유로 프로젝트를 통조림으로 만들었습니다.

기존 코드를 다른 사람의 혼란을 지속적으로 정리하는 것으로 보는 대신 많은 새로운 프로젝트를 수행 할 수있는 기회로 생각하십시오.

시스템에 추가 된 모든 새로운 기능은 그 자체로 작은 프로젝트입니다. 작업을 올바르게 완료하려면 여전히 전체 SDLC를 적용해야합니다. 물론, 기능에 대한 사양이 주어 졌을 수도 있지만 일반적으로 세부적인 부분이 남았으므로 표시된대로 문제를 분석하고 변경 사항을 적용하고 테스트하고 코딩하는 데 가장 적합한 방법을 설계해야합니다. 그런 다음 버전 관리 시스템으로 다시 릴리스하고 나중에 유지 관리하십시오.

완전히 그린 필드에서 일하지 않는 것은 저의 경험이었습니다. 종종 운이 좋았을 때 프로젝트의 유지 보수 중 일부를 통해 프로젝트를 보게 될 것입니다. 제품의 수명 또는 주어진 고용주와의 전체 시간. 제품에 대한 친밀한 경험은 지식 저장소가되며 다른 곳으로 이동하는 데 비용이 많이 드는 것으로 볼 수 있기 때문입니다. 기존 제품을 시작할 때 고용주는 최근에 자원을 잃었거나 프로젝트에 더 많은 자원이 필요하기 때문에 비즈니스에서 소프트웨어에 투자 한 금액을 너무 많이 잃지 않도록해야합니다. . 이것이 바로 소프트웨어 엔지니어가되는 현실입니다.

저는 지난 15 년 동안 소프트웨어 개발자로 거의 22 년 동안 IT 분야에서 일해 왔으며, 그 동안 내내 대부분의 시간 동안 해당 제품을 장기간 유지하거나 다른 사람을 유지하면서 약 5 개의 새로운 제품을 만들었습니다. 생성물. 각각은 저에게 해결해야 할 과제와 문제점을 주었고, 각각은 내가 단순히 참여하는 큰 프로젝트 일뿐만 아니라 완료하기위한 거대한 일련의 마이크로 프로젝트로 취급되었습니다.

약간의 정신 미용사가 당신의 일상 업무에 대한 인식과 즐거움을 완전히 바꿀 수있는 방법은 놀랍습니다. ;-)

기존 제품을 개선하거나 기존 코드를 새로운 고객이나 시장에 적용하는 것과 관련된 많은 소프트웨어 개발 작업이 있다고 생각합니다.

이것은 실제로 '유지 관리'가 아닙니다. 예를 들어 VMWare는 방금 버전 8을 출시했는데, 이는 주 제품의 주요 업그레이드입니다. VMWare의 첫 번째 코드 줄을 작성할 때이 작업을 수행 한 개발자는 거의 없었습니다. 그들은 오랫동안 움직 인 사람들이 작성한 코드를 크게 업그레이드했습니다.

오버에서 직장 베타 구글의 20 %를 개인 프로젝트 시스템의 작동 방식에 대한 질문이 있습니다 .

Google은 최고의 개발자가 새로운 소프트웨어 제품 제작에 참여하기를 원하며 결국 몇 가지 작은 기능을 추가하고 다음 포인트 릴리스를 위해 GUI를 조정하는 데 지칠 것입니다.

나는 20 %의 프로젝트를 가짐으로써 Google 개발자가 새로운 무언가를 시작할 때 여전히 재미있게 즐길 수 있기 때문에 Google 프로젝트를 계속 개선하지 않아도 될 것이라고 추측합니다.

새로운 사양을 준수하기 위해 새로운 기능을 만들고 기존 코드의 기능을 변경하는 데 시간을 할애합니다.

다른 사람들은 그 유지 보수를 호출하지만 끔찍한 용어입니다. 프로그램의 기능에 대한 새로운 아이디어에 부합하도록 소프트웨어를 재 설계하고 리팩토링 또는 재 코딩합니다.

나는 그것이 당신이 일하는 회사에 달려 있다고 말합니다.

저의 첫 번째 직업은 회계 소프트웨어 회사였습니다. 주요 제품은 ERP 시스템으로 Great Plains 또는 Peachtree와 거의 같은 수준으로 경쟁하고 있습니다 (QuickBooks에서 위로 이동했거나 GP의 난독 화 된 스키마 또는 다른 것에 질려서 옆으로 PT에 문제가 있다고 생각하면 계층에서 완전히 SAP와 같은 패키지로 이동했습니다. 이 작업은 99.99 %의 유지 관리 작업으로 소프트웨어의 작동 방식이나 수행 가능한 작업을 근본적으로 변경하지 않고 버그를 수정하고 "작은 물건"을 추가하는 것으로 정의되었습니다. CEO가 시스템을 한 페이지에 한 번 다시 작성하고 싶을 때 회사를 떠났습니다. 내부 플랫폼과 같이 명확한 안티 패턴이있는 여러 가지 디자인 기능 (고도의 사용자 정의 허용)을 주장한 것 외에는 시원했을 것입니다. 기본적으로 고객에게 바보 같은 VS 디자이너를 제공함으로써

그 후의 다음 일은 "턴키 개발"을 한 계약 회사였습니다. 고객이 지정한 시스템은 처음부터 하드웨어 및 소프트웨어로 구축 된 후 프로젝트가 완료되면 고객이 직접 유지 관리하거나 월별 요금으로 회사의 서비스를 유지할 수있는 고객에게 넘겨졌습니다. 저의 직업은이 주요 프로젝트 중 하나를 개발하는 것이 었습니다. 그래서 제가 일을하면서 시작한 전에는 거의 모든 것이 존재하지 않았습니다. 그럼에도 불구하고 개발은 본질적으로 반복적입니다. 당신은 항상 당신이 이미 가지고있는 것에 추가하고 (아무것도없는 경우에도) 회귀 문제를 피하고 수정해야합니다 (새로운 것은 오래된 것들을 깨는 것). 프로젝트가 "보증"상태로 전환되면

현재는 비디오 모니터링 및 오디오 피드백을 사용하여 알람 신호 확인 및 기타 "가상 보호"서비스를 제공하는 보안 회사의 사내 개발로 돌아 왔습니다. 이 분야는 빠르게 성장하고 있으며 여전히 발전하고 있습니다. 새로운 장비가 항상 시장에 등장하고, 새로운 일을하려는 신규 고객이 등록되었으며, 기존 제품은 더 이상 UL 및 정부 규정에 부합하지 않습니다. 이 직업의 99 %는 "통합"입니다. 이전에는 존재하지 않았던 새로운 소프트웨어를 작성하여 기존의 장비 또는 소프트웨어 중 하나를 기존의 다른 장비 또는 소프트웨어와 함께 작동시켜 두 가지 모두로 새로운 일을 할 수 있습니다.

나는 그것이 당신의 역할의 본질에 크게 의존한다고 말하고 싶습니다.

나는 소규모 팀의 일원이므로 내가 만든 모든 것을 유지하고 지원해야합니다.

5 년 전, 내가 한 일의 대부분은 "새로운"것이 었습니다. 이제 기존 코드의 유지 보수는 내 시간의 절반 이상을 차지하며 25 %는 기존 시스템의 "새로운"버전입니다.

그러나 코드를 릴리스 한 후 유지 관리 및 지원을 수행하기 위해 팀과 함께 개발자로만 작업 한 경우 기술적으로 모든 것이 "새"입니다. 자신의 코드를 유지할 필요가없는 직업을 찾으면 가져 가십시오!

1. 그것은 당신의 직업 위치가 얼마나 위험한 지에 달려 있습니다 : ;-)

   회사가 살아남을 위험이 높은 새로운 제품을 개발하는 새로운 회사에서 일하는 경우 훌륭한 신제품을 만들 수 있습니다.

   시장에서 안정적인 위치에있는 오래된 회사에서 근무하는 경우 유지 관리 모드에서 코드를 작성할 가능성이 높습니다. ;-).

2. 새로운 소프트웨어의 제작은 항상 매우 유혹적 입니다. 진실로 이것을 올바르게 하는 것은 어렵다 . 유지 관리 가능한 코드를 작성하는 것은 쉬운 일이 아닙니다.

   이러한 많은 측면을 생각한다면 올바른 로깅, 적절한 모니터링 및 통계 수집, 효율적이고 친숙한 사람들도 프로젝트에 참여하고 문서화, 자동 테스트 및 테스트 중심 개발에 도움이되는 설명적인 디자인을 작성해야합니다.

많은 사람들이 올바르게하고 있지 않으므로 코드를 유지하고 올바른 상태로 연마해야합니다. ;-)

좋은 소식은 회사에 오래 머무르면 새 코드 작성 방법에 영향을 줄 수 있다는 것입니다. :-)

주로 유지 관리를 수행할지 여부는 적어도 부분적으로 제어합니다. 필자의 경우, 지난 15 년 이상 동안의 대부분의 작업은 새로운 개발이었습니다. 새로운 개발을 할 수있는 일자리를 찾고 있기 때문입니다. 저는 계약자가 아니며 일반적으로 웹 개발을하지 않습니다. 저는 거의 항상 소규모 고용주를 위해 일해 왔으며 일반적으로 틈새 분야 (데스크톱 GUI 개발, QA 도구, 개발자 도구, 수직 시장)에서 일합니다.

또한 팀의 최고 프로그래머가 일반적으로 (항상 그런 것은 아니지만) 최상의 일자리를 얻는다는 것을 직접보고 경험했습니다. 따라서 회사에서 최고의 프로그래머가되는 데 집중하면 새로운 개발이 시작될 것입니다.

유지 관리 개발은 어려운 작업이며 여러 가지면에서 새로운 개발보다 어렵습니다. 내 경험상 고용주는 개발자가 유지 보수를 수행하는 것을 좋아합니다. 특히 그들이 잘하는 경우. 레거시 기술에서 우수한 유지 보수 개발자를 찾는 것은 최신 기술로 작업 할 수있는 사람을 찾는 것보다 어렵습니다.

나는 모든 유지 보수가 된 제품 팀과 새로운 개발이었던 프로젝트 팀으로 나뉘어 진 회사에서 근무했습니다. 양쪽에는 훌륭한 개발자가 있었지만 유지 보수 담당자는 확실히 더 전문화되어 레거시 기술을 사용했습니다.

다시 제안하고 새로운 개발 작업을 요청할 것을 제안 할 수 있습니까? 그리고 고용주가 유지 보수 만하는 경우 계속 이동해야합니까?

나는 그것이 많은 요인에 달려 있다고 말할 것입니다. 어디서 일하고, 어떤 종류의 제품을 만들고, 어떻게 팀을 구성하고 있습니까?

회사에서 근무한 4 년 동안 내 시간의 70-80 %가 새로운 것을 만드는 데 소비됩니다. 아마도 그 중 50-60 %는 완전히 새로운 코드 인 대규모 프로젝트에 사용되는 반면 나머지 시간은 현재 기능 향상에 사용됩니다.

내가 아는 한 가지는 회사가 어떻게 운영되는지입니다. 개발 팀의 모든 사람이 새로운 기능을 구축하는 데 많은 시간을 소비하는 것은 아닙니다. 버그 수정 / 헌팅에만 시간을 집중시키는 숫자가 있습니다. 새로운 기능이거나 도움이 필요한 경우 조사를 요청합니다. 일반적으로, 그 작은 버그 사냥꾼 팀은 더 큰 개발자 그룹이 중단없이 압박을 가할 수있게 해줍니다.

저는 QuickBooks 와 Excel 을 사용하는 회사의 유일한 개발자로 거의 3 년을 일해 왔으며 시작했을 때 다른 것은 없었습니다. 이제 Windows Forms 응용 프로그램, SharePoint 설정, SQL Server + 보고서, Excel 추가 기능 및 Outlook 추가 기능이 있습니다.

바로 오늘 , 사용자가 불만을 제기하는 속도로 이메일 요청을 관리하는 기능을 상실했기 때문에 티켓팅 시스템을 처음으로 설정했습니다.

저의 이전 직업은 다른 직업이 게시 한 것과 비슷하지만 다음 직업이 무엇을 가져올 지 결코 알지 못하기 때문에 비정형적인 경험을하게 될 것이라고 생각했습니다. 나는 지 쳤지 만이 직업에 대해 배운 금액은 그만한 가치가있었습니다.

내가 일하는 회사와 같은 일부 대규모 조직은 수년 후에 소프트웨어 폐기 정책을 가지고 있습니다. 아마도 작성된 개발 언어가 더 이상 사용되지 않거나 (Delphi 사람?) 플랫폼이 교체되고 있기 때문일 것입니다 (Windows XP). 또는 규제 요구 사항에 따라 요구됩니다. 예를 들어, 데이터베이스와 직접 통신하는 2 계층 프로그램은 이제 보안을 강화하기 위해 Kerberized 연결을 사용하는 3 계층을 선호합니다.

사용자는 여전히 원래 기능이 필요하므로 최신 기술을 사용하는 완전히 새로운 버전이 개발됩니다.

이 유형의 제품에는 5-7 년 교체주기가 필요합니다. 예를 들어, 2020 년까지 지금 쓰고있는 WPF (Client) / Java (server) 소프트웨어는 오래된 기술이며 새로운 것으로 대체 될 것으로 예상됩니다.