Блог

Идеальный тест должен быть понятным и легко читаемым. Кроме того, любой тест так или иначе состоит из трёх частей: подготовка данных, действие над системой и проверка — Arrange, Act и Assert. Посмотрите на любой свой тест — и вы так или иначе обнаружите там эти части. Я однажды разработал тестовый фреймворк для веб-компонентов, который состоял из 3х частей: Описание состояния компонента в начале и подготовка стабов ответов сервера. Одно действие (например, нажатие на кнопку).

Как фича гитхаба убила скорость разработки Вы, наверняка, каждый день на работе пулл реквесты заводите. А вы знаете зачем? Задумывались ли вы: может есть другой способ? Почему вообще делают пулл реквесты? История Pull Request’ов Историческая справка: pull request’ы появились как UX фича Github’а в 2008 году как удобная обвзяка над принятым тогда флоу. В те далёкие времена процедура запроса на стягивание (буквальный перевод pull request, на всякий случай) заключалась в том, что ты пушил код в свой форк и писал мейнтейнеру: “Братан, стяни, плз себе мои изменения”.

Недавно у нас на работе завезли локальную LLM’ку с китайскими премудростями. Среди прочих возможностей там есть RAG’и. Для тех, кто ещё не преисполнился: RAG — retrieval augmented generation, то есть такая фигня, где LLM’ка не просто гонит шизу, а делает это, используя переданный ей большой кусок контекста. То есть если вы ей скормили, например, wiki по aichat (🌚), то она будет не просто фантазировать, а искать ответы в этом контексте.

Зачем тесты бизнесу? Я на миллион процентов за QA, и я на миллион процентов против отделов QA. Мы боролись с ними в 90-е, мы их победили лет на 15, и вот они возвращаются. Кент Бек Но что делать с бизнесом, с теми кто давит выпустить «быстрее-быстрее»? Для начала надо определиться с тем, что мы делаем, зачем и как. Инженеров нанимают, чтобы они решали проблемы бизнеса. Нередко при этом надо писать код — тогда надо это делать быстро и качественно.

Если ты что-нибудь делаешь, делай это хорошо. Если же ты не можешь или не хочешь делать хорошо, лучше совсем не делай. Лев Николаевич Толстой Есть одна вещь, в которой на 100% сходятся все книжки из разряда «как быть крутым программистом» — это «вы несёте ответственность за свой код». Не буду оригинален и на вопрос «зачем нужно тестировать?» скажу: «потому что вы несёте ответственность». Хочешь быть профессионалом — будь добр, убедись, что свою работу ты выполняешь качественно.

После поста о моём уходе из Salesforce, мне написал товарищ, который идёт тем же путём с единственной разницей: он решил учить питон. И попросил советов и лайфхаков. Поэтому опишу, как я подошёл к смене стека. TL;DR, список советов: Постоянно изучайте новые для себя технологии. Изучать лучше решая практические задачи. В любом новом языке нужно знать: управление памятью, обработка ошибок, многопоточность. Не забывайте про БД. При переходе с Salesforce на другой стек легко забыть, что мир не ограничен SOQL.