LINQ와 같은 추상화를 사용하는 것이 왜 금기인가? [닫은]

저는 독립 계약자이므로, 매년 새로운 공연을 위해 3-4 회 인터뷰를합니다. 나는 지금 그주기의 한가운데에 있고 인터뷰가 잘 된 것처럼 느껴졌지만 기회를 거절 당했다. 올해도 같은 일이 두 번 일어났습니다.

이제 저는 완벽한 사람이 아니며 모든 조직에 적합한 사람은 아닙니다. 즉, 내 타율은 평소보다 낮아서 마지막 면접관에게 건설적인 피드백을 정중하게 요청하여 전달했습니다!

면접관에 따르면 가장 중요한 것은 저수준의 유기적으로 성장한 알고리즘보다는 추상화 (예 : LINQ) 사용에 너무 많이 의존하는 것 같습니다.

표면적으로는 이것이 의미가 있습니다. 실제로, 그 인터뷰에서 LINQ에 대해 비난을 받았기 때문에 다른 거부도 의미가있었습니다. 여러분).

이제 우리는 "거인의 어깨에 서서"(LINQ와 같이) 우리에게 이용 가능한 추상화를 사용해야한다면, 왜 일부 사람들은 그것을 그렇게 금기시한다고 생각합니까? 추가 비용없이 동일한 목표를 달성하는 경우 "선반에서"코드를 가져 오는 것이 합리적이지 않습니까?

LINQ가,이 경우에도 나에게 보일 수있을 것 입니다 추상화, 단순히 모든의 추상화 같은 일이 정확히 같은 끝을 달성하기 위해 작성합니다 알고리즘. 성능 테스트 만이 사용자 정의 접근 방식이 더 나은지 알 수 있지만 LINQ와 같은 요구 사항이 요구 사항을 충족하면 왜 자신의 클래스를 작성해야합니까?

여기서 LINQ에 중점을 두려는 것은 아닙니다. JAVA 세계에는 비슷한 것이 있다고 확신합니다. 일부 사람들은 왜 자신이 작성하지 않은 추상화를 사용한다는 생각에 불편을 느끼는지 알고 싶습니다.

최신 정보

Euphoric이 지적했듯이 Java 세계에는 LINQ와 비교할만한 것이 없습니다. 따라서 .NET 스택에서 개발하는 경우 항상 사용해 보지 않겠습니까? 사람들이 자신이하는 일을 완전히 이해하지 못할 가능성이 있습니까?

나는 그 자체가 불쾌한 추상화의 사용이라고 생각하지 않습니다. 다른 두 가지 가능한 설명이 있습니다. 하나는 추상화가 한 번에 모두 누출 된다는 것입니다. 당신이 정확한지 아닌지에 대한 인상을 주면, 당신이 근본적인 기초를 이해하지 못한다면, 그것은 인터뷰에서 제대로 반영되지 않을 수 있습니다.

다른 가능한 설명은 팬보이 효과입니다. LINQ에 대해 흥분스럽게 이야기하고 그것을 사용하지 않고 현재 계획이없는 회사와의 인터뷰에서 반복적으로 제기한다면, 그것은 당신이 불만족하거나 더 오래된 기술에 대한 불만을 품고 있다는 인상을줍니다. 또한 한 제품에 대한 열정으로 인해 대체 제품에 눈이 멀었다는 인상을 줄 수도 있습니다.

당신이 진정이 아닌 LINQ 가게에서 행복하다고 생각하면, 그들이 무엇에 대해 물어보십시오 않는 사용하고 그에 따라 답을 조정할. LINQ를 선호하는 동안 어떤 도구를 사용하든 유능함을 보여줍니다.

일부 .NET 프로그래머, 특히 클래식 VB / ASP 또는 C ++ 배경에서 온 프로그래머는 LINQ, MVC 및 Entity Framework와 같은 새로운 기능을 좋아하지 않습니다.

내가 관찰 한 바에 따르면,이 그룹의 전직 VB 's는 원래 10 년 전에 작성된 데이터 액세스 계층 및 기타 코드를 계속 사용하고있을 것입니다. 또한 "n-tier"등과 같은 오래된 유행어를 사용하며 .NET Framework 2.0 이외의 모든 것에 대해서는 전혀 이해하지 못하며 그것에 대해 배우고 싶지도 않습니다.

C ++의 개발자는 바퀴를 다시 발명하는 것을 의미하더라도 멋진 알고리즘을 코딩하는 것을 좋아하는 학문적 지향적 프로그래머입니다. 그들은 스스로 코딩하지 않은 것에 따라 증오합니다. 이러한 사람들 중 일부는 인터뷰 대상자가 특히 전통적인 배경을 가진 사람들보다 열등하다고 느끼게 만드는 것을 좋아합니다.

인터뷰 할 때 이와 같은 조직에 접근 할 가능성이 높습니다. 그러나 새로운 방법을 사용하는 사람도 있습니다. 몇 번의 나쁜 인터뷰로 인해 실망하지 마십시오.

Microsoft는 오랜 기간 동안 최신 기술을 개발 한 후 5 년, 10 년 또는 20 년 동안 잊어 버린 오랜 역사를 가지고 있습니다. LINQ 는 일부 사람들에게는 다른 것처럼 보일 수 있습니다. 그들은 Microsoft 가 SQL을 폐기 할 수는 없지만 LINQ는 Silverlight를 따를 수 있음을 알 수 있습니다 . 그래서 당신은 어려운 경험으로 인한 편집증을 보거나 현대 기술에 의해 남겨진 사람들과 그것을 원망하는 사람들 일 수 있습니다.

추가 비용없이 동일한 목표를 달성하는 경우 "선반에서"코드를 가져 오는 것이 합리적이지 않습니까?

항상 추가 비용이 있습니다.

기성품에 대한 학습 곡선은 항상 존재합니다. 업데이트 및 종속성을 얻는 데 따르는 어려움은 항상 있습니다. 내장으로 나사를 조일 수없는 경우가 항상 있습니다.

LINQ의 경우 첫 번째 방법 만 적용됩니다. 많은 사람들은 '이상한'코드를 읽기 어렵고 디버그하기 어렵다고 생각합니다. sql과 같은 구문은 내가 나온 이후로 일한 모든 전문 공연이 거의 개인이 아닌 것입니다. LINQ to SQL (및 기타 데이터 소스)에는 여러 가지 문제점과 제한적인 최적화 옵션이 있습니다.

이는 타사 도구 및 LINQ에 대한 일반적인 주장입니다. LINQ는 유용한 도구이므로 대부분의 상황에서 선호됩니다. 여기에서 발명되지 않은 울음 소리와 추상화가 인지 불협화음으로 강하게 호소되어서 는 안됩니다 .

그들은 LINQ를 모르거나 배울 수 없지만 "명백하게"훌륭한 개발자이므로 LINQ는 가치가 없어야합니다. 일반적인 함정입니다.

당신이 고려해야 할 또 다른 것은 멋진 새로운 기술에 대한 당신의 열정이 단순히 사람들을 불편하게 만들고 당신을 원하지 않게 할 수 있다는 것입니다. 당신은 그것들을 "강화"하지 않습니다. 왜냐하면 그것들이 아니라이 기술을 아는 사람이기 때문입니다. 그들이 스스로 깨닫지 못하더라도 이미 많은 시간을 투자 한 것을 강화할 후보를 찾고있을 수 있습니다.

"당신은 나쁜 일을하고 있을지도 모른다. 그것."

이 점에 대한 나의 견해 (그리고 우리 중 누구도 그 면접관들이 어떻게 생각하는지 말할 수 없기 때문에 추측하고있다)은 종종 그들이 당신 을 그들의 팀과 일하기 위해 당신 을 고용해야하는 이유를 설명하기 위해 인터뷰에 간다는 것이다 .

당신은 완벽한 개발자가 될 수 있습니다.하지만 당신이하고 싶은 일 (멋진 기술 gubbins에 대해 지나치게 열정적으로 말함으로써 강조하고 있음)이 단순히 당신에 대해 말하고 당신이하지 않을 것이라면 절대 의미가 없습니다. 그들이 원하는 것에 맞추십시오. 구식 데이터 액세스 시스템이있는 경우 어떤 이유로 든 업그레이드 할 수없는 경우 유지 관리 방법을 잊어 버린 사람이 필요하지 않습니다. 그들이 새로운 것을 개발하고 있고 정말로 멋진 새로운 기술을 어디에나 놓고 싶다면 미래의 코드 유지 관리 및 / 또는 직원 교육에 큰 문제가있을 것입니다.

프리랜서로서, 이것은 그들이 permie를 고용하는 경우 훨씬 더 많은 문제입니다. Permie를 사용하면 기존의 코드 및 관행의 범위 내에서 새로운 작업 방식의 교육 및 개발이 나쁘지 않습니다. 일을 더 잘하기 위해 오랫동안 머무를 것입니다. 프리랜서와 함께, 그들은 정말로 당신이 원하는 것을 후트하지 않습니다, 당신은 그들이 원하는 방식으로 그들의 일을 할 수 있고, 당신의 일은 다른 일을하는 것이 아닙니다. (동의-영구 직원이 됨)

아마 LINQ 자체와는 아무런 관련이 없습니다. 나는 후보자를 거부하고 Haskell에서 모든 것이 얼마나 잘 작성되는지 설명했습니다. 우리는 하스켈을하지 않습니다. 회사에서 사용하지 않는 기술에 대해서도 동일하게 적용되며 일반적으로 좋은 것으로 언급해도 문제가되지 않습니다. 문제가 너무 열성적이고 예리한 경우에 발생합니다.

Linq를 사용하지 않는 사람들로부터 들어 본 한 가지 유효한 우려가 있습니다. "실제로 구현을 볼 수 없다고해서 비용이 많이 들지 않는다"고 생각합니다.

다음 스 니펫을 가져옵니다.

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

여기에서 시작된 LINQ는 울고 있습니다. 왜? 이 코드가 멋지고 우아해 졌다고해서 끔찍하게 비효율적이지는 않습니다. 술어가있는 Count ()는 부모의 열거 가능한 모든 요소를 ​​평가하고 술어가 true를 리턴 한 시간을 합산합니다. 따라서이 N ^ 2 일뿐만 아니라 (InputList와 otherInputList가 거의 카디널리티 N 일 때) 절대 최악의 경우입니다. otherInputList의 모든 요소는 모든 입력 요소에 대해 순회됩니다. 대신 첫 번째 단계는 Count 대신 Any ()를 사용하는 것입니다. 왜냐하면 실제로 알고 싶은 것이기 때문에 응답이 "예"라고 알려진 즉시 종료됩니다. 고유 한 값을 저장하는 HashSet을 설정하면 otherInputListObject.OtherProperty도움이 될 수 있습니다. 액세스는 O (N) 대신 O (1)이되고이차 최고 사례 복잡성 대신 최악의 경우 복잡성.

따라서 우리는이 멋진 우아한 방법이 비용을 많이들이는 것을 알고 있으며, 그 비용이 무엇인지 모른다면 O (내 GD) 복잡성 알고리즘을 예비 고용주의 고성능 중앙 파일 서비스 업체에 매우 쉽게 코딩 할 수 있습니다 또는 다음 방문시 조정이 필요할 수있는 기본 방문 포털 페이지 그렇게 한 후에도 해고한다고해서 자신이 한 일이 취소되지는 않지만 그렇게 할 것이라고 생각되면 고용하지는 않습니다. 따라서 이것을 피하려면, 그것들을 잘못 증명해야합니다. 이러한 방법의 기능 (자신을 알아야 함)과 그 복잡성, 효율적인 (NlogN 이상) 시간 내에 답변을 얻는 방법에 대해 논의하십시오.

또 다른 우려는 "오직 유일한 도구가 망치 일 때"라는 좋은 오래된 주장입니다. 이 Linq 팬보이를 인터뷰하는 면접관 자리에 자신을 두십시오. 후보자는 Linq를 좋아하고, 그것을 사용하고 싶어하며, 그것이 최고라고 생각합니다. 주어진 모든 프로그래밍 문제가 Linq로 해결되었으므로 후보자가 코드없이 코드를 작성할 수없는 것처럼 보일 수도 있습니다. 사용할 수 없으면 어떻게 되나요? 여전히 많은 .NET 2.0 코드가 있습니다. 업그레이드 된 경우 서버, 사용자 워크 스테이션 등으로의 업그레이드가 필요하므로 멋진 확장 방법을 사용할 수 있습니다. 면접관으로서 Linq 라이브러리와 유사한 확장 방법이 꽤 괜찮다고 동의 할지라도 당신이 효율적인 정렬을 코딩하거나 2.0 정렬 방법을 사용할 수 있음을 보여 주려고 노력했습니다. 단. 요점을 보지 못한 면접관은 당신에게 다른 것에 대한 적성을 보여 주려고하지도 않을 것입니다. 그들은 당신이 그것을 가지고 있지 않다고 가정하고 계속합니다.

이것은 조금 길지만 누군가에게 도움이 될 수 있으므로 알려 드리겠습니다.

나는 지난달 20 회가 넘는 인터뷰 (전화와 얼굴 대면 혼합)를 거치면서 비슷한 것을 만났다. 확실히 손가락을 넣을 수없는 예상치 못한 일이있었습니다.

내가 알아 차린 것 중 하나는 일반적으로 지난 5-6 년 동안의 인터뷰주기의 중심점 인 것들이 결정적으로 논의되지 않았거나 짧은 샤리프를 받았다는 것입니다. OOP 분석 / 디자인, 패턴 (디자인 및 아키텍처 모두)의 기본 사항,보다 고급 / 추상 지향 .net 기능 (람다 또는 LINQ 포함, 제네릭, 직렬화 / 데이터 바인딩 등) 및 일반적으로 선호되는 방법론 (애자일 대 폭포 또는 어떤 애자일에 대해 신경 쓰지 않는 것으로 보임)과 ORM의 도구 또는 선택 또는 선호하는 협업 또는 소스 제어 관리 수단에 대한 인기 주제. 어떤 경우에는 전혀 언급되지 않았으며, 거의 모든 경우에 있어서는 걱정할 필요가 없습니다.

여러 인터뷰에서 관련성이없는 산업 분야의 다양한 관련 회사에 집중 한 것은 다음과 같습니다.

• 구식 / 개조 된 관습과 "돌로 돌아가는 시대"의 한계에 대한 이상한 고정. VS2003에서 원시 웹 응용 프로그램을 개발하는 것처럼 .net 시대의 명시 적 기능 범위 사용을 추가로 금지하는 터무니없는 제한 목록이있는 것처럼 ... 현대 개발자 능력의 실제 게이지 인 것처럼 ... 기억하는 능력 9 년 전의 패러다임과 한계는 비현실적이고 자의적인 제약으로 인해 더욱 악화되었다. 또 다른 장소는 제네릭 컬렉션 이전의 커스텀 컬렉션의 주제에 대해 매우 찬사를 받았습니다. 또 다른 장소는 계단식 생성자를 사용하지 않았기 때문에 내가 긁어 낸 클래스 모델의 코드 샘플을 없애 버렸습니다 (선언시 속성 초기화에 대한 지원을 알지 못하는 것으로 보였습니다).

• 플랫폼 또는 프로토콜에 무관심한 기술에 중점을 둔 기술의 경우에도 소우주 및 / 또는 구성 설정의 특정 구현 세부 사항에 중점을 둡니다 (즉, 요점은 특정 구현 또는 특정 사용법에 고정되지 않고 오히려 재사용 / 재용도 / 확장 성 / 필요한 통합).

• 오프 쇼어 팀과의 작업을 지정 / 감독 / 코드 검토 / 스풀링 (spool off)하려는 의도 및 그렇게하는 것과 관련된 비 코딩 기술.

• 특정 버전의 제품 / 플랫폼 / 모듈 / 등의 사용. 때로는 터무니없는 정도; "따라서 버전 1, 2 및 4를 사용 했습니까? 그러나 3은 아닙니다. 흠 ... {이력서에"no v3 !!!} "로 주석을 달았습니다. 사용 정도는 중요하지 않은 것 같습니다. 단지 당신이 또는 무언가를 사용하지 않은 것을 전혀 , 그들은 또한 요구되는 특정 일 ... 더 치환도 더 널리 사용되는 모든 기능을 갖춘 경쟁 제품의 카운트 것 같았다.

• "소프트웨어 개발자로서의 실력은 어느 정도입니까?"또는 "회사에 가치를 더하고 품질을 제공하는 데 도움이되는 기술과 경험이 있습니까?"보다 "우리 팀에 얼마나 잘 맞을 것인가"에 훨씬 더 집중합니다. 제품 "또는"당신은 들어오고 가게를 난파하는 위험한 바보 "입니다. 경우에 따라, 나의 이력서는 주어진 것으로 취해지고, 소위 "기술 화면"또는 기술 인터뷰조차도 기술 평가 이상의 성격 평가였습니다. 상대적으로 단기 계약직이더라도 두 시즌이 바뀌기 전에 다시 방문했습니다.

• 이번에 회사들은 특정 기술 문제 해결, 새로운 그린 필드 또는 빅 2.0 개발 프로젝트 시작, 또는 특정 제품을 시장에 출시하여 트렌드 나 기회 또는 일반적인 큰 시작을 활용하는 데 초점을 두지 않은 것으로 보였습니다. . 적어도 15 곳의 장소에서 반복되는 주제는 08 년 시장 붕괴의 생존자 인 3-5 명의 소규모 그룹이 지난 3 년 동안 제품을 생산할 수 있었다는 것입니다. 전체적으로 성공을 거두거나 회사 전체가 호황을 누리고 있으며 점점 더 많은 기능 요구에 부응하거나 이러한 시스템에 내장 된 설계 결함을 해결 / 극복하기 위해 또는 앞서 언급 한 플랫폼을 무료로 인수하기 위해 새로운 사람들을 고용하고 있습니다. "다른 프로젝트"를 수행하기 위해 구축 한 핵심 팀을 구성합니다.

그러나 ...이 사업에 대해 내가 아는 것이 있다면 그것이 순환 적이라는 것입니다. 다음에 새로운 공연을 찾을 때 게임이 다시 바뀌더라도 놀라지 않을 것입니다. 당신은 단지 정신적으로 융통성을 유지하고, 적극적으로 경청하고, 불필요하지만 족제비가 아닌 경우 절대적인 진술을 피하고, 1 차원적인 사람 (당신은 바보 또는 열심, 바람직하지 않음) 또는 너무 좋은 것 (위협적이며 공연 비용이들 수 있음).

접근 방식을 조정하고 다음에 좀 더 측정 된 응답을 제공하려고합니다. 문제에 접근 할 수있는 몇 가지 다른 방법을 언급합니다.하지만 지식이 불분명 한 경우에도 실제로 생각하는 것처럼 행동하고 그 자리에서 추론. 그런 식으로 더 겸손하고 덜 협박하거나 화를내는 것 같습니다.

물론 머피의 법칙은 "내가 가장 좋아하는 기술에 대해 열정적"인 것을 멈추고보다 균형 잡힌 수염을 취한 후의 다음 인터뷰 는 당신이 미쳤을 때 얻은 것입니다. 열성 남자. ;)

샘플 세트가 너무 제한되어 있기 때문에 잘못된 결론을 내리고 있다고 생각합니다. "발명되지 않은" ^1에 대한 강력한 혐오감을 가진 IT 샵의 상당한 점유율을 보았지만 기술 스택에서 선호도에 따라 후보자를 실격시킬 수있는 사람은 아무도 없었습니다. 집에서 자란 도서관.

나는 회사가 LINQ의 사용을 완전히 금지 한 것을 진지하게 의심한다. 아마도 그들은 당신이 그들에게 당신의 기술을 더 깊이 보여주기를 원했을 것입니다.

예를 들어, 해시 테이블을 알고 있는지 확인하는 한 가지 방법은 화이트 보드에 기본 테이블을 구현하도록 요청하는 것입니다. 이 간단한 연습에서는 검토 자에게 지식에 대한 놀라운 양의 데이터를 보여줍니다. 해시 코드 / 등호에 대해 알고 있으면 해시 충돌에 대해 알고있는 내용을 즉시 알게됩니다. 동시에, Microsoft가 그 일을 잘 했으므로 해시 테이블을 다시 구현하는 올바른 사람을 상상하기가 어렵습니다. 정렬 및 검색과 같은 많은 알고리즘도 마찬가지입니다. 면접관은 종종 .NET 라이브러리에 대한 실무 지식이 있는지 확인하기보다는 배경이 저수준 상호 작용을 이해하기에 충분한 지 알고 싶어합니다.

회사에서 일하기 위해 고용 된 후에는 자신이 아닌 라이브러리 구현을 사용 한다고 주장 하는 것이 거의 확실합니다 . 그러나 인터뷰 중에 그들은 당신을 당신의 진정한 능력에 대한 이해를 돕기 위해 저수준 코드로 밀어 넣을 것입니다.

"스코틀랜드에서 검은 소를 보았으니 모든 스코틀랜드 소는 검은 색입니다."

내가 당신을 인터뷰하면 내 linq 질문에 대답 할 수 없다면 실망 할 것입니다.

Linq는 까다로운 것으로, 많은 사람들이 그것을 부두라고 생각합니다. 그것은 실제로 매우 단순하고 더 영리하기 때문에 불공평합니다.

악마의 옹호자 역할을하는 이유는 많은 개발자들이 새로운 것에 신경 쓰지 않고 모든 것이 자체 개발 한 도구 (일반적으로 열등한 도구)로 해결되어야한다고 생각하기 때문입니다. 추상화를 사용하는 데 아무런 문제가 없습니다. 일반적으로 이러한 추상화를 사용 하지 않는 좋은 이유는 없습니다 .

가난한 개발자와 인터뷰를 한 것처럼 들리는데, 최신 정보를 얻지 못하고 모든 것에 망치와 못을 박는 방식입니다. NUnit, NHibernate 또는 다양한 IoC 컨테이너와 같은 유용한 오픈 소스 도구에 대해 전혀 모르는 개발자 유형입니다. 데이터베이스에 방대한 저장 프로 시저로 모든 문제를 해결하려고하는 사람들; MVC가 몇 년 동안 나왔음에도 불구하고 MVC에 대해 전혀 알지 못하는 사람들.