В разработке, как и в любой технической профессии, меня привлекает возможность творчески решать задачи и развивать на основе решений свой инструментарий. Различные утилиты, фреймворки и библиотеки - чем не творческое создание чего-то нового, уникального. Эти решения делают нашу разработку проще, а жизнь коллег - легче.
Но так ли это на самом деле? Вообще переиспользуемый код является большой и часто неотъемлемой частью разработки. Кастомные библиотеки и фреймворки часто бывают полезны и даже необходимы. Но как часто, открывая чужой код, вы :
- чувствуете, что уже видели подобное решение в списке популярных библиотек
- не понимаете, как работает то или иное решение
- сокрушаетесь, что чтобы внести правки, вам надо переписать чужой код почти полностью или оставить очередной костыль
- понимаете, что переписать проект с нуля не такая плохая идея

Что с этим делать, как избежать подобных эмоций у себя и коллег, и как все же стоит писать велосипеды - об этом мой доклад

В рамках доклада я рассмотрю
- Что такое common code и какой он бывает
- Что такое велосипедостроение в разработке
- Чем оно мешают командной разработке
- Как велосипед превращается в главную головную боль проекта
- Когда с ними нужно бороться
- Когда все же стоит писать common code и как это делать
- Как выработать стратегию командной работы с велосипедами