Bạn đã bao giờ tham gia vào một phần thưởng LỚN chưa? [đóng cửa]

Joel Spolsky nói trong một trong những bài viết nổi tiếng của mình:

Một sai lầm chiến lược tồi tệ nhất mà bất kỳ công ty phần mềm nào cũng có thể mắc phải: viết lại mã từ đầu.

Chad Fowler đã viết:

Bạn đã xem các video, các bài đăng weblog và quảng cáo và bạn đã quyết định sẽ triển khai lại sản phẩm của mình trong Rails (hoặc Java, hoặc .NET hoặc Erlang, v.v.).

Coi chừng. Đây là một con đường dài hơn, khó hơn, dễ thất bại hơn bạn mong đợi.

Bạn đã bao giờ tham gia vào một phần thưởng LỚN chưa?
Tôi quan tâm đến trải nghiệm của bạn về chủ đề bi thảm này, và đặc biệt, trong bất kỳ bản viết lại lớn nào đã được hoàn thành thành công (nếu có).

Tôi đã tham gia vào một vài bài viết về sự nghiệp của mình và tất cả chúng đều là thảm họa. Tôi nghĩ tất cả đều thất bại vì những lý do tương tự

• Rất ít đánh giá cao nỗ lực cần thiết: Mỗi khi ai đó muốn viết lại, đó là vì hệ thống cũ đang sử dụng công nghệ cũ và khó bảo trì. Những gì họ không xem xét là vì tuổi của nó, nó có thể có 30-40 năm nỗ lực phát triển của nó. Nghĩ rằng bạn có thể viết lại toàn bộ trong 6 tháng với một nhóm 5 người là điều ngớ ngẩn.
• Mất kiến ​​thức: Hệ thống cũ đã tồn tại quá lâu, nó làm rất nhiều thứ và bị cuốn vào mọi thứ. Không có tài liệu cập nhật và không có một cơ quan có thẩm quyền nào thực sự biết tất cả những điều hệ thống làm. Sẽ có những phần kiến ​​thức với người dùng cụ thể trong các bộ phận cụ thể và việc tìm kiếm tất cả chúng là khó khăn hoặc không thể.
• Các quyết định quản lý kém: Việc viết lại mà tôi đã tham gia có một kỳ vọng tương tự từ ban quản lý: Hệ thống mới nên được thực hiện và hệ thống cũ có thể bị tắt vào một ngày, thời gian cụ thể. Không có lựa chọn nào khác được chấp nhận. Tôi nghĩ rằng họ có được điều này trong đầu, bởi vì họ đang dành tất cả số tiền này để thuê người mới cho dự án khổng lồ này. Trong thực tế, chiến lược giảm thiểu rủi ro tốt hơn là viết lại các chức năng chính của hệ thống cũ, nói rằng giải quyết 50-75% hệ thống cũ cho lần phát hành đầu tiên, và sau đó xem cách nó hoạt động! Vì số 1 và số 2 ở trên, điều này có thể sẽ hoạt động tốt hơn nhiều, khi chúng tôi tìm ra một số tính năng bị bỏ lỡ và những gì cần thiết để thực sự tắt hệ thống cũ.

Viết lại có thể rất thành công nếu bạn phạm vi chính xác. Tôi không biết liệu những điều này có đáp ứng ngưỡng dự án "LỚN" (TM) của bạn không, nhưng hãy để tôi mô tả cho bạn một vài lần viết lại thành công hơn.

Dự án 1

Công ty tôi làm việc có một hệ thống in dải kệ được sử dụng để tạo nhãn mà bạn nhìn thấy trên các kệ bán lẻ từ một thứ gọi là đồ thị . Biểu đồ được tạo ra trong phần mềm tiêu chuẩn công nghiệp và các công cụ của chúng tôi đọc tài liệu đó để tạo các dải kệ sử dụng mẫu cho cửa hàng mục tiêu. Phần mềm tạo khuôn mẫu là một mớ hỗn độn với các máy trạng thái hữu hạn lồng nhau kéo dài một số lớp và 3 DLL. Khi đến lúc thực hiện phương pháp chờ cấp bằng sáng chế (sau đó) để làm bảng ghim, rõ ràng mã hiện tại không thể hỗ trợ những gì chúng tôi muốn làm.

Giải pháp: Chúng tôi đã sắp xếp lại việc viết lại thành công cụ mẫu. Chúng tôi đã sử dụng thiết kế OO thích hợp để chăm sóc các yêu cầu hiện tại, cũng như giải quyết các yêu cầu về bảng ghim mới. Thời gian viết lại là 1 tháng. Nếu chúng tôi thực hiện viết lại toàn bộ quy mô của toàn bộ chuỗi công cụ thì nó sẽ mất hơn một năm - nhưng chúng tôi không cần phải làm điều đó.

Dự án 2

Một ứng dụng web mà nhóm chúng tôi xây dựng từ đầu đã bắt đầu vượt xa thiết kế ban đầu của nó. Khách hàng của chúng tôi cũng có một bộ các yêu cầu mới sẽ giúp trang web của chúng tôi tốt hơn rất nhiều cho người dùng của chúng tôi, tuân thủ "Web 2.0" hơn nếu bạn muốn. Mặc dù chúng tôi có thể đã cắm sừng thiết kế hiện tại của chúng tôi vào khuôn khổ mà chúng tôi hiện có, bảo trì là một cơn ác mộng. Chúng tôi biết ứng dụng một cách mật thiết, và chúng tôi biết phần nào chúng tôi phải đưa ra và phần nào sẽ biến mất như một phần của phiên bản mới.

Giải pháp: Nhóm của chúng tôi mất 3 tháng để hoàn thành - nó không tầm thường. Sản phẩm cuối nhanh hơn, có thể mở rộng hơn và thú vị hơn cho người dùng cuối. Chúng tôi đã vượt qua sự mong đợi của khách hàng. Điều đó nói rằng, chúng tôi đã phải chia nhóm của chúng tôi để các bản sửa lỗi và bản vá hỗ trợ băng tần ngay lập tức sẽ được thực hiện trên hệ thống hiện có trong khi nửa còn lại làm việc trên hệ thống mới. Chúng tôi đã thử nghiệm rộng rãi tại chỗ, và kết hợp sớm trong quá trình. Lý do làm việc này rất tốt là vì chúng tôi biết rõ ứng dụng này và khách hàng của chúng tôi.

Dự án 3

Tôi phải bao gồm một thất bại ở đây. Chúng tôi đã hỗ trợ một khách hàng cần một công cụ quản lý thông tin để sử dụng trong các tình huống thảm họa / khủng hoảng. Chúng tôi đã thừa hưởng một ứng dụng Java Swing mà các nhà phát triển ban đầu đã viết mà không thực sự hiểu về Swing. Điều đó có nghĩa là họ đã không tuân theo các khuyến nghị của Sun để đối phó với Swing và quản lý UI đúng cách, kết quả là bạn sẽ đi vào các vòng lặp sự kiện vô hạn và các vấn đề kỳ lạ và khó theo dõi khác. Kết quả là nó có rất nhiều lỗi, sự cố giao diện người dùng, v.v ... Đây là một ứng dụng rất phức tạp. Để giữ gìn sự tỉnh táo của chúng tôi, chúng tôi đã cố gắng viết lại ứng dụng Swing được viết kém thành một ứng dụng Swing được viết tốt.

Giải pháp: Chúng tôi đã hoàn thành việc viết lại trong khoảng 4,5 tháng khi chúng tôi ước tính 3 tháng. Ứng dụng hoạt động tốt hơn, cả về giao diện người dùng và lượng dữ liệu có thể xử lý. Sau đó, sóng thần năm 2004 đã xảy ra. Mức độ nghiêm trọng của số lượng người họ phải theo dõi đã chứng minh rằng Swing là công nghệ sai cho những gì họ thực sự cần. Chúng tôi không thể theo kịp hiệu suất của chúng tôi và cuối cùng họ đã từ bỏ công cụ này để ủng hộ một ứng dụng web được ghép lại với nhau được tạo bởi nhóm Oracle mà họ có trong nhà. Chắc chắn rằng chúng tôi có thể biện minh cho những gì chúng tôi đã làm dựa trên kiến ​​thức chúng tôi có vào thời điểm đó, nhưng việc viết lại không đủ mạnh mẽ và chúng tôi đã không nói với khách hàng của mình rằng các yêu cầu của họ đối với số người có thể cần phải theo dõi cũng vậy Thấp.

Phần kết luận

Viết lại đôi khi là cần thiết, và chúng có thể được hoàn thành thành công nếu bạn lập kế hoạch chính xác. Bạn có thể nhận được nhiều hơn với các bản viết lại được nhắm mục tiêu cho các phần của hệ thống so với các bản viết lại bán toàn bộ. Cuối cùng, điều khiến một dự án thất bại không nhất thiết phải viết lại. Trong khi chúng ta không bao giờ có thể thấu thị, chúng ta có thể đưa ra một số tình huống xấu nhất. Tôi đã học cách thiết kế các hệ thống của mình để hỗ trợ gấp đôi trường hợp xấu nhất mà tôi có thể nghĩ ra. Trong trường hợp với hệ thống quản lý khủng hoảng, điều đó là không đủ - con số thực tế gấp 20 lần kịch bản tồi tệ nhất mà chúng tôi được đưa ra. Nhưng đó không phải là trường hợp xấu nhất mà chúng ta có thể nghĩ đến.

• Viết lại vì lợi ích của việc viết lại không phải là bạn của bạn. Luôn có rất nhiều điều phức tạp bạn không thấy, và bạn sẽ thấy rằng những điều xấu xí mà bạn thấy là những công cụ đào tạo cho khách hàng của bạn. Luôn luôn hiển thị tiến trình hiện tại của bạn cho khách hàng của bạn theo định kỳ để họ có thể giúp bạn bắt được những vi phạm tồi tệ nhất.
• Viết lại được nhắm mục tiêu là hữu ích để đối phó với các vi phạm tồi tệ nhất trong cơ sở mã của bạn. Đừng viết lại toàn bộ nếu bạn có thể giới hạn phạm vi và giải quyết phần lớn các vấn đề của bạn.

Tôi đã tham gia với một số bản viết lại từ VB6 sang .NET. Trong 2 trường hợp, việc viết lại diễn ra suôn sẻ và chúng tôi thực sự đã hoàn thành trước thời hạn. Việc viết lại khác đã mất nhiều thời gian hơn dự kiến ​​nhưng hoàn thành mà không có bất kỳ vấn đề lớn.

Trong trường hợp cụ thể của chúng tôi, viết lại KHÔNG phải là quyết định tồi tệ nhất mà công ty chúng tôi có thể đưa ra. Kết quả cuối cùng thực sự ổn định hơn nhiều so với bản gốc và đưa chúng tôi vào một nơi tốt hơn nhiều.

Một trong những cái bẫy lớn nhất khi viết lại hoàn toàn một hệ thống hiện có là nghĩ rằng "Chúng ta không cần chỉ định hệ thống mới phải làm gì - rất đơn giản, nó chỉ phải làm chính xác những gì hệ thống cũ làm!" .

Vấn đề là rất có thể không ai biết chính xác hệ thống cũ làm gì và bạn sẽ dành vô số thời gian để làm cho hệ thống mới của bạn hoạt động theo cách mà những người dùng khác nhau của hệ thống cũ nghĩ rằng nó nên hoạt động. Các yêu cầu ban đầu của hệ thống cũ rất có thể không có sẵn.

Của tôi là một câu chuyện "thành công". Dự án của tôi liên quan đến một trang web chính với 4 trang web vệ tinh được quản lý / viết độc lập (tên miền phụ với các ứng dụng khác nhau trên đó). Chúng tôi có 4 cơ sở người dùng chính (tất cả trong các thư mục hoạt động riêng biệt) và không có cơ sở xác thực chung. 3 là các ứng dụng được thiết lập tốt và silo và vệ tinh thứ 4 là hoàn toàn mới và đã sao chép phần lớn mã cơ sở từ trang web được thiết lập nhiều nhất của chúng tôi.

Mục tiêu: Triển khai hệ thống nhận dạng toàn doanh nghiệp có thể xác thực tài khoản trên 4 tên miền và quản lý toàn bộ (với dịch vụ tự phục vụ) trong 1 trong số các tên miền. Vì .Net đã được triển khai trên các vệ tinh, nên trang web asp cổ điển đóng vai trò là "khách hàng tiềm năng" sẽ cần phải được viết lại, quản lý danh tính được thêm vào và tất cả các trang web sẽ cần kiểm tra hồi quy để đảm bảo không có dịch vụ nào bị ảnh hưởng.

Tài nguyên: 3 kiến ​​trúc sư chính - lập trình viên, quản lý danh tính, quản lý dự án. Khoảng 20 nhà phát triển, 10 nhà phân tích, 10 người thử nghiệm.

Thời gian hoàn thành (bắt đầu để kết thúc): 1,5 năm

Ra mắt thành công: Gần thất bại

Thành công lâu dài: Tuyệt vời

Tôi là kiến ​​trúc sư quản lý danh tính, vì vậy tôi đã thiết kế cơ sở dữ liệu, hệ thống con và giao diện logic mà tất cả các vệ tinh sẽ tương tác. Kiến trúc sư "lập trình viên" là một nhà phát triển hàng đầu với kiến ​​thức kinh doanh sâu rộng về tất cả các vệ tinh và kinh nghiệm với các ứng dụng và sự phát triển của chúng cho đến thời điểm đó.

Sau vài tháng thu thập các yêu cầu với 50 người khác nhau từ các phòng ban khác nhau trong tập đoàn của chúng tôi, chúng tôi đã xoay sở để có được kiến ​​trúc logic được giải quyết và bắt đầu đập ra mã. Do bản chất của sự thay đổi, chúng tôi đã phải viết lại trang web của riêng mình và tất cả các chức năng mà nó chứa trong .Net. Trong một số trường hợp, đó chỉ là vấn đề tái cấu trúc. Trong nhiều trường hợp, nó liên quan đến việc viết lại hoàn toàn các quy trình xung quanh nó. Trong 2 trường hợp, chúng tôi chỉ đơn giản là từ bỏ tính năng ban đầu là không quan trọng. Chúng tôi đã bỏ lỡ 2 thời hạn trong quá trình (nhưng cuối cùng đã đạt đến thời hạn ban đầu tôi đã đề xuất - hầu như không). Vào ngày ra mắt không có gì làm việc. Chúng tôi đã ra mắt vào thứ bảy vì vậy tác động khá nhỏ, nhưng tôi đã dành cả ngày để lướt qua nhật ký, viết lại các phần và đánh giá tải máy chủ. Thử nghiệm nhiều hơn có thể đã giúp.

Đến cuối ngày đầu tiên, tất cả các trang web đều hoạt động và mọi thứ đều hoạt động (tôi sẽ nói là thành công trên danh nghĩa). Trong suốt 2,5 năm qua, mọi thứ đều thành công rực rỡ. Có tất cả các trang web của chúng tôi trên một kiến ​​trúc chung với cơ sở khung chung đã giúp cho việc phát triển và nhà phát triển chéo hoạt động dễ dàng hơn nhiều. Các tính năng tôi đã viết vào trang web của chúng tôi 2,5 năm trước (trong quá trình viết lại của chúng tôi) đã được nhìn thấy / chấp nhận bởi một vài silo vệ tinh.

Chúng tôi đã tăng đăng nhập, theo dõi người dùng, tăng thời gian, một ứng dụng đơn lẻ chịu trách nhiệm xác thực / ủy quyền / nhận dạng. Các silo vệ tinh có thể tập trung hoàn toàn vào các ứng dụng của họ và có thể tin tưởng rằng bất kỳ vấn đề xác thực / ủy quyền nào tồn tại với ứng dụng quản lý danh tính.

Dự án của chúng tôi là rất nhiều thất vọng, đau lòng và thảm họa. Cuối cùng nó đã được đền đáp và sau đó một số. Tôi đồng ý 100% với đánh giá của Joel Spolsky về việc viết lại như một quy tắc chung, nhưng luôn có những trường hợp ngoại lệ. Nếu bạn đang xem xét viết lại, bạn chỉ cần đảm bảo đó hoàn toàn là những gì bạn cần. Nếu có, thì hãy chuẩn bị cho tất cả những nỗi đau đi kèm với nó.

Bây giờ tôi đang tham gia vào một mã viết lại khổng lồ ... vấn đề duy nhất là tôi là người duy nhất làm việc với nó! Chi phí bảo trì phần mềm hiện tại của chúng tôi rất cao, nó có rất nhiều lỗi và chúng tôi có 1 nhân viên FT bảo trì nó nên chúng tôi quyết định tự xây dựng.

Nó chậm hơn rất nhiều sau đó tôi mong đợi nó sẽ xảy ra nhưng cuối cùng tôi nghĩ nó sẽ tốt hơn rất nhiều vì chúng ta sẽ có cơ sở mã riêng để mọi thay đổi họ muốn trong tương lai có thể dễ dàng thực hiện (phần mềm cần thay đổi thường xuyên để theo kịp thời điểm hiện tại). Ngoài ra, chúng tôi đang thực hiện một số thay đổi lớn cho thiết kế trong khi chúng tôi viết lại nó.

Tôi đã tham gia viết lại hoàn chỉnh trong công việc trước đây của tôi. Và chúng tôi đã rất hạnh phúc khi làm như vậy. Chúng ta hãy nói rằng đôi khi codebase bị thối đến mức tốt hơn là bắt đầu lại.

Đó là một ứng dụng nội bộ - ứng dụng kinh doanh chính, trên thực tế.

Chúng tôi duy trì hệ thống cũ như chúng tôi đã viết phiên bản 2. Nếu tôi nhớ lại một cách chính xác, chúng tôi mất khoảng một năm (hai lập trình viên, và sau đó là một phần ba). Chúng tôi không cần phải chạm vào cơ sở dữ liệu, vì vậy ít nhất việc di chuyển dữ liệu không phải là vấn đề.

Tất cả phụ thuộc vào. Trong trường hợp của tôi, tôi đã làm theo lời khuyên của Joel Spolsky và tôi đã sai . Đó là về một trang web bảo hiểm. Trang web thật kinh khủng và đây là những gì tôi đã làm, sau đó là những gì tôi nên làm:

Chiến lược tồi : Tôi giám sát một nhóm 4 sinh viên:

• Sinh viên số 1 - viết lại truy cập / truy vấn cơ sở dữ liệu để đảm bảo an toàn
• Sinh viên # 2 - di chuyển tất cả các css "lên"
• Học sinh # 3 - làm cho tất cả các trang tương thích với w3c
• Học sinh số 4 - đã giải quyết tất cả các lỗi đang chờ xử lý
• Bản thân tôi: đã xóa tất cả các cảnh báo php và nội dung nhảm nhí (mã trùng lặp, v.v.)

Mất 2 tháng. Sau đó, chúng tôi thiết kế lại trang web. Sau đó, chúng tôi đã làm nó đa ngôn ngữ. Nói chung, chúng tôi phải giữ một phần lớn mã crappy và cấu trúc cơ sở dữ liệu vẫn giữ nguyên. Vì vậy, tôi vẫn đang làm việc trên những thứ nhảm nhí trong một năm nay và nó sẽ không bao giờ kết thúc cho đến khi chúng tôi quyết định viết lại hoàn toàn, điều này sẽ không bao giờ thực sự xảy ra.

Chiến lược tốt :

• Nghiên cứu toàn bộ trang web, tạo ra một "tài liệu yêu cầu sản phẩm" tốt.
• Thiết kế lại đúng cơ sở dữ liệu
• Bắt đầu từ đầu với khuôn khổ của riêng tôi (đã hoạt động)
• Thiết kế lại trang web.
• Làm đa ngôn ngữ.

Thời gian cần có: hai tháng ( có thể ít hơn ).

• Mã tốt.
• Bảo trì tốt.
• Năng suất.
• Không có câu trả lời như "chúng tôi không thể làm điều này, Trang web không thể xử lý các sản phẩm đó".

Vì vậy, những lời cuối cùng của tôi: tất cả phụ thuộc vào sự phức tạp của những thứ bạn phải viết lại .

Đừng ngần ngại sửa bài viết của tôi để làm cho nó đúng tiếng Anh, xin cảm ơn rất nhiều

Olivier Pons

Một công ty tôi làm việc đã bắt đầu một công cụ tái cấu trúc lớn của codebase.

Một nửa nhóm được thiết lập để làm việc trên bộ tái cấu trúc và nửa còn lại tiếp tục duy trì và cải tiến sản phẩm hiện có.

Như bạn có thể tưởng tượng, công cụ tái cấu trúc không bao giờ thực sự đi đến điểm mà mọi thứ hoạt động - đó chỉ là một quá trình liên tục không thực sự có bất cứ điều gì thể hiện cho chính nó.

Ý tưởng là codebase được tái cấu trúc sẽ hoạt động tốt hơn và chúng tôi chỉ có thể "thả" vào các tính năng mới mà nhóm đã thêm vào sản phẩm hiện có sau khi hoàn thành và "bắt kịp".

Nhưng cuối cùng, sự sụp đổ của công ty.

Tôi đã viết lại rất nhiều trong 3 năm qua. Bản gốc chúng tôi ước tính dự án mất 2 năm. Ý tưởng cơ bản là thay thế phần cứng, sử dụng HĐH hiện có, viết lại logic nghiệp vụ (từ c sang CPP), tạo thẻ IO mới và viết UI mới.

Trên đường đi, chúng tôi đã đưa ra một số quyết định khủng khiếp. Chúng tôi không có kinh nghiệm thực sự về CPP và không có người cố vấn để dạy nó tốt. Chúng tôi đã cố gắng xây dựng một khung công tác UI dựa trên win32. Phần cứng là rẻ và BSP thiếu sót. Phần mềm siêu linh hoạt nhưng khó bảo trì. Năm ngoái, chúng tôi đã loại bỏ UI được trồng tại nhà và phát triển UI trong .net. Chúng tôi cũng hoàn toàn viết lại cơ chế kiên trì và giao thức truyền dữ liệu.

Phải mất rất nhiều nỗ lực, nhưng bây giờ dự án gần như đã hoàn thành và các đơn vị đầu tiên được thử nghiệm trong lĩnh vực này. Dự án có nhiều rủi ro để có bất kỳ thay đổi nào để thành công. Có một số điều tích cực về dự án, chúng tôi bắt đầu sử dụng SVN (thay vì VSS), chúng tôi đã dành thời gian để viết các bài kiểm tra đơn vị và thực hiện một bản dựng hàng đêm. Chúng tôi cũng bắt đầu sử dụng scrum để có một quy trình tốt hơn.

Nhìn lại, tôi nghĩ rằng việc viết lại logic kinh doanh là không cần thiết, chúng ta chỉ nên tái hiện những phần xấu nhất. Và để viết UI từ đầu, đừng làm điều đó trừ khi đó là công việc cốt lõi của bạn.

Thật ra tôi đang bắt đầu một cuộc tái cấu trúc lớn. 4MLocs có lẽ nên giảm kích thước xuống 800KLocs hoặc ít hơn. Dự án này có rất nhiều Copy & Paste, hiểu nhầm các tính năng ngôn ngữ, rất nhiều ý kiến ​​vô dụng lặp đi lặp lại, các quyết định kém, hack tạm thời và hack nhiều hơn đã biến thành vĩnh viễn (bao gồm cả cách giải quyết), thiếu kiến ​​thức về các nguyên tắc cơ bản về Khoa học máy tính hoặc Kỹ thuật phần mềm. Có lẽ đội bảo trì gồm 32 lập trình viên xấu sẽ được thay thế bằng 2 người giỏi sau khi tái cấu trúc.

Tôi đã viết một công cụ viết blog trong 3 tuần. Tôi viết lại nó trong 8 giờ.

Lập kế hoạch trước là chìa khóa để viết lại thành công. Biết hệ thống bên trong và bên ngoài nó cũng là một lợi ích.

Cách đây hơn một thập kỷ, tôi đã làm việc cho một công ty quyết định thực hiện "thiết kế lại" sản phẩm cốt lõi cũ của họ. Kể từ đó, nhắc đến từ "thiết kế lại" là một hành vi phạm tội bị trừng phạt. Mất nhiều thời gian hơn dự kiến, rõ ràng là có giá cao hơn và sản phẩm mới giống với sản phẩm cũ hơn nhiều so với dự kiến ​​ban đầu.