Сложно выделить что-то конкретное, поскольку я учусь каждый день. Но вот несколько вещей (порядок неважен).
1. Быть хорошей командой с хорошим менеджером важнее работы над конкретными проектами.
Проекты приходят и уходят, успешные или нет. А вот люди, с которыми ты работаешь, которые делают эти годы твоей жизни особенными, имеют большое значение. И показать все лучшее, на что ты способен в работе, ты можешь только в атмосфере честности, взаимной поддержки и уважения.
2. Большие переделки часто неудачны.
Если ты хочешь заменить какой-то старый код для решения определенных проблем, тебе для этого понадобится стратегия постепенной адаптации. Переписывая вслепую, на скорую руку, ты можешь создать гораздо больше проблем чем надеялся решить. Особенно если не сам писал оригинальную версию.
3. Большие переделки могут быть и успешными.
Предыдущий пункт часто повторяют как закон, но он таковым не является. Ты можешь полностью заменить большой кусок кода (как мы сделали с React 16), если у тебя есть хороший набор тестов по интегрированию, а также способ отправить новую реализацию для подмножества вида продукта подмножеству пользователей. Мы собираемся в скором времени опубликовать пост об этом в Facebook Engineering Blog.
4. Тесты для библиотек в идеале должны быть написаны поверх открытых API.
Это идет вразрез с распространенной мантрой о модульном тестировании. По нашему опыту это помогает убедиться как в том, что тестируются правильные вещи, так и в легкости замены базовой реализации. Но это также делает отказы программ во время отладочных тестирований более сложными.
5. Для очень сложного кода фаззинг может подойти лучше, чем модульное тестирование.
Если код, который ты тестируешь, должен справляться со многими неожиданными случаями, которые сложно предугадать, может быть лучше написать тесты в недетерминированной манере. Входные данные будут генерироваться случайным образом, а исходящие – проверяться на соответствие определенным условиям.
6. Думай о коде заблаговременно.
Думай о том его варианте, который существует сейчас, и о том, как он будет развиваться. Думай о том, что шаблон, который ты представляешь в базу кодов, может быть скопирован и вставлен в любом другом месте. И о том, что код, на совершенствование которого ты потратил столько времени, в любом случае будет удален. Думай о том, как добавленный тобой хак будет задерживать команду в долгосрочной перспективе, и как он же ускорит процесс в краткосрочной. Речь идет о компромиссах, а не о правилах. Мы все время идем на компромиссы и всегда должны думать, что делаем. Как чистый, так и грязный код могут помочь или помешать в достижении твоих целей.
7. Мы не обязаны быть супер умными.
Если, конечно, ты не строишь космический корабль, тогда да. Но что касается обычной веб-разработки, я думаю, это правда. Я волновался, когда не мог понять что-то в коде, и думал, что я тупой. Сейчас я тоже так думаю, но знаю, что это не моя вина. Это значит, что код структурирован неправильно, или покрытие теста недостаточно хорошее, или я не положил логи консоли в правильное место, чтобы визуализировать произошедшее. Мы не должны знать все. Но мы должны знать, когда нужно создать инструменты, позволяющие расширить наше понимание и научиться исследовать код, который мы не понимаем. Даже если это наш собственный код.
8. Используй двоичный поиск и научный метод.
Не буквально в коде, а в своем подходе к нему. Есть баг между точками А и В? Поставь лог между ними, посередине. Баг между А и серединной точкой? Поставь еще лог между ними. Что-то не то с входящими данными? Исключи половину из них. Работает? Попробуй другую половину. И так далее. Отладка может казаться очень прихотливой, но она проста, когда делаешь ее механически. Исследуй, сформулируй гипотезу, найди способ проверить ее, повтори. И обрезай вещи наполовину, когда их слишком много.
Надеюсь, это поможет!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]