Điều này bao gồm các quyết định kiến trúc, lựa chọn nền tảng hoặc bất kỳ tình huống nào trong đó một lựa chọn tồi tệ như vậy dẫn đến hậu quả tiêu cực.
Điều này bao gồm các quyết định kiến trúc, lựa chọn nền tảng hoặc bất kỳ tình huống nào trong đó một lựa chọn tồi tệ như vậy dẫn đến hậu quả tiêu cực.
Câu trả lời:
Nhiều năm trước, tôi là nhà phát triển chính trên một ứng dụng tập trung vào cơ sở dữ liệu bắt đầu ném lỗi. Tôi đã theo dõi nó đến thực tế là có các giá trị trùng lặp trong trường cơ sở dữ liệu không nên cho phép chúng.
Tôi đã tự đánh mình về việc quên đặt một ràng buộc duy nhất cho cơ sở dữ liệu khi tôi đã đẩy nó vào sản xuất vì nó quá rõ ràng đến mức lĩnh vực này cần một. Tôi đã tuyên dương một trong những nhà phát triển đồng nghiệp đã sửa chữa cho tôi ...
Nhà phát triển khác : "Ồ, bạn không quên, có một ràng buộc duy nhất trên lĩnh vực đó. Tôi mới gỡ bỏ nó."
Tôi : "Tại sao bạn loại bỏ nó?"
Nhà phát triển khác : "Tôi đã làm điều đó một vài tuần trước. Tôi đã nhận được các tệp dữ liệu từ khách hàng và họ sẽ không nhập vì ràng buộc duy nhất đang chặn dữ liệu mới. Vì vậy, tôi đã xóa ràng buộc đó để tôi có thể hoàn tất việc nhập dữ liệu đó."
Tôi: "Bạn đã dừng lại để xem xét rằng có thể có vấn đề nếu chúng tôi nhận được dữ liệu mới trùng lặp với dữ liệu hiện có và suy nghĩ về việc đề cập đến ai đó trước khi nhập dữ liệu?"
Nhà phát triển khác : (nhìn chằm chằm trống)
Tôi : Facepalm.
Không chắc chắn nếu điều này được coi là một quyết định công nghệ , nhưng tôi chịu trách nhiệm cho một trang web quản lý tài liệu giống như CMS được viết bằng PHP trong bốn năm. Trong suốt những năm này, tôi đã cố gắng nhiều lần để khiến mọi người (người quản lý, người dùng, người yêu cầu tính năng) có lẽ, có thể, có thể , xem xét khả năng ngồi lại với nhau và suy nghĩ về các yêu cầu và hướng tương lai của sự việc. Nó không bao giờ xảy ra. Luôn luôn có thêm tính năng này, tính năng này, cộng thêm tính năng đó, và mọi người đều không biết gì về tất cả các cách khác nhau mà mọi người khác sử dụng trang web. Khi tôi rời đi, nó đã trở thành một mớ hỗn độn các tính năng liên kết với nhau nhưng không liên quan và tôi là người duy nhất trong toàn bộ công ty biết mọi tính năng. Bây giờ, không ai làm. Mwahaha.
Viết lại một hệ thống thư thoại cấp Telco.
Hệ thống trước đó đang chạy trên Unix và vào khoảng cuối thập niên 90, công nghệ COM của Microsoft đã xuất hiện. Nhiều nhà phát triển đã làm việc trên hệ thống dựa trên NT mới này. Sau rất nhiều nỗ lực, hiệu năng của nó vẫn không ở đâu gần với hệ thống Unix và một khách hàng lớn đã mua hệ thống mới này đã tức giận. Công ty đã phải bán và một số người phải rời khỏi công ty.
Thật là xấu xí. Tất cả điều này xảy ra khoảng hai năm trước khi Joel viết bài viết của mình: Những điều bạn không bao giờ nên làm, Phần I
Thông qua một thư viện bên ngoài (trong trường hợp này là Spring RCP ) trước phiên bản phát hành đầu tiên, dựa trên ảnh chụp nhanh SVN. Nó được đảm bảo khá nhiều rằng dự án sẽ kết thúc ít nhiều đã chết và bạn sẽ thấy mình bị trói vào xác chết. Vâng, trong trường hợp của chúng tôi nó có thể đã tồi tệ hơn. Vẫn là một rủi ro lớn.
Một ví dụ tôi nhớ lại liên quan đến việc cam kết với một máy chủ ứng dụng Java cụ thể từ sớm mặc dù thực tế là nó chưa có các tính năng cần thiết cho dự án, chỉ là một lộ trình khi chúng sẽ được thực hiện. Đương nhiên, nhà cung cấp đã không giao hàng kịp thời như đã chỉ ra ban đầu, đây đáng lẽ là một vấn đề lớn nhưng thực tế chỉ là một trong số rất nhiều trò chơi trên con đường chậm chạp dẫn đến thất bại.
Hầu hết các trường hợp của loại vấn đề mà tôi gặp phải đều liên quan đến việc cam kết một công nghệ chưa được chứng minh / chưa trưởng thành, thường bởi vì ai đó có ảnh hưởng ở khía cạnh kỹ thuật là người đề xuất phát triển theo định hướng.
Ba năm trước, bộ phận BusDev của chúng tôi cho biết họ phải xây dựng hệ thống mgmt nội dung của họ trên Documentum vì các công ty Pharma mà họ đang cố gắng để biết tên và cảm thấy thoải mái với công nghệ. Vì vậy, chúng tôi đã chi rất nhiều tiền để xây dựng nó sau đó tạm gác nó 12 tháng sau đó.
Vào tháng Hai năm nay, họ đã công bố hệ thống mới sẽ dựa trên Sharepoint 2010. Bạn muốn đoán tại sao? Bởi vì, đột nhiên, ĐÂY là cái tên được biết đến bởi Pharmas và là cái mà họ cảm thấy thoải mái!\ uSlackr
Viết hệ điều hành hiện đại bằng C / C ++. Chúng tôi đã biết từ sâu Worm (cuối thập niên 80) rằng đó là ngôn ngữ hoàn toàn không phù hợp để xây dựng phần mềm nối mạng, nhưng điều đó đã không ngăn cản bất kỳ ai làm điều đó, về cơ bản là do sơ suất hình sự IMO.
std::string, nhưng nó hoạt động và cùng với các mẫu lớp container có thể loại bỏ một lớp lớn các lỗi tiềm ẩn.
Những gì tôi trông thấy....
Trở lại những năm 1980, có một công ty tên Prime sản xuất máy tính chạy phiên bản cơ sở dữ liệu Pick và BASIC. Bộ phận người dùng của nơi tôi đang làm việc lúc đó đã mua một người hoàn toàn tin tưởng rằng điều này sẽ giúp họ tiết kiệm rất nhiều tiền, rằng họ sẽ nhận được xử lý và kết quả họ muốn với một nhà phân tích kinh doanh trong một phần tư thời gian. Không lâu lắm trước khi có bốn nhà phân tích lập trình viên toàn thời gian và tồn đọng công việc.
Sai lầm lớn trong việc ước tính những gì công nghệ sẽ làm cho họ.