사내 vs. 소프트웨어 개발 환경

업계에서는 소프트웨어 개발자가 회사 자체에서 사용할 코드를 작성하는 '사내 개발'환경과 소프트웨어가 판매 / 배포되도록 구축 된 적절한 '소프트웨어 개발'환경이 구분됩니다. 대중에게.

그중에서도 소프트웨어 개발 지향 회사는 일반적으로 사양 작성, 테스트, 구축 등과 같은 소프트웨어 개발 라이프 사이클을 준수하지만 사내 지향적 인 상점은 일반적으로 자신이 최종 사용자이기 때문에 더 캐주얼 한 방식으로 작업을 수행하고 항상 제대로 수행되지 않은 것을 수정할 수 있습니다.

학생으로서 (대부분의 다른 학생들과 마찬가지로) 소프트웨어 개발 환경에서 일을 시작해야했지만 결국 사내 방식으로 더 많은 회사에서 일을 시작했습니다.

때로는 본격적인 소프트웨어 개발 경험을 놓치고 있는지 궁금합니다. 이 느낌에 대한 근거가 있습니까? 적절한 소프트웨어 개발 환경에 참여해야합니까?

내 경험상 "집에서"와 "배포 가능한 제품"을 구분하는 것은 잘못된 것입니다.

소프트웨어 개발 프로세스를 진지하게 받아들이는 회사와 그렇지 않은 회사가 있습니다. 그들이 "집", "주인"또는 "수축 포장"여부에 상관없이 많이 들어오지 않는 경향이 있습니다. 긴).

당신은 당신이 찾고있는 개발 표준이있는 장소를 찾아야합니다. 인터뷰 할 때, 이러한 관점에서 (그리고 다른면에서) 당신의 취향에 맞는지 확인하기 위해 이러한 질문을해야합니다.

이 기사를 읽을 수 있습니다

http://www.joelonsoftware.com/items/2007/12/04.html

Joel Spolsky의 질문에 정확하게 대응하고 있습니다.

저는 지난 몇 년 동안 판매 된 중간 크기의 소프트웨어 제품과 사내 소프트웨어를 모두 다루어야했습니다. 그 경험을 통해 두 플랫폼간에 차이점이 있음을 알 수 있지만 Joel이 설명한 것처럼 상황이 그렇게 나쁘지는 않습니다.

예를 들어, 사내 소프트웨어의 대부분은 매우 제한된 환경에서만 실행되어야합니다. 특정 네트워크 환경, 특정 사용자 수, 설치 루틴 등이 필요없는 특정 스프레드 시트 또는 데이터베이스 버전과 함께 작동하는 많은 도구 우리의 배송 제품. 반면, "사내"프로그램의 코드가 품질이 낮거나 "캐주얼 한 방식으로"작성된 것은 아닙니다.

오래 전에, Agile Project Management (제목을 기억할 수 있기를 바랍니다)에 관한 책을 읽었습니다. 저자는 시스템 결함에 대한 허용 수준에 따라 시스템을 구별했습니다. 결함에 대한 허용 오차는 매우 높을 수 있습니다 (예 : 버그가 불편한 다른 개발자가 사용하는 유틸리티), 우주 비행사 (버그가 발생할 수있는 경우)를위한 생명 유지를 실행하는 시스템 등 매우 낮을 수 있습니다. 생명을 위협합니다).

저자의 요점은 개발 방법론 (및 형식)이 시스템의 내결함성 (또는 중요도)으로 범위를 정해야한다는 것이었다. 사내 개발과 일반 배포 용 소프트웨어를 구분하는 것이 아니라이 차이점이 가장 중요하다고 생각합니다.

의료 품질에 영향을 줄 수있는 의료 기록 시스템을 구축하는 사내 개발자가있는 병원을 상상해보십시오. 이 경우 사내 상점은 일반 대중이 사용할 웹 제품을 구축하는 웹 사이트 컨설턴트보다 더 엄격 할 것입니다.

저는 소프트웨어 하우스, 마케팅 대행사, 휴대 전화 통신 회사 및 은행에서 근무한 프로세스의 수준을 결정하는 회사의 문화와 산업에서 일했습니다. 내가 경험 한 가장 엄격하고 느리고 제한적이고 테스트 된 환경은 은행을위한 자체 개발이었습니다. 가장 캐주얼 한 것은 마케팅 대행사였습니다.

이 경험을 통해 배우고 다음 작업의 미래 방향을 결정하는 데 사용하는 것이 좋습니다. 소프트웨어 개발 산업은 과학이 아니며 예술 / 과학으로 인해 회사마다 차이가 있습니다. 코드와 관련하여 올바른 작업을 수행하는 방법을 배우는 것이 더 중요합니다. 실패 나 프로세스 부족을 정신적으로 기록하는 것이 유용하지만 관리자가 더 나은 프로세스를 구현할 수 있습니다.