* На днях наткнулся на интересную заметку о плохих привычках программистов. Может для кого-то это очевидные вещи, но зачастую на них не обращаешь внимания.
Наши привычки постоянно развиваются и меняются. Изменяется стиль кодирования, подход к написанию кода в целом. Обычно это хорошо, но иногда этот процесс минует некоторые плохие привычки и они надолго остаются с нами. Я хотел бы поделиться размышлениями о некоторых «не очень хороших» привычках, которые я наблюдал в себе и в других людях на протяжении многих лет. Некоторые даже могут быть не похожи на плохие…
Бросаем неиспользуемый код
Иногда мы решаем переписать какую-то часть нерабочего кода или попросту хотим его немного улучшить (многие из нас стремятся к перфекционизму). Старый код комментируется и вместо него пишется новый. Это отлично, но после того, как работа закончена, старый код необходимо удалить! Если этого не сделать, количество таких закомментированных участков начнет увеличиваться, и со временем они станут отвлекать внимание от других важных частей.
К примеру, однажды ко мне обратился один из клиентов с просьбой добавить некоторые новые возможности в его существующем проекте. Я скачал код и обнаружил, что в нем закомментированных участков больше, чем реального кода. Это ужасно отвлекает и делает код менее читаемым.
Неиспользуемые функции в коде ваших приложений — это еще одна распространенная проблема. Когда-то в них была необходимость, но с развитием проекта они перестали вызываться. Привлекая нового разработчика к проекту будьте уверены — он потратит время на их анализ.
У вас же есть система контроля версий для хранения старого кода, не бойтесь его удалять! Сделайте это прямо сейчас!
Чрезмерно обобщаем
Многие программисты пытаются писать код, который будет способен обработать все, что вы ему скормите, и начинают применять этот подход в каждом проекте. Я создал много компонентов, фреймворков, свой игровой 3D-движок, чтобы достаточно разбираться в написании абстрактного кода. Для 90% приложений в таком подходе нет необходимости.
Мы думаем, что будем использовать наш код в дальнейшем, поэтому пытаемся сделать его максимально обобщенным и абстрактным. Вы разрабатываете свой компонент? Как насчет того, чтобы убедиться в том, что он обрабатывает 10 ситуаций, даже если нам необходимо всего 2 в текущем приложении?
У меня для вас плохие новости. Едва ли вы будете использовать свой код в других проектах. Вы тратите свое время или время вашего клиента (за которое он платит), создавая ненужные в проекте вещи вместо того, чтобы сфокусироваться на том, что действительно важно. Если вы используете ваш класс во втором (или даже в третьем) проекте, то вероятно вам стоит выделить его в отдельную сущность. Вы ведь наверняка в этом убедились на реальных проектах.
Зацикливаемся на ООП
Хочу отметить: я большой фанат ООП, я люблю этот подход, так как он легок для понимания и сопровождения.
Но некоторые люди склонны создавать себе проблемы, излишне увлекаясь декомпозицией (это похоже на предыдущий пункт о чрезмерном обобщении). Проект не должен увеличиваться пропорционально количеству классов, которое вы можете придумать. Если вы начали писать класс, который состоит из одной единственной функции, остановитесь и подумайте — действительно ли это так необходимо?
Чрезмерное обобщение и разбиение на классы может иметь в дальнейшем очень плохие последствия. Код, разбитый по нескольким классам, будет сложнее оптимизировать. Могут возникнуть сложности с добавлением новых функций… Всегда думайте о связях между вашими классами, действительно ли есть необходимость выносить этот код в отдельный класс? Может это не имеет большого смысла?
«Я могу реализовать это лучше»
У каждого из нас присутствует огромное эго. Мы думаем, что мы можем написать все, что угодно и наверняка лучше, чем кто-либо другой. Так вот, оставьте ваше эго дома!
Это касается практически всего, что мы делаем. Если возникает необходимость поработать над чужим проектом, достаточно беглого взгляда на код, чтобы подумать «он ужасен! я могу сделать это нааамного лучше!». Анализируя какой-то компонент для интеграции, вы можете решить «будет намного лучше, если я напишу это с нуля».
И снова у меня для вас плохая новость: практически любой код может выглядеть как полная ерунда для кого-то другого, ведь у каждого разные подходы и опыт. Разработчик, который месяцами систематически работал над проектом, действительно знает, что заслуживает внимания. Потенциально вы не можете этого оценить всего лишь окинув беглым взглядом его код. На самом деле есть много примеров, когда код действительно дерьмовый, но это становится очевидным сразу (код из реального проекта, который меня попросили улучшить, имена переменных изменены):
- (void)dealloc {
[A release];
[B release];
[A dealloc];
[B dealloc];
A = nil;
B = nil;
[self release];
[super dealloc];
}
Почти всегда можно найти хорошие компоненты, позволяющие решить поставленные задачи, вместо того, чтобы писать свои собственные. И всегда лучше использовать то, что уже оттестировано сообществом, вместо того, чтобы создавать это с нуля.
Просто прикиньте: сколько понадобится времени для того, чтобы написать код, затем убедиться, что все работает так, как задумано, и после всего осознать, что вы недостаточно хорошо что-то оттестировали. Разработка с нуля полезна только в целях обучения, но никак не в проекте, который надо сдавать через 2 недели.
А если вы не верите, что можете писать плохой код, просто откройте какой-то проект, который написали пару лет назад. Уверен, что вам этот код покажется ПЛОХИМ.
Боимся вспомогательных инструментов (писать меньше кода)
Люди противятся изменениям. У нас есть привычки, которые мы считаем правильными и необходимы определенные усилия, чтобы выйти из зоны комфорта и попробовать что-то новое.
Многие программисты, которых я встречал, считают, что использовать Interface Builder — плохо. После первого знакомства с IB, который мне откровенно не понравился, я в течение 2х лет создавал элементы UI через код. Однако затем я преодолел свою зону комфорта и дал ему второй шанс. За это время Interface Builder был существенно улучшен, появились приятные вещи по типу Storyboard, и он стал превращаться во все более полезный инструмент. В итоге IB оказался мне полезным в определенных случаях и не только для простых интерфейсов — с его помощью можно делать довольно продвинутые вещи.
Будьте прагматичны и выбирайте наиболее подходящий инструмент для своей работы. Иногда лучше реализовывать интерфейс через код (например свой UITableViewCell для быстрой отрисовки), но в большинстве случаев Interface Builder прекрасно решает поставленные задачи.
Ну и конце концов, чем меньше кода вы напишете, тем меньше багов придется отлавливать.
Заключение
Наверняка существует еще много плохих привычек, о которых вам известно (можно даже написать об этом книгу). Приведенные здесь примеры могут быть не самыми очевидными, но я сталкивался с ними довольно часто, работая с разными людьми. И самое главное — если кто-то совершает ошибки, то это вовсе не значит, что он плохой программист, ведь у каждого из нас есть плохие привычки и главная задача состоит в том, чтобы избавиться от них. Посмотрите на код, который вы написали 3 года назад и скажите, что он вам нравится сейчас.
