Đáng tiếc nhất thiết kế hoặc quyết định lập trình bạn đã thực hiện? [đóng cửa]

Tôi muốn nghe những loại quyết định thiết kế bạn đã thực hiện và làm thế nào chúng phản tác dụng. Vì một quyết định thiết kế tồi, cuối cùng tôi đã phải ủng hộ quyết định tồi tệ đó (tôi cũng có một phần trong đó). Điều này khiến tôi nhận ra rằng một lỗi thiết kế duy nhất có thể ám ảnh bạn mãi mãi. Tôi muốn học hỏi từ những người có kinh nghiệm hơn về loại sai lầm mà họ đã trải qua và họ đã học được gì từ họ.

Tôi chắc chắn rằng điều này sẽ giúp ích rất nhiều cho các lập trình viên khác bằng cách giúp họ không lặp lại những quyết định đó.

Cảm ơn vì đã chia sẽ kinh nghiệm của bạn.

Bỏ qua YAGNI , hết lần này đến lần khác ...

"WIll do it later"
"Later" không bao giờ đến.

C ++, thừa kế ảo nhiều hình kim cương . Bạn có được ý tưởng.

Cấu hình trong một ứng dụng là tốt đẹp. Quá nhiều cấu hình là một cơn ác mộng để sử dụng và bảo trì.

Từ một trong những sai lầm của tôi, tôi đã học được rằng bình thường hóa DB không nên bị theo dõi một cách mù quáng. Bạn có thể, và trong một số tình huống, bạn PHẢI làm phẳng các bảng của mình.

Tôi đã kết thúc việc quản lý vô số bảng (thông qua các mô hình) và hiệu suất không tốt như có thể với một chút làm phẳng cho các bảng.

Sử dụng một char trong cơ sở dữ liệu cho các trạng thái, v.v. lên khá khó hiểu, hoặc chạy ra ngoài (không phải cho các trạng thái, nhưng những thứ khác). Tốt hơn hết là chỉ đưa phiên bản có thể đọc được của con người vào và cũng có trong mô hình Java của bạn (trong trường hợp của tôi) một enum với các giá trị khớp.

Tôi đoán đây là một hình thức tối ưu hóa sớm không cần thiết và mù quáng. Như thể sử dụng một char duy nhất sẽ cứu thế giới những ngày này. Ngoài booleans Y / N trong cơ sở dữ liệu không hỗ trợ booleans / bit.

Không phát triển Lớp truy cập dữ liệu phù hợp và có sql ở mọi nơi trong mã của tôi, chỉ để có được thứ gì đó "nhanh chóng" hoạt động. Sau này, khi dự án bắt đầu mở rộng và các yêu cầu thay đổi, nó trở thành một cơn ác mộng. Lúc đó tôi không biết DAL là gì.

... rất vui vì tôi đã vượt qua điều đó, mặc dù tôi vẫn thấy các lập trình viên với hơn 20 năm "kinh nghiệm" làm việc này.

Nghĩ rằng tôi có thể là Kiến trúc sư, Nhà phát triển và PM tất cả trong cùng một dự án.

2 tháng ngủ 3 tiếng mỗi đêm đã dạy tôi rằng bạn không thể làm điều đó.

Kết hợp các lớp Microsoft Foundation (MFC) để viết Java IDE.

Đó không phải là quyết định của tôi (tôi đã gia nhập công ty sau đó một chút) nhưng ở đâu đó tôi làm việc đã đưa i18n đi quá xa, bao gồm cả việc dịch tất cả các thông điệp tường trình của họ.

Các kết quả:

• Đau đớn hơn để thêm đăng nhập mới
• Thêm chi phí dịch thuật
• Nhật ký khó đọc hơn sau đó

Úi.

Phát minh lại bánh xe

Làm quá nhiều thiết kế . Tạo nhiều sơ đồ UML, đặc biệt là sơ đồ tuần tự cho mọi hoạt động đơn lẻ, phần lớn trong số đó cuối cùng hóa ra vô dụng. Cuối cùng, hóa ra lượng thời gian đáng kể có thể đã tiết kiệm được bằng cách bỏ qua các thiết kế / sơ đồ chi tiết không cần thiết và bắt đầu mã hóa trực tiếp.

Khách hàng tin tưởng biết những gì họ muốn và sau đó làm quá nhiều trước khi kiểm tra với họ.

Quyết định thiết kế tồi tệ nhất của tôi? Quay trở lại những năm 1980, tôi đã làm việc trong một dự án nơi chúng tôi có ý tưởng sáng tạo để tạo ra một loại mẫu cho màn hình nhập dữ liệu của chúng tôi sẽ được diễn giải vào thời gian chạy. Một quyết định không tồi: nó làm cho màn hình đầu vào dễ dàng thiết kế. Về cơ bản chỉ cần tạo một tệp giống với màn hình nhập dữ liệu, với một số mã đặc biệt để xác định nhãn là gì so với trường đầu vào là gì và để xác định xem trường nhập là alpha hay số. Sau đó, tôi quyết định thêm một số mã đặc biệt hơn vào các tệp này để xác định những xác nhận nào sẽ được thực hiện. Sau đó, tôi đã thêm nhiều mã hơn để cho phép xây dựng màn hình có điều kiện, trường X chỉ được bao gồm khi một số điều kiện là đúng, v.v. Sau đó, tôi đã thêm nhiều mã để thực hiện một số xử lý đơn giản cho các đầu vào. Vân vân. Cuối cùng, chúng tôi đã biến mẫu màn hình của mình thành ngôn ngữ lập trình mới, hoàn chỉnh với các biểu thức, cấu trúc điều khiển và thư viện i / o. Và để làm gì? Chúng tôi đã làm rất nhiều công việc để phát minh lại FORTRAN. Chúng tôi đã có một kệ đầy đủ các trình biên dịch cho các ngôn ngữ được thiết kế tốt hơn và được kiểm tra tốt hơn. Nếu chúng ta dành nhiều nỗ lực đó để xây dựng các sản phẩm mà chúng ta thực sự có chuyên môn, công ty đó vẫn có thể kinh doanh cho đến ngày nay.

Quá hăng say áp dụng YAGNI (được gọi là Thiết kế bởi Enumeration trong Cạm bẫy của Object Oriented Development ) trong một môi trường mà bất kỳ người nào hợp lý có thể nói rằng các yêu cầu đã được chắc chắn sẽ thay đổi. Và thay đổi nhiều lần.

Nếu bạn (cứng-) mã hóa mọi thứ chính xác theo yêu cầu hiện tại, trong khi đánh bại bất cứ ai nói rằng "không thể chung chung hơn sao?" với trung tâm mua sắm YAGNI của bạn và sau đó các yêu cầu thay đổi mạnh mẽ (nhưng theo cách có thể dự đoán một cách hợp lý), thì đó có thể là sự khác biệt giữa mất 2 tuần để thích nghi, so với mất 20 phút.

CẬP NHẬT: Để làm rõ, đây là một ví dụ hư cấu không quá xa so với những gì đã xảy ra. Stack Overflow được thiết kế để hỗ trợ huy hiệu, nhưng giả sử lúc đầu họ chỉ có thể nghĩ ra bốn huy hiệu. Chỉ có bốn, một con số nhỏ như vậy, vì vậy họ đã mã hóa cứng hỗ trợ cho chính xác bốn huy hiệu trong toàn bộ logic trong trang web. Trong cơ sở dữ liệu, trong thông tin người dùng, trong tất cả các mã hiển thị. Bởi vì "Ya sẽ không cần" bất kỳ huy hiệu nào mà bạn không thể nghĩ ra, phải không? Giả sử sau đó trang web đi vào hoạt động và mọi người bắt đầu đề xuất các huy hiệu mới. Mỗi huy hiệumất tới hai tuần để thêm, bởi vì có quá nhiều mã hóa cứng để điều chỉnh mọi nơi. Tuy nhiên, "Ya sẽ không cần" bất kỳ huy hiệu nào nhiều hơn danh sách ngày nay, vì vậy không bao giờ có bất kỳ tái cấu trúc nào để hỗ trợ một bộ huy hiệu chung. Một bộ sưu tập chung như vậy có mất thêm thời gian trước không? Không nhiều, nếu có.

YAGNI là một nguyên tắc có giá trị, nhưng nó không nên được sử dụng để bào chữa cho thiết kế kém và mã hóa không phù hợp. Có một sự cân bằng, và với kinh nghiệm, tôi tin rằng tôi đang tiếp cận nó.

Nguồn nhân lực không đủ

Cố gắng làm một cái gì đó đúng và tuyệt vời với những người sai!
Ngay cả khi họ đang ở trong vai trò của một PM bản ngã không cần thiết (điều này khá phổ biến, đặc biệt là ở các công ty lớn, nơi sự bất tài của họ có thể tồn tại trong một thời gian dài hơn).

Mỗi lần tôi tạo nợ kỹ thuật, viết mã thủ tục, bỏ qua các bài kiểm tra viết, v.v. bởi vì tôi đang gấp rút. Gần như chắc chắn tôi thấy điều này tạo ra nỗi đau cho tôi xuống đường.

Sử dụng Dịch vụ tích hợp máy chủ SQL (SSIS).

Tôi không muốn nó trên kẻ thù tồi tệ nhất của tôi.

Sau khi xây dựng một số gói SSIS trong hai tháng qua, chỉ để biết rằng các gói tôi đã phát triển không thể phân phối được và không thể triển khai. Cụ thể trong một môi trường không có web, không có SQL Server được cấp phép.

Đây là một tình huống rất tồi tệ, khi bạn có ít hơn 48 giờ để viết lại các gói SSIS của mình bằng mã .NET POCO thuần túy hoặc bỏ lỡ thời hạn được nhắm mục tiêu.

Điều làm tôi ngạc nhiên là tôi đã có thể viết lại ba gói SSIS (tôi mất hai tháng để thử nghiệm và phát triển), trong vòng 12 giờ bằng mã .NET thuần túy, với Bộ điều hợp OLEDB và Bộ điều chỉnh SQL.

SSIS không thể phân phối và sẽ không thực thi các gói từ máy khách nếu nó không có giấy phép SQL Server được cài đặt trên đó (Cụ thể là DTSPipeline.dll). Điều này sẽ là tuyệt vời để biết lên phía trước. Tôi thấy từ chối trách nhiệm ngay bây giờ (bản in đẹp) trên MSDN. Điều đó không tốt khi bạn có mã ví dụ trên internet chỉ sử dụng mã máy SQL-LICENSED. Về cơ bản, bạn phải tạo một dịch vụ web sẽ nói chuyện với máy chủ SQL của bạn, để chạy các gói SSIS của bạn theo chương trình. Bạn không thể thực thi chúng từ mã .NET thuần túy, trừ khi bạn đã cài đặt giấy phép SQL trên máy thực thi. Làm thế nào là không thực tế? Microsoft có thực sự mong đợi SSIS sẽ được sử dụng từ các máy yêu cầu cài đặt máy chủ SQL không? Thật là một sự lãng phí hoàn toàn trong hai tháng.

Công ty của tôi sẽ không bao giờ sử dụng SSIS nữa vì bản in "gotcha" nhỏ này.

Không xác định cơ chế / mô hình triển khai càng sớm càng tốt.

Ném một số quả trứng Phục sinh 'hài hước' vào một số mã tôi đã viết trước khi đi nghỉ 2 tuần. Tôi nghĩ tôi sẽ là người duy nhất đọc nó khi tôi quay lại, nó sẽ khiến tôi cười thầm và sẵn sàng viết lại mã.

Không cần phải nói, ông chủ của tôi đã không ấn tượng khi anh ta xem xét nó khi tôi đi vắng, và anh ta thậm chí còn ít ấn tượng hơn khi một trong những 'quả trứng Phục sinh' liên quan đến khuôn mặt của anh ta hoạt hình vui nhộn trong ASCII.

Ừm ...

Sử dụng Chủ đề ASP.Net khi chỉ là một thư mục CSS thông thường sẽ hoàn thành tốt.

Đi theo con đường nhanh để làm cho một số mã hoạt động, thay vì đường đúng (bit chung, nhưng chúng tôi sẽ gọi đó là một sự trừu tượng và do đó là một câu trả lời 'đúng').

Công ty của tôi có một mô hình phát triển giống như thác nước, nơi người dùng doanh nghiệp và nhà phân tích kinh doanh của chúng tôi sẽ xác định các yêu cầu cho các dự án. Trong một trong những dự án "lớn" của chúng tôi, chúng tôi đã nhận được rất nhiều yêu cầu và tôi nhận thấy một số yêu cầu chứa chi tiết triển khai , cụ thể là thông tin liên quan đến lược đồ cơ sở dữ liệu của chúng tôi được sử dụng bởi hệ thống kế toán của chúng tôi.

Tôi đã nhận xét với người dùng doanh nghiệp rằng việc triển khai là miền của tôi , không nên chứa trong các yêu cầu. Họ không sẵn lòng thay đổi yêu cầu của mình bởi vì, sau tất cả, họ là KINH DOANH, và nó chỉ có ý nghĩa đối với kế toán để thiết kế phần mềm kế toán. Là một nhà phát triển thấp kém trong cuộc thăm dò ý kiến ​​totem, tôi được trả tiền để làm thay vì suy nghĩ . Nhiều như tôi đã chiến đấu với nó, tôi không thể thuyết phục họ viết lại các yêu cầu - có quá nhiều giấy tờ và băng đỏ xung quanh những thay đổi mà nó quá rắc rối.

Vì vậy, tôi đã cho họ những gì họ yêu cầu. Ít nhất, nó sắp xếp hoạt động , nhưng cơ sở dữ liệu được thiết kế kỳ lạ:

• Rất nhiều bình thường hóa không cần thiết. Một bản ghi chứa 5 hoặc 10 trường được chia thành 3 hoặc 4 bảng. Tôi có thể giải quyết vấn đề đó, nhưng cá nhân tôi muốn có tất cả các trường 1: 1 được kéo vào một bảng duy nhất.

• Rất nhiều sự không chuẩn hóa không phù hợp. Chúng tôi có một bảng lưu trữ dữ liệu hóa đơn lưu trữ nhiều hơn dữ liệu hóa đơn. Chúng tôi lưu trữ một số cờ linh tinh trong bảng InvoiceData, ngay cả khi cờ không liên quan về mặt logic với bảng InvoiceData, sao cho mỗi cờ có một giá trị Khóa chính được mã hóa cứng và tất cả các trường khác bị vô hiệu hóa trong bảng InvoiceData. Vì cờ được biểu diễn dưới dạng bản ghi trong bảng, tôi đề nghị kéo cờ vào bảng riêng.

• Nhiều sự không chuẩn hóa không phù hợp hơn. Một số cờ trên toàn ứng dụng được lưu trữ dưới dạng cột trong các bảng không phù hợp, như việc thay đổi cờ của ứng dụng yêu cầu cập nhật mọi bản ghi trong bảng.

• Khóa chính chứa siêu dữ liệu, sao cho nếu khóa chính varchar kết thúc bằng "D", chúng tôi sẽ tính toán hóa đơn bằng một bộ giá trị, nếu không, chúng tôi sẽ tính toán nó bằng một bộ khác. Sẽ có ý nghĩa hơn khi kéo siêu dữ liệu này vào một cột riêng hoặc kéo tập hợp các giá trị để tính toán vào một bảng khác.

• Khóa ngoại thường đi đến nhiều bảng, sao cho khóa ngoại kết thúc bằng "M" có thể liên kết với bảng tài khoản thế chấp của chúng tôi, trong khi khóa ngoại kết thúc bằng "A" có thể liên kết với bảng tài khoản tự động của chúng tôi. Sẽ dễ dàng hơn để chia dữ liệu thành hai bảng, MortageData và AutoInsuranceData.

Tất cả những lời đề nghị của tôi đã bị bắn hạ với nhiều tiếng khóc lóc và nghiến răng. Ứng dụng này hoạt động như thiết kế, và trong khi nó là một quả bóng lớn, tất cả các vụ hack khó chịu, trường hợp đặc biệt và các quy tắc kinh doanh kỳ lạ đều được ghi lại một cách mỉa mai và hài hước trong mã nguồn.

Bám sát công nghệ cũ hơn vì có vẻ quá rắc rối khi để khách hàng của bạn nâng cấp lên phiên bản .NET framework mới, nhưng thực sự sẽ mất nhiều thời gian phát triển hơn để tạo phần mềm vì bạn không thể sử dụng một số thành phần (tiết kiệm thời gian) của phiên bản khung mới hơn.

Trở lại trường đại học, tôi đang thực hiện dự án thiết kế cao cấp của mình. Một anh chàng khác và tôi đang viết một hệ thống theo dõi lỗi dựa trên web. (Không có gì đột phá, nhưng cả hai chúng tôi đều muốn có được một số trải nghiệm web.) Chúng tôi đã làm điều đó với các máy chủ Java và nó hoạt động khá tốt, nhưng vì một số lý do ngớ ngẩn, thay vì chọn sử dụng Ngoại lệ làm cơ chế xử lý lỗi, chúng tôi đã chọn để sử dụng mã lỗi.

Khi chúng tôi trình bày dự án của chúng tôi cho một lớp và một trong các giảng viên đã hỏi không thể tránh khỏi, "Nếu bạn phải làm lại, bạn sẽ làm gì khác?" Tôi ngay lập tức biết câu trả lời: "Tôi sẽ sử dụng ngoại lệ, đó là những gì họ đang ở đó."

Không phải lựa chọn phương pháp của tôi, nhưng đã tạo XSLT để chuyển đổi tệp XML dựa trên hàng thành báo cáo HTML dựa trên cột.

Nó chỉ hoạt động trong IE, hoàn toàn không thể giải mã cách nó hoạt động. Mỗi khi chúng tôi cần mở rộng nó, vô cùng khó khăn và mất nhiều thời gian.

Cuối cùng, tôi đã thay thế bằng một tập lệnh C # nhỏ bé cũng làm điều tương tự.

cố gắng sử dụng tất cả các công nghệ mới (để tìm hiểu công nghệ mới) mặc dù nó thậm chí còn yêu cầu ..

Tôi đã không mất đủ thời gian để đánh giá mô hình kinh doanh. Tôi đã làm những gì khách hàng yêu cầu, nhưng 6-12 tháng sau, cả hai chúng tôi đã đi đến kết luận rằng nó nên làm khác đi.

Thiết kế mà không có một đặc điểm kỹ thuật.

Tôi đã thực hiện một phần phụ của một ứng dụng theo yêu cầu.

Nó chỉ ra rằng các yêu cầu đã được tăng cường và mạ vàng, và mã của tôi được thiết kế quá mức. Tôi nên thiết kế phần phụ của mình để chỉ hoạt động với những gì tôi đã thêm vào lúc đó, nhưng lên kế hoạch thêm tất cả những thứ khác mà không bao gồm hỗ trợ chung cho nó ngay từ đầu.