Быстрые решения могут иметь долгосрочные последствия

Почему разработчикам стоит заботиться об именах

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

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

Имена имеют долгую жизнь

Я работал над проектом, который был назван в честь птицы, скажем, Попугай. Нам пришлось разработать веб-сервис только для этого проекта, но не было учтено, что сервис может быть расширен и повторно использован для каких-то будущих нужд. Новое приложение было названо Parrot и звучало хорошо и логично. Вначале.

Но угадайте, что случилось, когда проект закончился?

Веб-сервис продолжал использоваться, но больше не имел никакого коммерческого значения. Конечно, мы рассматривали возможность изменения его названия, но это никогда не было приоритетной задачей, и затраты не были незначительными, поскольку это было публично разоблачено. В конце концов, были веб-службы под названием Order для управления заказами или Customer для управления клиентами и Parrot для управления… что, птицы? Теперь вы понимаете, почему это было плохое название.

Имена могут сбивать с толку

Каждый разработчик сталкивался с искушением определить такие переменные, как foo, value или даже одну букву, например i. Во-первых, это экономит несколько символов, поэтому вы можете ускорить время разработки, сократив его до нескольких миллисекунд ввода. Молодец!

Но теперь, если вы попытаетесь прочитать код еще раз, вы можете потратить дополнительное время на то, чтобы угадать, что такое foo. Отправка кода рецензенту будет стоить еще больше времени (и если рецензент немного опытен, он / она должен указать на это как на ужасную практику и отклонить ваш запрос на перенос, поскольку это снова пустая трата времени, но для двух человек Теперь).

Код пишется только один раз, но читается десятки раз.

Именование, а не комментирование

Некоторые разработчики обычно добавляли комментарии в тело методов, и иногда компания может потребовать от компании написать документ для каждого (общедоступного) метода. С моей точки зрения, и то, и другое не нужно, если именование хорошее. Вам действительно нужно написать документ для метода с именем getOrdersByDeliveryDate? Что бы вы написали, чтобы описать это? Этот метод позволяет получать заказы в соответствии с датой их доставки. Да, правда? Ух ты!

Единственное исключение для комментариев - это когда код может вести себя не так, как ожидалось, независимо от воли разработчика. Например, если в коде используется сторонняя библиотека или когда результат вызова внешней службы звучит немного странно. Во всех остальных случаях я не вижу веских причин для написания комментариев, я просто предпочитаю хорошее нейминг. Что касается документации по методам / службам, хотя существуют такие инструменты, как Javadoc, они полезны только в открытом виде. И до сегодняшнего дня я никогда не работал в компании, которая публикует свою кодовую документацию, даже внутри компании. Итак, мой совет - сосредоточиться на написании хороших спецификаций, глобальных схем, архитектурных проблем или описании API, но не на самом коде.

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

Говорите на одном языке

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

Я помню застенчивого коллегу на предыдущей должности, который отчитывался перед занятым старшим разработчиком, печально известным своим малым терпением. Я часто видел, как этот запуганный младший разработчик подходил к старшему с опасениями, боясь показаться глупым. Как только он открыл рот, он стал подбирать слова, потратив много времени на объяснение чего-то, что в конечном итоге оказалось неясным. Старший изо всех сил старался сохранять спокойствие, но однажды он грубо ответил: «Хорошо, возвращайся к своему столу и возвращайся, когда поймешь свой вопрос». Всем было ужасно неловко.

Я на 100% убежден, что таких ситуаций можно было бы избежать, если бы разработчик говорил точными словами, точным вариантом использования, сначала настраивая контекст, а затем задавая четкий вопрос с предложением решений, то есть говоря на одном языке. Возможно, это также помогло ему преодолеть застенчивость. Назовите вещи правильно и поймите их, прежде чем двигаться дальше.

Ничего революционного, правда?

Заворачивать

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

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