Другими словами, организации внедряют микросервисы для получения операционной выгоды в ущерб производительности.
Архив рубрики: Разработка
Acceptance, functional, unit. В таком порядке.
Вы решили написать тесты? Отлично! С чего начнем?
Блин!
Ваш проект полон “костылей” и кода, которые делают тестирование сложным или даже почти невозможным, а если вы еще и новичок в тестировании. Что делать?
Очень просто! Начните с Acceptance-тестов, далее functional-тесты и только в самом конце unit-тесты!
Приемочные (acceptance) тесты очень похожи на Behat-тесты, где вы тестируете конкретные пользовательские истории и поведение. Приемочные тесты проверяют весь цикл от веб-сервера до базы данных и обратно, они способны выявить множество ошибок приложения.
Как только вы напишите приемочные тесты – можно приступать к рефакторингу кода приложения и написанию функциональных (functional) тестов, которые проверяют взаимодействие отдельных компонентов. Дальнейший рефакторинг делает возможным написание модульных (unit) тестов – тестов, которые проверяют компоненты приложения отдельно друг от друга.
Тестирование это не “все или ничего”! Начните с простейших тестов, которые охватывают все части приложения и тестируют верхнеуровневую логику.
Начните писать тесты уже сегодня!
Приходите, научу писать тесты….
Тренажер по Python
Все же решил немного освежить свои скромные знания по Python.
Долго искал хорошие материалы/курсы/онлайн тренажеры.
Про полную лажу на рынке Российского онлайн-образования не писал только ленивый. “СкилбоСсы” и прочие “ГикБрайсы” выжгли поле, срубили тонны денег и сломали весь рынок =) Но об этом в следующий раз.
В итоге нашел “хайперскил” от JetBrains и старый добрый “хекслет“
У обоих довольно хорошие программы по питону.
Свойство только пишется, но не читается.
В PhpStorm есть отличная штука – свойства класса, которые пишутся (инициализируются в конструкторе), но не читаются – подсвечиваются.
Очень удобно рефакторить, например, легаси контроллеры, в которых инжектится куча сервисов, но в процессе эволюции часть из них перестает использоваться.
Открыл, увидел подсветку и спокойно все выпилил.
А если хотите, чтобы кто-то порефакторил за вас – приходите за разработкой к нам =)
База знаний в saas-проекте
Любой интернет-проект, а особенно если это saas-сервис, должны иметь хорошую документацию для пользователей. На эту документацию должны ссылаться специалисты технической поддержки при работе с клиентами, ссылки на эту документацию должны быть аккуратненько и уместно размещены в личном кабинете сервиса (или на сайте).
Небольшой список требований к такой базе знаний и движкам, для их построения:
- Актуальность. Информация всегда должна быть актуальной. Поменялся интерфейс системы – меняйте скриншоты в базе знаний. Добавили новый функционал – добавьте информацию об этом в базу знаний.
- Структурирированность. Информации о продукте становится все больше и больше. Правильное ее структурирование обеспечит удобство использования.
- Поиск. Он просто должен быть и быть классным +)
- Простота ведения. Интерфейс администратора/оператоа должен быть элементарным (привет, конфлюенс!)
Ну и хватит пока.
Под требования выше подходит практически любая современная CMS или вики-движок, имеются и специализированные решения.
В голове рождаются мысли о написании такого движка на Symfony, постараюсь их отогнать =)