Cạm bẫy trong thế giới thực khi giới thiệu F # vào một nhóm kỹ thuật và cơ sở mã hóa lớn [đã đóng cửa]

Tôi là CTO của một công ty phần mềm với một cơ sở mã lớn hiện có (tất cả C #) và một nhóm kỹ thuật khá lớn. Tôi có thể thấy các phần nhất định của mã sẽ dễ dàng hơn để viết trong F #, dẫn đến thời gian phát triển nhanh hơn, ít lỗi hơn, triển khai song song dễ dàng hơn, v.v., về cơ bản tăng năng suất chung cho nhóm của tôi. Tuy nhiên, tôi cũng có thể thấy một số cạm bẫy về năng suất khi giới thiệu F #, cụ thể là:

1) Mọi người đều phải học F # và nó không tầm thường như chuyển từ, giả sử, Java sang C #. Các thành viên trong nhóm chưa học F # sẽ không thể làm việc trên các phần F # của cơ sở mã.

2) Nhóm lập trình viên F # đáng tin cậy, tính đến thời điểm hiện tại (tháng 12 năm 2010) là không tồn tại. Tìm kiếm các kỹ sư phần mềm khác nhau tiếp tục cơ sở dữ liệu cho "F #", cách ít hơn 1% hồ sơ có chứa từ khóa.

3) Hỗ trợ cộng đồng tính đến thời điểm hiện tại (tháng 12 năm 2010) ít khả dụng. Bạn có thể google gần như bất kỳ vấn đề nào trong C # và tìm ai đó đã xử lý nó, không phải như vậy với F #. Hỗ trợ công cụ của bên thứ ba (NUnit, Resharper, v.v.) cũng sơ sài.

Tôi nhận ra rằng đây là một chút Catch-22, tức là nếu những người như tôi không sử dụng F # thì cộng đồng và các công cụ sẽ không bao giờ thành hiện thực, v.v. Nhưng, tôi đã có một công ty để điều hành và tôi có thể chặt chẽ nhưng không chảy máu mép.

Bất kỳ cạm bẫy nào khác tôi không xem xét? Hoặc bất cứ ai quan tâm để bác bỏ những cạm bẫy mà tôi đã đề cập? Tôi nghĩ rằng đây là một cuộc thảo luận quan trọng và rất thích nghe những phản biện của bạn trong diễn đàn công cộng này có thể giúp ích rất nhiều để tăng sự chấp nhận F # theo ngành.

Tìm kiếm sơ yếu lý lịch cho các ngôn ngữ chức năng khác như Scheme, Lisp hoặc Haskell. Rất nhiều người học những điều này ở trường và có chúng trong sơ yếu lý lịch của họ; Tôi chắc rằng nhiều người trong số họ sẽ không học F #. Tôi có Scheme trong sơ yếu lý lịch của mình mặc dù tôi chưa bao giờ sử dụng nó sau giờ học và một công việc liên quan đến F # có lẽ cũng khiến tôi chú ý.

Bất kỳ cạm bẫy nào khác tôi không xem xét?

Trong thực tế, sai lầm chính mà tôi thấy mọi người mắc phải là cố gắng sử dụng F # cho các vấn đề trong đó nó là công cụ sai cho công việc.

Hoặc bất cứ ai quan tâm để bác bỏ những cạm bẫy mà tôi đã đề cập?

Tất cả chúng rõ ràng là mối quan tâm hợp lệ ở một mức độ nào đó nhưng tôi đặt câu hỏi ở mức độ nào.

Ví dụ, bạn nói rằng mọi người sẽ phải học F # để làm việc với mã F #. Mặc dù đúng, đây không phải là một vấn đề lớn trong thực tế. Học F # không có ý nghĩa hơn học WPF, Silverlight hoặc TPL. Tôi đang dạy cho khoảng 30 nhà phát triển cách sử dụng F # cho một khách hàng ở Luân Đôn ngay bây giờ và khoảng một chục người đã làm việc toàn thời gian với mã F # chỉ sau vài tuần và họ mới giao sản phẩm đầu tiên của họ (đúng giờ và trong ngân sách! ) được viết gần như hoàn toàn bằng F # chỉ sau vài tháng. Trên thực tế, họ gặp nhiều khó khăn về kỹ thuật với Silverlight hơn F # và họ thấy sự hỗ trợ công nghệ cho Silverlight kém hơn nhiều so với F #.

Bạn tham khảo nhóm tương đối nhỏ của các lập trình viên F # có sẵn, nhưng, một lần nữa, đưa ra cách dễ dàng để nhận F # Tôi không nghĩ rằng đây là một mối quan tâm đáng kể. Tôi nghi ngờ bạn sẽ cần phải thuê nhiều, nếu có. Khách hàng của tôi có hai người F # cho hơn 100 lập trình viên và công việc của chúng tôi là gieo mầm và giám sát việc sử dụng F #.

Mối quan tâm thứ ba và cuối cùng của bạn liên quan đến sự hỗ trợ cộng đồng ít hơn, Googling cho các giải pháp C # so với F # và hỗ trợ công cụ của bên thứ ba. Một lần nữa, tôi không thấy những vấn đề này trong thực tế. Tôi đã gửi email cho fsbugs với nhận xét về các đơn vị đo lường trong F # và nhận được phản hồi trong vòng 24 giờ từ nhà nghiên cứu đã phát minh ra nó với lời giải thích chi tiết về lý do giải thích của tôi sai và tại sao nó hoạt động theo cách của nó. Tôi chưa bao giờ có được điều đó từ Anders Hejlsberg ;-). Tôi tìm kiếm các giải pháp mọi lúc và tìm thấy chúng được viết bằng C #, VB hoặc thậm chí IronPython, nhưng, trong 3 năm sử dụng F # ngành, chỉ có thể nhớ lại một trường hợp duy nhất trong đó việc dịch giải pháp sang F # không phải là chuyện nhỏ. Trên thực tế, gần đây tôi đã chuyển đổi mẫu C # tuần tự hóa dữ liệu từ MSDN sang F # và nó ngắn hơn 5 ×. Cuối cùng, bạn đã đề cập đến hỗ trợ F # trong các công cụ như NUnit khi chúng tôi ' đã sử dụng NUnit từ F # mà không gặp vấn đề gì. Đây là các công cụ .NET, không phải công cụ C #.

Nghiên cứu điển hình : Khách hàng hiện tại của tôi không chỉ sử dụng NUnit để thử nghiệm đơn vị mà họ đã xây dựng TickSpec trong F # trên NUnit như một giải pháp thay thế vượt trội về mặt kỹ thuật so với SpecFlow cho BDD. Tác giả đã đưa ra quan điểm cho tôi thấy rằng TickSpec là một phần rất nhỏ kích thước của SpecFlow và cung cấp nhiều tính năng hơn. Hơn nữa, một số nhà phát triển đang làm việc không có kinh nghiệm F # trước đó (và, tôi tin rằng, không có kinh nghiệm lập trình chức năng trước đó) đã chọn nó và bắt đầu sử dụng nó trong các dự án không liên quan mà không có vấn đề chính xác vì F # + TickSpec giúp giải quyết dễ dàng hơn các vấn đề.

FWIW, tôi đã cho khách hàng của mình đăng ký trang web miễn phí vào Tạp chí F # .NET của chúng tôi , điều này rất phù hợp với nhiều nhà phát triển học F #.

HTH!

Như bạn nhận ra ở điểm đầu tiên, các lập trình viên của bạn không biết F # không thể làm việc trên phần F # của cơ sở mã của bạn. Tuy nhiên, bạn không cần phải viết lại toàn bộ cơ sở mã của mình trong F # để đạt được lợi thế từ việc sử dụng nó - chỉ cần viết lại các phần mà bạn sẽ thấy lợi ích lớn nhất. Thực tế là F # tương tác thực sự tốt với C # sẽ giúp việc khắc các bộ phận nhất định và tạo ra các bộ phận F # từ chúng tương đối dễ dàng.

Nếu bạn có các kỹ sư của bạn làm việc trên một ứng dụng 3 tầng truyền thống, có lẽ bạn sẽ không khăng khăng rằng tất cả họ cần có kiến ​​thức sâu về SQL, HTML, Javascript, CSS, v.v. Thay vào đó, bạn tự nhiên có một số chuyên gia làm việc trên các phần khác nhau của ứng dụng. Do đó, tôi không nghĩ rằng việc thêm một ngôn ngữ mới cho một phần trong ứng dụng của bạn sẽ là một trở ngại quá lớn. Hơn nữa, bạn có thể sử dụng các tiêu chuẩn mã hóa và các thực tiễn khác để cố gắng đảm bảo rằng mã F # của bạn có thể đọc được ngay cả bởi các kỹ sư không có nền tảng F # sâu.

Những cạm bẫy của việc thêm F # vào các ngôn ngữ bạn sử dụng bao gồm những cạm bẫy của việc giới thiệu bất kỳ công nghệ mới nào. Bất kể lợi ích là gì, nếu một số nhóm của bạn không muốn hoặc không đủ linh hoạt để học, họ sẽ không thể làm việc trên các dự án F #. Tuy nhiên, nếu bạn để khủng long trong nhóm của bạn ngăn chặn việc bạn áp dụng các công nghệ mới, công ty của bạn sẽ bị tiêu diệt.

Những cạm bẫy duy nhất tôi đã trải nghiệm cá nhân là:

1. Khó khăn khi gỡ lỗi. Theo dòng thực thi của một chương trình dựa trên biểu thức trong trình gỡ lỗi được thiết kế cho các ngôn ngữ dựa trên câu lệnh có thể khó khăn.

2. Bực bội nội tâm. Tự động hoàn thành dừng hoạt động chính xác khi bạn cần. Microsoft phải làm việc để làm cho trình phân tích cú pháp nền có khả năng chịu lỗi cao hơn.

3. Cú pháp nhạy cảm thụt lề gây khó khăn cho việc sao chép-dán hoặc định dạng lại mã.

4. Thiếu tái cấu trúc.

5. Một số tiện ích mở rộng VS tiện lợi hiện có cho F # (mã gấp, tô màu sâu) hơi chậm, khiến trải nghiệm gõ hơi khó chịu.

Theo tôi, không có vấn đề nào trong số này là điểm dừng và tôi có thể sống với họ trong thời gian này. Các công cụ dễ dàng cải thiện và sửa chữa hơn các ngôn ngữ.

Nỗi sợ của bạn rằng việc thuê các lập trình viên mới có khả năng viết bằng F # sẽ khá khó khăn nhưng theo tôi là không chính đáng. Nếu bạn định viết hướng dẫn mã hóa, bạn có khuyên chống lại hoặc cấm bất kỳ tính năng nào sau đây trong C # : yield return, LINQ cho các đối tượng, lambdas, sắp tới asynckhông?

Nếu bạn tin rằng các tính năng này giúp viết mã tốt hơn, thì không có lý do gì để kiềm chế F #. Ngôn ngữ hỗ trợ các tính năng này một cách trơn tru và chu đáo, điều mà C # thực sự không thể làm được do di sản của nó.

Nếu nhóm của bạn đủ thông minh để hiểu các khái niệm đằng sau các tính năng tôi đã đề cập, họ có tất cả những gì họ cần để trở thành lập trình viên xuất sắc trong F #. Điều tương tự cũng xảy ra với các tân binh trong tương lai: Bạn sẽ thuê bất cứ ai không có khả năng hoặc không muốn sử dụng các tính năng được giới thiệu sau C # 1.0?

Tôi đã suy ngẫm về tình huống chính xác này.

Đây là những gì tôi lên kế hoạch cho nhóm của mình:

• Trộn C # với F #, điều này có thể được thực hiện bằng cách sử dụng C # cho phần lớn cơ sở mã. Khi cần xử lý dữ liệu nặng , hãy viết các hàm liên quan trong F # và đặt nó vào trong một dll hoặc tham chiếu nó. Ví dụ ở đây

• Từ từ tái yếu tố cơ sở mã hiện tại của bạn theo cách trên.

• Không phải tất cả các mã phải có chức năng.

• Yêu cầu nhóm của bạn tìm hiểu những điều cơ bản về Haskell, LISP vào cuối tuần .

• Cho họ học F #, bằng cách cố gắng giải các câu đố của Dự án Euler (điều đó đã giúp tôi rất nhiều khi tôi học F #). Một lần nữa, điều này nên được thực hiện vào cuối tuần, hoặc trong thời gian làm việc nếu bạn muốn dành một ngày để "đào tạo".

1) Học một ngôn ngữ chức năng sẽ tăng khả năng tổng thể của một số người như một lập trình viên, tuy nhiên điều này chỉ áp dụng cho những người muốn học hỏi và cải thiện. Không phải mọi lập trình viên đều muốn trở nên tốt hơn cũng như họ không muốn thay đổi trong môi trường làm việc của họ (biết nhóm của bạn.)

2) Tôi không thể tranh luận với điều này. Bạn sẽ phải trả tiền cho thời gian học 6 tháng của bất kỳ ngôn ngữ mới nào, tuy nhiên việc biết các thư viện .net sẽ loại bỏ các năm cần thiết để học các thư viện mới.

3) Hỗ trợ cộng đồng trong khi nhỏ hơn C # có khá nhiều nhà phát triển F # hoạt động có tay nghề cao đăng trên web. Đừng quên rằng hầu hết hỗ trợ ngôn ngữ là hỗ trợ thư viện và có sự hỗ trợ tuyệt vời cho .NET.

Con khỉ đột ngàn pound ở đây là quản lý rủi ro. "Tôi có thể cắt cạnh nhưng không chảy máu cạnh." Tôi cho rằng F # không bị chảy máu. Nó đã được phát hành với VS2010 và được Microsoft hỗ trợ trực tiếp. Chảy máu cạnh là "beta" và từ chối trách nhiệm từ Microsoft nói điều gì đó về việc không chịu trách nhiệm cho bất cứ điều gì.

Là một vấn đề thực tế, hỗ trợ IntelliSense khá thiếu - đến mức tăng năng suất của suy luận kiểu kém hơn so với tự động hoàn thành kém tinh vi có sẵn trong C #.

Các thông báo lỗi do suy luận kiểu sai cũng mất nhiều thời gian hơn để sửa cho người mới bắt đầu (và thường cho người dùng trung gian như tôi), đơn giản vì bạn ít có xu hướng cung cấp chú thích loại hơn so với ngôn ngữ như C #.

OOP cũng thiếu những cách đáng ngạc nhiên trong F #; ví dụ, không có hỗ trợ cho các loại / lớp lồng nhau. Bạn phải cẩn thận khi chuyển mã, bởi vì có một số điều bạn có thể làm trong C # mà bạn không thể làm trong F #, thật đáng buồn.

Cuối cùng nhưng không kém phần quan trọng, cả quy mô và chất lượng của cộng đồng F # đều gây thất vọng. Rất nhiều thông tin F # trên mạng là dành cho các phiên bản cũ hoặc đơn giản là không tốt lắm - không thành ngữ, hiệu suất kém hoặc không chính xác. Sau đó, có những người tính tiền rất lớn cho các bản tin mà phần lớn chỉ là các thông tin hiện có.

Bản thân tôi sử dụng C # cho các dự án công việc và F # cho công cụ của riêng tôi. Nhiều như tôi yêu F #, thật không may, thật khó để dự đoán làm thế nào / khi mọi thứ có thể sụp đổ.

Vấn đề chính là luôn duy trì.

Tôi rất thích viết mã trong Scheme, nhưng người bảo trì tiếp theo có lẽ sẽ muốn săn lùng tôi và tra tấn tôi.

Tôi muốn nói rằng điều đầu tiên bạn cần làm là hỏi các thành viên trong nhóm của bạn họ cảm thấy thế nào về việc giới thiệu F #. Nếu họ thích ý tưởng đó, mọi thứ sẽ suôn sẻ hơn nhiều nếu họ không.