Làm thế nào để đánh giá các phần mở rộng của bên thứ 3?

Mặc dù Magento thực hiện rất nhiều 'ngoài luồng', chúng tôi đã tìm thấy có những tính năng và phương tiện chắc chắn cần thiết cho các cửa hàng khách yêu cầu gia hạn bên thứ 3.

Tuy nhiên, với bản chất của phương tiện, nó có thể là một đề xuất rủi ro để giới thiệu mã 'nước ngoài' cho một hệ thống phức tạp như vậy xử lý các giao dịch thương mại.

Bạn tìm kiếm gì khi đánh giá các phần mở rộng Magento? 'Cờ đỏ' bạn đã gặp là gì (hiệu suất, rủi ro bảo mật, thực tiễn xấu về kiến ​​trúc) là gì?

Dưới đây là một số suy nghĩ về việc đánh giá các Mô-đun của bên thứ 3:

Khái niệm cơ bản:

• Hỗ trợ phiên bản Magento hiện tại - Nó có hỗ trợ phiên bản Magento mới nhất (bao gồm cả phiên bản hiện tại mà chúng tôi đang phát triển) không?

  Nếu một mô-đun không hỗ trợ bản phát hành mới nhất của Magento, có lẽ sẽ khó để làm cho nó hoạt động mà không dành thời gian phát triển quý giá cho nó.

• Hỗ trợ - Các nhà phát triển đã tạo mô-đun có hỗ trợ sản phẩm không?

  Một trong những dấu hiệu của một mô-đun lành mạnh là các nhà phát triển tích cực hỗ trợ nó. Nếu họ không ủng hộ thì đó là cờ đỏ, tại sao họ không ủng hộ sản phẩm nếu nó tốt?

  Ngoài ra, khi một mô-đun được hỗ trợ, chúng ta thường có thể nhận thông tin quan trọng từ các nhà phát triển bằng một email đơn giản (ví dụ: mô-đun này sử dụng jQuery hoặc Prototype).

• Nhận xét - Người dùng khác nói gì? Kinh nghiệm của họ thế nào?

  Bằng cách đọc các đánh giá, chúng ta có thể hiểu rõ hơn về bức tranh lớn, có vấn đề gì về cài đặt không? Các nhà phát triển có trả lời kịp thời và hữu ích không? Nó có hoạt động như quảng cáo không?

• Hoàn lại tiền - Họ sẽ trả lại tiền cho bạn nếu nó không hoạt động như dự định?

  Nhiều lần chúng tôi muốn thử mô-đun để chúng tôi có thể kiểm tra nó, nếu nó hoạt động và đáp ứng các thông số kỹ thuật tuyệt vời của chúng tôi! Nhưng nếu không, chúng tôi muốn tùy chọn trả lại và nhận tiền hoàn lại cho nó.

Trung gian:

• Ghi đè lớp - Mô-đun có ghi đè bất kỳ lớp lõi nào không?

  Nói chung, một mô-đun tốt không nên ghi đè bất kỳ lớp lõi nào, thay vào đó, nó nên sử dụng Trình quan sát.

  Một lý do cho điều này, là nó có thể làm cho việc nâng cấp Magento trở nên khó khăn. Ngoài ra, các mô-đun khác có thể phụ thuộc vào một đầu ra từ một chức năng nhất định và mô-đun này đang cung cấp một mô-đun khác.

  Đôi khi điều này là không thể làm được, nếu đây là trường hợp, nên có một lý do rất chính đáng tại sao nó lại ghi đè một lớp cốt lõi.

• Cập nhật bố cục - Mô-đun có thay đổi một số cài đặt bố cục của tôi không?

  Một số mô-đun thay đổi cài đặt bố cục cho trang web của bạn (ví dụ: trang sản phẩm), đảm bảo rằng nó không phá vỡ bố cục hiện tại của bạn và nếu nó thực hiện những gì sẽ được yêu cầu (đọc: chúng tôi sẽ mất bao nhiêu thời gian) để khắc phục .

• Thay đổi mẫu - Mô-đun có bao gồm các mẫu thay đổi thiết kế hiện tại của tôi không?

  Mô-đun này sẽ giới thiệu các mẫu mới? Nếu có, họ sẽ phá vỡ thiết kế của tôi? Sẽ mất bao nhiêu thời gian để thiết kế theo cách chúng ta muốn?

• Phụ thuộc - Mô-đun có phụ thuộc vào bất kỳ mô-đun nào khác không?

  Nếu mô-đun phụ thuộc vào người khác, chúng tôi cần đảm bảo rằng chúng ở đó và được cài đặt. Ngoài ra, chúng ta cần phải tự hỏi mình, chúng ta có muốn tắt mô-đun mà nó phụ thuộc trong tương lai không?

Nâng cao:

• Các kịch bản nâng cấp SQL - Mô-đun có cập nhật DB theo một cách nào đó không?

  Khi một mô-đun cập nhật cơ sở dữ liệu, chúng ta cần đảm bảo một vài điều.

  Nó có cập nhật một bảng cốt lõi? Nếu có, điều đó không tốt, chúng tôi muốn cơ sở dữ liệu của chúng tôi sạch sẽ và sẵn sàng để nâng cấp.

  Liệu nó lưu trữ thông tin một cách hợp lý? Nếu chúng ta muốn lấy dữ liệu thô từ cơ sở dữ liệu, liệu chúng ta có thể hiểu ý nghĩa của nó không?

• Sự kiện - Mô-đun có quan sát hoặc gửi bất kỳ sự kiện nào không?

  Nếu một mô-đun gửi hoặc quan sát các sự kiện, chúng tôi muốn biết:

  Những sự kiện nào nó đang quan sát / gửi đi? Điều này sẽ ảnh hưởng đến một mô-đun khác làm việc trong hệ thống. Ví dụ: nếu một trong các mô-đun của chúng tôi thay đổi tên của sản phẩm đang tải thành chữ hoa và mô-đun này thêm từ 'miễn phí' vào tên của sản phẩm đang tải, thì nó sẽ hoạt động như thế nào? Từ 'miễn phí' cũng sẽ xuất hiện trên?

• Xem lại mã - Mô-đun có sử dụng các kỹ thuật mã hóa chấp nhận được không?

  Điều này có liên quan nhiều đến các kỹ thuật mã hóa PHP hơn Magento.

  Mã có sử dụng các khối Thử / Bắt không?

  Liệu mã thoát khỏi đầu vào của người dùng?

  Các chi tiết cụ thể của việc này thực sự phụ thuộc vào mức độ / yêu cầu kỹ năng của chúng tôi.

• Các vấn đề tiềm ẩn - Những vấn đề tiềm năng nào có thể xảy ra do cài đặt mô-đun này?

  Hãy thử tưởng tượng năm vấn đề hàng đầu có thể xảy ra nếu chúng ta cài đặt mô-đun này, thật đáng ngạc nhiên vì nó có thể thực sự mang lại cái nhìn sâu sắc cho toàn bộ dự án.

Tóm lại:

Tất cả những điều này là tốt đẹp để có trong một thế giới lý tưởng, trong các kịch bản thế giới thực, chúng ta cần phải làm điều này được gọi là 'thỏa hiệp' :)

Ngoài ra, các hướng dẫn này có ý nghĩa giúp chúng tôi, không gây trở ngại cho chúng tôi, do đó, nếu chúng tôi chỉ cài đặt một mô-đun, giả sử mô-đun chia sẻ xã hội và dành cho khách hàng cần thiết lập trang web đơn giản, ở đó không có ý nghĩa trong việc thực hiện một tấn nghiên cứu.

Nói cách khác: Đó là tất cả về hiệu quả với thời gian của chúng tôi, nếu sử dụng hướng dẫn (mục này) sẽ giúp tôi tiết kiệm thời gian trong thời gian dài sử dụng nó, nếu không bỏ nó và tiết kiệm sự tỉnh táo của bạn.

Một số cờ đỏ "thực hành xấu" cụ thể của Magento là:

• bất kỳ mã nào trong app/code/local/Mage
• các mẫu được ghi đè (các tệp trong app/designđó đã tồn tại trong lõi)
• viết lại các lớp học thiết yếu như catalog/product. Nói chung, tôi xem xét cẩn thận mỗi lần viết lại, để xem liệu nó có thể tránh được không
• vi phạm nghiêm trọng các tiêu chuẩn mã hóa Zend / Magento. Mặc dù đây chỉ là về định dạng mã, tôi kết luận rằng các nhà phát triển bất cẩn về tiêu chuẩn rất có thể sẽ bất cẩn về những thứ khác, quan trọng hơn, cũng vậy.
• thay đổi trong bảng cơ sở dữ liệu cốt lõi
• văn bản được mã hóa cứng trong các mẫu (không sử dụng cơ chế dịch) và các nơi khác
• logic nghiệp vụ trong các mẫu (quy tắc ngón tay cái: bất kỳ sự xuất hiện nào Mage::getModeltrong thư mục mẫu thường là một dấu hiệu xấu)

Một số cờ đỏ liên quan đến PHP (đây là danh sách rất chọn lọc và không đầy đủ):

• bất kỳ Thông báo và Cảnh báo nào có báo cáo lỗi được kích hoạt ( E_STRICT)
• sử dụng của @nhà điều hành
• không vệ sinh dữ liệu người dùng trước khi xuất

Một số cờ đỏ liên quan đến hiệu suất:

• truy vấn cơ sở dữ liệu bên trong các vòng lặp
• tải toàn bộ bộ sưu tập chỉ để sử dụng một phần của nó

Ngoài ra, hãy chú ý đến Mùi Mã chung , những lá cờ đỏ không cần thiết nhưng giúp ước tính chất lượng tổng thể.

Bước # 1 - Khách hàng của bạn có đủ khả năng hỗ trợ tiện ích mở rộng này nếu nhà phát triển đi AWOL không?

Nếu không, bạn không thể sử dụng phần mở rộng.

Nếu có, tiến hành đánh giá mở rộng.

Những người tốt ở Inchoo có một bài viết về phân tích mã mô-đun của bên thứ 3. Bài viết đề cập đến việc viết lại lớp, công việc định kỳ, cập nhật bố cục và quan sát sự kiện.

Tôi đã tìm thấy mã trình quan sát sự kiện để có tiềm năng đạt hiệu suất cao nhất. Hãy chú ý đến tài nguyên chuyên sâu, mã bên thứ 3 chạy cho các sự kiện được gửi thường xuyên. Các sự kiện như, control_action_predispatch hoặc tải bộ sưu tập.

Tôi sử dụng mô-đun tiện ích này từ Prattski để có cái nhìn tổng quan về viết lại và quan sát viên.

Có bất kỳ mẫu và tài sản giao diện nào nằm trong mặc định / mặc định (hoặc pro hoặc doanh nghiệp) thay vì cơ sở / mặc định là khá khó chịu.

Mã Obfuscated là một cái gì đó để đề phòng - tìm kiếm các cuộc gọi đến eval (), base64_decode () và tương tự. Điều này thường được sử dụng để xác thực giấy phép, nhưng có thể độc hại hoặc đáng sợ - Tôi đã thấy ít nhất một thành phần đánh giá mã độc lập từ nguồn cấp RSS.

Tìm kiếm các cuộc gọi dl () - ít nhất một thành phần cổng thanh toán mà tôi thấy yêu cầu cài đặt tiện ích mở rộng PHP để thực hiện các kết nối của nó!

Bạn đúng rồi.

Thật không may là không có phép thuật: bạn phải kiểm tra chúng, kiểm tra mã để xem nó có phát triển tốt không, có hỗ trợ tốt cho các mô-đun thương mại nhờ vào diễn đàn của họ hoặc nhanh chóng trả lời câu hỏi của bạn ...

Có một số đánh giá về Magento Connect và sự phổ biến của tiện ích mở rộng có thể giúp biết liệu nó có giá trị hay không nhưng thành thật mà nói bạn có thể tìm thấy các mô-đun rất phổ biến với nhiều lỗi. Tôi đã có một ví dụ hay vào tuần trước với mô-đun MailChimp, chủ yếu được thực hiện tốt nhưng tôi phải sửa một số lỗi và cung cấp chúng cho nhà phát triển. Luôn có rủi ro, bạn phải kiểm tra.

WebShopApp đã có ý tưởng để đi theo hướng này, ý tôi là mang đến một nền tảng để có được thông tin tốt về các mô-đun. Ý tưởng là đẩy Magento theo hướng này. Vì vậy, chất lượng mô-đun là một câu hỏi thực tế.

Lời khuyên của tôi: hãy hết sức chú ý đến các mô-đun có tập lệnh cài đặt / nâng cấp thay đổi giá trị trong các bảng cốt lõi bởi vì không phải lúc nào cũng dễ dàng khôi phục loại thay đổi đó.

Thử nghiệm số 1 mà tôi có thể đưa ra là tìm ra cách khai thác 0 ngày trong mã của họ (thường không khó lắm với các tiện ích mở rộng Magento), chỉ báo cáo thiệt hại do khai thác giả cho nhóm bảo mật của họ (không đưa ra dấu hiệu nào một phần của mã dễ bị tấn công) và bắt đầu đồng hồ bấm giờ - bởi vì đây chính xác là điều sẽ xảy ra khi trang web của bạn bị hack. Khi nhân viên hỗ trợ của họ yêu cầu quyền truy cập FTP và mysql toàn cầu, hãy từ chối một cách lịch sự rằng nó vi phạm PCI-DSS và đề nghị cho phép họ truy cập chỉ đọc vào kho lưu trữ mã nguồn của bạn.

Bài kiểm tra số 2 mà tôi thực hiện là gọi cho nhà cung cấp và bắt họ cảnh giác. Hỏi họ về loại thử nghiệm hành vi / đơn vị nào họ thực hiện, họ sử dụng hệ thống kiểm soát nguồn nào, phiên bản PHP nào họ thử nghiệm, phiên bản nào của Magento được thử nghiệm, máy chủ web nào được thử nghiệm, cho dù họ có sử dụng trình duyệt hay không -stack để kiểm tra các thành phần đầu cuối, v.v ... Nếu nhà cung cấp không biết bạn đang nói về điều gì, hãy im lặng hoặc muốn "nhờ một chuyên gia gửi email lại cho bạn", hãy chạy như địa ngục vì rất có thể họ sử dụng số tệp zip cho "kiểm soát phiên bản" và chỉ sửa lỗi 3 tháng sau khi khách hàng của họ báo cáo.

Nói về PCI-DSS, tất cả các sửa đổi hệ thống cũng được yêu cầu phải có chiến lược đảo ngược. Với các mô-đun thêm các cột không thể rỗng vào các bảng cốt lõi, điều này trở nên không thể thực hiện được trong khi vẫn duy trì chiến lược đảo ngược sẽ vượt qua kiểm toán. Chạy như địa ngục từ bất kỳ mô-đun nào sẽ gây ra sự cố (đọc: Lỗi SQL) khi bị tắt.

PCI-DSS v3

6.4.5.4 Thủ tục rút lui.

Xác minh rằng các quy trình sao lưu được chuẩn bị cho mỗi thay đổi được lấy mẫu.

Đối với mỗi thay đổi, cần có các quy trình sao lưu tài liệu trong trường hợp thay đổi không thành công hoặc ảnh hưởng xấu đến bảo mật của ứng dụng hoặc hệ thống, để cho phép hệ thống được khôi phục về trạng thái trước đó.

Điều này, ngoài các câu trả lời khác. IMO nên có một bức tường xấu hổ cho một số crap nguy hiểm đã được sinh ra trên nền tảng này.