Стоит тратить время на красивый код

11 ноября, 14:23 Работа 3792 3

Стоит ли тратить время на «красивое» оформление кода согласно разным Style Guide, если того не требует заказчик? Или же это всё дурные мысли, появляющиеся от безделья, и главное, чтобы код работал?

3 комментария
Сортировка:
Добавить комментарий
Віктор Омелян
Віктор Омелян 2019, 11 ноября, 18:32
0
Если программист работает в команде (или в ближайшее время такая работа планируется), то возникает необходимость в документировании и тестировании исходного кода, а также в корректном именовании переменных, соблюдении стилевого гида. Это необходимо для того, чтобы прямо через исходный код сообщать о своих намерениях коллегам. В противном случае, над проектом всегда будет висеть угроза большого количества ошибок, возникших в результате влияния одних кусков кода на другие — регрессий. Командная работа также подразумевает использование нетривиальных техник программирования — design patterns. С их помощью код разбивается на необходимые структурные элементы, которые документируются и тестируется независимо друг от друга. Если все программисты, работающие над одним проектом, говорят на одном «языке» архитектуры приложения, то каждый сможет написать такие независимые модули, а вероятность их «поломки» будет стремиться к нулю. Design patterns, unit tests, документирование кода — это своеобразное письменное соглашение программистов о том, как ведётся работа над конкретным проектом. Она помогает коллегам лучше помогать друг друга через код.
Artur Voznesenskij
Artur Voznesenskij 2019, 11 ноября, 16:52
0
Программист-профессионал чётко знает, что и для кого он пишет, какую задачу должен решать этот код, даже если единственное требование заказчика — «чтобы работало». Код не должен впечатлять, он должен быть понятным, однозначным, конкретным, предсказуемым в будущем. Такой код намного проще не только поддерживать, но и оптимизировать, и фиксить при необходимости. Большую роль играют наименования переменных и методов, поскольку значительно упрощают чтение кода. Достижение той же цели, но значительно меньшим количеством кода, делает его более надёжным. Комментируйте, но не увлекайтесь. Не проектируйте лишнего, отталкивайтесь от определённой задачи. Отслеживайте ошибки.
Viktor Kravchenko
Viktor Kravchenko 2019, 11 ноября, 16:51
0
Открывая меню любого ресторана/бара/кафе, что вы делаете в первую очередь? Видите картинки. Для себя определяете: нравится ли блюдо, понятен ли его состав, большая ли порция, будет ли её достаточно. Согласитесь: если вам принесут некую непонятную субстанцию, пусть даже и гипотетически вкусную, первая реакция — недоверие. Так и с кодом: глядя на него, вам будет хотеться понять его алгоритм, оценить, как программа поведёт себя в том или ином случае, где необходимо внести определённые правки.

IT Новости

Смотреть все