Эта статья — перевод с medium.com, в которой Daan, ее автор, предостерегает нас от неверных решений при выборе между скоростью и эффективностью в программировании.
Фото с сайта Unsplash. Автор: Artem Sapegin
Работа программиста неразрывно связана с необходимостью принимать множество решений. Иногда мы понимаем, что решение никуда не годится, но все же его принимаем.
На то могут быть самые разные причины: спортивный интерес, лень и т. д. Понятно одно: не стоит следовать перечисленному в статье, хотя что-то может действительно показаться подходящим вариантом.
Итак, 6 вещей, которые делают программисты, прекрасно зная о негативных последствиях.
Порой вы знаете, что принятое вами решение не самое оптимальное. Тем не менее, реализуется именно оно, потому что так будет быстрее, да и код функционирует. При этом у вас больше времени на отлаживание всего остального. Ничего страшного, так ведь?
Приятно, когда удается за короткий срок решить проблему. Но заставить код работать — это лишь малая часть задачи. Скоропалительность становится причиной серьезных погрешностей, которые приводят к увеличению технического долга.
Вынося очередное решение из серии «на скорую руку» на обсуждение, вы должны осознавать, что оно может отрицательно повлиять на атмосферу в команде.
В вашу защиту стоит сказать, что иногда поспешность не имеет негативных последствий. А в отдельных случаях даже оказывается наиболее верным выходом из положения (например, если такой код нужен на короткий период времени).
Но если вам требуется код на долгосрочную перспективу, поспешность в урегулировании проблем обязательно потом откликнется какими-нибудь неприятностями. Не стоит оправдывать такие решения обещаниями позже привести все в порядок. Мы все отлично знаем, чем заканчиваются подобные истории.
Я много раз видел, как неопытные разработчики допускают промах, скрыто обрабатывая ошибки в коде. Среди возможных причин — отсутствие понимания, что происходит в коде на более низком уровне. Тем не менее, искушенные разработчики тоже склонны замалчивать ошибки. И, в отличие от первых, они делают это преднамеренно.
Когда полно работы и начинают гореть дедлайны, у вас нет времени на все проблемы, которые сыплются в баг-трекер. Иногда, чтобы не вздрагивать от новых уведомлений, вы решаете молча «проглотить» ошибку. Это позволяет вам сконцентрироваться на других, уже имеющихся в работе задачах.
Можно представить себе несколько прецедентов, в которых было бы предпочтительнее скрыть уведомление об ошибке (например, по какой-либо причине не удалось создать лог-файл, но сообщить об этом негде). Тем не менее, как показывает опыт, этого лучше не делать.
Большинство разработчиков хоть раз занимались внедрением каких-нибудь шаблонов проектирования, в которых не было особой необходимости. Однако то, что вы можете добавить шаблон, вовсе не значит, что это нужно.
Это классическая форма оверинжиниринга, и все, чего вы с ним добьетесь — усложнение технической стороны кодовой базы. Такое чаще всего происходит, когда разработчикам не хватает трудных и мотивирующих задач, тогда они начинают создавать их себе сами.
Еще одна причина оверинжиниринга — убежденность в том, что какой-то кусочек кода пригодится в будущем. Этот фрагмент добавляется в кодовую базу, но на деле вряд ли потом пригодится. Вероятно, лучше всего объяснить оверинжиниринг можно так: это код, который разрешает несуществующие проблемы.
Разработчики любят время от времени изобретать велосипед, собирая что-нибудь с нуля. Причина в том, что это отличный способ понять, как работают некоторые вещи. Создавая заново, вы проходите весь путь, что дает более глубокие знания.
Изобретать велосипед может быть довольно весело, но на это требуется время, которого у разработчиков чаще всего нет. Нужно соблюдать дедлайны, поэтому такие вещи не поощряются.
Иногда временные затраты оправданны, иногда в них нет никакой необходимости. А иные задачи настолько важны, что если вы что-то напутаете, это приведет к ужасающим последствиям. Вот почему решение изобрести велосипед не самое лучшее, что вы могли бы сделать.
Множество разработчиков пишут неинформативные комментарии к коммитам, даже зная, что в долгосрочной перспективе сами же от этого пострадают. Любой разработчик поймет, почему вы, возможно, не тратите время на хороший комментарий. Вы закончили фичу, которую так долго пытались отладить, и хотите наконец закоммитить финальные правки. И чем скорее, тем лучше.
Тем не менее, крайне важно потратить время и написать качественные комментарии к коммитам, с полезной информацией о том, что изменилось и почему. Когда все летит кувырком, быстро обнаружить ошибку можно именно с помощью истории изменений.
Если вы хотите узнать больше о важности написания качественных комментариев к коммитам, загляните в одну из моих статей.
С ней вы будете сталкиваться довольно часто. Разработчики, как правило, прокрастинируют, когда они в тупике или проект «не заходит». В какой-то момент вы можете обнаружить, что прокрастинируете, потому что не видите леса за деревьями. Количество работы, которая должна быть сделана, настолько давит, что в итоге вы не делаете ничего.
Лучше не прокрастинировать слишком долго, это пустая трата времени. Разделите работу на более мелкие фрагменты. Если не помогает, попробуйте сделать небольшой перерыв, чтобы освежить мозг.
Есть вещи, которые делают программисты, хотя знают, что это имеет негативные последствия. Если говорить о написании кода, сюда можно отнести принятие поспешных решений, скрытую обработку ошибок, создание неинформативных комментариев к коммитам и оверинжиниринг. Кроме того, попытки изобрести велосипед — на это уходит чересчур много времени. То же относится и к прокрастинации.
Я надеюсь, вы стали более осознанными в отношении перечисленных не самых удачных действий, так что можете попробовать избегать их (даже если что-то все-таки кажется удачным).
Спасибо за чтение!
Фото с сайта Unsplash. Автор: Artem Sapegin
Работа программиста неразрывно связана с необходимостью принимать множество решений. Иногда мы понимаем, что решение никуда не годится, но все же его принимаем.
На то могут быть самые разные причины: спортивный интерес, лень и т. д. Понятно одно: не стоит следовать перечисленному в статье, хотя что-то может действительно показаться подходящим вариантом.
Итак, 6 вещей, которые делают программисты, прекрасно зная о негативных последствиях.
1. Поспешные решения
Порой вы знаете, что принятое вами решение не самое оптимальное. Тем не менее, реализуется именно оно, потому что так будет быстрее, да и код функционирует. При этом у вас больше времени на отлаживание всего остального. Ничего страшного, так ведь?
Приятно, когда удается за короткий срок решить проблему. Но заставить код работать — это лишь малая часть задачи. Скоропалительность становится причиной серьезных погрешностей, которые приводят к увеличению технического долга.
Вынося очередное решение из серии «на скорую руку» на обсуждение, вы должны осознавать, что оно может отрицательно повлиять на атмосферу в команде.
В вашу защиту стоит сказать, что иногда поспешность не имеет негативных последствий. А в отдельных случаях даже оказывается наиболее верным выходом из положения (например, если такой код нужен на короткий период времени).
Но если вам требуется код на долгосрочную перспективу, поспешность в урегулировании проблем обязательно потом откликнется какими-нибудь неприятностями. Не стоит оправдывать такие решения обещаниями позже привести все в порядок. Мы все отлично знаем, чем заканчиваются подобные истории.
2. Привычка проглатывать ошибки в коде
Я много раз видел, как неопытные разработчики допускают промах, скрыто обрабатывая ошибки в коде. Среди возможных причин — отсутствие понимания, что происходит в коде на более низком уровне. Тем не менее, искушенные разработчики тоже склонны замалчивать ошибки. И, в отличие от первых, они делают это преднамеренно.
Когда полно работы и начинают гореть дедлайны, у вас нет времени на все проблемы, которые сыплются в баг-трекер. Иногда, чтобы не вздрагивать от новых уведомлений, вы решаете молча «проглотить» ошибку. Это позволяет вам сконцентрироваться на других, уже имеющихся в работе задачах.
Можно представить себе несколько прецедентов, в которых было бы предпочтительнее скрыть уведомление об ошибке (например, по какой-либо причине не удалось создать лог-файл, но сообщить об этом негде). Тем не менее, как показывает опыт, этого лучше не делать.
3. Оверинжиниринг
Большинство разработчиков хоть раз занимались внедрением каких-нибудь шаблонов проектирования, в которых не было особой необходимости. Однако то, что вы можете добавить шаблон, вовсе не значит, что это нужно.
Это классическая форма оверинжиниринга, и все, чего вы с ним добьетесь — усложнение технической стороны кодовой базы. Такое чаще всего происходит, когда разработчикам не хватает трудных и мотивирующих задач, тогда они начинают создавать их себе сами.
Еще одна причина оверинжиниринга — убежденность в том, что какой-то кусочек кода пригодится в будущем. Этот фрагмент добавляется в кодовую базу, но на деле вряд ли потом пригодится. Вероятно, лучше всего объяснить оверинжиниринг можно так: это код, который разрешает несуществующие проблемы.
4. Попытки изобрести велосипед
Разработчики любят время от времени изобретать велосипед, собирая что-нибудь с нуля. Причина в том, что это отличный способ понять, как работают некоторые вещи. Создавая заново, вы проходите весь путь, что дает более глубокие знания.
Изобретать велосипед может быть довольно весело, но на это требуется время, которого у разработчиков чаще всего нет. Нужно соблюдать дедлайны, поэтому такие вещи не поощряются.
Иногда временные затраты оправданны, иногда в них нет никакой необходимости. А иные задачи настолько важны, что если вы что-то напутаете, это приведет к ужасающим последствиям. Вот почему решение изобрести велосипед не самое лучшее, что вы могли бы сделать.
5. Неинформативные комментарии к коммитам
Множество разработчиков пишут неинформативные комментарии к коммитам, даже зная, что в долгосрочной перспективе сами же от этого пострадают. Любой разработчик поймет, почему вы, возможно, не тратите время на хороший комментарий. Вы закончили фичу, которую так долго пытались отладить, и хотите наконец закоммитить финальные правки. И чем скорее, тем лучше.
Тем не менее, крайне важно потратить время и написать качественные комментарии к коммитам, с полезной информацией о том, что изменилось и почему. Когда все летит кувырком, быстро обнаружить ошибку можно именно с помощью истории изменений.
Если вы хотите узнать больше о важности написания качественных комментариев к коммитам, загляните в одну из моих статей.
6. Прокрастинация
С ней вы будете сталкиваться довольно часто. Разработчики, как правило, прокрастинируют, когда они в тупике или проект «не заходит». В какой-то момент вы можете обнаружить, что прокрастинируете, потому что не видите леса за деревьями. Количество работы, которая должна быть сделана, настолько давит, что в итоге вы не делаете ничего.
Лучше не прокрастинировать слишком долго, это пустая трата времени. Разделите работу на более мелкие фрагменты. Если не помогает, попробуйте сделать небольшой перерыв, чтобы освежить мозг.
Действие побеждает бездействие (Ог Мандино).
Подводя итог
Есть вещи, которые делают программисты, хотя знают, что это имеет негативные последствия. Если говорить о написании кода, сюда можно отнести принятие поспешных решений, скрытую обработку ошибок, создание неинформативных комментариев к коммитам и оверинжиниринг. Кроме того, попытки изобрести велосипед — на это уходит чересчур много времени. То же относится и к прокрастинации.
Я надеюсь, вы стали более осознанными в отношении перечисленных не самых удачных действий, так что можете попробовать избегать их (даже если что-то все-таки кажется удачным).
Спасибо за чтение!
