Kiểm kê kỹ thuật ban đầu của trang web legacy

Tài liệu ban đầu về việc triển khai hiện tại của bizneshelper.ru đã được nhận.

Stack đã được xác nhận

• Ruby on Rails 3.2.21 — phiên bản framework legacy.
• Phiên bản Ruby không được ghim rõ ràng; dự án giả định một dải các phiên bản Ruby cũ tương thích, xấp xỉ 1.9.3–2.2.x. Để chạy lại cục bộ, Ruby 2.2.10 có vẻ là điểm khởi đầu hợp lý, nhưng tính tương thích cần được xác nhận bằng việc chạy thực tế.
• MySQL thông qua mysql2 ~> 0.3.11.
• Bundler 1.15.4.
• Một môi trường Solr riêng biệt được sử dụng để tìm kiếm toàn văn thông qua sunspot_rails / sunspot_solr.

Các phụ thuộc quan trọng

• devise — xác thực, bao gồm quyền truy cập quản trị.
• ckeditor — chỉnh sửa nội dung.
• paperclip ~> 3.0 — xử lý tệp và hình ảnh được tải lên.
• friendly_id ~> 4.0.9 — URL thân thiện với con người; rất quan trọng để phân tích các định tuyến hiện tại và giữ lại URL trong quá trình di chuyển.
• sunspot_rails, sunspot_solr — tìm kiếm; cần có Solr để tái tạo hoàn toàn hành vi legacy.
• omniauth và các nhà cung cấp mạng xã hội — các kịch bản OAuth lịch sử, tính liên quan của từng nhà cung cấp cần được kiểm tra riêng.
• will_paginate, simple_form — phân trang và biểu mẫu.

Cấu trúc dữ liệu và tệp

• db/ chứa 77 migration, schema.rb và seeds.rb; đây là nguồn quan trọng để khôi phục mô hình dữ liệu thực tế và lịch sử phát triển của nó.
• files/ chứa khoảng 1320 mục; danh mục này cần được đối chiếu riêng với các mô hình Paperclip và URL media công khai.
• public_html/ chứa các tài nguyên tĩnh cần được phân biệt với các trang do Rails tạo ra khi chuẩn bị sơ đồ di chuyển (migration map).
• solr/ chứa cấu hình tìm kiếm và phải được tính đến khi kiểm kê chức năng tìm kiếm.

Các tính năng công khai

• Giao diện quản trị có sẵn tại /admin và sử dụng Devise.
• Ngôn ngữ mặc định là tiếng Nga (config.i18n.default_locale = :ru).

Rủi ro kỹ thuật chính

1. Stack đã lỗi thời đáng kể, vì vậy việc chạy cục bộ trên một hệ thống hiện đại có thể yêu cầu môi trường legacy riêng hoặc container hóa.
2. therubyracer / libv8 có khả năng gây ra vấn đề khi build trên các hệ điều hành hiện đại.
3. mysql2 ~> 0.3.11 có thể không tương thích với các thư viện client MySQL hiện tại nếu không có các biện pháp bổ sung.
4. Việc tái tạo hoàn toàn tính năng tìm kiếm sẽ cần Solr; nếu không có nó, trang web có thể khởi động, nhưng một trong các kịch bản người dùng sẽ không đầy đủ.
5. Cần nghiên cứu friendly_id trước khi thiết kế các định tuyến cho haih-cms, vì các slug và quy tắc URL hiện tại có thể là một phần của tài sản SEO tích lũy.
6. Paperclip và thư mục files/ yêu cầu đối chiếu riêng: cần hiểu sơ đồ đường dẫn, liên kết với các mô hình và tỷ lệ các tệp thực sự được sử dụng.
7. Các nhà cung cấp OAuth thuộc về các tích hợp legacy; một số trong số chúng có thể không hoạt động hoặc không cần thiết trong phiên bản mới, vì vậy chúng không được tự động chuyển đổi như một chức năng bắt buộc.

Các bước tiếp theo cần kiểm tra

• Phiên bản Ruby thực tế thông qua các tệp lock/config/deploy hoặc chạy thử cục bộ thành công.
• Gemfile.lock và các phiên bản chính xác của tất cả các gem.
• schema.rb và các mô hình Rails: thành phần của các thực thể, mối quan hệ và các trường đính kèm của Paperclip.
• routes.rb: các định tuyến công khai thực tế, /admin, friendly_id và các chuyển hướng legacy.
• Bộ điều khiển (controllers) và giao diện (views): các loại trang công khai thực tế.
• Mối liên hệ giữa các tệp trong files/ với các bản ghi cơ sở dữ liệu.
• Việc sử dụng Solr trong các kịch bản người dùng.
• Tính thực tế của OAuth và các tích hợp bên ngoài khác.

Kết luận

Dự án là một nguyên khối Rails 3.2 legacy cổ điển với các hệ thống con lưu trữ tệp và tìm kiếm Solr riêng biệt. Để di chuyển sang haih-cms, điều quan trọng là trước tiên phải tái tạo mô hình dữ liệu hiện tại, các định tuyến và liên kết media, sau đó mới chuyển nội dung và tính năng. Cố gắng coi trang web chỉ như một tập hợp các trang HTML sẽ dẫn đến việc mất đi một phần đáng kể logic của hệ thống legacy.

Làm rõ về kết quả chạy cục bộ

Việc triển khai cục bộ trang web cũ (legacy) đã hoàn tất thành công, cho phép xác nhận một số dữ liệu trước đây chỉ là giả định.

Đã xác nhận

• Môi trường máy chủ ban đầu sử dụng Ruby 2.2.5 thông qua Passenger.
• Rails 3.2.21 tương thích khi chạy trong container trên Ruby 2.2.10.
• Ứng dụng cũ sử dụng MySQL qua kết nối mạng khi chỉ định rõ host.
• Nhánh ckeditor mới hơn không tương thích với Rails 3.2; phương án hoạt động yêu cầu cố định phiên bản 4.0.x tương thích.
• Dự án có chứa các thư mục và tệp đặc trưng của Rails 5 (app/channels, app/jobs), mặc dù ứng dụng chính vẫn là Rails 3.2. Điều này quan trọng cần lưu ý khi phân tích cấu trúc mã nguồn: không phải tất cả các tệp trong cây dự án đều là một phần của runtime cũ đang thực sự hoạt động.

Kết luận cho việc kiểm kê

Giờ đây, dự án có thể được nghiên cứu không chỉ tĩnh thông qua mã nguồn và tệp kết xuất (dump), mà còn động thông qua một bản sao đang chạy cục bộ. Điều này cho phép đối chiếu các mô hình, định tuyến và nội dung với hành vi thực tế của trang web, đồng thời giảm nguy cơ di cư nhầm các thành phần không được sử dụng hoặc còn sót lại từ lịch sử.

Ưu tiên tiếp theo là duyệt qua các tuyến đường công khai, kiểm tra liên kết media, tìm kiếm, biểu mẫu và phần quản trị, so sánh hành vi quan sát được với routes.rb, các mô hình và lược đồ cơ sở dữ liệu.

Điều chỉnh phạm vi kiểm kê

Kỹ thuật đảo ngược (reverse engineering) toàn diện ứng dụng Ruby không còn là mục tiêu nữa. Việc kiểm kê phải trả lời được câu hỏi thực tế: những thực thể, trường dữ liệu, phương tiện truyền thông (media), URL và kịch bản người dùng nào thực sự cần thiết cho trang web mới và quá trình di chuyển dữ liệu.

Trang web cũ (legacy) được sử dụng làm tài liệu tham khảo và dự phòng. Các phần không sử dụng của mã nguồn cũ và các đường dẫn lịch sử chỉ được nghiên cứu nếu chúng ảnh hưởng đến dữ liệu hoặc các tính năng công khai cần được chuyển đổi.

Kết luận về chất lượng bên trong của trang web cũ (Legacy)

Khi nghiên cứu cấu trúc dữ liệu, có thể nhận thấy rằng trạng thái bên ngoài của trang web có thể đánh giá thấp đáng kể độ phức tạp thực tế của dự án. Đối với người dùng cuối, một trang có thể trông hoàn toàn bình thường, nhưng bên trong, nội dung có thể được phân bổ qua các bảng và trường phi logic, và dữ liệu có ý nghĩa giống nhau lại được lưu trữ ở các nơi khác nhau.

Một ví dụ điển hình: nội dung chính của một trang thông thường được lưu trữ trong trường description, trong khi nội dung của trang chủ lại nằm trong các cài đặt hệ thống của trang web. Cấu trúc này không rõ ràng nếu không nghiên cứu mã nguồn và hành vi thực tế của ứng dụng.

Tại sao điều này lại quan trọng

Tổ chức nội bộ kém không chỉ ảnh hưởng đến chi phí bảo trì. Nó ảnh hưởng trực tiếp đến sự sẵn sàng của lập trình viên hoặc chủ sở hữu trong việc tiếp tục làm việc với trang web. Nếu ngay cả một thay đổi nội dung đơn giản cũng đòi hỏi phải nhớ các vị trí lưu trữ dữ liệu phi tiêu chuẩn, các đặc điểm của mã cũ và các ngoại lệ đối với logic chung, thì mọi thay đổi sẽ trở nên khó chịu và tốn kém hơn.

Theo thời gian, điều này thường dẫn đến việc trang web ít được chạm đến hơn, sau đó các bản cập nhật kỹ thuật bị trì hoãn, và cuối cùng dự án thực sự trở nên bị bỏ hoang, mặc dù bề ngoài vẫn tiếp tục hoạt động.

Kết luận cho việc triển khai mới

Cơ chế quản lý nội dung thuận tiện và có thể dự đoán được không phải là một cải tiến mang tính trang trí của CMS, mà là một phần thiết yếu cho sự tồn tại của trang web. Việc triển khai mới nên giảm chi phí cho các thay đổi hàng ngày và làm cho cấu trúc dữ liệu dễ hiểu mà không cần phải nghiên cứu nội bộ hệ thống mỗi lần.

Một trang web tốt không chỉ phải thuận tiện cho khách truy cập mà còn không gây ra sự kháng cự cho những người duy trì và quản lý nội dung của nó.