Як оцінити розширення сторонніх розробників?

Хоча Magento робить багато "поза коробкою", ми виявили, що тут неминуче є функції та засоби, необхідні для клієнтських магазинів, які потребують розширення сторонніх розробників.

Однак, зважаючи на характер носія, може бути ризикованою пропозицією запровадити «іноземний» код до такої складної системи, що займається комерційними операціями.

На що ви звертаєте увагу, оцінюючи розширення Magento? Які "червоні прапори", на які ви натрапили (прагнення до експлуатації, ризики безпеки, погані архітектурні практики)?

Ось кілька думок щодо оцінювання сторонніх модулів:

Основи:

• Поточна підтримка версії Magento - чи підтримує вона останню версію Magento (включаючи поточну, для якої ми її розробляємо)?

  Якщо модуль не підтримує останню версію Magento, можливо, буде складно змусити його працювати, не витрачаючи на нього дорогоцінний час.

• Підтримка - Чи підтримують продукт розробники, які створили модуль?

  Однією з ознак здорового модуля є те, що розробники активно підтримують його. Якщо вони не підтримують це червоний прапор, то чому б вони не підтримали продукт, якщо він хороший?

  Крім того, коли модуль підтримується, ми можемо отримувати важливу інформацію від розробників за допомогою простої електронної пошти (наприклад, чи використовує цей модуль jQuery або прототип).

• Відгуки - Що кажуть інші користувачі? Яким був їхній досвід?

  Читаючи огляди, ми можемо краще зрозуміти велику картину, чи є проблема з установкою? Чи реагують розробники своєчасно та корисно? Чи працює вона як рекламується?

• Повернення коштів - Чи повернуть вам гроші, якщо це не вийде за призначенням?

  Багато разів ми хочемо випробувати модуль, щоб ми могли його перевірити, якщо він працює і відповідає нашим специфікаціям чудово! Але якщо цього немає, ми хочемо повернути його та отримати повернення за нього.

Проміжні:

• Перекриття класу - Чи модуль перекриває будь-які основні класи?

  Взагалі хороший модуль не повинен перекривати жодні основні класи, скоріше він повинен використовувати Observers.

  Однією з причин цього є те, що це може ускладнити модернізацію Magento. Крім того, інші модулі можуть залежати від одного виходу з певної функції, і цей модуль забезпечує інший.

  Іноді це неможливо зробити, якщо це так, то має бути дуже вагома причина, чому він перекриває основний клас.

• Оновлення макета - чи змінює модуль деякі мої настройки макета?

  Деякі модулі змінюють налаштування макета на ваш сайт (наприклад: сторінка продукту), переконайтеся, що він не порушує ваш поточний макет, і якщо він виконує те, що потрібно (прочитайте: скільки часу нам знадобиться), щоб виправити це .

• Зміни шаблону - Чи включає модуль шаблони, які змінюють мій поточний дизайн?

  Чи введе цей модуль нові шаблони? Якщо так, вони порушують мою конструкцію? Скільки часу знадобиться дизайн, як ми хочемо?

• Залежності - Чи залежить модуль від будь-якого іншого модуля?

  Якщо модуль залежить від інших, нам потрібно переконатися, що вони там і встановлені. Крім того, нам потрібно запитати себе, чи хочемо ми відключити модуль, від якого залежить в майбутньому?

Розширений:

• Сценарії оновлення SQL - Чи модуль якимось чином оновлює БД?

  Як тільки модуль оновлює базу даних, нам потрібно переконатися в кількох речах.

  Чи оновлено основну таблицю? Якщо так, це не добре, нам подобається, що наші бази даних чисті та готові до оновлення.

  Чи зберігає вона інформацію в розумному вигляді? Якщо ми хочемо самі отримувати дані з бази даних, чи зможемо ми зрозуміти це?

• Події - чи модуль спостерігає чи відправляє якісь події?

  Якщо модуль розсилає або спостерігає за подіями, ми хочемо знати:

  Які події він спостерігає / диспетчеризує? Чи вплине це на інший модуль, який працює в системі. Наприклад, якщо один із наших модулів змінить назву нашої продукції при завантаженні на великі регістри, і цей модуль додає слово "безкоштовно" до назви товару при завантаженні, як це буде працювати? Чи вийде слово "вільний" також у верхньому регістрі?

• Перегляд коду - Чи використовує модуль прийнятні методи кодування?

  Це більше стосується методів кодування PHP, ніж Magento.

  Чи використовує код Try / Catch блоки?

  Чи входить код уникнення користувача?

  Специфіка цього дійсно залежить від рівня / вимог нашої кваліфікації.

• Потенційні проблеми - Які потенційні проблеми можуть виникнути в результаті встановлення цього модуля?

  Спробуйте уявити п’ять перших проблем, які можуть виникнути, якщо ми встановимо цей модуль, як не дивно, він справді дає уявлення про проект в цілому.

Нижня лінія:

Всі ці речі приємно мати в ідеальному світі, в реальних сценаріях нам потрібно робити це, що називається "компроміс" :)

Крім того, ці вказівки покликані допомогти нам, а не перешкоджати нам, якщо ми встановлюємо лише один модуль, скажімо, модуль соціального обміну, і це для клієнта, якому потрібна проста налаштування сайту. немає сенсу проводити тонну досліджень.

Іншими словами: Справа в тому, щоб бути ефективним у наш час, якщо використання цього (пункту в) настанови допоможе мені заощадити час у довгостроковій перспективі, використовуючи його, якщо не відкиньте його і збережіть здоровий розум.

Деякі червоні прапори, що стосуються Magento:

• будь-який код в app/code/local/Mage
• перезаписані шаблони (файли, app/designякі вже є в ядрі)
• переписування основних класів, як catalog/product. Загалом я уважно переглядаю кожне перезапис, щоб побачити, чи можна було його уникнути
• серйозні порушення стандартів кодування Zend / Magento. Хоча мова йде лише про форматування коду, я роблю висновок, що розробки, які недбало ставляться до стандартів, швидше за все, будуть недбалі до інших, більш важливих, речей.
• зміни в основних таблицях баз даних
• жорстко закодований текст у шаблонах (не використовуючи механізм перекладу) та інших місцях
• бізнес-логіка в шаблонах (правило: будь-яке виникнення Mage::getModelв каталозі шаблонів, як правило, є поганим знаком)

Деякі червоні прапори, пов'язані з PHP (це дуже вибірковий і неповний список):

• будь-які сповіщення та попередження із увімкненим повідомленням про помилки ( E_STRICT)
• використання @оператора
• не санітувати дані користувачів перед виведенням

Червоні прапори, пов’язані з ефективністю:

• запити до бази даних всередині циклів
• завантаження цілої колекції просто для використання її частини

Також слідкуйте за загальними кодовими запахами , вони не потрібні червоним прапорам, але допомагають оцінити загальну якість.

Крок №1 - Чи може ваш клієнт дозволити підтримати це розширення, якщо розробник перейде на AWOL?

Якщо ні, ви не можете використовувати розширення.

Якщо так, перейдіть до оцінки розширення.

Непогані люди в Inchoo мають статтю про аналіз коду сторонніх модулів. У статті згадуються переписування класів, завдання в Cron, оновлення верстки та спостерігачі за подіями.

Я знайшов код спостерігача за подіями, який має потенціал для найвищого показника. Будьте уважні до ресурсомісткого, стороннього коду, який працює для часто відправлених подій. Такі події, як контролер Managed_predispatch або завантаження колекції.

Я використовую цей корисний модуль від Працького, щоб отримати хороший огляд переписувачів та спостерігачів.

Наявність будь-яких шаблонів та активів шкіри, розташованих у стандартному / за замовчуванні (або професіональному чи підприємницькому), а не базовому / за замовчуванням, досить дратує.

Зашкоджений код - це те, на що слід спостерігати - пошук викликів на eval (), base64_decode () тощо. Це часто використовується для перевірки ліцензії, але може бути шкідливим чи страшним - я бачив принаймні один компонент, який би оцінював довільний код із RSS-каналу.

Шукайте дзвінки dl () - принаймні один компонент шлюзу платежів, який я бачив, потребує встановлення розширення PHP, щоб виконувати його з'єднання!

Ти правий.

На жаль, немає ніякої магії: вам доведеться протестувати їх, перевірити код, щоб перевірити, чи добре він розроблений, мати гарну підтримку комерційних модулів завдяки їх форуму чи швидкості відповіді на ваші запитання ...

Існує кілька відгуків про Magento Connect, і популярність розширення може допомогти дізнатися, чи є він цінним чи ні, але чесно, ви можете знайти дуже популярні модулі з великою кількістю помилок. На минулому тижні я мав гарний приклад з модулем MailChimp, в основному добре зробленим, але мені довелося виправити деякі помилки і надав їх розробнику. Завжди є ризики, вам доведеться перевірити.

WebShopApp мав ідею просуватися в цьому напрямку, я маю на увазі залучити платформу, щоб отримати гарну інформацію про модулі. Ідея полягала в тому, щоб просунути Magento в цьому напрямку. Тож якість модуля - актуальне питання.

Моя порада: приділіть надзвичайну увагу модулям, у яких встановлені / оновлені сценарії, які змінюють значення в основних таблицях, оскільки відкатувати такі зміни не завжди легко.

Тест №1, який я можу придумати, - це знайти в їхньому коді нульовий день експлуатації (як правило, не дуже складно з розширеннями Magento), повідомити лише про отриманий збиток від макетного подвигу своїй команді безпеки (не вказуючи, що саме частина коду є вразливою), і починайте секундомір - адже це саме те, що відбудеться, коли ваш сайт буде зламаний. Коли їхній персонал служби підтримки просить отримати доступ до глобального FTP та mysql, ввічливо відмовляють, заявляючи, що це порушує PCI-DSS, і пропонують їм дозволити доступ лише до читання до вашого сховища вихідного коду.

Тест №2, який я виконую, полягає в тому, щоб зателефонувати продавцю і застати їх не охороняти. Запитайте їх про те, яку поведінкову / одиничну перевірку вони роблять, яку систему управління джерелами вони використовують, які версії PHP вони тестують, які версії Magento тестуються, на яких веб-серверах тестуються, користуються вони чи ні браузер -стак для тестування фронтальних компонентів тощо ... Якщо продавець не знає, про що ви говорите, замовчує або хоче "отримати експерта, який вам надішле електронну пошту", біжіть як пекло, оскільки вони, швидше за все, використовують нумеровані zip-файли для "контролю версій" і виправляти помилки лише 3 місяці після того, як їх клієнти повідомляють про них.

Якщо говорити про PCI-DSS, всі модифікації системи також повинні мати стратегію реверсії. З модулями, що додають стовпчики до нульових стовпців до основних таблиць, це стає майже неможливим при збереженні стратегії реверсії, яка пройде аудит. Запускайте, як пекло, з будь-яких модулів, які спричинять проблеми (читайте: помилки SQL) при відключенні.

PCI-DSS v3

6.4.5.4 Процедури зворотного виходу.

Переконайтесь, що підготовлені процедури зворотного виходу для кожної вибірки.

Для кожної зміни повинні бути задокументовані процедури зворотного виходу, якщо зміна не спрацьовує або негативно впливає на безпеку програми чи системи, щоб дозволити відновлення системи до попереднього стану

Це, крім інших відповідей. ІМО має бути стіною сорому за деякі небезпечні лайно, що породили цю платформу.