팀이 사내에서 모든 것을 쓰는 것이 얼마나 흔한 일입니까? [닫은]

최근의 인터뷰에서 나는 인터뷰 자들에게 "신기술과 라이브러리 (예 : SignalR)를 평가하고 그것들을 사용하게하려면 어떻게해야합니까?" 그들은 그렇지 않다고 말했습니다. 대신에 모든 것을 스스로 작성하므로 다른 사람에게 의지 할 필요가 없습니다.

이 회사는 정부 나 국방 계약 업체 나 안전에 중요한 프로젝트 나 그와 비슷한 일을 위해 일하지 않습니다. 그들은 평균적인 중간 규모의 소프트웨어 개발 회사 일뿐입니다.

제 질문은 팀이 모든 것을 스스로 작성하는 것이 얼마나 흔한 일입니까? 팀이 걱정해야합니까?

편집-대부분의 모든 응답에서 이것이 우려되는 부분이라고 말했습니다. 두 번째 인터뷰는 집안에있는 모든 것을 쓸 때 자신의 입장을 분명히하고 / 반복하도록 요청하기에 적절한 시간입니까?

타사 라이브러리를 사용 하지 않는 태도 는 터무니 없습니다. 코드베이스의 모든 행이 회사 직원이 작성해야하는 엄격한 비즈니스 요구 사항이없는 한, 모든 것을 직접 작성하는 것은 회사 시간을 끔찍하게 사용하지만, 이는 특히 민간 기업과 같은 특이한 시나리오입니다. 당신은 설명했다.

보다 합리적이고 철저한 답변은 다음과 같은 타사 라이브러리 만 사용한다는 것입니다.

• 그렇지 않으면 스스로 작성하는 코드의 요구를 충족
• 회사의 비즈니스 모델과 호환되는 라이센스에 따라 사용 가능
• 포함 된 테스트
• 코드 검토 통과

이러한 기준이 충족되면 (그리고 제 경험상 코드 검토가 특히 우수한 테스트가있는 경우 매우 유연합니다) 더 이상 "다른 사람에 의존하지"않습니다. 암호.

코드가 오픈 소스 인 경우 최악의 경우 타사 라이브러리는 유지 관리되지 않습니다. 그러나 누가 신경 쓰나요? 테스트 결과 라이브러리가 사용자의 요구에 적합하다는 것이 입증되었습니다!

또한 기존의 타사 라이브러리로의 혐오감은 프로그래머의 생산성을 심각하게 저해합니다. 회사가 웹 애플리케이션을 작성하고 있고 (예를 들어) jQuery 사용을 거부했다고 가정 해 DOM 조작을 단순화하기 위해 자체적 인 교차 브라우저 라이브러리를 작성했습니다. 거의 확실하게 우리는 그들의 구현이 다음과 같다고 가정 할 수 있습니다.

• jQuery에 이미 익숙한 개발자에게 외국 API가있을 것입니다.
• jQuery만큼 잘 문서화되지 않습니다
• 라이브러리 사용시 문제가 발생했을 때 관련 Google 검색 결과가 없습니다.
• jQuery만큼 필드 테스트되지 않습니다.

이러한 모든 점은 프로그래머의 생산성에 큰 장애물입니다. 기업은 어떻게 그런 생산성을 포기할 수 있습니까?

질문을 업데이트하여 두 번째 면접에 도움이되는지 물었습니다. 절대적으로 그렇습니다.

첫 번째 인터뷰에서 면접관의 답변을 잘못 해석했을 수도 있고, 면접관이 회사의 입장을 잘못 설명했을 수도 있고 새로운 면접관이이를 명확히 할 수도 있습니다.

외부 라이브러리에 대한 입장에 대해 우려하고 있다고 설명하면 가능한 두 가지 결과가 있습니다.

• 그것들은 변화하기에 개방적이며, 그들의 과정에 대한 당신의 관심은 다른 후보들보다 당신을 더 좋아 보이게 만듭니다.
• 그들은 변화에 개방적이지 않으며, 당신을 "우리가 고용하고 싶지 않은 종류의 개발자"라고 생각합니다. 중요하지 않습니다, 그것은 당신이 어쨌든 일하고 싶은 곳이 아닙니다.

엄청나게 경쟁적이지 않은 것 같습니다. 나는 Hibernate와 같은 표준 오픈 소스 라이브러리를 건너 뛰고 "치명적인"누락 된 기능으로 인해 자체 롤업하기로 결정한 상점에서 일했다. 결국 소프트웨어는 구축 및 유지 관리 비용이 엄청나게 비쌌습니다. 물론 사내 도서관의 비용은 크게 과소 평가되었습니다. 사내 라이브러리가 작성되는 동안 표준 라이브러리는 빠르게 발전하여 사내 라이브러리에서는 사용할 수 없었던 새로운 기능을 추가했습니다. 결국 표준 라이브러리를 사용하는 데 1 시간이 걸리는 작업에는 이틀이 걸렸습니다. 그리고 세상이지나 가면서 개발자의 경력에 ​​나쁜 영향을 미쳤습니다. 나는 그런 가게를 피할 것입니다. 나는 전달하는 것을 좋아하며 재사용 할 수있을 때 다시 써야 할 인내심이 없습니다.

가게에는 Not Invented Here 라는 질병이 있습니다 . 즉석에서 인터뷰를 종료하고 즉시 떠나는 것이 좋은 이유입니다. 이것은 일어날 가능성이 거의없는 하향식 집 청소로만 치료할 수 있습니다.

당신의 질문에 대답하기 위해, 그것은 당신이 생각하는 것보다 슬프게도 훨씬 더 일반적이며 그것은 반드시 걱정해야 할 이유입니다.

예, 확실히 걱정하십시오! 그것은 오만과 어리석은 말입니다. 두뇌가 절반 정도 인 프로그래머는 signalR과 같은 라이브러리를 직접 작성하는 대신 사용합니다. 이미 해결 된 문제를 해결하는 데 시간을 낭비 할 필요는 없습니다. 나는 아마도 더 많은 정보를 먼저 찾으려고 노력할 것입니다-그들은 당신을 오해했을 수도 있습니다 (면접이 끝나면 어려울 수 있습니다!)

나는 여기에 증후군을 발명하지 않은 소프트웨어 하우스에서 일하는 두 명의 친구가 있습니다 . 그래서 마음가짐이 있습니다.

그들이 한 관찰은 개발팀에서 배양 한 접근 방식의 문화에 관한 것이었다. 그들은 둘 다 소프트웨어 개발에 대한 전망 측면에서 상당히 고립 된 사람들과 실제로 새로운 것을 배우고 품질을 추구하도록 이끌지 않은 사람들과 협력했습니다. 경력의 어느 단계에 관계없이 항상 동료로부터 새로운 것을 배울 수있는 곳에서 일하고 싶습니다. 그러나 이러한 종류의 환경은 일반적으로 모든 것을 스스로 롤링하려는 곳에서 발견되지 않는 것 같습니다.

내가 사는 곳은 흔하지 않으며 동료를 통해 많은 회사를 알고 있습니다. 나는 그것이 바로 "감사하지 않는다"고 말하기까지했다.

나는 이미했던 좋은 점들을 되풀이하지 않을 것이지만 한 가지를 추가 할 것이다.

그들은 방금 고용을 훨씬 더 어렵게 만들었습니다.

• 모든 신입 사원은 소프트웨어 / 도메인의 주요 부분보다 학습 곡선이 훨씬 가파 릅니다.
• 최고의 후보자들은 그들의 기술이 사용되지 않기를 원하기 때문에 연기 될 것입니다.
• 사람들이 자신이 좋아하는 도구를 사용하지 않는 것이 얼마나 나쁜지 알게되면 직원들은 오래 머 무르지 않을 것입니다.

당연히 도전을 좋아하는 사람들이있을 것입니다. 그러나 나는 그들이 소수에 있다고 생각합니다.

마찬가지로 "인터넷 규모", 아마존, 페이스 북 등에서 운영하는 일부 회사는 사용자 지정 요구가 미치지 만 소수의 회사도 있습니다.

저는 소프트웨어 회사가 타사 및 / 또는 오픈 소스 소프트웨어에 의존하지 않고 오늘날에도 살아남을 수 있다고 생각하지 않으며, 경쟁력을 유지하기 위해서는 물론 새로운 기술을 적극적으로 추적해야합니다. 그러나 적어도 그것에 대해 다소 방어적인 견해를 취하는 데에는 충분한 이유가 있습니다.

예를 들어, 소프트웨어를 판매하고 연중 무휴 24 시간 지원을 제공한다고 주장하고 소프트웨어가 올바르게 작동하는 데 대한 법적 책임이있는 경우, 문제가있는 경우 발생할 수있는 일에 대한 매우 정확한 아이디어가 필요합니다. 예를 들어, 1 시간의 생산 중단 시간이 수백만 달러에 달하는 공장에서 소프트웨어를 사용하면 사용중인 오픈 소스 라이브러리에 심각한 버그가 발생합니다. 나를 믿으십시오. 문제가되는 소프트웨어에 대해 매우 철저한 평가를 수행 할 것입니다.

당신이 작성한 것으로부터,이 시나리오는 문제의 핵심이 아닌 것 같습니다.

특정 규모의 기술 기반 회사 인 경우 예를 들어 점점 더 많은 자체 기술을 개발하는 것처럼 보일 것입니다 .Google은 대부분의 소프트웨어를 공개적으로 소싱하는 동안 소프트웨어를 전부는 아니지만 많이 개발하지는 않습니다. 업계 표준으로 만들기 위해

소규모 회사의 경우 특정 비즈니스 제품에 자체 비즈니스 로직을 제공하려고 할 때 시간 낭비로 보일 수 있으며, 제 경험상 중소 기업이 그렇게하는 것을 보지 못했습니다.

암호화 알고리즘-어떤 사람들은 작동 방식에 대한 기본적인 이해를 가지고 있지만 실제로 솔루션을 구현하는 복잡한 부분은 직접 발을 내딛는 것처럼 보일 것입니다. 그런 것들을 전문으로하는 암호 전문가를 고용하지 않는 한.

일부 회사에서는 자유롭게 자신 만의 오픈 소스 프로젝트를 만들 수 있습니다.

나는 개인적으로 그런 문화가있는 곳에 가지 않을 것입니다.

당신이 가진 것은 두 번째 인터뷰에 들어가서 그들에게 어려운 질문을 할 수있는 정말 좋은 기회입니다. 나는 회사가 무엇을하는지 모르겠다. 왜 이것이 이상한 선택인지 말하기 어렵다. Google의 타사 라이브러리 사용과 관련하여 @Daniel Pryden의 의견을 사용할 수 있습니다.

사내 또는 타사에서 사용하는 모든 소프트웨어에는 장단점이 있습니다. 사내 도구가 아니기 때문에 도구를 사용하지 마십시오. 작업에 가장 적합한 도구 인 경우에도 닫힌 사고 방식을 보여 주므로 결코 혁신과 창의성을 장려하지 않습니다.

아마도, 아마도, 당신은 그 변화를 소개 할 사람 일 것입니다. 모든 행운을 빕니다.

물론 걸어 가야합니다. 나는 여기에 언급 된 것을 보지 못했지만 직업을 넘겨야하는 가장 큰 이유는 이전 가능한 기술을 많이 얻지 못하기 때문입니다.

다음 인터뷰에서 어떤 기술을 사용했는지 묻고 베어 본 C ++ 만 언급 할 수 있다고 상상해보십시오.

대기업은 모든 것을 스스로 작성합니다.

직접 작성하면 몇 가지 장점이 있습니다.

1. 귀하는 소프트웨어를 직접 소유하고 있음을 보증합니다
2. 생성 된 작업량을 정확하게 계산할 수 있습니다.
3. 다음에 lib를 사용할 수없는 경우에도 단계를 반복 할 수 있습니다.
4. 그것은 당신의 요구 팽창을 줄입니다
5. 당신은 다른 사람들이 이미 한 일을 반복하지 않습니다
6. 당신은 그것을 유지하기에 충분한 사람들이 보장됩니다
7. 소프트웨어의 모든 부분을 수정할 수 있습니다
8. 소프트웨어 크기는 보유한 리소스 양에 따라 제한됩니다

다른 사람의 라이브러리를 사용하는 경우 각 포인트가 어떻게 깨지는가는 다음과 같습니다.

1. 다른 사람이 라이브러리를 소유
2. lib를 만들기 위해 얼마나 많은 노력을했는지 몰라
3. 동일한 라이브러리를 더 이상 사용할 수 없으므로 다음 버전의 제품을 새 플랫폼에서 작성할 수 없습니다.
4. 요구 사항을 구현하는 능력은 몇 년 전에 lib가 구현했는지 여부에 달려 있습니다.
5. 다른 사람도 동일한 라이브러리를 사용하여 동일한 제한과 기능을 얻습니다.
6. 라이브러리를 만들지 않았으므로 제품에 모든 소프트웨어를 유지 관리 할 사람이 충분하지 않습니다.
7. 립은 이진이며 수정할 수 없습니다. 소스를 사용할 수 있더라도 많은 양의 코드를 수정할 사람이 충분하지 않습니다.
8. 작성한 코드와 libs를 유지하는 것은 원래 예상했던 것보다 더 큰 노력입니다.