Читаю "Working with Legacy Code" в оригинале, но иногда интересно посмотреть как перевели те или иные понятия на русский (бедный переводчик!)

> 1. Определение точек изменения.
> 2. Нахождение тестовых точек.
> 3. Разрывание зависимостей.
> 4. Написание тестов.
> 5. Внесение изменений и реорганизация кода.

Параллельно слегка читаю "Слово живое и мёртвое" Норы Галь. Думаю, она заругала бы за такой перевод :D
В английском есть герундий (*-ing) и это очень удобно. На русский его часто переводят как существительное, и получается что-то неестественное. Например, "разрывание" 🤨 Обычно можно переписать так, чтобы вместо существительных были глаголы.

Да, Нора писала не про технические тексты, но я думаю, что часто её советы подходят и к ним.

#книги

Нужно что-то читать параллельно "Working with Legacy Code", поэтому купила "How to Bake pi" Евгении Ченг.
Ожидаю введение в теорию категорий для самых маленьких. Посмотрим, что будет на самом деле.

#книги

Как у нас вчера провели первое апреля:
https://twitter.com/ThePracticalDev/status/1112759560547258368

После деплоя небольшой фичи решили полностью почистить кэш. В итоге, вместо ожидаемых небольших проблем с производительностью это привело к глобальной перегрузке, и сайт лежал.
Но ничего, поднялись.

#devto

Написала первый пост на dev.to (не считая поста для shecoded).
Пока введение в тему обучения через чтение книг 📚
Чувствую необходимость написать ещё несколько постов про книги, прежде чем переходить к другим темам 💁🏻‍♀️
https://bit.ly/2Vm8ov9

#книги

https://github.com/github/personal-website

Репозиторий от гитхаба, с помощью которого можно создать сайт-портфолио (с кодом).
Внутри jekyll, а значит, сайт можно легко использовать, как блог.
Естественно, всё кастомизируется, репозиторий даёт только заготовку.

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

https://m.signalvnoise.com/to-smile-again/
Интересный пост про выгорание и восстановление от бывшего сотрудника 37signals/Basecamp.
Мне сложно представить, как можно сразу же после увольнения из-за серьёзного выгорания, начинать бизнес, хоть и в другой сфере.
Наверное, я больше сталкивалась с общей усталостью, а не выгоранием именно от программирования.

https://dev.to/devteam/expanding-the-dev-core-team-5b0g
Теперь совсем официально в команде.

#devto

https://twitter.com/github/status/1131477029730308096?s=12
На гитхабе теперь можно спонсировать людей, напоминает Patreon.

📚 Дочитала "How to bake pi" (https://amzn.com/0465097677), очень крутая, попробую написать обзор на неё.
Сейчас дочитываю "Working with Legacy Code" и вместо чтения буду выделять побольше времени на письмо.
Следующей книгой скорее всего будет "Release it!"(https://amzn.com/1680502395), но читать её буду в более свободном режиме.

#книги

Доклад о TDD и о том, что с ним не так

https://www.youtube.com/watch?v=EZ05e7EMOLM

Вот что можно из него вынести:

- читайте Кента Бека, многие проблемы там уже разобраны (я ещё не читала)
в частности "TDD by example" https://www.amazon.com/gp/product/0321146530/

- не следуйте tdd религиозно
Как обычно, нужно в первую очередь думать своей головой. Не всегда оптимально использовать TDD. Тут так же, как с говнокодом: иногда писать его - нормально.

- тестируйте стабильное, а не детали имплементации
Тестируйте интерфейс класса, то есть то, что доступно извне (в руби это будут просто публичные методы). Интерфейс должен быть небольшим, а детали имплементации должны быть скрыты. Таким образом, их можно будет поменять, не меняя тесты. Если возникает вопрос, как тестировать приватные методы, возможно стоит вынести логику в отдельный класс.

- не мокайте слишком много
Лучше мокать только "дорогие" операции, а не всё подряд. Если пытаться изолировать класс, чтобы протестировать только его, то очень легко пропустить ошибки.

Сама недавно столкнулась с такой ситуацией: опечатку отловила только глазами на код-ревью, хотя тесты присутствовали. Просто замокано было слишком много.
Если следовать этому правилу и не мокать все зависимости, юнит-тесты становятся мини-интеграционными. Я думаю, что в этом нет ничего страшного, пока тесты действительно "мини-" и проходят достаточно быстро.
Понравилось определение из доклада: developer-тесты вместо юнит-тестов. То есть название по роли в разработке, а не по тому, что они тестируют.

- причиной написать тест должно быть изменение поведения, а не добавление нового метода

Принцип "Red-green-refactor", по-моему, описан стандартно:
- сначала пишем "красный" тест (который падает), иначе можно случайно написать тест, который ничего толком не тестирует
- пишем грязный код, только чтобы прошли тесты
- рефакторим "под прикрытием"
- не пишем новые тесты, когда рефакторим детали (приватные методы, реализацию публичных)

Ещё доклад помогает потренироваться понимать неидеальную английскую речь.
Поначалу очень трудно было разобрать, что он говорит, но через несколько минут мозг натренировался. Одновременно смотреть слайды и слушать всё равно трудно, а вот в формате подкаста усвоить информацию получилось.

Меня несколько раз спрашивали, как dev.to зарабатывает деньги.
Вот ответ одного из фаундеров: https://dev.to/ben/comment/bdlb

#devto

Удобный плагин для VsCode для переключения между кодом и тестом (на рельсовых проектах), почему-то не сразу стала им пользоваться.
https://marketplace.visualstudio.com/items?itemName=sporto.rails-go-to-spec
Ещё один похожий для js и руби:
https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec

"Свободное" время на работе

Многим айтишницам хотелось бы делать свои проекты, контрибьютить в опенсурс, читать книги, писать посты. На это сложно выделить время, потому что работа фуллтайм занимает примерно всю жизнь. Даже если время есть, хочется заняться чем-то ещё, а не тратить силы на околорабочую деятельность.

Часто дополнительно обучение — это и пожелание работодателя, поэтому некоторые компании пытаются решить эту проблему, выделяя рабочее время.

В первый раз я услышала о немного другой, но похожей практике, применительно к Google. Это было "правило 20%". Суть в том, что один рабочий день в неделю можно выделить на "свои" проекты. Меня это не очень впечатлило, т.к. проекты, естественно, являлись собственностью компании, хотя теоретически это даёт некоторую свободу. С самим правилом тоже не всё так просто, его реализацию много критикуют. Например, говорят, что самом деле это не 20, а 120% (https://bit.ly/2WrtUyh), и что людей нельзя заставить "быть креативными" в определённое время.

В последнее время мне стала попадаться информация о других компаниях, в которых есть подобная практика.
Например, "investment time" в thoughbot (https://thoughtbot.com/blog/investment-time). 4 дня в неделю сотрудники работают над клиентскими проектами, а по пятницам — над другими полезными для компании вещами: можно подготовить доклад, написать пост, записать подкаст, поработать над опенсурсом, почитать книгу или пройти курс. Это не обязательно что-то техническое, например, мне понравился вариант — расписать стену в офисе.

В небулабе (https://bit.ly/2MBk8tL) делают примерно так же.

У Thoughtbot и Nebulab есть открытые плейбуки, из которых можно узнать, как устроена работа в компаниях:
https://thoughtbot.com/playbook
https://playbook.nebulab.it/

Сокращённая рабочая неделя — другая тема, и скорее служит бонусом для сотрудников и защитой от выгорания. Впрочем, дополнительный выходной можно потратить и на вклад в свою карьеру.
Вот пара примеров:
- в icelab'е просто заявлена 4-хдневная 32-хчасовая рабочая неделя (https://www.icelab.com.au/careers)
- в basecamp'е — 4-хдневная рабочая неделя с начала мая по конец августа. https://bit.ly/31rwMyT

#работа

Плейлист о карьере от Маюко.
Скорее ориентирован на начало карьеры, но будет полезен и опытным. Мне понравились части про нетворкинг и карьерные цели.
Видео очень короткие - по 2-5 минут и их удобно смотреть по кусочкам.
https://www.youtube.com/playlist?list=PL1hNTJtl-Vt5FGkgnfo3e0HjK-YPYCQzR

В рельсах появится вью-компоненты (ActionView::Component)
https://dev.to/andy/rails-to-introduce-view-components-3ome

На одной из первых работ (в конце 2000-х) у нас была своя супер-cms на php и там была похожая концепция.
Как тогда они меня бесили! Тогда хотелось простой mvc, т.к. параллельно изучала всякие php-фреймворки и казалось, что это единственный правильный вариант.
Сейчас уже мало что о них помню, но в последние годы уже не раз вспоминала эти компоненты, например, после изучения реакта. Возможно, они были не такой уж плохой идеей :D
Интересно, как меняется восприятие со временем и приобретённым опытом.

Но надо помнить, что mvc - не mvc☝️
https://twitter.com/avdi/status/1139232955530993665

https://twitter.com/jessleenyc/status/1139586747208273920
Команда растёт за счёт интернов и единорогов ✨

#devto

Я подозрительно отношусь к shoulda_matchers [https://git.io/fj23m] 🕵️‍♀️
Вроде красиво, но пока не заглянешь в код гема, не видно, как и что там на самом деле проверяется:

it { is_expected.to validate_uniqueness_of(:username) }

На днях напоролась на одну особенность:
Для проверки уникальности shoulda сама создаёт записи в минимальными атрибутами, но не валидирует их:
https://git.io/fjg2g

При этом создание может зафейлиться из-за органичений в базе данных, а в нашем случае — из-за того, что не хватило данных для коллбека:
https://git.io/fjadm

Конечно, наличие такой логики в коллбеках само по себе не очень, но это уже отдельная тема.