Хотел бы я, чтобы это было чем-то, что я понял раньше в своей жизни как разработчик программного обеспечения.
Когда вы начинаете, вы хотите писать красивый код, самодокументирующийся код, вы хотите писать тесты, чтобы убедиться, что ваш код надежен, вы хотите должным образом писать комментарии на уровне классов и методов. Затем, когда вы пишете программное обеспечение в течение нескольких лет, вы хотите спроектировать хорошее программное обеспечение. Вы хотите использовать шаблоны проектирования, вы хотите убедиться, что то, что вы создаете, имеет архитектурный смысл, что вам не придется переделывать или переписывать весь материал при следующем запросе функции. . Еще несколько лет, и тогда вы захотите стремиться к сплоченности, согласованности, архитектурной целостности. И, безусловно, именно к этому вы ДОЛЖНЫ стремиться. Но это не ваша Работа.
Бесчисленное количество людей говорили это до меня, поэтому я только констатирую то, что, вероятно, очевидно, но нет, это НЕ ваша работа. Ваша работа заключается в создании продуктов, которые удовлетворяют набор потребностей пользователей. Ваша работа состоит в том, чтобы создавать продукты, которые решают проблему для некоторых заинтересованных сторон — вашего пользователя, людей, поддерживающих серверные системы, тех, кто тестирует ваше программное обеспечение, людей, которые занимаются привлечением пользователей. Да, при его создании вы должны писать четкий, поддерживаемый код, вы должны писать тесты, вы должны стремиться к тому, чтобы ваши проекты были простыми, а архитектура связной. Но это только часть Путешествия. Это НЕ пункт назначения, это НЕ конец.
Я понял это несколько дней назад, когда мы начали обсуждение библиотеки, которую мы создавали, и мы попали в эту спираль хорошего и интуитивно понятного дизайна, оптимизированной интеграции с нашей библиотекой. И какое-то время становится хорошо — Ах, да! Я создаю что-то, что имеет концептуальную целостность, клиентам понравится интегрировать это, бла-бла-бла. Но где-то мы поняли, что сделанное нами предположение о том, кто будет использовать эту библиотеку и какиммодом, возможно, все это время было неверным! Итак, мы столкнулись с продуктом и службой поддержки наших партнеров, и все пошло по предсказуемому пути, когда каждый хочет казаться самым умным человеком в группе. Но мы не задавались простыми вопросами о том, какие предположения мы делали, какие потребности эта библиотека должна решать, кто будет ее использовать, есть ли что-то, что конкретно ищут пользователи, интегрирующие эту библиотеку! Но в этот момент ясности наша группа пришла к этому пониманию, и все, казалось, встало на свои места. Оказалось, что, хотя мы делали правильные предположения (по крайней мере, в общих чертах), мы не были полностью осведомлены о том, что пользователи искали в этой библиотеке, каковы их болевые точки, какие часто задаваемые вопросы они пинговали в нашу службу поддержки. с участием. Как только мы получили эту картину, стало невероятно и до боли ясно, что нужно построить!
Если бы мы вместо этого трепетали о хорошем, цельном дизайне, мы могли бы создать что-то, что могло бы похвастаться хорошим, целостным дизайном, но прискорбно не соответствовало реальным потребностям пользователей!
Поэтому в следующий раз, когда наш менеджер по продукту обратится к нам с просьбой добавить функцию, я решил потратить время на понимание необходимости. Мы собираемся поговорить о том, что нужно нашим пользователям, достаточно ли мы их понимаем, можем ли мы заполнить пробелы в постановке задачи, которую наши пользователи сообщают нашим специалистам по разработке продуктов и бизнесу. Мы начнем строить что-то, чтобы подтвердить эту потребность, поставить ее под сомнение, получить отзывы о том, решает ли то, что мы строим, правильную проблему, или мы просто строим башни из слоновой кости, которые будут служить нет цели!
