В 2004 году я окончил университет по специальности Компьютерные науки и устроился на работу в крупный инвестиционный банк. С тех пор я работал технологом в некоторых из крупнейших банков мира, а с 2017 года — в стартапе в Лондоне.
У меня было много должностей: бизнес-аналитик, руководитель проекта, руководитель группы; но я всегда писал код.
Ранее на этой неделе я наткнулся на эту тему на Hacker News. Это ветка Спросите HN: Какие привычки делают программиста великим?. Идите и прочитайте его, там есть несколько отличных советов.
Это заставило меня задуматься о том, что я мог бы добавить к этому обсуждению. Я не великий программист, но я добиваюсь цели, и у меня было много лет ошибок, на которых можно учиться.
Итак, вот мои 2р..
Вы расстроитесь, и это нормально
Наше поле поклоняется производительности. Мы слышим об удивительных приложениях, созданных за выходные. Всегда есть кто-то, кто сделает все быстрее.
Правда в том, что программирование сложно, иногда одиноко и часто разочаровывает. Некоторые из нас работают долгие часы, сталкиваются со сложными сроками и трудными клиентами. Доведение дела до конца может быть долгим и трудным делом.
Злиться и расстраиваться — это совершенно нормально. Однако, если не управлять должным образом, это приведет к выгоранию и разочарованию.
Узнайте, какие стратегии выживания лучше всего подходят для вас. Когда я чувствую, что все становится слишком много для меня, я иду на прогулку. Другие берут кофе и изливаются перед другом, некоторые даже разговаривают с резиновыми уточками.
Будьте добры к себе. Программирование требует умственных усилий, и ваша эффективность зависит от ряда факторов, которые вы можете не контролировать. Несколько дней будут отстойными, и вы почувствуете, что ничего не сделали. Ничего страшного.
Знай и люби свои инструменты
Наша область развивается быстро, и каждый день появляется новый инструмент, менеджер пакетов или фреймворк, который решит все ваши проблемы и сделает вас программистом в 10 раз больше. Это ловушка.
Возьмем, к примеру, IDE. Я использую IntelIJ IDEA для разработки на Java, Python и JavaScript. Это, наверное, самое сложное приложение на моем компьютере. Мне потребовались годы, чтобы просто добраться до точки, где я могу ориентироваться в интерфейсе, понимать возможности и продуктивно использовать IDE. Если бы я переключился на что-то другое, моя продуктивность сразу бы упала.
Вы уже потратили часы на изучение инструментов, которыми пользуетесь сейчас. Подумайте о возврате инвестиций (ROI) за все время, которое вы потратили, прежде чем двигаться дальше. Изучайте и любите инструменты, которые вы используете, и стремитесь к максимальной рентабельности инвестиций.
Инструменты и фреймворки приходят и уходят, а время движется только в одном направлении.
Не ныряйте прямо в
Я склонен к действию. Имея выбор между тем, чтобы просто начать что-то делать (что угодно) или потратить несколько минут на размышления и планирование, я предпочитаю действие созерцанию. Я вижу ту же тенденцию у многих других программистов.
Нырять прямо в воду приятно, кажется продуктивным, однако я понял, что это всего лишь иллюзия. Этот подход привел меня в тупик, впустую потраченное время и разочарование.
Столкнувшись с необходимостью создания функции или проблемой, которую необходимо решить, я задаю себе следующие вопросы:
- Какова цель?
- Будет ли это продвигать вещи (продукт, проект или компанию) вперед?
- Как эта проблема связана с тем, что я уже знаю? Достаточно ли я знаю?
После того, как я обработал проблему, я работаю над изложением решения. Это может быть дудл, пользовательская история или иногда просто куча комментариев в IDE. Это упражнение делает написание кода легкой частью всего процесса.
Кент Бек заявил в прошлом году, что: Начинайте проекты, измеряя текущее состояние мира. Это идет вразрез с нашими инженерными инстинктами, чтобы начать чинить вещи. Но когда вы измерите базовый уровень, вы на самом деле будете знать, исправляете ли вы что-то.
Рефакторинг или переписывание — ложная дилемма
Каждый сталкивается с кодовой базой, которая настолько запутана, настолько беспорядочна, настолько корява, что первое побуждение состоит в том, чтобы просто захотеть выкинуть ее и начать все сначала. В некоторых случаях это может быть правильным решением, например, если ваш клиент готов заплатить за функцию, которую невозможно реализовать с учетом текущей кодовой базы.
Однако в большинстве случаев более продуктивным подходом является поиск способов очистки устаревшей кодовой базы путем ее рефакторинга. Современные IDE и инструменты покрытия кода упрощают рефакторинг большой кодовой базы. Это в сочетании с прагматичным подходом к модульному тестированию поможет вам быстро и безопасно получить ценность.
Рефакторинг или переписывание — это не бинарный выбор. Это континуум, сильно смещенный в сторону рефакторинга.
Я был и был членом команды многочисленных проектов, которые были переписаны с нуля. Большинство из них были ужасными неудачниками. Мы потратили недели (иногда месяцы) на создание уже существующей функциональности. К тому времени, когда мы приступили к добавлению ценности, проекты отставали от графика и превышали бюджет.
Не игнорируйте контекст
Никто не хочет писать ужасный код. Беспорядочная кодовая база, которую вы унаследовали, — это результат выигранных сражений и извлеченных уроков. Это может вызвать у вас головную боль, но всегда есть чему поучиться.
Стоит потратить некоторое время на то, чтобы понять, какие проблемы пытается решить кодовая база и почему все закончилось так, как получилось. В большинстве случаев именно унаследованная кодовая база активно используется вашими клиентами и платит вам зарплату.
Игнорируя «почему» и сосредотачиваясь на «как», мы обречены на повторение ошибок прошлого. Если кодовая база запутана и сломана, попытайтесь понять, что вызвало эту ситуацию, и постарайтесь не повторять одних и тех же ошибок или использовать одни и те же шаблоны.
В заключении
Я участвовал в большем количестве проектов, которые были успешными с оговорками и безусловными провалами, чем с безоговорочно успешными. Я посредственный программист, но я стараюсь учиться на своих ошибках и каждый день вносить небольшие улучшения.
Чему вы научились на своих ошибках?