Ac # dev có nên chuyển sang VB.net khi hỗn hợp ngôn ngữ nhóm không?


14

Gần đây tôi đã tham gia một nhóm phát triển mới, nơi các tùy chọn ngôn ngữ được trộn lẫn trên nền tảng .net.

  • Nhà phát triển 1: Biết VB.net, không biết c #

  • Nhà phát triển 2: Biết VB.net, không biết c #

  • Nhà phát triển 3: Biết c # và VB.net, thích c #

  • Dev 4: Knows c # và VB6 (VB.net nên khá dễ nhận), thích c #

Dường như với tôi rằng các nhà lãnh đạo tư tưởng trong không gian .net là c # dev gần như phổ biến. Tôi cũng nghĩ rằng một số công cụ của bên thứ 3 không hỗ trợ VB.net nhưng khi tôi bắt đầu tìm hiểu về nó, tôi đã không tìm thấy bất kỳ ví dụ hay nào.

Tôi muốn đưa cả nhóm vào c # nhưng nếu không có lý do chính đáng nào để buộc vấn đề này ngoài sở thích thì tôi không nghĩ đó là lựa chọn đúng đắn.

Có bất kỳ lý do nào tôi nên dẫn mọi người ra khỏi VB.net không?


5
Độ dài chỉ trong VB sẽ đưa bạn đến C # ...
Aaron McIver

13
Âm thanh với tôi như nhóm phát triển của bạn thiếu một số lãnh đạo nghiêm túc. Tại sao người quản lý của bạn không giải quyết vấn đề này?

2
Tại sao bạn lại trôi dạt về phía VB .Net? Từ sơ đồ của bạn ở trên, 2 nhà phát triển với bất kỳ kỹ năng nào đều biết C # và những người khác không biết bất kỳ .Net nào cả. Chắc chắn sẽ là tốt nhất để mang lại cho những người không biết ngôn ngữ tăng tốc với C # vì hai nhà phát triển khác đã có kỹ năng c # để phát triển?

15
Dưới cái mũ trùm đầu họ có thể giống nhau, nhưng cú pháp VB là em gái bị mụn cóc xấu xí đứng cạnh cô em gái C # nóng bỏng, được tắm rửa tốt. Cú pháp của nó chỉ nên được ghi nhớ như một điểm tham chiếu đến máu chảy ra từ nhiều nhà phát triển khi họ nhìn vào phiên bản địa ngục của chính họ. VB nên được trung lập, bị giết và bị bỏ lại bên đường để thối trong cái nóng mùa hè ấm áp. Nắm bắt cú pháp đẹp hơn và trốn tránh mà mẹ thiên nhiên đã chọn để quên đi. Chọn một cách khôn ngoan.
Moo-Juice

2
Nếu tôi không nhầm, On Error Resume Next là để hỗ trợ kế thừa. Hãy thử các khối Catch tồn tại trong VB.Net ... vì nó .Net.
Tony Abrams

Câu trả lời:


2

Không có lý do thực sự thuyết phục để buộc ai đó thay đổi ngôn ngữ trừ khi một tính năng sẽ đặc biệt hữu ích hoặc tiết kiệm thời gian cho (các) dự án của bạn. Cả hai sẽ biên dịch xuống IL và thực hiện tương đương (giả sử Option Strictlà trong VB.NET ... nếu không, bạn có thể phải chịu các hình phạt cho ràng buộc muộn). Mọi thứ khác thực sự là ưu đãi (không bỏ qua điều đó, nhưng nó không phải là một số liệu khách quan).

Tôi sẽ đề nghị xem xét danh sách công việc trong khu vực của bạn và xem ngôn ngữ nào phổ biến hơn cả về nguồn cung công việc (tức là nhóm lao động cho cả hai ngôn ngữ). Xem cái nào sẽ cung cấp cho bạn một nhóm lao động lớn hơn hoặc tốt hơn có lẽ sẽ là số liệu hấp dẫn nhất của bạn.


Tôi đồng ý với những gì bạn nói về danh sách công việc địa phương. Tôi nghĩ một điều dễ bị bỏ qua là nhóm tài năng tiềm năng và hiệu quả của việc chọn một ngôn ngữ này có thể có trong các nỗ lực tuyển dụng trong tương lai của bạn.
jjr2527

7

May mắn thay, câu trả lời rất đơn giản: không có ngôn ngữ "tốt nhất". Tất cả các ngôn ngữ .NET sử dụng, tại thư mục gốc của chúng, chức năng từ tập hợp các lớp được cung cấp bởi .NET Framework. Do đó, mọi thứ bạn có thể làm trong VB.NET bạn có thể làm trong C # và ngược lại. Sự khác biệt duy nhất giữa các ngôn ngữ chỉ là một cú pháp cú pháp.

Các lập trình viên C ++, Java và J ++ sẽ thích cú pháp ngắn gọn, vô nghĩa của C #. Các lập trình viên Visual Basic (VB) có thể thích gắn bó với ma quỷ mà họ biết cách tiếp cận ngôn ngữ tự nhiên, giả, không phân biệt chữ hoa của Visual Visual .NET. Nếu bạn có lập trình viên VB và họ là những lập trình viên thực thụ (Xem BẬT tùy chọn BẬT), bạn sẽ nhận được kết quả tương tự. VB dài dòng hơn .... C # là một buster bóng với độ nhạy trường hợp.


Đúng, cả hai có thể làm 98% mà người kia có thể NHƯNG có rất nhiều sợi dây để treo mình trong VB. On Error Resume Nextmột mình sẽ gửi cho tôi chạy về phía C #. Các Modulekhái niệm cũng rất nguy hiểm. Nó tương tự như static classtrong C # nhưng ... mọi thứ trong đó đều có thể truy cập toàn cầu mà không cần tham chiếu đến lớp cha và tự động tĩnh với bất kỳ dấu hiệu nào khác ... ngoại trừ lớp cha là Mô-đun ...!
Paul Sasik

6
Xin lỗi cho nitpick nhưng điều này không đúng. Ví dụ: làm thế nào bạn sẽ viết một bộ lọc ngoại lệ trong C #? blog.msdn.com/b/clrteam/archive/2009/08/25/ từ

@LukeH Để thêm bộ lọc ngoại lệ vào C #, chúng ta có thể xây dựng một hàm trong VB hoặc IL, sau đó gọi nó trong C #: D

4
@Anna: Do đó bác bỏ tuyên bố của bạn rằng "mọi thứ bạn có thể làm trong VB.NET bạn có thể làm trong C #" .

2
Có khá nhiều điều mà bạn đơn giản không thể làm trong VB.Net mà bạn có thể làm trong c # - xem thêm: stackoverflow.com/q/2362381/50447
Rowland Shaw

5

Thành thật mà nói, một nhóm Dev nên sử dụng cùng một ngôn ngữ hoặc ít nhất là biết cùng một ngôn ngữ.

Điều này sẽ hỗ trợ đào tạo chéo và hỗ trợ giữa các ứng dụng khác nhau mà nhóm phát triển tạo ra.

Cuối cùng, VB vs C # hoàn toàn là một trận chiến của các sở thích, nhưng nhóm nên ở cùng một trang với cái mà họ sẽ sử dụng hoặc hỗ trợ.


5

Ac # dev có nên chuyển sang VB.net khi hỗn hợp ngôn ngữ nhóm không?

Nhà phát triển nên sử dụng ngôn ngữ .NET là tiêu chuẩn cho nhóm. IMO, nên có một ngôn ngữ được sử dụng (trừ khi có thể thực hiện một trường hợp cực kỳ hấp dẫn).

Có bất kỳ lý do nào tôi nên dẫn mọi người ra khỏi VB.net không?

Tôi nghĩ rằng hầu hết mọi người ở đây thích C # nhưng đây không phải là một câu hỏi kỹ thuật như là một quyết định chính trị hoặc kinh doanh. Quyết định sử dụng ngôn ngữ .NET nào và sau đó sử dụng ngôn ngữ đó. Bây giờ rõ ràng có một loạt các yếu tố để xem xét:

  • Có một codebase hiện có? Ngôn ngữ nào là phần lớn của nó được viết bằng?
  • Các nhà phát triển VB.NET có thể dễ dàng chọn C # không? Họ có muốn không?
  • Liệu đầu tư vào đào tạo / đào tạo C # có hợp lý không?
  • Làm thế nào bất kỳ chuyển đổi ngôn ngữ sẽ tác động đến việc cung cấp hiện có?

+1 để suy nghĩ về nhóm, thay vì sở thích cá nhân
MarkJ

4

Trên thực tế, VB.NET có một vài tính năng mà C # hiện tại không có: XML bằng chữ và cú pháp truy vấn để sử dụng phương thức Tổng hợp trong LINQ.


1
VB.NET cũng không có trình lặp (tức là từ khóa Yield trong C #).
atconway


2

Tôi đã ở trong một tình huống rất giống vào năm 2003 mà bạn đang ở hiện tại. Tôi đang quản lý một nhóm chuyển sang ASP.NET từ ASP Classic. Hầu hết nhóm của chúng tôi đã có kinh nghiệm với VBScript là ngôn ngữ defacto cho ASP, nhưng khoảng một nửa nhóm ủng hộ C # mặc dù đường dẫn di chuyển phức tạp hơn một chút từ ASP / VBScript. Cuối cùng, tôi đã chọn VB.NET, nhưng nhìn lại, tôi thực sự ước mình đã đi theo con đường C #.

Vào kỷ niệm 5 năm của quyết định đó, tôi đã viết một bài viết trên blog về lý do của mình để đưa ra quyết định và cố gắng cung cấp lợi ích của sự nhận thức của tôi cho các nhà quản lý phát triển khác đang cố gắng thực hiện cuộc gọi tương tự. Đây là một liên kết đến bài viết:

"Hồi tưởng của người quản lý về quyết định C # so với VB.NET"

Câu chuyện dài, đối với những người không muốn đọc toàn bộ bài viết: Tôi không nghĩ dự án tồi tệ hơn khi chọn VB.NET trên C # và có lẽ nó đã giúp chúng tôi tiết kiệm rất nhiều thời gian trong thời gian ngắn. Vấn đề lớn nhất là thực sự với tuyển dụng. Tôi rất vui khi thuê một lập trình viên C # hoặc VB.NET làm việc bằng một trong hai ngôn ngữ. Họ thực sự không khác biệt đáng kể. Tuy nhiên, dù xứng đáng hay không, VB.NET có một sự kỳ thị khiến một số nhà phát triển giỏi tránh các công việc mà họ biết họ sẽ làm việc với nó như ngôn ngữ chính.


Là một lập trình viên C #, tôi đã làm việc trên các dự án sử dụng VB.NET. Nhưng thường thì các lập trình viên VB.NET không biết họ đang làm gì, không có bằng Comp Sci và viết các phương thức với 100 dòng mã. Vì vậy, tôi nghiêng về bỏ qua bất kỳ quảng cáo công việc nào yêu cầu VB.NET.
Ian

1

Tôi sẽ nghiêng về C # vì nó ít dài dòng hơn và theo kinh nghiệm của tôi thì phổ biến hơn nhiều trên internet. Tôi cũng sẽ tranh luận rằng C # hoặc VB.NET dễ học và nhanh chóng, đến mức không đáng kể và không đáng kể. Mặt khác, .NET framework rất lớn và là một sinh vật không ngừng phát triển. Làm chủ .NET mất nhiều năm, nhưng thành thạo C # hoặc VB.NET có thể mất vài tháng hoặc ít hơn.


0

Tôi nghĩ rằng @Anna Karin có một điểm tốt, vì vậy bạn không cần phải lo lắng về các thư viện. Ít nhất, tôi không thể nhớ bất kỳ cái nào chỉ hoạt động với c # chứ không phải với vb.net.

Một điểm quan trọng khác là nó sẽ biến việc kiểm tra mã trở nên khó khăn hơn giữa các thành viên trong cùng một nhóm nếu họ làm việc với các ngôn ngữ khác nhau. Tôi nghĩ là một ý tưởng tốt nhất sử dụng một số ngôn ngữ commom, để giảm ma sát trong giao tiếp.


0

Mặc dù tôi đồng ý với câu trả lời trước đó rằng .NET nên có cùng tính năng, nhưng điều này không phải lúc nào cũng đúng, nhưng đủ gần để nếu bạn có một dự án đơn giản thì điều đó không thành vấn đề.

Lý do chính tôi sẽ đưa ra để chuyển sang C # trong toàn đội là vì đó là ngôn ngữ mà hầu hết các ví dụ đều có và hầu hết các dự án nguồn mở đều xuất bản mã nguồn trong C #. Vì vậy, nếu nhóm của bạn không thể sử dụng tài nguyên như vậy, bạn có thể tự giới hạn bản thân một cách không cần thiết.


0

C # và VB.NET dựa trên nền tảng .NET; điều quan trọng đối với các nhà phát triển làm việc trong .NET là phải biết .NET, các nguyên tắc, kỹ thuật, mẫu ... Trong trường hợp đó, việc chuyển đổi giữa các ngôn ngữ sẽ không thành vấn đề - chủ yếu là về cú pháp. Trong một nhóm hỗn hợp, có lẽ tất cả bọn họ nên cố gắng học cả hai ngôn ngữ (nó không phải là vấn đề lớn), nhưng nó có thể quan trọng đối với sự hợp tác trong tương lai giữa các thành viên của nhóm.


0

Tôi muốn nói rằng một lợi thế của việc mọi người sử dụng cùng một ngôn ngữ là điều đó có nghĩa là bất kỳ nhà phát triển nào cũng có thể làm việc trên bất kỳ phần nào của mã.

Ngoài ra, VB.NET và C # chỉ khác nhau theo cú pháp trong .NET. Và mã được viết bằng cả hai ngôn ngữ có thể cùng tồn tại trong cùng một dự án.


0

Tôi sẽ đi với C # vì:

  • nó gần gũi hơn với Java và C ++ (ngôn ngữ thường được dạy trong các khóa học CS).
  • có nhiều tài nguyên trên Internet bằng C # hơn trong VB (từ những gì tôi đã thấy ngoài đó).
  • cơ hội cao hơn để tìm / thuê các nhà phát triển khác biết C # tốt hơn VB (từ những gì tôi đã thấy trong công ty của mình) để duy trì dự án.

0

Ý kiến ​​của tôi là sẽ cho phép phát triển dựa trên hợp đồng với giao diện và nhà phát triển sẽ có thể mã hóa một lớp bằng bất kỳ ngôn ngữ nào anh ta muốn và có thể tách các lớp cấp thấp / cấp cao trong các hội đồng khác nhau. Miễn là các lớp tôn trọng giao diện được yêu cầu và thực hiện yêu cầu thì sẽ có ít vấn đề.


0

Tôi đồng ý với nhiều câu trả lời khác ở đây. Tôi đã là một phần của hai đội phải đưa ra quyết định này. Trong cả hai ban đầu họ quyết định rằng các nhà phát triển có thể chọn vì hai ngôn ngữ này hoạt động cùng nhau. Tuy nhiên, trong năm đầu tiên, cả hai đều ước họ đã chọn C # và đưa ra một yêu cầu mới là tất cả các dự án mới đều nằm trong C #.


0

Lý do nên sử dụng C #:

  • Nó đã làm cho hai nhà phát triển của bạn hạnh phúc cho đến nay và có thể làm hài lòng hai người kia một khi họ học được nó.
  • Bạn có kế hoạch thuê thêm các nhà phát triển tại một số điểm và muốn tránh đám đông "20 năm kinh nghiệm VB".
  • Bạn yêu thích niềng răng xoăn.
  • Bạn yêu cuộc sống.

Lý do nên sử dụng VB.NET:

  • Hai nhà phát triển không biết C # hoàn toàn từ chối học nó.
  • "Lấp ló trên con đường ít kháng cự nhất" là phương châm của công ty bạn.
  • Có một cơ sở mã VB lớn hiện có không thể cập nhật.
  • Bạn đang ở trong một cú đá HP Lovecraft, và than thở về việc thiếu "nỗi kinh hoàng" trong cuộc sống hàng ngày của bạn.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.