대규모 코드베이스 및 엔지니어링 팀에 F #을 도입하는 실제 함정 [폐쇄]

저는 기존의 대규모 코드베이스 (모두 C #)와 상당한 규모의 엔지니어링 팀을 보유한 소프트웨어 회사의 CTO입니다. F #에서 코드의 특정 부분을 작성하는 것이 훨씬 쉬워 개발 시간이 단축되고 버그가 줄어들며 병렬 구현이 쉬워지며 기본적으로 팀의 전반적인 생산성 향상을 얻을 수 있습니다. 그러나 F #을 도입하면 다음과 같은 생산성 문제가 발생할 수 있습니다.

1) 누구나 F #을 배워야하며, Java에서 C #으로 전환하는 것만 큼 간단하지는 않습니다. F #을 배우지 않은 팀 구성원은 코드베이스의 F # 부분에서 작업 할 수 없습니다.

2) 현재 (2010 년 12 월) 현재 고용 가능한 F # 프로그래머 풀이 존재하지 않습니다. 다양한 소프트웨어 엔지니어 이력서 데이터베이스에서 "F #"을 검색하십시오. 이력서의 1 % 미만이 키워드를 포함합니다.

3) 현재 (2010 년 12 월) 현재 커뮤니티 지원이 부족합니다. C #에서 거의 모든 문제를 Google로 처리하고 F #이 아니라 이미 처리 한 사람을 찾을 수 있습니다. 타사 도구 지원 (NUnit, Resharper 등)도 스케치되어 있습니다.

나는 이것이 Catch-22라는 것을 알고 있습니다. 예를 들어 나와 같은 사람들이 F #을 사용하지 않으면 커뮤니티와 도구는 결코 실현되지 않을 것입니다. 출혈이 없습니다.

내가 고려하지 않은 다른 함정은? 아니면 내가 언급 한 함정을 반박 할 사람이 있습니까? 나는 이것이 중요한 토론이라고 생각하며이 공개 포럼에서 업계의 F # 채택을 높이는 데 많은 반대 의견을 듣고 싶습니다.

Scheme, Lisp 또는 Haskell과 같은 다른 기능 언어에 대한 검색이 재개됩니다. 많은 사람들이 학교에서 이것들을 배우고 이력서를 가지고 있습니다. 나는 그들 중 많은 사람들이 F #을 배우는 것을 신경 쓰지 않을 것이라고 확신합니다. 방과 후에 사용한 적이 없어도 이력서에 Scheme이 있으며 F # 관련 직업도 관심을 끌 것입니다.

내가 고려하지 않은 다른 함정은?

실제로 사람들이 보는 주된 실수는 F #을 작업에 대한 잘못된 도구 인 문제에 강제로 사용하려고한다는 것입니다.

아니면 내가 언급 한 함정을 반박 할 사람이 있습니까?

그것들은 어느 정도 분명한 관심사이지만 어느 정도 궁금합니다.

예를 들어, F # 코드 작업을하려면 모든 사람이 F #을 배워야한다고 말합니다. 사실이지만 이것은 실제로 큰 문제는 아닙니다. FPF 학습은 WPF, Silverlight 또는 TPL 학습보다 중요하지 않습니다. 저는 현재 30 명의 개발자들에게 런던에서 클라이언트를 위해 F #을 사용하는 방법을 가르치고 있습니다. 그리고 몇 주 후에 12 명 정도가 F # 코드를 풀 타임으로 일하고 있었고 첫 제품 (정시 및 예산 내)을 배송했습니다! )는 몇 개월 후에 거의 전적으로 F #으로 작성되었습니다. 실제로 F #보다 Silverlight의 기술적 인 어려움이 더 많았고 Silverlight의 기술 지원이 F #보다 훨씬 나빴습니다.

사용 가능한 F # 프로그래머의 비교적 작은 풀을 참조하지만 F #을 쉽게 얻을 수 있다는 점을 고려할 때 이것이 중요한 문제라고 생각하지 않습니다. 나는 당신이 있다면 많은 것을 고용해야한다고 의심한다. 내 고객은 프로그래머가 100 명 이상인 두 명의 F # 직원을두고 있으며 F # 사용을 시드하고 감독하는 일을합니다.

세 번째이자 마지막 관심사는 커뮤니티 지원 감소, C # 솔루션 용 Googling 대 F # 및 타사 도구 지원에 관한 것입니다. 다시, 나는 이것들이 실제로 문제가되는 것을 발견하지 못했다. F #의 측정 단위에 대한 의견과 함께 fsbugs에게 전자 메일을 보냈으며 24 시간 이내에 연구원이 내 해석이 왜 틀 렸으며 그것이 어떻게 작동하는지에 대한 자세한 설명으로 응답했습니다. 나는 Anders Hejlsberg ;-)에서 그것을 얻지 못했습니다. Google은 항상 솔루션을 찾고 C #, VB 또는 IronPython으로 작성된 솔루션을 찾았지만 3 년 동안 F # 산업을 사용하면 솔루션을 F #으로 변환하는 것이 쉽지 않은 단일 인스턴스 만 불러올 수 있습니다. 사실, 최근에는 데이터 직렬 변환기 C # 샘플을 MSDN에서 F #으로 변환했으며 5 배 더 짧았습니다. 마지막으로 NUnit과 같은 도구에서 F # 지원에 대해 언급했습니다. 한동안 문제없이 F #에서 NUnit을 사용했습니다. 이들은 C # 도구가 아닌 .NET 도구입니다.

사례 연구 : 현재 고객은 단위 테스트를 위해 NUnit을 사용하고있을뿐 아니라 BDD 용 SpecFlow에 대한 기술적으로 탁월한 대안으로 NUnit 위에 F #에 TickSpec 을 구축 했습니다 . 필자는 TickSpec이 SpecFlow의 작은 크기이며 더 많은 기능을 제공한다는 점을 보여주었습니다. 또한 이전 F # 경험이없는 (및 이전의 기능적 프로그래밍 경험이없는) 작업중인 일부 개발자가 F # + TickSpec을 사용하면 문제를 쉽게 해결할 수 있기 때문에 관련 프로젝트에서 문제없이 정확하게 사용하기 시작했습니다. 문제.

FWIW, 나는 클라이언트에게 F #을 배우는 많은 개발자들과 잘 어울리는 F # .NET 저널에 무료 사이트 구독을주었습니다 .

HTH!

첫 번째 요점에서 알 수 있듯이 F #을 모르는 프로그래머는 코드베이스의 F # 부분에서 작업 할 수 없습니다. 그러나 F #으로 전체 코드베이스를 다시 작성하지 않아도 코드를 사용할 때 이점을 얻을 수 있습니다. 가장 큰 이점이있는 부분을 다시 작성하면됩니다. F #이 C #과 실제로 잘 작동한다는 사실은 특정 부품을 조각하고 F # 어셈블리를 만들기가 비교적 쉬워야합니다.

엔지니어가 기존의 3 계층 응용 프로그램을 개발하도록했다면 SQL, HTML, Javascript, CSS 등에 대한 깊은 지식이 필요하다고 주장하지는 않을 것입니다. 대신 자연스럽게 일부 전문가가 작업하게됩니다 응용 프로그램의 다른 부분에. 따라서 응용 프로그램의 한 부분에 새로운 언어를 추가하는 것이 너무 큰 장애물이라고 생각하지 않습니다. 또한 코딩 표준 및 기타 관행을 사용 하여 깊은 F # 배경이없는 엔지니어도 F # 코드를 읽을 수 있도록 할 수 있습니다 .

사용하는 언어에 F #을 추가 할 때의 함정에는 새로운 기술을 도입 할 때의 함정이 포함됩니다. 이점에 관계없이 일부 팀이 배우기를 원치 않거나 유연하지 않은 경우 F # 프로젝트를 수행 할 수 없습니다. 그럼에도 불구하고 팀의 공룡이 새로운 기술의 채택을 막을 수있게하면 회사가 파멸 될 것입니다.

내가 개인적으로 경험 한 유일한 함정은 다음과 같습니다.

1. 디버깅시 어려움. 명령문 기반 언어를 위해 설계된 디버거에서 식 기반 프로그램의 실행 흐름을 따르는 것은 까다로울 수 있습니다.

2. 실망스러운 지능. 필요할 때 자동 완성 기능이 정확하게 작동하지 않습니다. Microsoft는 백그라운드 파서를 내결함성이 있도록 노력해야합니다.

3. 들여 쓰기에 민감한 구문을 사용하면 코드를 복사하여 붙여 넣거나 다시 포맷하기가 어렵습니다.

4. 리팩토링 부족.

5. F # (코드 접기, 깊이 채색)에 대한 기존의 편리한 VS 확장 중 일부는 약간 느려서 타이핑 경험이 약간 좌절됩니다.

제 생각에는 이러한 문제 중 어느 것도 쇼 스토퍼가 아니며 당분간 그와 함께 살 수 있습니다. 언어보다 도구를 개선하고 수정하기가 더 쉽습니다.

F #으로 글을 쓸 수있는 새로운 프로그래머를 고용하는 것이 어려울 것이라는 당신의 두려움은 매우 흔하지 만 제 생각에는 정당하지 않습니다. 코딩 지침을 작성하려면 C #의 다음 기능 중 하나에 대해 조언하거나 금지하십시오. yield return, LINQ to objects, lambdas, 향후 async?

이러한 기능이 더 나은 코드를 작성하는 데 도움이된다고 생각한다면 F #을 삼가야 할 이유가 없습니다. 이 언어는 부드럽고 신중하게 이러한 기능을 지원하므로 C #은 레거시 때문에 실제로 할 수 없습니다.

팀이 내가 언급 한 기능의 기본 개념을 이해하기에 충분히 똑똑하다면 F #에서 우수한 프로그래머가되기 위해 필요한 모든 것을 갖추고 있습니다. C # 1.0 이후에 도입 된 기능을 사용할 수 없거나 사용하지 않으려는 사람을 고용 하시겠습니까?

나는이 정확한 상황을 생각했다.

이것이 내가 팀을 위해 계획 한 것입니다.

• C #과 F #을 혼합하면 대부분의 코드 기반에 C #을 사용하여 수행 할 수 있습니다. 무거운 데이터 처리 가 필요한 경우 F #에 관련 함수를 작성하고 dll 안에 넣거나 참조하십시오. 여기 예

• 위의 방식으로 기존 코드베이스를 천천히 리팩터링하십시오.

• 모든 코드 가 작동 할 필요는 없습니다 .

• 주말 동안 팀에서 Haskell, LISP 의 기초 를 배우도록하십시오 .

• 오일러 프로젝트 퍼즐 을 풀 면서 F #을 배우도록하십시오 (F #을 배울 때 많은 도움이되었습니다). 다시 말하지만 이것은 주말 동안 또는 "훈련"을 위해 하루를 따로 떼고 싶다면 근무 시간 동안해야 할 일입니다.

1) 기능적 언어를 배우면 프로그래머로서의 전반적인 능력이 향상되지만 배우고 개선하려는 사람들에게만 적용됩니다. 모든 프로그래머가 더 나아지기를 원하거나 업무 환경의 변화를 원하는 것은 아닙니다 (팀을 알고 있습니다).

2) 나는 이것으로 논쟁 할 수 없다. .net 라이브러리를 이미 알고 있기 때문에 새로운 언어의 6 개월 학습 곡선을 지불해야합니다.

3) C #보다 작은 커뮤니티 지원에는 웹에 게시하는 고도로 숙련 된 활동적인 F # 개발자가 있습니다. 대부분의 언어 지원은 라이브러리 지원이며 .NET에 대한 큰 지원이 있다는 것을 잊지 마십시오.

여기서 천 파운드 고릴라는 위험 관리입니다. "나는 최첨단이 될 수 있지만 최첨단이 될 수는 없습니다." F #이 최첨단이 아니라고 주장합니다. VS2010과 함께 릴리스되었으며 Microsoft에서 직접 지원합니다. 출혈 가장자리는 "베타"이며 Microsoft의 책임에 대한 책임을지지 않습니다.

실질적으로 IntelliSense 지원은 매우 부족합니다 .C #에서 제공되는 덜 정교한 자동 완성 기능으로 인해 유형 유추의 생산성 향상이 능가합니다.

잘못된 형식 유추로 인한 오류 메시지는 C #과 같은 언어에서보다 형식 주석을 제공하는 경향이 적기 때문에 초보자 (및 종종 자신과 같은 중급 사용자)의 경우 수정하는 데 시간이 더 오래 걸립니다.

F #에서는 OOP도 놀라운 방식으로 부족합니다. 예를 들어 중첩 형식 / 클래스는 지원되지 않습니다. F #에서는 할 수없는 일이 C #에서 할 수 있기 때문에 슬프게도 코드를 이식 할 때는주의해야합니다.

마지막 으로, F # 커뮤니티 의 규모 와 품질은 실망 스럽습니다. 웹에있는 많은 F # 정보는 이전 버전 용이거나 비정형 적이거나 성능 저하 또는 부정확 한 잘못된 것입니다. 그렇다면 기존 정보 요약에 불과한 뉴스 레터에 엄청난 돈을 청구하는 사람들이 있습니다.

나 자신은 작업 프로젝트에 C #을 사용하고 내 물건에는 F #을 사용합니다. 불행히도 F #을 좋아하는 한, 어떻게 / 어떻게 부서 지는지 예측하기가 어렵습니다.

주된 문제는 항상 유지 보수성입니다.

Scheme에서 코딩하고 싶지만 다음 관리자가 나를 사냥하고 고문하고 싶을 것입니다.

가장 먼저해야 할 일은 팀원에게 F # 도입에 대한 느낌을 물어 보는 것입니다. 그들이 아이디어를 좋아한다면 모든 것이 훨씬 매끄럽게 진행됩니다.