Đầu tiên, một chút về lý lịch. Tôi đang mã hóa một tra cứu từ Tuổi -> Tỷ lệ. Có 7 dấu ngoặc tuổi nên bảng tra cứu có 3 cột (Từ | Đến | Tỷ lệ) với 7 hàng. Các giá trị hiếm khi thay đổi - chúng là tỷ lệ được luật hóa (cột thứ nhất và thứ ba) giữ nguyên trong 3 năm. Tôi đã hiểu rằng cách dễ nhất để lưu trữ bảng này mà không cần mã hóa cứng là trong cơ sở dữ liệu trong bảng cấu hình toàn cầu, vì một giá trị văn bản duy nhất chứa CSV (vì vậy "65,69,0,05,70,74,0,06" là cách các lớp 65-69 và 70-74 sẽ được lưu trữ). Tương đối dễ dàng để phân tích sau đó sử dụng.
Sau đó, tôi nhận ra rằng để thực hiện điều này, tôi sẽ phải tạo một bảng mới, một kho lưu trữ để bọc xung quanh nó, kiểm tra lớp dữ liệu cho repo, kiểm tra đơn vị xung quanh mã hủy kết nối CSV vào bảng và kiểm tra xung quanh việc tra cứu. Lợi ích duy nhất của tất cả công việc này là tránh mã hóa bảng tra cứu.
Khi nói chuyện với người dùng (những người hiện đang sử dụng bảng tra cứu trực tiếp - bằng cách nhìn vào một bản sao cứng), ý kiến khá nhiều là "tỷ lệ không bao giờ thay đổi". Rõ ràng điều đó không thực sự chính xác - tỷ lệ chỉ được tạo ra ba năm trước và trong quá khứ những thứ "không bao giờ thay đổi" đã có thói quen thay đổi - vì vậy đối với tôi để lập trình phòng thủ này, tôi chắc chắn không nên lưu trữ bảng tra cứu ứng dụng.
Ngoại trừ khi tôi nghĩ YAGNI . Tính năng tôi đang triển khai không xác định rằng giá sẽ thay đổi. Nếu giá thay đổi, chúng vẫn sẽ thay đổi, hiếm khi bảo trì thậm chí không được xem xét và tính năng không thực sự đủ quan trọng để mọi thứ sẽ bị ảnh hưởng nếu có sự chậm trễ giữa thay đổi tốc độ và ứng dụng được cập nhật.
Tôi đã quyết định khá nhiều rằng sẽ không có gì có giá trị nếu tôi mã hóa việc tra cứu và tôi không quá quan tâm đến cách tiếp cận của tôi đối với tính năng đặc biệt này. Câu hỏi của tôi là, như một chuyên gia, tôi đã biện minh đúng đắn cho quyết định đó? Các giá trị mã hóa cứng là thiết kế xấu, nhưng sẽ gặp khó khăn trong việc loại bỏ các giá trị khỏi ứng dụng dường như vi phạm nguyên tắc YAGNI.
EDIT Để làm rõ câu hỏi, tôi không quan tâm đến việc thực hiện thực tế. Tôi lo ngại rằng tôi có thể làm điều nhanh, xấu và biện minh bằng cách nói YAGNI, hoặc tôi có thể thực hiện một cách tiếp cận phòng thủ, nỗ lực cao hơn, ngay cả trong trường hợp tốt nhất cuối cùng cũng có lợi ích thấp. Là một lập trình viên chuyên nghiệp, quyết định của tôi để thực hiện một thiết kế mà tôi biết là thiếu sót chỉ đơn giản là đi đến phân tích chi phí / lợi ích?
EDIT Mặc dù tất cả các câu trả lời đều rất thú vị vì tôi nghĩ rằng điều này thuộc về lựa chọn thiết kế của một cá nhân, tôi nghĩ rằng câu trả lời tốt nhất là của @ Corbin và @EZ Hart khi họ đưa ra những điều mà tôi đã xem xét trong câu hỏi:
- sự phân đôi sai của 'loại bỏ chính xác các giá trị được mã hóa cứng' bằng cách di chuyển nó vào cơ sở dữ liệu so với 'áp dụng hiệu quả YAGNI' bằng cách sử dụng mã hóa cứng. Có một tùy chọn thứ ba là đặt bảng tra cứu vào cấu hình ứng dụng, điều này không phát sinh chi phí chính xác và không có hiệu quả của YAGNI. Chúng tôi thường không giới hạn ở một trong hai hoặc quyết định, và sau đó đi đến quyết định chi phí / lợi ích.
- việc tạo mã có thể giảm chi phí di chuyển các giá trị được mã hóa cứng vào cơ sở dữ liệu và theo cách đó cũng loại bỏ quyết định quá kỹ thuật của tôi để xử lý CSV vào bảng. Có khả năng điều này cũng thêm một vấn đề bảo trì dài hạn với mã được tạo nếu các yêu cầu cơ bản thay đổi cho phương thức tra cứu. Tất cả điều này chỉ ảnh hưởng đến phân tích chi phí / lợi ích và có khả năng là nếu tôi có sẵn sự tự động hóa đó, tôi thậm chí sẽ không xem xét việc mã hóa cứng như thế này.
Tôi đánh dấu câu trả lời của @ Corbin là chính xác vì nó thay đổi các giả định của tôi về chi phí phát triển và có lẽ tôi sẽ thêm một số công cụ tạo mã vào kho vũ khí của mình trong tương lai gần.