Писать код как генеральный директор

Среднестатистический разработчик ежедневно принимает сотни решений. Это распространяется на всех программистов, включая новичков, старших и ведущих разработчиков и архитекторов. Они устанавливают очередность выполнения работ, определяют, какие ошибки исследовать и каким способом устранять проблемы.

Хотя некоторые решения можно назвать менее важными, все они оказывают определенное влияние. Когда возникает слишком много противоречивых требований, расстановка приоритетов становится простым, но в то же время разумным решением. Устранив неясности, вы сможете согласовать важность работы и уменьшить помехи. Но как насчет незначительных решений? Каждое из них реализуется по-разному.

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

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

Не знаете, сколько времени потратить на каждый элемент? Маленькая хитрость: мыслите, как генеральный директор. Продолжите фразу "Если бы я руководил компанией, я бы посоветовал..."

Такой стиль мышления может служить "путеводным маяком" во время процесса принятия решений. Помните, что думать, как генеральный директор нелегко. Вместо того, чтобы мысленно меняться ролями, многие разработчики стремятся присоединить образ мышления генерального директора к своему существующему.

Такой подход неэффективен и в конце концов окажет радикальное влияние на принятие решений. Большинство генеральных директоров ограничиваются элементарными знаниями программирования. Они мыслят категориями времени, денег и ценности. Во многих компаниях программирование является элементом огромного пазла.

Я не имею ввиду, что программная разработка занимает второстепенное место в компании. Наоборот, крупные инвестиции времени и денег свидетельствуют о ее особой роли. Чрезмерное количество неправильных незначительных решений могут задержать выпуск продукта на недели или месяцы. Излишний рефакторинг, конфигурируемость и сложная логика служат примерами "малых" решений, которые способны осложнить работу. Именно они -- тайные убийцы программной индустрии.

источник