Прекратите позволять "следует", академики и случайные сообщения в блогах мешать вам и вашей команде отгрузить товар.
Раньше я работал под очень академическим техническим руководителем. Когда он не переписывал функции, которые создавались в течение нескольких дней или недель, чтобы сделать их более совершенными - с точки зрения организации кода и файлов - он читал сообщения в блогах о шаблонах проектирования и о том, как все должно быть в вашей кодовой базе.
Прошло три месяца с даты, когда мы должны были выпустить первую версию нашего приложения, а у нас по-прежнему ничего не было. Пока другие члены нашей команды были заняты созданием и поставкой функций для v1, он писал и переписывал, экспериментировал с файловой структурой и пытался сделать все идеальным. В конце концов наш технический директор узнал об этом, так как проходила неделя за неделей, а приложение все еще не выпускалось.
После того, как приложение было выпущено, наш технический руководитель покинул компанию, и меня повысили до его должности. Затем произошло нечто странное:
Первоначально я хотел продолжить традицию. Не переписывание, а перфекционизм.
Вскоре после этого я создавал функцию единого входа для наших корпоративных клиентов и начал болтать о «лучшем» способе написания очень маленькой функции и о том, где она должна находиться. Наверное, 5 строк, максимум.
Это должна быть бесплатная функция? Должен ли он быть в отдельном файле или вместе с другим кодом единого входа?
Должен ли это быть класс с единственной открытой функцией?
Поскольку он такой маленький, могу ли я просто прикрепить его к другой части единого знака работы и не беспокоиться о том, что он будет жить сам по себе?
Его образ мышления стал моим, и я был парализован решениями, которые практически не имели последствий в реальном мире и не имели никакого значения для людей, платящих нашей компании много денег.
Я подошел к нашему вице-президенту по проектированию, чтобы определить, что лучше всего делать с этой маленькой функцией. Я был готов к такой же беседе с ним, как и бесчисленное количество раз с нашим предыдущим техническим руководителем,
Вместо этого разговор был кратким. Его ответ, навсегда изменивший то, как я работал и думал о коде, был:
«Мне все равно, просто заставь это работать».
Я чувствовал себя свободным.
В конце концов, я был техническим руководителем! Это была моя команда!
Нам всем не нравился прежний стиль академического перфекционизма и ориентированного на публикации в блогах. Почему я продолжал беспокоиться о том, соответствует ли наш код тому, как кто-то за пределами нашей команды сказал, что следует делать?
Эти тенденции меняются со временем. Поверьте, я редактор Better Programming 😊. Сообщение в блоге было полезно в теории, но в конечном итоге не имело значения для бизнеса.
Нам просто нужно было отправить.
Начиная с этого разговора, это изменило то, как я руководил командой.
«Сделайте заметку, давайте вернемся к ней после того, как мы отправим товар» - вот что я хотел сказать. Мы все знали, что нам нужно делать. Мы создадим эту функцию, обеспечим ее контроль, исправим все ошибки, затем назовем это готовым и перейдем к следующей функции. Где-то был этот список, надежно спрятанный, вещи, к которым нам нужно вернуться в будущем.
После отправки ничего страшного не произошло, потому что наш код не был идеальным.
Промедление было замаскированным страхом. Потребовался этот короткий разговор с моим вице-президентом, чтобы я понял это.
Совершенно нормально согласовать стандарты в кодовой базе и передовые методы для вашей команды и для вашей компании. Если ваша команда работает медленнее из-за того, что каждый член команды должен отфильтровать свой код в соответствии с определенным стилем или предпочтениями определенного, очень самоуверенного инженера, вам потребуется гораздо больше времени, чтобы выпустить все.
Итак, учитесь ли вы программировать и читаете это, или вы углубляетесь в свою инженерную карьеру, тратьте больше времени на то, чтобы что-то заработало, и меньше времени на то, чтобы думать о обязанностях инженерии.
Убедитесь, что ваш код безопасен, надежен и относительно эффективен. Но помните: ваш код, скорее всего, (пока) не работает в таком масштабе, при котором неэффективность будет стоить вашему бизнесу значительных денег. Так что это не имеет значения! Просто заставь это работать.
По мере масштабирования вы перепишете этот код, чтобы он стал лучше. Вернитесь к этому после отправки.
Гораздо более вероятно, что ваш код, который не поставляется, обойдется компании дороже.
