Có những lợi thế cho các giá trị dữ liệu mã hóa cứng vào một chương trình?

Tôi là một lập trình viên tự học, mới làm quen, vì vậy tôi xin lỗi nếu tôi không đóng đinh các lập trình viên.

Tôi đang làm việc trong một dự án mà tôi đang cung cấp dữ liệu sẽ được cập nhật liên tục cho các nhà phát triển, những người về cơ bản sẽ tạo ra một công cụ để tạo báo cáo từ các truy vấn trên dữ liệu.

Dường như mọi người liên quan đều nghĩ rằng họ cần mã hóa các giá trị dữ liệu (không phải lược đồ, mà là chính các miền / giá trị) vào chương trình tạo báo cáo.

Ví dụ, giả sử chúng tôi đã báo cáo về nhân sự; báo cáo sẽ được chia thành các loại, với một tiêu đề cho từng bộ phận, và sau đó dưới mỗi tiêu đề của bộ phận sẽ là các tiêu đề phụ của chức danh, và dưới mỗi phân nhóm sẽ là một danh sách các nhân viên. Các nhà phát triển muốn mã hóa cứng các phòng ban và chức danh công việc. Mặt khác, tôi sẽ nghĩ rằng họ có thể / sẽ truy vấn những thứ đó trong thời gian chạy, sắp xếp các bản ghi theo chúng và tạo các tiêu đề báo cáo một cách linh hoạt dựa trên những giá trị nào ở đó.

Vì danh sách các giá trị tiềm năng sẽ thay đổi theo thời gian (ví dụ: các phòng ban sẽ được tạo / đổi tên, chức danh công việc mới sẽ được thêm vào), mã sẽ cần được cập nhật liên tục. Dường như với tôi rằng chúng ta có thể bỏ qua các bước bảo trì mã và tự động tổ chức các báo cáo.

Vì tôi không phải là nhà phát triển, tôi tự hỏi tôi đang thiếu gì. Những lợi thế nào có thể có đối với các giá trị mã hóa cứng vào một công cụ như thế này? Đây có phải là cách chương trình thường được thiết kế?

Wikipedia:

Mã hóa cứng (cũng là mã hóa cứng hoặc mã hóa cứng) đề cập đến thực tiễn phát triển phần mềm của việc nhúng những gì có thể, có lẽ chỉ khi nhìn lại, được coi là dữ liệu đầu vào hoặc cấu hình trực tiếp vào mã nguồn của chương trình hoặc đối tượng thực thi khác hoặc định dạng cố định của dữ liệu, thay vì lấy dữ liệu đó từ các nguồn bên ngoài hoặc tạo dữ liệu hoặc định dạng trong chính chương trình với đầu vào đã cho.

Mã hóa cứng được coi là một antipotype.

Được coi là chống mẫu, mã hóa cứng yêu cầu thay đổi mã nguồn của chương trình bất cứ khi nào dữ liệu đầu vào hoặc định dạng mong muốn thay đổi, khi người dùng cuối có thể thuận tiện hơn để thay đổi chi tiết bằng một số phương tiện bên ngoài chương trình.

Đôi khi bạn không thể tránh nó nhưng nó nên tạm thời.

Mã hóa cứng thường được yêu cầu. Các lập trình viên có thể không có giải pháp giao diện người dùng động cho người dùng cuối đã làm việc nhưng vẫn phải cung cấp tính năng hoặc phát hành chương trình. Điều này thường là tạm thời nhưng không giải quyết, trong một ý nghĩa ngắn hạn, áp lực để cung cấp mã. Sau đó, mã hóa mềm được thực hiện để cho phép người dùng truyền các tham số cung cấp cho người dùng cuối cách sửa đổi kết quả hoặc kết quả.

• Mã hóa tin nhắn làm cho việc quốc tế hóa một chương trình trở nên khó khăn.
• Đường dẫn mã hóa cứng khiến nó khó thích nghi với vị trí khác.

Ưu điểm duy nhất của mã hóa cứng dường như là cung cấp mã nhanh.

Có thật không? Không có trường hợp sử dụng hợp lệ có thể?

Mặc dù tôi đồng ý rằng mã hóa cứng nói chung là một mô hình chống hoặc ít nhất là mùi mã rất xấu , có rất nhiều trường hợp có ý nghĩa:

• đơn giản ( YAGNI ),
• đầu vào thực sự là hằng số và sẽ không bao giờ thay đổi (nghĩa là nó đại diện cho hằng số tự nhiên hoặc kinh doanh hoặc xấp xỉ một. Ví dụ 0, PI, ...),
• phần mềm nhúng (hạn chế bộ nhớ và phân bổ đến với tâm trí),
• phần mềm bảo mật (các giá trị này không có sẵn và / hoặc dễ giải mã hoặc kỹ sư đảo ngược, ví dụ: mã thông báo và muối mã hóa),
• mã được tạo (bộ xử lý trước hoặc trình tạo của bạn có thể định cấu hình được, nhưng tạo ra mã với các giá trị được mã hóa cứng),
• và có lẽ một vài nữa

Vẫn là Anti-Pattern ? Vì vậy, là Over-Kỹ thuật ! Đó là về Tuổi thọ của Phần mềm của bạn !!

Không phải là tôi đang nói có tất cả lý do tuyệt vời, và nói chung tôi sẽ chùn bước trước các giá trị được mã hóa cứng. Nhưng một số có thể dễ dàng vượt qua vì lý do hợp lệ.

Và đừng giám sát cái đầu tiên về tính đơn giản / YAGNI bằng cách nghĩ nó tầm thường: có lẽ không có lý do gì để triển khai trình phân tích cú pháp và trình kiểm tra giá trị điên rồ cho một tập lệnh đơn giản thực hiện tốt một trường hợp cho trường hợp sử dụng hẹp.

Thật khó để tìm thấy sự cân bằng. Đôi khi bạn không thấy trước rằng một phần mềm sẽ phát triển và tồn tại lâu hơn so với tập lệnh đơn giản mà nó bắt đầu. Tuy nhiên, thông thường, đó là cách khác: chúng tôi chế tạo quá nhiều thứ và một dự án được hoãn nhanh hơn bạn có thể đọc Lập trình viên thực dụng. Bạn đã lãng phí thời gian và công sức cho những thứ hơn là một nguyên mẫu ban đầu không cần.

Đó là ý nghĩa của Anti-Forms: chúng có mặt ở cả hai cực phổ và sự xuất hiện của chúng phụ thuộc vào độ nhạy cảm của người xem xét mã của bạn.

Đôi khi nó ổn với các giá trị mã cứng. Ví dụ: có một số số như 0 hoặc một hoặc nhiều giá trị n ^ 2-1 khác nhau cho bitmasks cần phải là giá trị nhất định cho mục đích thuật toán. Cho phép các giá trị như vậy vào cấu hình không có giá trị và chỉ mở ra khả năng xảy ra sự cố. Nói cách khác, nếu thay đổi một giá trị sẽ chỉ phá vỡ mọi thứ, nó có lẽ nên được mã hóa cứng.

Trong ví dụ bạn đưa ra, tôi không thấy mã hóa cứng sẽ hữu ích ở đâu. Tất cả mọi thứ bạn đề cập sẽ / nên có trong cơ sở dữ liệu bao gồm các tiêu đề. Ngay cả những thứ thúc đẩy bản trình bày (chẳng hạn như thứ tự sắp xếp) có thể được thêm vào nếu chúng không có ở đó.

Việc triển khai một giải pháp mạnh mẽ cho phép các giá trị có thể được mã hóa cứng thay vào đó có thể được cấu hình bởi người dùng cuối yêu cầu xác thực mạnh mẽ các giá trị đó. Họ đã đặt trong một chuỗi trống? Có phải họ đã đặt một cái gì đó không phải là số mà đáng lẽ nó phải là một con số? Có phải họ đang thực hiện SQL tiêm? Vân vân.

Mã hóa cứng tránh được rất nhiều rủi ro này.

Điều đó không phải để nói rằng mã hóa cứng luôn luôn, hoặc thậm chí thường xuyên, là một ý tưởng tốt. Đây chỉ là một trong những yếu tố cần tính đến.