2

Là một nhà phát triển Java tị nạn lần đầu tiên dọn dẹp bờ biển .Net, tôi khá ngạc nhiên về tình trạng nghèo nàn của các công cụ và thư viện dường như được sử dụng phổ biến. Tôi không thể tin thị trấn tồi tàn này là tình trạng của nghệ thuật; nhưng với một mùa xuân trong bước chân tôi đã hành quân vào đất liền. Vài năm sau, tôi có thể thành thật nói rằng đó thực sự không phải là một điểm tuyệt vời mà có một số điểm cao, nhưng có rất nhiều điểm thấp. Lúc đó tôi đã không nhận ra, nhưng là một nhà phát triển Java, tôi đã vô cùng hư hỏng bởi một cộng đồng nguồn mở hoạt bát sản xuất vô số phần mềm tuyệt vời. Trong thế giới .net, dường như có hai cách giải quyết bất kỳ vấn đề nào:

  1. Cách của Microsoft
  2. Cách khác*

* Lưu ý: có thể không hoạt động, có thể tốn tiền.

Ý tưởng

Nơi rõ ràng để bắt đầu là IDE. Tôi xin lỗi, nhưng Visual Studio không đủ tốt. So với Eclipse và IntelliJ để phát triển hàng ngày Visual Studio là một sự bắt chước kém. Tồi tệ hơn, cho đến gần đây, nó  đắt đỏ như một nhà phát triển đơn độc. Mặc dù đã có phiên bản cộng đồng của Visual Studio, nhưng chúng thậm chí còn được giảm xuống so với phiên bản chuyên nghiệp không sử dụng được. Thành thật mà nói, nếu bạn không thể chạy ReSharper, thì nó không được tính là IDE.

Tôi nghe nói thực sự có những người sử dụng Visual Studio mà không cần ReSharper. Những người này là gì? Những kẻ tàn bạo? Họ làm gì? Tôi hy vọng nó không viết phần mềm. Có lẽ điều này giải thích tình trạng nghèo nàn của rất nhiều phần mềm; Với những công cụ xấu này thì có gì lạ không?

Nhưng cuối cùng, Microsoft đã thấy được ánh sáng và gần đây phiên bản Visual Studio miễn phí hỗ trợ các plugin có nghĩa là bạn có thể sử dụng ReSharper. Bạn vẫn phải trả tiền cho nó, nhưng với những thay đổi cấp phép gần đây của họ, tôi không cảm thấy quá tệ khi giao một vài tháng một lần thuê ReSharper trước khi tôi cam kết mua giấy phép hoàn toàn. Rõ ràng tình hình của các công ty là khác nhau, một công ty dễ dàng hơn nhiều để biện minh cho việc chi tiền cho giấy phép Visual Studio và giấy phép ReSharper.

Với ReSharper, Visual Studio ít nhất là gần với Eclipse hoặc IntelliJ. Nó vẫn còn thiếu, nhưng rõ ràng chỉ có rất nhiều thỏi son mà JetBrains có thể đặt lên con lợn đặc biệt đó. Tuy nhiên tôi rất hy vọng vào Project Rider , về cơ bản là IntelliJ cho .net.

Dịch vụ nghỉ ngơi

Vài năm trước, một người tị nạn Java khác và tôi bắt đầu thử viết một dịch vụ web kiểu RESTful, CQRS bằng C #. Chúng tôi đã làm điều tương tự ở một công ty trước đây trong ngăn xếp Java và dự kiến ​​các lựa chọn của chúng tôi sẽ thay đổi tương tự. Nhưng, thay vì rất nhiều cách tiếp cận từ trình nghe HTTP cơ bản đến các thùng chứa servlet đến các máy chủ ứng dụng đầy đủ, chúng tôi đã thu hẹp trường thành hai lựa chọn:

  1. WCF của Microsoft
  2. Dịch vụ

Nhà phát triển đồng nghiệp của tôi đã chơi với WCF và quyết định rằng anh ta không thể làm cho nó dễ dàng phù hợp với phong cách RESTful, CQRS mà anh ta có trong tâm trí. Sau khi chơi với ServiceStack, chúng tôi thấy nó có thể. Nhưng, sau đó bắt đầu quá trình dài, quanh co để tìm tất cả những thứ ServiceStack hoàn toàn không đúng với tất cả những điều chúng tôi không hoàn toàn đồng ý. Bây giờ, điều này không hoàn toàn không phổ biến trong bất kỳ quy trình lựa chọn công nghệ. Nhưng, chúng tôi đã nhanh chóng thu hẹp lĩnh vực xuống còn hai. Bây giờ chúng tôi đã cam kết với một công nghệ mà ở mỗi lượt đều gây ra cho chúng tôi những vấn đề mới, không lường trước được (khó chịu nhất là những vấn đề mà các nhóm phát triển khác không gặp phải với dịch vụ WCF vanilla!)

Chúng tôi đã nói đùa (không thực sự nói đùa) rằng việc viết lớp dịch vụ của riêng chúng tôi lên trên hỗ trợ HTTP cơ bản trong .Net sẽ đơn giản hơn. Nhìn lại, nó có thể đã được. Nhưng thực sự, chúng tôi đã phải trả giá vì đã có sự bực bội để bước ra một cách chân thực của Microsoft.

Tồi tệ hơn, những gì đã bắt đầu như một dự án nguồn mở đã được trả tiền trong quá trình phát triển dịch vụ của chúng tôi, điều đó có nghĩa là dịch vụ web hoàn toàn mới của chúng tôi ngay lập tức vì lớp dịch vụ được xây dựng không còn được hỗ trợ chính thức.

Quản lý phụ thuộc

Điều tôi thấy ngạc nhiên nhất khi đến vùng đất .Net là mọi người đang kiểm tra tất cả các nhị phân của bên thứ ba của họ để kiểm soát phiên bản giống như những năm 1990! Các nhà phát triển Java có thể phàn nàn rằng Maven không gì khác hơn là DSL để tải xuống internet. Nhưng bạn biết không, nó rất tốt trong việc tải xuống internet. Thay vào đó, tôi đã kiểm tra internet để kiểm soát phiên bản.

Tuy nhiên, sự cứu rỗi đã ở trong tầm tay với NuGet. Ngoại trừ, NuGet thực sự là một chút tào lao. NuGet không quản lý quá nhiều sự phụ thuộc của tôi khi phá vỡ chúng trong suốt thời gian chết tiệt. Chúng ta có nên hạn chế tất cả các phiên bản của thư viện (giả sử log4net) thành một phiên bản trên toàn bộ giải pháp không? Không, chúng ta hãy có một vài biến thể. Ồ, nhưng NuGet, bây giờ tôi gặp lỗi thời gian chạy ngẫu nhiên do chữ ký phương thức khớp sai. Nhưng, nó không làm cho việc xây dựng thất bại? Rực rỡ, cảm ơn bạn, nuget.

Vì vậy, tại địa điểm hiện tại của tôi, chúng tôi đã viết một kịch bản dựng sẵn để kiểm tra xem nuget đã không làm hỏng phụ thuộc. Kiểm tra trước khi xây dựng này thất bại thường xuyên hơn tôi muốn tin.

Vì vậy, quản lý một tập hợp các phụ thuộc nhất quán không phải là công việc của công cụ phụ thuộc, vậy nó làm gì? Nó tải xuống một tập tin tại một thời điểm từ internet. Làm tốt. Tôi nghĩ rằng wget cũng có thể làm điều đó. Đó cũng là một cảnh tượng chết tiệt nhanh hơn cả bảng điều khiển vỏ năng lượng NuGet. NuGet: nó có thể phá vỡ các bản dựng của bạn, nhưng ít nhất là nó chậm.

Con đường của Microsoft

Và sau đó, tôi tìm thấy những thứ thổi tôi đi. Ở nơi hiện tại của tôi, chúng tôi đã viết một số bổ trợ cho Excel để những người sống và chết bằng Excel có thể tương tác với phần mềm của chúng tôi. Điều này khá thú vị: thêm các nút, menu và ruy băng vào Excel, tất cả được tích hợp vào các dịch vụ phụ trợ của tôi.

Trong cuộc đời là một nhà phát triển Java, tôi thậm chí không bao giờ có thể tưởng tượng được việc thử này. Các vòng nhảy qua sẽ là quá nhiều. Nhưng, trong Visual Studio? Tạo một loại giải pháp mới, cụ thể, nhấn F5, Excel sẽ mở. Đặt điểm dừng, Excel dừng. Ôi chúa ơi, đây là một môi trường phát triển tích hợp.

Rõ ràng, tất cả dữ liệu của chúng tôi được lưu trữ trong Microsoft SQLServer. Điều này cũng có sự tích hợp tuyệt vời với Visual Studio. Ví dụ: chúng tôi đã thử nghiệm tạo một tập hợp .Net để đọc một số dữ liệu nhị phân mà chúng tôi đang lưu trữ trong DB. Bằng cách này, chúng ta có thể chạy các truy vấn hiệu quả trên các loại dữ liệu phức tạp trực tiếp trong DB. Quá trình dev cho điều này? Tương tự tuyệt vời: triển khai lên DB và chạy trực tiếp từ bên trong Visual Studio. Holy chu kỳ dev tích hợp, Batman!

Khi có một cách của Microsoft, đây là lý do tại sao nó rất hấp dẫn. Bất cứ điều gì họ làm sẽ được tích hợp rực rỡ với mọi thứ khác họ làm. Nó có thể không có tính linh hoạt mà bạn muốn, nó có thể không có tất cả các tính năng bạn muốn, nhưng nó sẽ được tích hợp một cách ngoạn mục với mọi thứ khác mà bạn đang sử dụng.

Tại sao?

Tại sao nó phải theo cách này? C # là một ngôn ngữ thực sự tuyệt vời, được thiết kế tốt với nhiều sức mạnh biểu cảm. Nhưng, hệ sinh thái nguồn mở xung quanh nó rất cằn cỗi. Nếu cách của Microsoft không phù hợp với hóa đơn, bạn thường hoàn toàn bị mắc kẹt.

Tôi nghĩ rằng nó đi vào lịch sử của Visual Studio là rất đắt. Ngay cả khi là nhà phát triển C # vào ban ngày, tôi không chi tiêu hết 1.000 bảng để có một môi trường phát triển phù hợp ở nhà,  vì vậy tôi có thể chơi . Ngay cả khi tôi đã có một ý tưởng vững chắc về một dự án nguồn mở để bắt đầu, tôi sẽ không đầu tư một ngàn quid chỉ để xem.

Nhưng cuối cùng, Microsoft dường như đang nắm bắt được điều nguồn mở. Các phiên bản miễn phí của Visual Studio và các dự án như CoreCLR chỉ có thể trợ giúp. Tuy nhiên, hệ sinh thái Java có khởi đầu thập kỷ và điều này cuối cùng tạo ra hiệu ứng mạng: thật khó để viết phần mềm nguồn mở tốt cho .Net vì có rất ít công cụ nguồn mở tốt cho .Net.

|