В любой работе встречаются свои трудности. Иногда их провоцирует сам работник, нарушая заповеди своей профессии. Но мало кто задумывается об этом. А вот пользователи сайта Quora составили личные списки грехов программирования.
Джон Парселл, создатель CaveOfProgramming.com
- Использовать «Пробел» вместо «Tab». Всегда, всегда используйте «Tab», а не «Пробел».
- Использовать «Tab» вместо «Пробела». Всегда, всегда используйте «Пробел», а не «Tab».
- Не использовать автоформатирование. Забудьте про весь мусор вроде табов и пробелов, используйте автоформатирование в своем коде и людям не придется видеть ваши странные скобки и отступы.
- Использовать интегрированную среду разработки (IDE) с ее автоформатированием и цветными клавишами. Все коды должны быть написаны в vi или Emacs, что подтверждает безупречность ваших навыков программирования.
- Не использовать IDE. Никто не хочет платить за время, которое вы тратите на набор текста, если это можно сделать в один клик, или за прокручивание вверх-вниз с помощью заумной комбинации клавиш из LISP.
- Не учить С и С++. Два этих языка жизненно необходимы любому программисту. Думаете, Java так же хорош? Отлично, создайте мне систему управления гоночными автомобилями в режиме реального времени на Java, и я вам поверю.
- Учить С и С++ в то время, которое вы могли бы использовать на что-то более современное, например, на Java. Признайте – все таблицы, написанные на С или С++, изживают себя в течение 5 лет. И в таком случае в программном обеспечении есть серьезные ошибки, которые Java просто не позволил бы вам совершить.
Рой Леман, разработчик ПО
- Сначала написать, потом подумать. Вы получили требования к товару, пробежались по ним, запустили свою любимую IDE и принялись за работу. Легко, не правда ли?
Стоп! Вы уверены, что поняли требования до конца? Я не сомневаюсь в вашем умении читать. Но учли ли вы все пограничные случаи? Продумали, как будете тестировать систему? Набросали алгоритм, который собираетесь использовать? Завтра вы этого и не вспомните! - Изобретать колесо. Итак, вам нужно создать шаблон проектирования Producer-Consumer. Вы знаете, как это сделать, еще с университетской скамьи… Легко, не правда ли?
Стоп! Не важно, с каким языком вы работаете, уже существуют готовые шаблоны, или модули, или открытые исходники. Используйте их. Или по крайней мере изучите их перед тем, как создавать свои. - Бояться прикасаться к коду. Итак, у вас есть задание добавить несколько функций к 20 000-линейному файлу (О, нет! За что?) Вы радостно беретесь за работу и вдруг замечаете огрехи в исходных функциях – нет пограничного случая или проверки на нулевой показатель. Это находится за пределами сферы вашей ответственности. Так? Стоп! Если вы видите небезопасный код – исправьте его. Вы еще хлебнете на этих ошибках, даже если код написан не вами!
- Быть безразличным к тому, чем занимается ваша компания. Вы программист, верно? Написание кодов – это здорово, вы не изучали маркетинг или продажи, с чего вам интересоваться тем, что не имеет к вам отношения?
А следовало бы! Как можно создать продукт, не понимая, чем занимается компания? Как сделать так, чтобы продукт удовлетворял потребности клиента?
Никак! Изучите дело, будьте в курсе всех вопросов компании, а не только тех, которые касаются непосредственно вас. Это важно! В какой-то момент это даже может повлиять на ваше повышение.
- Не следить за новыми трендами. Вы занимаетесь программированием уже 10 лет и подыскиваете работенку.
Перед этим вы работали старшим разработчиком С++ в крупной корпорации – за многое отвечали и имеете отличные рекомендации. Вы вроде знаете, что такое DevOps, но на практике никогда не сталкивались с этими практиками и с С++14? На вашем предыдущем месте работы в ходу был С++98… Не так уж важно, не так ли?
Нет, не так!
Никто не похвалит вас за владение технологиями 15-летней давности!
Если вы не учитесь в свободное время, чтобы соответствовать запросам работодателя, ваша кандидатура будет отвергнута! - Не обладать коммуникативными навыками. Вы разработчик, к чему вам уметь общаться с людьми! Вам платят за умение общаться с компьютером, а не коллегами. Сиди себе, пиши качественные коды и добьешься успеха, верно?
Не верно!
Ваше неумение кратко и четко изложить суть дела вышестоящим – самая большая головная боль для менеджера.
Очевидно, что это не единственный параметр, по которому вас оценивают, но все же – грамотное предоставление информации в дружественной манере повысит доверие со стороны коллег и вот тогда вы добьетесь успеха. - Не иметь целей. Вам нравится ваша работа, вы прекрасно владеете технологиями Deep Learning. Передовые технологии, прекрасные коллеги… Вы могли бы работать так вечно.
Но – вы не будете. Все когда-нибудь заканчивается, иногда резко и неожиданно. Если у вас не будет карьерных целей, вы можете оказаться на задворках, выполняя работу и получая зарплату, которые вас не достойны.
Так что думайте наперед – где бы вы хотели оказаться через 10 лет? В какой роли вы себя видите?
Научным работником? Разработчиком? Менеджером по продукции? Вице-президентом? Техническим директором? Исполнительным директором?
Вам решать!
Нико Салминен, старший консультант
- Лень: Ну, кажется, код работает нормально. Нет необходимости писать комментарии или проводить автоматизированное тестирование.
- Похоть: Эй, а ведь этот новый срочный проект – отличная возможность опробовать новый крутой фреймворк, о котором все говорят!
- Зависть: Другая команда продвигается быстрее, чем мы. Лучше не помогать, если у них возникнут проблемы при интеграции с нашим кодом.
- Чревоугодие: Мне нужно выполнить итерацию ключей объекта. Мне совершенно необходимо импортировать 1,5-Мбайтную библиотеку для проведения этой операции.
- Гордыня: Прочтение этой книги по шаблонам проектирования сделало меня лучшим разработчиком, нежели коллеги! Я собираюсь использовать каждый шаблон, упомянутый в книге при работе над следующим проектом.
- Гнев: К черту все! Пускаю этот патч hotfix прямиком в производство!
- Алчность: Они что предлагают изменить код в моем репозитории? Отклонить! Это мой проект!
Усман Шаукат, более 8 лет опыта в сфере веб-разработки, PHP, Javascript, Node.Js
Вопрос касается программирования не как процесса разработки ПО в целом, так что мой ответ касается непосредственно фазы программирования:
- Программировать, не планируя. Самый страшный из всех грехов.
- Пытаться изобрести колесо. Если есть возможность, всегда используйте алгоритмы, предложенные в книгах и научных статьях (например, алгоритмы сортировки, поиска и т.д.), а не пишите собственные.
- Писать несистематизированные/некачественные коды и не придерживаться стандартов программирования.
- Считать, что тестирование – это не ваша забота. Я вас очень прошу, пожалуйста, тестируйте свои коды.
- Писать сложный код, когда с тем же успехом можно обойтись простым. Простые коды – это элегантно.
- Слепое копирование-вставка с сайтов вроде stackoverflow.com без ознакомления с пояснениями и комментариями.
- Последнее, и самое важное – совершенствуйтесь сами и осваивайте новый инструментарий. Никогда не бойтесь новшеств. Знакомьтесь с ними раньше всех. Это поможет вам оставаться востребованным.
Автор: Валерий Фетисов
Дата публикации: 2018-01-31T06:09:00.000+02:00
