№3. Как они могут оставить дефект в коде?
Программисты делают много ошибок в повседневной работе. Довольно часто приходится идти на компромисс с некоторыми передовыми практиками при доставке кода в сжатые сроки. А иногда качество кода страдает просто из-за лени программиста.
Однако, когда те же разработчики видят чужой код, они много жалуются на качество кода. Они рассказывают о деталях, которые могут быть или не иметь решающего значения для функциональности. Иногда жалобы могут касаться поведенческих проблем, которые разработчики делают сознательно или неосознанно.
Вот список из пяти распространенных ошибок, на которые разработчики часто жалуются, но часто допускают одни и те же ошибки.
1. Нет документации
Это распространенная жалоба разработчиков, когда они пытаются работать над кодом, написанным кем-то другим. Отсутствие документации затрудняет понимание функционального и системного рабочего процесса, особенно для новичков.
Даже существующие члены команды часто теряются в сложной логике программы, если они никогда не работали над этой частью кода. Я много раз испытывал то же чувство в нашей огромной устаревшей кодовой базе. Следовательно, я считаю, что беспокойство по поводу отсутствия документации в какой-то степени оправдано.
Однако те же разработчики, которым сложно понять функциональность без документации, часто предпочитают не документировать свои собственные функции. Если вы попросите их задокументировать, они расскажут вам, как код должен быть самодокументированным.
Так повторяется цикл непонятного кода. Программисты хотят, чтобы код был хорошо документирован, чтобы их было легче понять. При этом никто не хочет тратить время на написание документов на свои поставки.
2. Этот код - просто беспорядок
Работать с запутанным кодом всегда больно. Когда разработчик просматривает чужой код, он чувствует, что программу можно было бы написать намного лучше. Программисты находят проблемы в каждых нескольких строках, особенно если это унаследованный код.
Однако очень немногие разработчики задумываются о сохранении читабельности кода. Хотя они могут заклеймить чужой код как беспорядок, они никогда не думают дважды, прежде чем применить временное решение. Если у них будет возможность, они с радостью воспользуются ярлыками, чтобы завершить свое задание и оставить кучу TODO.
Ты знаешь почему? Потому что всегда легко пожаловаться на чужой код.
Каждая кодовая база прекрасна в первые дни. Разработчики начинают с чистого листа и стараются следовать всем лучшим практикам. Но период чистого кода длится только определенное количество циклов доставки и если команда небольшая.
Со временем все больше и больше разработчиков вкладывают свои силы в код. Каждый пытается реализовать функции, используя свой собственный стиль. В конце концов, если одна и та же кодовая база постоянно меняется на протяжении многих лет, она будет казаться постороннему беспорядком - как бы вы ни старались сохранить ее в чистоте.
3. Как они могут оставить дефект в коде?
Это обычная жалоба, когда разработчик пытается исправить ошибку в чужом коде. Они ставят под сомнение возможности разработчика, который в первую очередь реализовал код.
Я могу понять разочарование. Всегда трудно читать чужой код, особенно если вы не имеете предварительного представления об этой функции.
Следовательно, разочаровываться, когда вы исправляете код, реализация которого вам непонятна, вполне естественно. Вдобавок ко всему, если проблема носит эскалационный характер, необходимость ее быстрого решения усугубляет проблему разработчика. И не забывать о постоянных запросах на обновление статуса.
Дефекты - довольно естественная часть процесса разработки программного обеспечения. Я не думаю, что есть программист, который никогда не создавал ни единой ошибки. Но обычно, когда дефект находится в собственной реализации программиста, реакция совершенно противоположна тому, когда дефект находится в чужом коде.
Разработчик очень настороженно относится к таким дефектам. Первоначальная реакция часто заключается в том, чтобы как-то их отвергнуть. Если это невозможно, они пытаются найти лазейки в деталях требований, средах или в понимании тестировщика.
4. Почему нет входа в код?
Когда вы работаете над программным приложением, неизбежно возникают проблемы с производством. И в таких ситуациях хорошо оформленный журнал с соответствующими данными может спасти вам жизнь.
Если вы думаете, что отсутствие документации не является проблемой для понимания функции, представьте себе устранение производственных проблем без необходимых журналов. Работая над дефектом, разработчики расстраиваются, когда не находят помощи в журналах. Очень немногие разработчики обращают внимание на ведение соответствующих журналов.
Но я видел, как те же разработчики, которых разочаровывает отсутствие журналов, сами не записывают соответствующие операторы журнала. Когда я поднимаю вопрос во время проверки кода, они показывают мне кучу элементов TODO. Эти элементы TODO почти никогда не пересматриваются, чтобы заменить их действительными утверждениями.
В настоящее время у нас есть много полезных инструментов (например, Splunk) для эффективного поиска релевантной информации в миллионах строк журнала. Но инструмент работает только в том случае, если разработчик помещает в него действительные операторы журнала с требуемой информацией. Строки статического журнала без каких-либо динамических данных, кто угодно!
5. Разве они не читают электронные письма и не слушают во время разговоров?
Электронная почта и конференц-связь становятся все более важными в сценариях удаленной работы. Работая в корпоративных приложениях с заинтересованными сторонами и членами команды со всего мира, вы все равно не сможете их избежать.
Разработчики очень расстраиваются, когда им приходится часто кому-то объяснять детали. Они жалуются на невнимательность и искренность со стороны участников. Я очень хорошо понимаю разочарование.
Не приятно выделять время в своем плотном графике, чтобы просмотреть детали, которые вы уже отправили по электронной почте или объяснили во время предыдущего звонка.
Но те же самые разработчики делают прямо противоположное, когда их получают. Они не будут читать электронные письма и не обращать внимания на звонки. Позже они симулируют незнание темы и попросят вас снова объяснить.
Я чувствую, что многие люди с трудом очищают свои почтовые ящики регулярно. Не уверен, сколько из них на самом деле внимательно прочитали электронные письма. А сейчас, когда так много масштабных собраний, нелегко сосредоточиться на протяжении всего разговора. Однако мы должны помнить о времени каждого и проявлять должную осмотрительность, чтобы читать электронные письма или внимательно слушать на собраниях.
Последние мысли
Это некоторые из довольно распространенных жалоб разработчиков. Но довольно часто вы обнаружите, что люди, которые жалуются, делают те же ошибки, когда приходит их очередь.
Понятно, что никто не может быть идеальным. Мы все время от времени совершаем ошибки. Нет ничего необычного в том, чтобы ошибиться в течение долгого изнурительного рабочего дня. Близкие сроки и частые изменения требований тоже не помогают.
Будет замечательно, если каждый разработчик сделает свое дело на отлично. Но в реальной среде разработки программного обеспечения этого не происходит. Следовательно, будет полезно, если вы сможете внести свой вклад и помочь навести порядок, который кто-то оставил в своей доставке.
Спасибо, что прочитали статью. Вы также можете прочитать пару моих самых успешных постов:
