2010-10-20 27 views
27

Tôi biết câu hỏi này có thể tương tự với những người khác nhưng thực sự tôi đang tìm kiếm lý do tại sao các nhà phát triển VB6 nên chuyển sang C#.Thuyết phục ứng dụng kế thừa VB6 nhà phát triển để thực hiện chuyển sang C#

Công ty của tôi gần đây đã phê duyệt dự án được viết bằng C#, vì vậy chúng tôi có rất nhiều lập trình VB.Net, tuy nhiên, chúng tôi có một số nhà phát triển ứng dụng cũ cũng có trong VB6. Chúng tôi có khung thời gian để viết lại các ứng dụng đó vào ứng dụng web .Net. Vì vậy, không có vấn đề gì họ sẽ phải học những thứ mới.

Một trong những nhà phát triển hôm nay đặc biệt hỏi "tại sao chúng ta nên chuyển sang C#?"

Tôi trả lời rằng cộng đồng phần lớn đã quyết định rằng C# là cách để đi với khoảng 80% các ví dụ trong C#. Tôi là một lập trình viên VB.Net và tôi rất vui khi cuối cùng đã cắt răng của mình trên C#, tuy nhiên, vì tôi quá mới, tôi không chắc mình có thể trả lời "tại sao?" câu hỏi. Lý do của tôi là nhiều hơn bởi vì tôi muốn tìm hiểu nó.

Vì vậy mà không giảm dần vào một câu VB C# Tôi thực sự tò mò nếu có bất kỳ tài nguyên mà tôi có thể gửi cho các nhà phát triển để bình tĩnh thần kinh của họ.

Rất mong nhận được ý kiến ​​của bạn!

Trả lời

24

Theo như sự di cư qua NET đi, muộn còn hơn không ! Theo như lời khuyên của tôi, số dặm của bạn có thể thay đổi, nó đáng giá mỗi xu bạn trả cho nó!

Cá nhân tôi tin rằng bạn đang đưa ra lựa chọn đúng. Bản năng đầu tiên cho các nhà phát triển VB là chuyển sang VB.NET. Nghe có vẻ hoàn toàn hợp lý, nhưng theo ý kiến ​​của tôi, đó là lựa chọn sai lầm. Bạn thực sự phải chia nhỏ lý do cho việc chuyển đổi thành hai loại: Tại sao chuyển sang .NET, và tại sao chuyển sang C#?

Tại sao chuyển sang .NET trên VB6:

  • Multithreading trong VB6 là về mặt kỹ thuật có thể từ góc độ lập trình, nhưng chỉ là về bất khả thi nếu bạn muốn sử dụng IDE.

  • Tôi không tin rằng bạn có thể tạo ứng dụng gốc 64 bit trong VB6. Quy tắc đó rất nhiều.

  • Không có cải tiến mới nào được thực hiện cho VB6.

  • OK, có rất nhiều lý do tôi có thể nghĩ đến, có thể tôi sẽ dừng ở đó.

Tại sao chuyển sang C# thay vì VB.NET

  • phát triển có thể được ru ngủ trong một cảm giác sai lầm về sự quen thuộc với VB.NET - điều trị các nguồn lực như họ đã làm trong VB6 mà không hiểu khái niệm đầy đủ. Một ví dụ: bạn thường thấy các chuyển đổi mới thành các đối tượng thiết lập VB.NET thành Nothing, tin rằng đó là một cách kỳ diệu để giải phóng tài nguyên. Không phải vậy.

  • Đúng là hầu hết các ví dụ đều có trong C#. Quan trọng hơn, Jeff Richter's book chỉ có trong C# bây giờ. Nếu bạn muốn hiểu làm thế nào NET thực sự hoạt động, IMO cuốn sách của ông là khá nhiều bắt buộc.

  • Trong .NET, bạn sẽ thấy rằng bạn sẽ sử dụng các biểu thức lambda mọi lúc, đặc biệt khi hoạt động với LINQ.IMO VB's verbosity thực sự trở thành rào cản đối với việc hiểu và dễ đọc ở đây, theo những cách đơn giản trước đây: foo.Select(x => x > 50), chỉ bằng bất kỳ tiêu chuẩn nào, thông thạo hơn và dễ đọc hơn foo.Select(Function(x) x > 50). Nó trở nên tồi tệ hơn khi các biểu thức trở nên phức tạp hơn.

  • Một số thực tiễn tồi tệ nhất với VB6 là không thể hoặc ít nhất ít có khả năng truy cập nhiều hơn trong C# (chẳng hạn như bảo tồn ReDim và tiếp tục lỗi khi tiếp tục).

  • VB được thêm một số cú pháp khiến cho nó khá cồng kềnh và khó hiểu khi sử dụng khi tạo thư viện CLR đa năng. Ví dụ, trong C#, bạn sử dụng các bộ chỉ mục với các dấu ngoặc vuông []. Trong VB, bạn dùng parens. Điều đó làm cho nó khó khăn cho người dùng của một chương trình con để biết đó là một trình chỉ mục hay một hàm. Nếu ai đó cố gắng sử dụng thư viện của bạn bên ngoài VB, sự khác biệt sẽ là quan trọng, nhưng nhà phát triển VB có thể có khuynh hướng tạo các chương trình con nên các chỉ mục là hàm, vì chúng trông giống nhau.

  • Tôi không có bất kỳ dữ liệu nào về điều này, nhưng nếu bạn đang cố gắng thuê một nhóm lập trình viên tốt, thì những người lập trình tốt nhất sẽ ít có khuynh hướng làm việc trong một cửa hàng viết VB.NET hơn C#. Họ thường sợ rằng mã mà các đồng nghiệp của họ sẽ tạo ra có khả năng là mã .NET chuẩn, và chúng ta hãy thẳng thắn ở đây - có một sự kỳ thị đối với các nhà phát triển VB.NET và chất lượng mã của họ trong cộng đồng. Ở đó. Tôi đã nói rồi. Hãy để ngọn lửa bắt đầu ...

Như một chú thích, theo quan điểm của tôi, VB.NET là một cơ hội thực sự bị bỏ lỡ đối với MS. Những gì nó cần phải có được là một cách để liên tục chuyển đổi mã VB6 cũ của bạn sang thế giới .NET - với lời gọi động và chất lượng cao COM interop ngay từ đầu. Những gì nó đã kết thúc được là một bản sao gần của C# 's tính năng thiết lập với một cú pháp chi tiết hơn và ít hoặc không có khả năng tương thích ngược. Buồn, thật đấy. Nó đã khóa rất nhiều tổ chức từ .NET trong một thời gian dài. Sau đó, một lần nữa, có lẽ nó đã buộc một "lạnh-gà tây" phá vỡ sạch từ quá khứ ...

+1

'ReDim Preserve' ==' Array.Resize'. Vì vậy, nó có thể. Tôi cũng không thấy lý do tại sao nó phải là một "thực hành tồi tệ nhất" (đặc biệt xem xét rằng VB thiếu hỗ trợ tốt cho các cấu trúc dữ liệu có kích thước động). Ngoài ra, tôi (như một fan hâm mộ lớn của VB.NET) có xu hướng đồng ý với tài khoản của bạn. –

+0

Đúng, nó * tương tự *, nhưng không hoàn toàn giống nhau. Xem câu trả lời và nhận xét của Jon Skeet: http://stackoverflow.com/questions/327916/redim-preserve-in-c. Cấp, kể từ khi CLR hoạt động cơ bản khác với VB, việc triển khai .NET có thể không tệ như trong VB6 ngày từ quan điểm hiệu suất. Dù bằng cách nào, tôi sẽ thay đổi cách nói của tôi. –

+1

Một trong những vấn đề quan trọng nhất về việc đào tạo những người đến từ vb6 đến vb.net là kiểu biến đổi chuyển đổi, quyền anh, hoạt động unboxing, Văn hóa và định dạng. Họ sử dụng để dựa vào chuyển đổi tiềm ẩn quá nhiều khi họ sử dụng VB6. Phát minh VB.NET tồi tệ hơn là tùy chọn rõ ràng và tùy chọn nghiêm ngặt, vì chúng có thể được TẮT. Tôi đã cố hết sức để đào tạo mọi người về việc không dựa vào các hoạt động tiềm ẩn và cách giết chúng vĩnh viễn bằng cách đặt cả Tùy chọn rõ ràng và Tùy chọn nghiêm ngặt thành BẬT. – Larry

6

này có thể không trả lời câu hỏi của bạn, trên thực tế nó thậm chí có thể mâu thuẫn với câu trả lời của bạn và chứng minh cho bạn bè đúng, nhưng đây là một danh sách tốt về những điểm tương đồng (và khác nhau) giữa VB.NET và C#:

C#/VB.NET comparison

Khi bạn đi xuống danh sách này, bạn sẽ nhận thấy mức độ tương tự của hai ngôn ngữ đã trở thành và với mỗi phiên bản mới, có thể có ít lý do để chuyển đổi hơn. Nhưng, cuối cùng, nếu bạn làm việc chuyển đổi, bài viết Wikipedia khá nhiều tóm tắt những lợi thế mà C# có hơn VB.NET khá tốt:

Wikipedia article listing advantages of C# over VB and vice versa

+0

VB .NET không phải là VB 6. – Joren

+1

Tôi chưa bao giờ tuyên bố. Tôi đang cố gắng chỉ ra rằng các nhà phát triển VB6 có thể chuyển sang VB.NET ... –

+0

Đủ công bằng, tôi hiểu lầm. – Joren

22

tôi đã thực hiện một LOT của VB6 trong quá khứ, và rất nhiều C/C++, và khi di chuyển .NET lớn của chúng tôi xảy ra, tôi không nghi ngờ gì về việc C# là con đường để đi. Có nói rằng, những gì các VB6 guys nên thực sự được học tập là NET, và CLR (một thời gian chạy hướng đối tượng thích hợp chứ không phải là một COM câm front-end), và không phải là một cú pháp. Tập trung vào đó, và tránh xa cuộc chiến tôn giáo.

+1

Tôi không chắc chắn cách các nhận xét như "câm COM front-end" không phải là bức ảnh trong một cuộc chiến tôn giáo, nhưng .Net không phải là câu trả lời duy nhất. Bạn có bản gốc C++ hoặc Delphi, Java và nhiều lựa chọn thay thế ngoài những thay thế được cung cấp cho hệ sinh thái .Net. Ngay cả ở đó bạn có rất nhiều lựa chọn ngôn ngữ có thể, mặc dù nó khá rõ ràng C# là lần đầu tiên trong số các ngôn ngữ "công dân hạng nhất". – Bob77

+0

Tôi đồng ý với nhận xét của bạn. Bước nhảy lớn hơn cho các nhà phát triển VB6 sẽ được học khuôn khổ hơn là học một cú pháp mới. – webdad3

3

Lợi thế lớn nhất C# có trên VB6 đúng là đã được thừa kế.

(OK, để được công bằng đó là yêu thích cá nhân của tôi, vì vậy tôi hoàn toàn sai lệch.)

lợi thế khác:

  • accessors chính
  • loại ngoại lệ (Tôi không nghĩ rằng VB6 có loại ngoại lệ, nhưng hãy sửa lại cho tôi nếu tôi sai)
  • Generics
  • Lambda biểu thức

Và những điều sau có liên quan nhiều hơn đến.NET nền tảng hơn ngôn ngữ bản thân:

  • thư viện Rất giàu
  • Visual Studio refactoring và goodies khác

Cuối cùng, lập luận phổ biến luôn là icky (phổ biến <> tốt), nhưng nó đưa ra một ý tưởng về quy mô cộng đồng của mỗi nhóm và do đó, những trợ giúp có sẵn ở đó và ngành công nghiệp đang hướng tới cái gì nói chung.

Các câu hỏi về SO:

+0

Câu hỏi là "VB.Net hoặc C#", không phải "VB6 hoặc VB.Net" –

+1

Tôi nghĩ rằng chúng đã được bán trên switch từ VB6 đến .NET, câu hỏi đặt ra là có nên đi C# hay VB.NET không. [Tôi nghĩ rằng downvote là một chút khắc nghiệt, kể từ khi điểm của bạn đang thực sự nổ khi nói đến lý do để đổ VB6] – lesscode

+0

Để phản ánh @Michael Goldshteyn, tôi không bao giờ tuyên bố nó được. – MPelletier

3

Tôi nghĩ rằng các câu trả lời khác đã thực hiện tốt công việc bao gồm các điểm kỹ thuật. Tôi cũng sẽ chỉ ra cho các nhà phát triển vb6 của bạn rằng không chỉ có nhiều sách hướng tới C# và nhiều câu hỏi về SO trên C#, nhưng có lẽ quan trọng hơn đối với họ, nhiều danh sách công việc hơn nữa.

Một tìm kiếm nhanh trên SO nghiệp:

  • 92 việc đăng cho C#
  • 11 tin đăng việc cho vb.net
  • 1 việc đăng cho vb6
+5

0 thông tin việc làm cho Cobol. Bạn nghĩ gì nhất? – GvS

+2

@GvS: À vâng, nhưng có nhiều khả năng là kết quả trong việc quay phim ở nơi làm việc? Đó là nguy hiểm trả tiền! –

+0

@GvS: 1G/năm lần 0 công việc = 0 – MPelletier

4

Các VB.net cú pháp sự kiện có vẻ đẹp hơn nhiều so với C#; Mặc dù thiếu bất kỳ phương tiện nào cho một lớp để hủy đăng ký tất cả các trình xử lý WithEvents mà nó đã đăng ký hoặc xóa tất cả các mục đăng ký khác đối với các sự kiện của nó, làm cho nó khó khăn một chút để tránh rò rỉ sự kiện. .

Ngoài ra, trong vb.net, có thể có Trình xử lý cuối cùng biết được trường hợp ngoại lệ xảy ra (nếu có) trong khối Thử của nó mà không phải thực sự bắt nó. Nếu bất kỳ trường hợp ngoại lệ nào xảy ra trong khối Cuối cùng, ngoại lệ ban đầu có thể được bao gồm trong CleanupFailedException (cùng với các ngoại lệ khác đã xảy ra trong khối Cuối cùng). Điều đó có vẻ như là một lợi thế tốt đẹp.

3

lý do tại sao các nhà phát triển VB6 nên chuyển sang C#

Những người khác đã đưa lý do kỹ thuật cho C# trên VB.NET, nhưng tôi nghĩ rằng bạn đang đối phó với một người vấn đề, vì vậy tôi sẽ cung cấp những gì tôi nghĩ là lý do thuyết phục nhất tại sao phát triển nên thích nó:

  • C# các nhà phát triển được trả tiền nhiều hơn VB nhà phát triển .NET, để làm giống hệt nhau suy nghĩ, chỉ cần gõ mã nguồn khác nhau sau khi làm điều đó nghĩ

Cũng

  • ReSharper cho C# là tốt hơn so với ReSharper cho VB.NET
+0

Bạn không cần ReSharper nhiều như vậy với VB.NET vì IDE đã thực hiện một số trong số đó. Tuy nhiên, bằng cách sử dụng ReSharper đã cải thiện chất lượng của mã VB.NET tôi viết. – CoderDennis

2

Khác với lợi thế kỹ thuật/xã hội là hơn theo định hướng kinh doanh, hỗ trợ Mainstream cho VB6 đã kết thúc và hỗ trợ mở rộng mà chắc chắn là tốn kém sẽ sớm kết thúc. Di chuyển sang nền tảng mới trong trường hợp này mang lại nhiều ý nghĩa kinh doanh hơn. Ngoài ra IDE không còn được hỗ trợ bởi microsoft nên trong trường hợp phát hành bạn sẽ là SOL, và cài đặt nó trên máy tính xách tay mới sáng bóng có thể cung cấp một trải nghiệm vô cùng thoải mái.

Lưu ý rằng họ không cần phải chuyển tất cả các ứng dụng, chỉ không được chấp nhận phần cần được thay thế bằng bộ tiếp xúc .Net.

Mặt khác, có kinh nghiệm trong việc chuyển phần mềm từ nền tảng lỗi thời sang nền tảng mới sẽ khiến những người này trở nên giàu có, miễn là họ sẵn sàng tìm hiểu nền tảng mới.

1

VB6 không hoàn toàn hướng đối tượng và thiếu tập hợp phong phú các bộ sưu tập/cấu trúc. VB.Net và C# đều hướng đối tượng đầy đủ và bao gồm một tập hợp phong phú các lớp thu thập như là một phần của .NET. .NET 2 cũng thêm các generics cho sự linh hoạt hơn nữa.

Tôi đồng ý với những người nghĩ rằng VB.Net là một chút thừa - nó cố định các vấn đề với VB6 và cuối cùng là một chút của một "tôi quá" cùng với C#. Có nói rằng, tôi làm rất nhiều COM interop và tìm VB.Net cũ thời ON ERROR xây dựng một cách thuận tiện để xử lý thời gian chờ và chức năng retries. Bạn có thể làm điều đó với thử ... bắt chỉ là nó phức tạp hơn.

4

"Nhà phát triển có thể bị ruồng bỏ thành cảm giác sai lầm quen thuộc với VB.NET - xử lý các tài nguyên giống như họ đã làm trong VB6 mà không hiểu khái niệm đầy đủ". (@Markle)

Tôi đã không sử dụng điều này cho một cuộc tranh luận trước đây, nhưng đó là một điểm rất tốt. Khi tôi chọn một ứng dụng VB.NET được viết bởi một loạt các lập trình viên mới của VB, nó đã được rải rác với các cuộc gọi tương thích cũ với không gian tên VisualBasic cũ. CStr(), VbNewLine, Mid(), v.v ... Làm việc trong một ngôn ngữ không được thiết kế để hỗ trợ chuyển đổi mã kế thừa ngăn cản việc sử dụng các di tích đó. (Vì vậy, loại bỏ tham chiếu đến không gian tên cũ, FYI.)

Tôi chuyển đổi giữa VB.NET và C# khá thường xuyên. Bất cứ khi nào tôi đi từ VB đến C#, tôi nghĩ rằng "Điều này là khác nhau, nó sẽ đưa tôi một vài phút để điều chỉnh." Bất cứ khi nào tôi đi từ C# để VB, tôi nghĩ rằng "Đây là một ngôn ngữ lập trình không hiệu quả; có quá nhiều cách gõ cần thiết, làm thế nào gây phiền nhiễu."

0

Các câu hỏi về SO:

[C#]: 116,337 
[VB.NET]: 11,740 
[VB6]: 1,897 

Điều đó chứng minh gì cả. VB6 tồn tại lâu trước khi SO thực hiện. Tất cả các lập trình viên VB giỏi đều học được những gì họ cần biết và MSFT đã làm với VB6.Hầu hết những người mới bắt đầu MSFT đổ xô đến C# vì sự căm ghét bất hợp lý của họ về bất cứ điều gì BASIC (mà vẫn thoát ra - chỉ nhìn vào Xojo) và tất nhiên là tiếp thị MSFT. Nhưng làm thế nào để họ cảm thấy bây giờ với C# nhận được thay đổi ngắn so với C + + trên nền tảng Windows 8? (ví dụ: XNA đã biến mất). Thị trường đòi hỏi khá nhiều C# trên VB.net.

Các vấn đề liên quan