Nên mã hóa thực hành tốt nhất luôn luôn được sử dụng [đóng]

Khi mã hóa phần mềm, kiến ​​trúc phải luôn luôn là thực tiễn tốt nhất hoặc thực tiễn thực tế liên quan đến ứng dụng đang được xây dựng?

Nếu tôi đang xây dựng một ứng dụng web hai trang có thể tồn tại 5 năm và có 2 cải tiến trong 5 năm đó, tôi có nên viết mã phụ thuộc, mẫu thiết kế, trình điều khiển chế độ xem mô hình với các mô hình xem, v.v.

Nên sử dụng mã hóa thực hành tốt nhất

Luôn luôn? Không, đó là ngớ ngẩn.

Thực hành tốt nhất là hướng dẫn. Đối với hầu hết mọi người, trong hầu hết các tình huống, nếu được thực hiện với một số khéo léo, họ sẽ mang lại kết quả tốt nhất. Chúng là nơi bạn bắt đầu khi xem xét các giải pháp. Nhưng sẽ có những nơi mà các thực tiễn tốt nhất có thể và nên được bỏ qua, bởi vì có những giải pháp tốt hơn.

Vấn đề là con người không thể nhìn vào tương lai. Và những người mới bắt đầu (và một nhóm những người không mới bắt đầu) chắc chắn nghĩ rằng họ đang ở trong kịch bản đặc biệt đó, nơi các quy tắc không áp dụng cho họ. Khi nghi ngờ, sử dụng các thực hành tốt nhất. Nhiều năm tranh luận và kinh nghiệm trên hàng tấn kỹ sư thông minh hơn bạn hoặc tôi đã tìm thấy họ để tạo ra kết quả tốt nhất quán. Nhưng không ai (hoặc hầu như không ai) biết vấn đề cụ thể của bạn cũng như bạn làm. Đôi khi bạn sẽ gặp phải trường hợp đặc biệt trong đó các quy tắc có thể bị bẻ cong.

Vâng. Đó là điều hiển nhiên. Tại sao bạn không làm những gì tốt nhất?

Đó không phải là vấn đề mặc dù. Phần khó là tìm ra cách thực hành tốt nhất của IS, bởi vì để trả lời rằng bạn cần biết chính xác những yêu cầu bạn có và dự án có khả năng phát triển như thế nào trong những năm qua, và điều đó thật khó khăn.

Tuy nhiên, một nguyên tắc tốt: KHÔNG phải là cách tốt nhất để lấy tên của một loạt các mẫu thiết kế và chỉ cần ghép chúng lại với nhau mà không cần suy nghĩ.

Ngoài ra, câu hỏi của bạn thực sự không thể được trả lời. Tìm ra chính xác "thực hành tốt nhất" là gì cho một tình huống nhất định là tất cả những gì về một kỹ sư phần mềm. Bạn sẽ phải thu hẹp nó để có câu trả lời tốt hơn.

Cách thực hành tốt nhất là cách đáp ứng hiệu quả nhất các yêu cầu về chức năng và phi chức năng của phần mềm đối với các tính năng, khả năng bảo trì, hiệu suất, v.v. Nếu thực tiễn đó xảy ra phù hợp với một số "tiêu chuẩn ngành", thì thật tuyệt vời. Nhưng nếu không, chủ nghĩa thực dụng sẽ thắng.

Nơi tôi hiện đang làm việc, chúng tôi đang xây dựng một giao diện người dùng web mới cho sản phẩm của chúng tôi từ đầu. Nó sẽ không được RESTful theo bất kỳ cách nào; nó sử dụng POST độc quyền. Nó không phải là đa tầng, không sử dụng bất kỳ dịch vụ siêu nhỏ nào và không sử dụng cơ sở dữ liệu NoQuery. Nó không có bất kỳ loại kiến ​​trúc nào như Enterprise Java.

Nói cách khác, nó hoàn toàn không phải là hông.

Nhưng nó được tích hợp một khung HTML5 hiện đại có tính năng cơ sở dữ liệu giống như Angular, tự động mở rộng cho các loại thiết bị khác nhau như điện thoại di động và máy tính để bàn, tích hợp với Giao diện người dùng Kendo của Telerik để thực hiện tất cả các công việc nặng, và được mã hóa và bảo mật hoàn toàn kênh dữ liệu.

Trên hết, nó sẽ được thực hiện trong 30 ngày, một kỳ tích mà sẽ cần một đội ngũ các nhà phát triển Java trong kiến ​​trúc Doanh nghiệp một năm để đạt được. Mã này là ES6 / Typecript; đó là một số mã sạch nhất tôi từng thấy.

Không . Thực hành tốt nhất là những điều thường được coi là điều tốt nhất để thực hiện 99% thời gian, nhưng điều đó không có nghĩa là chúng luôn áp dụng cho mọi tình huống.

Là một nhà phát triển, công việc của bạn là biết và sử dụng những thực tiễn tốt nhất đó, nhưng cũng biết khi nào an toàn để gạt chúng sang một bên.

Đây không phải là tự quảng cáo, nhưng gần đây tôi đã viết một bài đăng blog liên quan đến công việc của tôi trên nền tảng Salesforce.com chi tiết một trong những dịp này . Một trong những quy tắc vàng là "Không bao giờ thực hiện truy vấn bên trong vòng lặp", nhưng gần đây, lần đầu tiên sau 7 năm làm việc trên nền tảng, tôi có một lý do hoàn toàn hợp lệ để không tuân thủ quy tắc đó.

Điểm chính là nền tảng có giới hạn về số lượng truy vấn bạn có thể thực hiện trong ngữ cảnh thực thi nhất định, nhưng trong trường hợp này tôi phải truy vấn bên trong một vòng lặp để tránh hết dung lượng heap và biết rằng tôi sẽ truy vấn tốt giới hạn.

Vì vậy, điều này rất hiếm, nhưng có những lúc các thực tiễn tốt nhất không liên quan đến một kịch bản, vì vậy nếu chúng không phù hợp, đừng ép buộc chúng.

Tôi giả sử "thực hành tốt nhất" bạn có nghĩa là một số danh sách các quy tắc mà ai đó đã viết trong một cuốn sách. Tất nhiên nếu bạn có nghĩa là cụm từ theo nghĩa đen, thì tất nhiên bạn nên luôn luôn viết mã tốt nhất bạn có thể.

Tôi có cần chỉ ra rằng không có một tập hợp "thực hành tốt nhất" nào được chấp nhận rộng rãi không? Đối với bất kỳ quy tắc nào được thúc đẩy bởi một chuyên gia, bạn hầu như luôn có thể tìm thấy một chuyên gia khác có thông tin tương đương, người nói điều gì đó khác biệt.

Nhưng đến mức: Câu trả lời ngắn: thường, nhưng không phải luôn luôn.

Mỗi lĩnh vực có "thực tiễn tốt nhất" và "giải pháp sách giáo khoa". Chúng đại diện cho kinh nghiệm tích lũy và trí tuệ của nhiều người, nhiều người trong nhiều, nhiều năm và không nên bỏ qua. NHƯNG! Luôn luôn có những trường hợp đặc biệt, trường hợp bên lề, v.v ... Người thực sự có khả năng trong bất kỳ lĩnh vực nào biết khi nào nên tuân theo các quy tắc và khi nào nên phá vỡ chúng.

Tôi muốn nói chung: Bắt đầu bằng cách làm theo các quy tắc sách giáo khoa. Khi tuân theo các quy tắc trong sách giáo khoa dẫn đến rắc rối - sự phức tạp không cần thiết, hiệu suất kém, bất cứ điều gì - sau đó xem xét liệu việc phá vỡ quy tắc này một lần có thể không phải là một ý tưởng tốt hơn.

Nếu bạn bỏ qua các quy tắc và đi bất cứ nơi nào ý thích của bạn dẫn bạn, mã của bạn có thể sẽ là một mớ hỗn độn. Cho dù bạn thông minh đến đâu, bạn không phải là lập trình viên đầu tiên trên thế giới. Nó có ý nghĩa để học hỏi từ kinh nghiệm của người khác. Trong cuộc sống hàng ngày của chúng tôi, đây là lý do tại sao chúng tôi có cha mẹ và giáo viên và nhà thuyết giáo: vì vậy chúng tôi không phải lặp lại mọi sai lầm ngu ngốc để biết rằng đó là một sai lầm ngu ngốc.

Nhưng nếu bạn không tuân theo một danh sách các quy tắc từ một số cuốn sách 100% thời gian, bạn sẽ thường thấy mình mắc một cái chốt vuông vào một cái lỗ tròn. Những người đã viết ra quy tắc có thể không gặp phải trường hợp nào giống như bạn. Và ngay cả khi họ có, nếu nó hiếm đến mức họ có thể bỏ qua nó. Một quy tắc hoạt động 80% thời gian là một quy tắc tuyệt vời - miễn là bạn hiểu rằng nó hoạt động 80% thời gian chứ không phải 100% thời gian.

Tôi đã viết một cuốn sách về thiết kế cơ sở dữ liệu bao gồm nhiều quy tắc mà tôi khuyên các nhà thiết kế cơ sở dữ liệu tuân theo. (Tôi sẽ không đưa ra tiêu đề để tôi trông giống như tôi đang tự quảng cáo một cách đáng xấu hổ.) Tôi chắc chắn khuyến khích bất cứ ai muốn thiết kế cơ sở dữ liệu để đọc một cuốn sách như của tôi và học tất cả những gì họ có thể từ nó . Nhưng KHÓA HỌC có những lúc bạn nên phá vỡ các quy tắc tôi liệt kê.

Tôi đã từng viết một tài liệu tiêu chuẩn lập trình cho một nhóm các nhà phát triển mà tôi đã lãnh đạo vào thời điểm đó. Và quy tắc cuối cùng đã diễn ra như sau: "Nếu bạn có lý do chính đáng để phá vỡ một trong những quy tắc trên, thì hãy tiếp tục, NHƯNG bạn phải bao gồm một nhận xét trong mã của mình giải thích lý do tại sao bạn phá vỡ quy tắc. Nếu bạn không thể đến với một lý do chính đáng, sau đó làm theo quy tắc. Nếu viết bình luận gặp nhiều rắc rối hơn là tuân theo quy tắc, thì hãy tuân theo quy tắc. " Chúng tôi chỉ có một vài lần rằng ai đó tìm thấy việc phá vỡ một quy tắc đáng để giải thích tại sao.

Theo các thực tiễn tốt nhất , tôi giả sử bạn có nghĩa là "các quy tắc không chính thức mà cộng đồng phát triển phần mềm đã học theo thời gian có thể giúp cải thiện chất lượng phần mềm" và không phải là một cách tốt nhất để thực hiện một nhiệm vụ cụ thể.

Có, cho đến khi bạn có một lý do để không. Đó phải là một lý do chính đáng mà bạn đã cân nhắc nghiêm túc và áp dụng vào hoàn cảnh và giới hạn của nhiệm vụ trong tay. Điều đó có nghĩa là bạn hoàn toàn hiểu được thực hành và có thể áp dụng nó. Chúng ta đừng hiểu khái niệm này rằng nếu bạn không hiểu nó, thì đó không phải là kiểu suy nghĩ tốt nhất. Xem định nghĩa.

Bạn sẽ không luôn luôn làm những gì tốt nhất. Khi ông chủ nói với bạn, "Gửi mảnh rác này hoặc bạn bị sa thải!" Bạn sẽ gửi nó và có thể đi tìm một công việc khác, nhưng bạn vẫn sẽ giao nó. Đôi khi bạn sẽ thấy mình làm điều gì đó đủ tốt. Tất nhiên, bạn không muốn tạo thói quen này, nhưng đôi khi bạn phải làm cho những chiếc xe ngựa lăn và bạn không thể lo lắng về việc những con ngựa bị mù.

Một số điều quan trọng, một số thì không.

Bạn nên điều chỉnh sự lựa chọn của bạn về ngôn ngữ và phong cách cho vấn đề trong tầm tay.

Ví dụ, "Thực tiễn tốt nhất" để xử lý ngoại lệ có thể là luôn luôn bắt ngoại lệ và ghi nhật ký, nhưng khi tạo bài kiểm tra đơn vị, cách tốt nhất thường là để chúng loại bỏ để khung kiểm tra đơn vị có thể báo cáo chính xác.

Mặt khác, hãy xem xét quy tắc "DRY". Phấn đấu để mã không lặp lại luôn luôn tốt, không chỉ vì những lý do rõ ràng, mà còn bởi vì bạn càng viết mã theo cách mà bạn trở thành một lập trình viên giỏi hơn - đó là một cách tuyệt vời để rèn luyện kỹ năng mã hóa / tư duy của bạn thay vì các kỹ năng đánh máy và sao chép / dán của bạn và về lâu dài, bạn thường cảm thấy tốt hơn khi xem lại mã của mình (ngay cả khi bạn dự đoán đó là mã vứt đi) nếu bạn tuân theo một số quy tắc hợp lý.

Tóm lại, hãy linh hoạt nhưng đừng chỉ viết mã rác không thể đọc được vì bạn nghĩ đó là mã vứt đi.

Tôi sẽ cố gắng nhìn từ một góc độ khác.

Các khung hiện đại ngày nay giúp dễ dàng thiết lập một dự án cơ bản với mvc, tiêm phụ thuộc, kiến ​​trúc phân lớp, v.v. (người yêu khởi động mùa xuân ở đây). Tôi muốn nói bắt đầu với một cơ sở được tạo và sử dụng các công cụ được cung cấp cho bạn, cho đến khi bạn va vào một thứ gì đó đòi hỏi một giải pháp thủ công. Sau đó, bạn có thể cắt góc từ những thực tiễn tốt nhất.

Không khó để sử dụng một cái gì đó như Spring Boot cho ứng dụng web 2 trang, sau đó cuộn các servlet của riêng bạn, truy vấn jdbc và những thứ khác.

Theo kinh nghiệm của tôi, chỉ có một thực hành tốt nhất mà tôi cho là bắt buộc:

Giữ nó đơn giản, ngu ngốc (KISS)

Nói cách khác: Dù bạn chọn công cụ, API, kiến ​​trúc nào, v.v. - nếu bạn đơn giản, có thể dễ dàng làm việc trong tương lai, ít lỗi hơn, nhanh, hiệu quả bộ nhớ và mọi thứ khác bạn muốn.

Tất cả những điều khác mà mọi người nói về: Nguyên tắc, mô hình, thực tiễn, v.v. - Tôi coi đó là một công cụ mà tôi có thể chọn, chọn những công cụ phù hợp nhất với dự án mà tôi đang làm. Họ đều cung cấp các kỹ thuật và ý tưởng để giải quyết vấn đề. Bí quyết là tìm ra nếu bạn có những vấn đề đó ngay từ đầu.

"Thực tiễn tốt nhất" tốt nhất luôn chứa một phần mà bạn nên sử dụng trí thông minh và kinh nghiệm của mình để xác định khi các mục trong hướng dẫn không phù hợp. Chúng cũng có thể chứa một phần về đánh giá, phê duyệt và ghi lại các trường hợp ngoại lệ đó và biến chúng thành một phần của các thực tiễn "tốt nhất".

Khi mã hóa phần mềm, kiến ​​trúc phải luôn luôn là thực tiễn tốt nhất hoặc thực tiễn thực tế liên quan đến ứng dụng đang được xây dựng?

Trong Lý thuyết, vâng.

Trong thế giới thực, [vẫn] có, miễn là bạn có thể đủ khả năng để làm điều đó.

Điều đó, tất nhiên, có nghĩa là, "Không".

Áp lực về thời gian và tiền bạc sẽ luôn cố gắng đẩy bạn xuống con đường của một giải pháp "nhanh và bẩn", bởi vì nó mang lại giá trị "tốt hơn" cho khách hàng. Làm thế nào điều đó được thực hiện là không quan tâm đến khách hàng hoặc kế toán viên của họ. Nếu bạn có thể làm một công việc [tồi tệ] trong hai ngày hoặc hoàn hảo trong ba tháng, bạn nghĩ họ sẽ yêu cầu bạn làm gì?

Khoảng cách giữa hai - thực tiễn tốt nhất và những gì bạn phải "thoát khỏi" với - được gọi là "Nợ kỹ thuật"; hoàn toàn chấp nhận được, miễn là bạn có kế hoạch "trả nợ", tức là quay lại và cải thiện mọi thứ sau này. Một lần nữa, không phải cái gì bạn luôn luôn (bao giờ?) Có được ngân sách cho.

Một chiến thuật là phát hành phiên bản Beta sớm, có sửa lỗi "nhanh", nhưng đảm bảo rằng các cải tiến kiến ​​trúc cần thiết được ưu tiên trước khi phát hành "đầy đủ". Một lần nữa, không phải cái gì bạn luôn luôn (bao giờ?) Làm.