Ý kiến ​​lập trình gây tranh cãi nhất của bạn là gì?

Điều này chắc chắn là chủ quan, nhưng tôi muốn cố gắng tránh nó trở thành tranh luận. Tôi nghĩ nó có thể là một câu hỏi thú vị nếu mọi người đối xử với nó một cách thích hợp.

Ý tưởng cho câu hỏi này xuất phát từ chuỗi nhận xét từ câu trả lời của tôi cho "Năm điều bạn ghét về ngôn ngữ yêu thích của bạn là gì?" câu hỏi . Tôi cho rằng các lớp trong C # nên được niêm phong theo mặc định - Tôi sẽ không đặt lý do của mình vào câu hỏi, nhưng tôi có thể viết một lời giải thích đầy đủ hơn như một câu trả lời cho câu hỏi này. Tôi đã rất ngạc nhiên trước sức nóng của cuộc thảo luận trong các bình luận (hiện tại có 25 bình luận).

Vì vậy, những ý kiến ​​gây tranh cãi nào bạn giữ? Tôi muốn tránh loại điều cuối cùng mang tính tôn giáo với cơ sở tương đối ít (ví dụ như đặt nẹp) nhưng các ví dụ có thể bao gồm những thứ như "thử nghiệm đơn vị không thực sự hữu ích" hay "lĩnh vực công cộng thực sự ổn". Điều quan trọng (với tôi, dù sao đi nữa) là bạn có lý do đằng sau ý kiến ​​của mình.

Vui lòng trình bày ý kiến ​​và lý luận của bạn - Tôi sẽ khuyến khích mọi người bỏ phiếu cho các ý kiến ​​được tranh luận tốt và thú vị, cho dù bạn có tình cờ đồng ý với họ hay không.

Các lập trình viên không viết mã trong thời gian rảnh rỗi để giải trí sẽ không bao giờ trở nên tốt như những người làm.

Tôi nghĩ ngay cả những người thông minh và tài năng nhất cũng sẽ không bao giờ trở thành những lập trình viên thực sự giỏi trừ khi họ coi nó không chỉ là một công việc. Có nghĩa là họ làm các dự án nhỏ ở bên cạnh, hoặc chỉ lộn xộn với nhiều ngôn ngữ và ý tưởng khác nhau trong thời gian rảnh rỗi.

(Lưu ý: Tôi không nói rằng các lập trình viên giỏi không làm gì khác hơn là lập trình, nhưng họ làm nhiều hơn chương trình từ 9 đến 5)

"Thực hành tốt nhất" duy nhất bạn nên sử dụng mọi lúc là "Sử dụng bộ não của bạn".

Quá nhiều người nhảy vào quá nhiều bandwagons và cố gắng ép buộc các phương thức, mô hình, khung, v.v. vào những thứ không đảm bảo cho họ. Chỉ vì một cái gì đó mới, hoặc bởi vì ai đó được tôn trọng có ý kiến, không có nghĩa là nó phù hợp với tất cả :)

EDIT: Chỉ cần làm rõ - Tôi không nghĩ mọi người nên bỏ qua các thực tiễn tốt nhất, các ý kiến ​​có giá trị, v.v ... Chỉ là mọi người không nên mù quáng nhảy vào một cái gì đó mà không nghĩ về lý do tại sao "điều này" lại tuyệt vời như vậy, nó có thể áp dụng cho những gì tôi Tôi đang làm, và nó mang lại lợi ích / nhược điểm gì?

"Googling nó" là được!

Vâng, tôi biết điều đó xúc phạm một số người ngoài kia rằng những năm ghi nhớ mãnh liệt và / hoặc những cuốn sách lập trình vinh quang của họ đang bắt đầu rơi xuống bên cạnh một nguồn tài nguyên mà bất cứ ai cũng có thể truy cập trong vài giây, nhưng bạn không nên chống lại mọi người sử dụng nó

Tôi thường xuyên nghe thấy những câu trả lời googling cho các vấn đề kết quả của sự chỉ trích, và nó thực sự là vô nghĩa. Trước hết, phải thừa nhận rằng mọi người đều cần tài liệu để tham khảo. Bạn không biết tất cả mọi thứ và bạn sẽ cần phải tìm kiếm mọi thứ. Ép buộc điều đó, có thực sự quan trọng khi bạn lấy thông tin không? Có vấn đề gì không nếu bạn tra cứu nó trong một cuốn sách, tìm kiếm nó trên Google hoặc nghe nó từ một con ếch biết nói mà bạn bị ảo giác? Không. Một câu trả lời đúng là một câu trả lời đúng.

Điều quan trọng là bạn hiểu tài liệu, sử dụng nó làm phương tiện để kết thúc một giải pháp lập trình thành công và khách hàng / nhà tuyển dụng của bạn hài lòng với kết quả.

(mặc dù nếu bạn đang nhận được câu trả lời từ những con ếch biết nói ảo giác, có lẽ bạn nên nhận được sự giúp đỡ nào đó)

Hầu hết các ý kiến ​​trong mã trên thực tế là một hình thức sao chép mã nguy hiểm.

Chúng tôi dành phần lớn thời gian để duy trì mã được viết bởi người khác (hoặc chính chúng tôi) và các bình luận nghèo nàn, không chính xác, lỗi thời, sai lệch phải ở gần đầu danh sách các hiện vật gây phiền nhiễu nhất trong mã.

Tôi nghĩ rằng cuối cùng nhiều người chỉ để trống chúng, đặc biệt là những quái vật hộp hoa.

Tốt hơn nhiều để tập trung vào việc làm cho mã có thể đọc được, tái cấu trúc khi cần thiết và giảm thiểu các thành ngữ và sự khó hiểu.

Mặt khác, nhiều khóa học dạy rằng các bình luận gần như quan trọng hơn chính mã, dẫn đến dòng tiếp theo này thêm một vào phong cách bình luận hóa đơn.

XML được đánh giá cao

Tôi nghĩ rằng có quá nhiều người nhảy vào băng thông XML trước khi sử dụng bộ não của họ ... XML cho các công cụ web là tuyệt vời, vì nó được thiết kế cho nó. Mặt khác, tôi nghĩ rằng một số định nghĩa vấn đề và suy nghĩ thiết kế nên ưu tiên mọi quyết định sử dụng nó.

5 xu của tôi

Không phải tất cả các lập trình viên đều được tạo ra như nhau

Khá thường xuyên các nhà quản lý nghĩ rằng DeveloperA == DeveloperB đơn giản chỉ vì họ có cùng mức độ kinh nghiệm, v.v. Trong thực tế, hiệu suất của một nhà phát triển có thể gấp 10 hoặc thậm chí 100 lần so với nhà phát triển khác.

Đó là rủi ro về mặt chính trị để nói về nó, nhưng đôi khi tôi cảm thấy như chỉ ra rằng, mặc dù một vài thành viên trong nhóm có thể xuất hiện được các kỹ năng tương đương, nó không phải luôn luôn như vậy. Tôi thậm chí đã thấy các trường hợp trong đó các nhà phát triển chính là 'vượt quá hy vọng' và các nhà phát triển cơ sở đã làm tất cả công việc thực tế - mặc dù tôi chắc chắn rằng họ đã nhận được tín dụng. :)

Tôi không hiểu tại sao mọi người nghĩ rằng Java hoàn toàn là ngôn ngữ lập trình "đầu tiên" tốt nhất được dạy trong các trường đại học.

Đối với một người, tôi tin rằng ngôn ngữ lập trình đầu tiên phải sao cho nó làm nổi bật nhu cầu tìm hiểu luồng điều khiển và các biến, chứ không phải các đối tượng và cú pháp

Mặt khác, tôi tin rằng những người chưa có kinh nghiệm trong việc gỡ lỗi rò rỉ bộ nhớ trong C / C ++ không thể đánh giá đầy đủ những gì Java mang đến cho bảng.

Ngoài ra, tiến trình tự nhiên nên từ "làm thế nào tôi có thể làm điều này" đến "làm thế nào tôi có thể tìm thấy thư viện làm điều đó" chứ không phải theo cách khác.

Nếu bạn chỉ biết một ngôn ngữ, cho dù bạn biết nó tốt đến đâu, bạn không phải là một lập trình viên tuyệt vời.

Dường như có một thái độ nói rằng một khi bạn thực sự giỏi về C # hoặc Java hoặc bất kỳ ngôn ngữ nào khác mà bạn bắt đầu học thì đó là tất cả những gì bạn cần. Tôi không tin nó - mọi ngôn ngữ tôi từng học đã dạy tôi một điều mới về lập trình mà tôi có thể mang lại cho công việc của mình với tất cả những ngôn ngữ khác. Tôi nghĩ rằng bất cứ ai giới hạn bản thân trong một ngôn ngữ sẽ không bao giờ tốt như họ có thể.

Nó cũng chỉ ra cho tôi một sự thiếu hiểu biết nhất định và sẵn sàng thử nghiệm mà không nhất thiết phải kiểm đếm những phẩm chất mà tôi mong đợi sẽ tìm thấy ở một lập trình viên thực sự giỏi.

Hiệu suất không thành vấn đề.

Báo cáo in là một cách hợp lệ để gỡ lỗi mã

Tôi tin rằng việc gỡ lỗi mã của bạn bằng cách xả rác bằng mã System.out.println(hoặc bất kỳ câu lệnh in nào hoạt động cho ngôn ngữ của bạn là hoàn toàn tốt ). Thông thường, việc này có thể nhanh hơn gỡ lỗi và bạn có thể so sánh các kết quả đầu ra được in với các lần chạy khác của ứng dụng.

Chỉ cần đảm bảo xóa các báo cáo in khi bạn đi vào sản xuất (hoặc tốt hơn, biến chúng thành các báo cáo ghi nhật ký)

Công việc của bạn là đưa mình ra khỏi công việc.

Khi bạn viết phần mềm cho chủ nhân của mình, bất kỳ phần mềm nào bạn tạo sẽ được viết theo cách mà bất kỳ nhà phát triển nào có thể chọn và hiểu với một nỗ lực tối thiểu. Nó được thiết kế tốt, được viết rõ ràng và nhất quán, được định dạng sạch sẽ, được ghi lại ở nơi cần thiết, xây dựng hàng ngày như mong đợi, được kiểm tra vào kho lưu trữ và được phiên bản phù hợp.

Nếu bạn bị xe buýt đâm, bị sa thải, bị sa thải hoặc nghỉ việc, chủ nhân của bạn sẽ có thể thay thế bạn trong một khoảnh khắc, và anh chàng tiếp theo có thể bước vào vai trò của bạn, lấy mã của bạn và đứng dậy và chạy trong vòng một tuần. Nếu anh ấy hoặc cô ấy không thể làm điều đó, thì bạn đã thất bại thảm hại.

Thật thú vị, tôi đã thấy rằng có mục tiêu đó đã làm cho tôi có giá trị hơn đối với các nhà tuyển dụng của tôi. Tôi càng cố gắng để trở nên dùng một lần, tôi càng trở nên có giá trị đối với họ.

1) Trò chơi ứng dụng kinh doanh :

Tôi nghĩ rằng toàn bộ khuôn khổ "Doanh nghiệp" là khói và gương. J2EE, .NET, phần lớn các khung công tác Apache và hầu hết các khái niệm trừu tượng để quản lý những thứ đó tạo ra sự phức tạp hơn nhiều so với chúng giải quyết.

Sử dụng bất kỳ Java hoặc .NET ORM thông thường hoặc bất kỳ khung MVC được cho là hiện đại nào để thực hiện "phép thuật" để giải quyết các tác vụ đơn giản, tẻ nhạt. Cuối cùng, bạn đã viết một số lượng lớn các bản tóm tắt XML xấu xí, khó xác thực và viết nhanh chóng. Bạn có các API khổng lồ trong đó một nửa trong số đó chỉ để tích hợp công việc của các API khác, các giao diện không thể tái chế và các lớp trừu tượng chỉ cần để khắc phục tính không linh hoạt của Java và C #. Chúng tôi chỉ đơn giản là không cần hầu hết điều đó.

Làm thế nào về tất cả các máy chủ ứng dụng khác nhau với cú pháp mô tả mờ nhạt của riêng họ, cơ sở dữ liệu và các sản phẩm phần mềm nhóm quá phức tạp?

Điểm của điều này không phải là sự phức tạp đó == xấu, đó là sự phức tạp không cần thiết == xấu. Tôi đã làm việc trong các cài đặt doanh nghiệp lớn, trong đó một số điều cần thiết, nhưng ngay cả trong hầu hết các trường hợp, một vài tập lệnh được phát triển tại nhà và một trang web đơn giản là tất cả những gì cần thiết để giải quyết hầu hết các trường hợp sử dụng.

Tôi sẽ cố gắng thay thế tất cả các ứng dụng enterprisey này bằng các khung web đơn giản, DB nguồn mở và các cấu trúc lập trình tầm thường.

2) N-năm kinh nghiệm cần thiết:

Trừ khi bạn cần một chuyên gia tư vấn hoặc kỹ thuật viên để xử lý một vấn đề cụ thể liên quan đến một ứng dụng, API hoặc khung, thì bạn không thực sự cần một người có 5 năm kinh nghiệm trong ứng dụng đó. Những gì bạn cần là một nhà phát triển / quản trị viên có thể đọc tài liệu, người có kiến ​​thức về miền trong bất cứ điều gì bạn đang làm và người có thể học nhanh chóng. Nếu bạn cần phát triển một loại ngôn ngữ nào đó, một nhà phát triển đàng hoàng sẽ chọn nó trong vòng chưa đầy 2 tháng. Nếu bạn cần một quản trị viên cho máy chủ web X, trong hai ngày anh ta nên đọc các trang và nhóm tin tức và cập nhật nhanh chóng. Bất cứ điều gì ít hơn và người đó không xứng đáng với những gì anh ta được trả.

3) Chương trình học "khoa học máy tính" phổ biến:

Phần lớn các ngành khoa học máy tính và kỹ thuật phần mềm là bull. Nếu ngôn ngữ lập trình đầu tiên của bạn là Java hoặc C #, thì bạn đã làm sai điều gì đó. Nếu bạn không nhận được một số khóa học đầy đủ về đại số và toán học, thì đó là sai. Nếu bạn không đi sâu vào lập trình chức năng, nó không hoàn chỉnh. Nếu bạn không thể áp dụng các bất biến vòng lặp cho một vòng lặp tầm thường, thì bạn không đáng để bạn trở thành một nhà khoa học máy tính. Nếu bạn có kinh nghiệm về ngôn ngữ x và y và hướng đối tượng, nó sẽ đầy s ***. Một nhà khoa học máy tính thực sự nhìn thấy một ngôn ngữ theo các khái niệm và cú pháp mà nó sử dụng và xem các phương pháp lập trình là một trong số đó, và hiểu rất rõ về các triết lý cơ bản của cả việc chọn ngôn ngữ mới, phương pháp thiết kế hoặc ngôn ngữ đặc tả nên tầm thường

Getters và Setters được sử dụng quá mức

Tôi đã thấy hàng triệu người cho rằng các lĩnh vực công cộng là xấu xa, vì vậy họ biến chúng thành riêng tư và cung cấp các bản thu và setters cho tất cả chúng. Tôi tin rằng điều này gần giống với việc công khai các trường, có thể hơi khác một chút nếu bạn đang sử dụng các luồng (nhưng nói chung không phải vậy) hoặc nếu người truy cập của bạn có logic kinh doanh / trình bày (ít nhất là 'lạ').

Tôi không ủng hộ các lĩnh vực công cộng, nhưng chống lại việc tạo một getter / setter (hoặc Tài sản) cho mọi người trong số họ, và sau đó tuyên bố rằng việc đó là đóng gói hoặc che giấu thông tin ... ha!

CẬP NHẬT:

Câu trả lời này đã gây ra một số tranh cãi trong các bình luận, vì vậy tôi sẽ cố gắng làm rõ nó một chút (Tôi sẽ để nguyên bản không bị ảnh hưởng vì đó là điều mà nhiều người ủng hộ).

Trước hết: bất cứ ai sử dụng các lĩnh vực công cộng đều phải chịu án tù

Bây giờ, tạo ra các lĩnh vực tư nhân và sau đó sử dụng các IDE để tự động tạo ra getter và setter cho mỗi một trong số họ là gần như là xấu như sử dụng các lĩnh vực công cộng.

Nhiều người nghĩ:

private fields + public accessors == encapsulation

Tôi nói (tự động hoặc không) tạo cặp getter / setter cho các trường của bạn thực sự đi ngược lại với cái gọi là đóng gói mà bạn đang cố gắng đạt được.

Cuối cùng, hãy để tôi trích dẫn chú Bob trong chủ đề này (lấy từ chương 6 của "Mã sạch"):

Có một lý do mà chúng tôi giữ các biến của chúng tôi riêng tư. Chúng tôi không muốn bất cứ ai khác phụ thuộc vào họ. Chúng tôi muốn tự do thay đổi loại hình của họ hoặc thực hiện theo một ý thích bất chợt hoặc một xung lực. Tại sao, sau đó, rất nhiều lập trình viên tự động thêm getters và setters vào đối tượng của họ, để lộ các lĩnh vực riêng tư của họ như thể chúng là công khai?

Các sơ đồ UML được đánh giá cao

Tất nhiên có các sơ đồ hữu ích, ví dụ như sơ đồ lớp cho Mẫu tổng hợp , nhưng nhiều sơ đồ UML hoàn toàn không có giá trị.

Ý kiến: SQL là mã. Đối xử với nó như vậy

Đó là, giống như C #, Java hoặc ngôn ngữ đối tượng / thủ tục yêu thích khác của bạn, phát triển một kiểu định dạng có thể đọc và duy trì được.

Tôi ghét khi tôi thấy mã SQL được định dạng miễn phí cẩu thả. Nếu bạn hét lên khi bạn thấy cả hai kiểu dấu ngoặc nhọn trên một trang, tại sao hoặc tại sao bạn không hét lên khi thấy SQL hoặc SQL được định dạng miễn phí che khuất hoặc che giấu điều kiện THAM GIA?

Khả năng đọc là khía cạnh quan trọng nhất của mã của bạn.

Thậm chí nhiều hơn là chính xác. Nếu nó có thể đọc được, thật dễ dàng để sửa chữa. Nó cũng dễ tối ưu hóa, dễ thay đổi, dễ hiểu. Và hy vọng các nhà phát triển khác cũng có thể học được điều gì đó từ nó.

Nếu bạn là nhà phát triển, bạn sẽ có thể viết mã

Tôi đã thực hiện khá nhiều cuộc phỏng vấn vào năm ngoái và trong phần phỏng vấn tôi phải kiểm tra cách mọi người nghĩ và cách họ thực hiện các thuật toán đơn giản đến vừa phải trên bảng trắng. Ban đầu tôi đã bắt đầu với những câu hỏi như:

Cho rằng Pi có thể được ước tính bằng cách sử dụng hàm 4 * (1 - 1/3 + 1/5 - 1/7 + ...) với nhiều số hạng hơn cho độ chính xác cao hơn, hãy viết hàm tính toán Pi với độ chính xác 5 chữ số thập phân .

Đó là một vấn đề khiến bạn phải suy nghĩ, nhưng không nên xa tầm với của một nhà phát triển dày dạn (nó có thể được trả lời trong khoảng 10 dòng C #). Tuy nhiên, nhiều ứng cử viên của chúng tôi (được cho là sàng lọc trước) thậm chí không thể bắt đầu trả lời hoặc thậm chí giải thích cách họ có thể trả lời câu hỏi đó. Vì vậy, sau một thời gian, tôi bắt đầu hỏi những câu hỏi đơn giản hơn như:

Cho diện tích hình tròn được cho bởi Pi nhân với bán kính bình phương, hãy viết hàm để tính diện tích hình tròn.

Thật đáng ngạc nhiên, hơn một nửa số ứng viên không thể viết chức năng này trong bất kỳ ngôn ngữ (tôi có thể đọc hầu hết các ngôn ngữ phổ biến vì vậy tôi cho phép họ sử dụng bất kỳ ngôn ngữ nào họ chọn, bao gồm cả mã giả). Chúng tôi đã có "nhà phát triển C #", những người không thể viết chức năng này trong C #.

Tôi đã rất ngạc nhiên bởi điều này. Tôi đã luôn nghĩ rằng các nhà phát triển sẽ có thể viết mã. Dường như, ngày nay, đây là một ý kiến ​​gây tranh cãi. Chắc chắn đó là trong số các ứng cử viên phỏng vấn!

Biên tập:

Có rất nhiều cuộc thảo luận trong các ý kiến ​​về việc câu hỏi đầu tiên là câu hỏi tốt hay xấu, và liệu bạn có nên đặt câu hỏi phức tạp như câu hỏi này trong một cuộc phỏng vấn. Tôi sẽ không đi sâu vào vấn đề này ở đây (đó là một câu hỏi hoàn toàn mới) ngoài việc nói rằng bạn phần lớn đang thiếu điểm của bài viết .

Vâng, tôi đã nói mọi người không thể thực hiện bất kỳ bước tiến nào với điều này, nhưng câu hỏi thứ hai là tầm thường và nhiều người cũng không thể thực hiện bất kỳ bước tiến nào với câu hỏi đó! Bất cứ ai tự gọi mình là nhà phát triển sẽ có thể viết câu trả lời cho câu hỏi thứ hai trong vài giây mà không cần suy nghĩ. Và nhiều không thể.

Việc sử dụng ký hiệu của Lynn nên bị trừng phạt bằng cái chết.

Điều đó nên đủ gây tranh cãi;)

Các mẫu thiết kế đang làm tổn thương thiết kế tốt hơn là chúng giúp nó.

Thiết kế phần mềm IMO, đặc biệt là thiết kế phần mềm tốt quá đa dạng để được nắm bắt một cách có ý nghĩa trong các mẫu, đặc biệt là trong số ít mẫu mà mọi người thực sự có thể nhớ - và chúng quá trừu tượng để mọi người thực sự nhớ nhiều hơn một chút. Vì vậy, họ không giúp đỡ nhiều.

Mặt khác, có quá nhiều người say mê với khái niệm này và cố gắng áp dụng các mẫu ở khắp mọi nơi - thông thường, trong mã kết quả, bạn không thể tìm thấy thiết kế thực tế giữa tất cả các Singletons và các nhà máy trừu tượng (hoàn toàn vô nghĩa).

Ít mã hơn là tốt hơn!

Nếu người dùng nói "có phải vậy không?" Và công việc của bạn vẫn ở chế độ ẩn, điều đó đã đúng. Vinh quang có thể được tìm thấy ở nơi khác.

PHP hút ;-)

Bằng chứng là trong pudding.

Kiểm thử đơn vị sẽ không giúp bạn viết mã tốt

Lý do duy nhất để có các bài kiểm tra Đơn vị là để đảm bảo rằng mã đã hoạt động không bị hỏng. Viết bài kiểm tra trước, hoặc viết mã cho các bài kiểm tra là vô lý. Nếu bạn viết cho các bài kiểm tra trước mã, bạn thậm chí sẽ không biết các trường hợp cạnh là gì. Bạn có thể có mã vượt qua các bài kiểm tra nhưng vẫn thất bại trong các trường hợp không lường trước được.

Và hơn nữa, các nhà phát triển giỏi sẽ giữ sự gắn kết ở mức thấp, điều này sẽ khiến việc bổ sung mã mới khó có thể gây ra vấn đề với các công cụ hiện có.

Trong thực tế, tôi sẽ khái quát hóa hơn nữa,

Hầu hết các "Thực tiễn tốt nhất" trong Kỹ thuật phần mềm đều có để ngăn các lập trình viên xấu không gây ra quá nhiều thiệt hại .

Họ ở đó để nắm tay các nhà phát triển tồi và ngăn họ khỏi những sai lầm ngớ ngẩn. Tất nhiên, vì hầu hết các nhà phát triển đều xấu, đây là một điều tốt, nhưng các nhà phát triển tốt nên vượt qua.

Viết phương pháp nhỏ. Có vẻ như các lập trình viên thích viết các phương pháp loooong nơi họ làm nhiều việc khác nhau.

Tôi nghĩ rằng một phương thức nên được tạo ra bất cứ nơi nào bạn có thể đặt tên cho nó.

Thỉnh thoảng viết mã rác

Đôi khi một đoạn mã rác nhanh và bẩn là tất cả những gì cần thiết để hoàn thành một nhiệm vụ cụ thể. Các mẫu, ORM, SRP, bất cứ điều gì ... Ném lên Bảng điều khiển hoặc Ứng dụng web, viết một số sql nội tuyến (cảm thấy tốt) và đưa ra yêu cầu.

Mã == Thiết kế

Tôi không phải là người hâm mộ các sơ đồ UML tinh vi và tài liệu mã vô tận. Trong một ngôn ngữ cấp cao, mã của bạn phải dễ đọc và dễ hiểu. Tài liệu và sơ đồ phức tạp không thực sự thân thiện với người dùng hơn.

Đây là một bài viết về chủ đề Code as Design .

Phát triển phần mềm chỉ là một công việc

Đừng hiểu lầm tôi, tôi thích phát triển phần mềm rất nhiều. Tôi đã viết một blog trong vài năm qua về chủ đề này. Tôi đã dành đủ thời gian ở đây để có> 5000 điểm danh tiếng. Và tôi làm việc trong một công ty khởi nghiệp thường làm 60 giờ một tuần với số tiền ít hơn nhiều so với số tiền tôi có thể làm với tư cách là một nhà thầu vì đội ngũ này rất tuyệt vời và công việc rất thú vị.

Nhưng trong sơ đồ lớn của mọi thứ, nó chỉ là một công việc.

Nó có tầm quan trọng dưới nhiều thứ như gia đình, bạn gái, bạn bè, hạnh phúc, v.v. và dưới những thứ khác tôi muốn làm nếu tôi có nguồn cung cấp tiền mặt không giới hạn như đi xe máy, du thuyền, hoặc trượt tuyết.

Tôi nghĩ đôi khi rất nhiều nhà phát triển quên rằng phát triển chỉ là thứ cho phép chúng ta có những thứ quan trọng hơn trong cuộc sống (và có chúng bằng cách làm điều gì đó chúng ta thích) chứ không phải là mục tiêu cuối cùng.

Tôi cũng nghĩ không có gì sai khi kiểm soát nguồn nhị phân .. nếu có lý do chính đáng cho việc này. Nếu tôi có một hội đồng mà tôi không có nguồn cho và có thể không nhất thiết phải ở cùng một vị trí trên mỗi máy dev, thì tôi sẽ thường dán nó vào một thư mục "nhị phân" và tham chiếu nó trong một dự án bằng một đường dẫn tương đối .

Khá nhiều người dường như nghĩ rằng tôi nên bị đốt cháy vì đã đề cập đến "kiểm soát nguồn" và "nhị phân" trong cùng một câu. Tôi thậm chí biết những nơi có quy tắc nghiêm ngặt nói rằng bạn không thể thêm chúng.

Mọi nhà phát triển nên làm quen với kiến ​​trúc cơ bản của máy tính hiện đại. Điều này cũng áp dụng cho các nhà phát triển nhắm mục tiêu vào một máy ảo (thậm chí có thể hơn thế, bởi vì họ đã được nói đi nói lại rằng họ không cần phải lo lắng về việc quản lý bộ nhớ, v.v.)

Kiến trúc sư / Nhà thiết kế phần mềm được đánh giá quá cao

Là một nhà phát triển, tôi ghét ý tưởng của Kiến trúc sư phần mềm. Về cơ bản họ là những người không còn mã toàn thời gian, đọc tạp chí và bài viết, sau đó cho bạn biết cách thiết kế phần mềm. Chỉ những người thực sự viết phần mềm toàn thời gian để kiếm sống mới nên làm điều đó. Tôi không quan tâm nếu bạn là lập trình viên giỏi nhất thế giới 5 năm trước khi bạn trở thành Kiến trúc sư, ý kiến ​​của bạn là vô ích đối với tôi.

Làm thế nào mà gây tranh cãi?

Chỉnh sửa (để làm rõ): Tôi nghĩ rằng hầu hết các Kiến trúc sư phần mềm tạo ra các Nhà phân tích kinh doanh tuyệt vời (nói chuyện với khách hàng, yêu cầu viết, kiểm tra, v.v.), tôi chỉ đơn giản nghĩ rằng họ không có chỗ trong thiết kế phần mềm, trình độ cao hay cách khác.

Không có cách tiếp cận "một kích thước phù hợp với tất cả" để phát triển

Tôi ngạc nhiên rằng đây là một ý kiến ​​gây tranh cãi, bởi vì nó dường như đối với tôi như lẽ thường. Tuy nhiên, có nhiều mục trên các blog phổ biến thúc đẩy cách tiếp cận "một kích thước phù hợp với tất cả" để phát triển vì vậy tôi nghĩ rằng tôi thực sự có thể thuộc thiểu số.

Những điều tôi đã nhìn thấy được chào mời như là các cách tiếp cận chính xác cho bất kỳ dự án - trước khi bất kỳ thông tin được biết về nó - là những thứ như việc sử dụng các phát triển Test Driven (TDD), Domain Driven Design (DDD), Object-Relational Mapping (ORM) , Agile (viết hoa A), Định hướng đối tượng (OO), v.v ... bao gồm mọi thứ, từ phương pháp luận đến kiến ​​trúc đến các thành phần. Tất cả với các từ viết tắt thị trường tốt đẹp, tất nhiên.

Mọi người thậm chí dường như đi xa hơn khi đặt huy hiệu trên blog của họ như "Tôi đang thử nghiệm" hoặc tương tự, như thể việc họ tuân thủ nghiêm ngặt một cách tiếp cận duy nhất cho dù chi tiết của dự án dự án thực sự là một điều tốt .

Không phải vậy.

Chọn các phương pháp và kiến ​​trúc và các thành phần chính xác, v.v., là điều nên làm trên cơ sở từng dự án , và không chỉ phụ thuộc vào loại dự án bạn đang làm và các yêu cầu duy nhất của nó, mà còn cả quy mô và khả năng của nhóm bạn đang làm việc cùng.