Почему программисты не любят чужой код

Какие привычки программистов мешают писать хороший код и как от них избавиться — отвечают эксперты

Ответы экспертов, 14 октября 2019 в 17:41
Никита Прияцелюк

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

Александр Патлух , разработчик образовательных программ в «Яндекс.Практикуме»

Мы видим много новичков в веб-разработке, мы их учим. Многие меняют жизнь кардинально и не обладают никаким опытом, а кто-то приходит к нам, попробовав что-то на других платформах. У большинства можно встретить типовые ошибки и заблуждения, которые ведут их не туда, мы стараемся корректировать поведение студентов и обращаем на это внимание.
Когда только начинаешь кодить, у тебя всё получается, ведь задачи перед тобой стоят простые. В этот момент легко очароваться и почувствовать своё всемогущество. Рынок стонет и рассказывает нам, как много неадекватных джунов приходит на собеседования. Это напрямую связано с опасным заблуждением новичков, что они уже классные, если могут что-либо собрать на определённом стеке. Нужно помнить, что профессионала не в последнюю очередь определяет количество ошибок и проблем, с которыми он справился.

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

Третья группа заблуждений связана с самими технологиями. Для большинства задач уже написаны библиотеки, которые упрощают написание кода. Но это не значит, что надо сфокусироваться на изучении библиотек. Если ты действительно хорошо знаешь JavaScript и добавляешь к этому базу computer science, тебе не важно React, Vue, Angular или новенький Svetle указан в ТЗ. Просто нужно время на чтение документации. Словом, нужно всегда стараться смотреть на более низкий уровень технологий и разбираться, как всё работает «под капотом».

Есть ещё проблема нежелания расширять кругозор, предпочитая учить что-то одно. Безусловно, на старте нужно привыкнуть к новому синтаксису или особенностям какого-то языка программирования или фреймворка. Но на самом деле учиться надо программировать, а не писать на чем-либо. Программирование — это не про конкретный язык, это про то, как писать инструкции компьютерам. Человечество многогранно изучило этот вопрос ещё до появления JS или Python. Парадигмы, паттерны, структуры данных, алгоритмы — это всё великое наследие, не стоит им пренебрегать.

Отдельно в этом контексте хочется отметить новичков, которым нравится верстать, но они не могут назвать хотя бы три студии или дизайнера, чьи работы их вдохновляют.

Напоследок самое, пожалуй, неочевидное. Изучая программирование, необходимо тренировать не только хард скиллы, но и софт скиллы. Умение задавать вопросы на Stack Overflow, проходить собеседование, вести себя в технической команде, — часто про это забывают. При этом, быть приятным человеком со знанием основ часто лучше, чем быть гуру, но мерзавцем.

Наталья Тищенко , SMM-специалист в компании Seven Winds Studio

Многие новички считают свой код идеальным, но они заблуждаются. Идеального кода не существует! Любой код имеет возможности совершенствоваться. Как сказал один из наших программистов:

Сколько бы лет ты не занимался написанием кода, новый всё равно будет лучше и лучше предыдущего.

У начинающих разработчиков, узнавших о новом фреймворке или изучавших новый язык программирования, часто возникает непреодолимое желание прямо здесь и сейчас переписать проект с нуля, «теперь-то уже точно правильно». Поспешим расстроить — это плохая практика. Реальность такова, что за каждым проектом обычно стоят бюджеты и сроки. Остановка разработки на несколько месяцев при переписывании проекта обычно никому не нужна. Постепенное переделывание проекта по модулям — хорошо. Снос до основания и переделывание с нуля — плохо.

Ещё один из немаловажных вопросов — стоит ли бояться костылей? Нет, но к ним нужно относиться настороженно. Это рабочий, но не универсальный код, который желательно отметить комментарием. Костыли могут теряться со временем и при расширении/увеличении программы костыль скорее всего сломается/придётся от него избавиться. Костыли — это меньшее зло. Большее — сорвать сроки!

Любому программисту всегда следует читать мануалы. Мануалы — любая литература/статьи/обзоры/видео по той теме которую делаешь. Причем начинать можно с азов: if, переменные, память, — и до чего-то объёмного: паттерны, архитектуры кода и что-то обособленное — VR, вёрстка, оптимизация. Если застряли — спрашивайте у опытных товарищей или на форуме. Можно сначала поискать информацию в интернете, а можно сразу бежать за советом — это вопрос совести.

Чужой код — это ловушка. Если вы не знаете, как это работает, — значит, не знаете и результат работы кода.

Плагин = чужой код, который ты не знаешь.

Будьте всегда готовы, что ОНО обновится и отвалится. Поэтому плагины стоит использовать с осторожностью.

Для того, чтобы у вас как у начинающего программиста получился хороший код, необходимо придерживаться следующих правил:

Следуйте стандартным правилам оформления кода.
Пишите комментарии к своему коду в процессе написания. Что делает каждая из функций, её положительные и отрицательные стороны. Также стоит помнить, что лучший комментарий — это говорящие сами за себя названия функций и переменных.
Не копируйте чужой код. Вместо этого изучите его. Как он работает и будет ли он полезен вам?
Избегайте использования аналогичных кусков кода.
Не забывайте проверять свой код на наличие ошибок.
Проектируйте код с расчётом на дальнейшее расширение функциональности.
Не полагайтесь на то, что определённые типы данных (integer, указатели и временные метки) будут иметь конкретную длину (например 32 бита), потому что этот параметр отличается на разных платформах.

В профессии программиста существуют как хорошие, так и плохие привычки, но всё зависит именно от вас. Как вы распределяете своё время и насколько стараетесь совершенствовать свой код. Помните, что любой код имеет свойство устаревать.

О чем нужно помнить, читая чужой код

Перевод статьи Вильяма Шона «How to Read Code (Eight Things to Remember)»

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

Причина ненависти к чтению чужого кода проста: этот код писали не мы. Я не открою большой секрет, сказав, что в глубине души каждый считает себя лучшим программистом в мире. Буквально никто не может писать код так, как пишем его мы. Связано это с тем, что при создании кода происходит интенсивная умственная деятельность, а пассивное чтение не приводит к такому эффекту, и это разочаровывает.

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

Вы видите перед собой готовый продукт. И единственный явный контекст это слова у вас на экране. Если, конечно, не углубляться в поиски.

1. Учитесь внедряться

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

Если вам предстоит работать с кодом, создатели которого пользовались системой контроля версий, то вы настоящий везунчик. У вас есть доступ к богатству метаданных, что позволит вам понять не только код, но и контекст, причем с меньшими усилиями. Для целей этой статьи будем считать, что вы пользуетесь Git, но идеи те же и в случае с SVN.

git blame

Благодаря команде git blame вы можете узнать, кто автор и когда файл изменяли в последний раз. Также можно посмотреть хэш коммита для каждой строки.

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

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

Знакомство с автором даст вам возможность обратиться к нему напрямую, если вам встретиться непонятная функция, с которой вы не сможете разобраться самостоятельно.

git log

Команда git log используется для просмотра истории коммитов по всему репозиторию. Она выводит все commit messages. Поэтому, если вам нужно найти что-то определенное, воспользуйтесь конвейером и командой grep. Следующая команда выведет все сообщения, в которых встречается «someFunction», с тремя строками контекста:

При использовании флага -p можно просмотреть историю какого-то конкретного файла:

Посмотрите, кто вносил самые недавние изменения: так вы будете знать, к кому обращаться за информацией, если что.

2. Обратитесь к прошлому

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

Если ваш проект хостится на GitHub или в похожей системе, то вам повезло. Вы можете извлечь кучу полезный сведений, просматривая issues, пул-реквесты и ревью кода. Приглядитесь к issues, по которым были самые длинные дискуссии. Они могут оказаться проблемными местами. Когда-нибудь вы на них наткнетесь, а заранее почитав ветку обсуждений, будете уже знать, что с этим делать.

3. Читайте спецификации

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

4. Воспринимайте комментарии как подсказки

Допустим, вам повстречалась странная функция, а чтение комментария к ней только еще больше все усложнило. Есть вероятность, что этот комментарий уже утратил актуальность.

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

5. Найдите основное

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

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

Проверьте этот файл с помощью git blame, посмотрите, что менялось в недавнее время. Отрывок кода, в который вносились последние изменения, может стать зацепкой. С ее помощью вы сумеете определить причины проблем, с которыми команда столкнулась в последние недели. Возможно, была представлена новая библиотека, возможно, дело в попытках настроить библиотеку, которая не работала должным образом, а может, это просто boilerplate code, который нужно постоянно обновлять.

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

6. Стиль написания

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

Каков общий уровень абстракции? Если это высокоабстрактный многослойный код, вы должны быть готовы писать такой же.

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

Как пишут код другие члены команды? Если разработчики предпочитают циклы, а не maps, то вам, вероятно, стоит поступать так же.

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

7. Ожидайте столкнуться с мусором

Вы можете обнаружить функции, которые никогда не использовались. Да что там – целые файлы. Вам может попасться закомментированный код, к которому годами никто не прикасался (git blame в помощь). Не тормозите и не думайте об этом чересчур долго, а также не бойтесь избавляться от таких вещей.

Если бы этот код был нужен, то кто-нибудь пометил бы его в ревью кода. Удалив его, вы облегчите участь следующего читателя.

8. Не заблудитесь

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

7 навыков успешного программиста

Блогер с ником SeattleDataGuy в своей колонке на Medium рассказал о семи навыках, которыми должен обладать хороший программист.

1. Умение читать чужой код

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

Почему это полезный навык? Во-первых, способность понимать чужой код – отличная возможность увидеть, что значит плохое проектирование. Анализируя чужую работу, вы понимаете, что получается, а что – нет. Более того, вы осознаете, какой код легче понимать другим разработчикам, а какой – наоборот.

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

2. Чутье на плохие проекты

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

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

3. Избегание совещаний

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

Самый распространенный метод – просто блокировать по два часа каждый день в расписании на совещание. Еще один способ – приходить на работу раньше всех, чтобы успеть сделать работу в тишине и покое и не отвлекаться.

4. Умение пользоваться Github

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

Независимо от того, какую систему использует ваша компания, она превращается в большую помеху, если использовать ее неправильно. Простой push или commit могут привести к тому, что вы часами будете пытаться распутать паутину из множества бранчей и форков. В дополнение к этому, если вы забудете о команде pull и не обновите последнюю версию репозитория, вам придется решать разные конфликты слияния, что вряд ли можно назвать интересным занятием.

5. Написание простого рабочего кода

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

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

6. Умение говорить «нет» и расставлять приоритеты

На самом деле это касается любой должности. Но в частности кажется, что от сотрудников-технарей всегда всем что-то нужно.

Приоритезация и умение говорить «нет» – тесно связанные друг с другом навыки. Расставлять приоритеты – значит уделять время на задачи, которые окажут большое влияние на компанию. Говорить «нет» – значит избегать работу, которую должна делать другая команда.

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

7. Дизайн-мышление

Навык, который сложно протестировать во время собеседования и которому сложно обучиться в университете – умение понимать, как конечный пользователь может неправильно использовать ваш софт.

Например, поскольку основная часть программирования – это поддержание, это значит, что зачастую приходится менять запутанный код другим. Даже простое изменение требует отслеживания каждой возможной отсылки на объект, метод и/или API. Иначе вы можете случайно сломать привязанные модули, о существовании которых не знали. Даже если вы просто меняете тип данных в базе данных.

Это также включает продумывание пограничных случаев и всего высокоуровневого проектирования перед началом разработки.

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

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

Источники:

http://tproger.ru/experts/bad-programmers-habits/
http://vk.com/@javarush-o-chem-nuzhno-pomnit-chitaya-chuzhoi-kod
http://rb.ru/story/7-effective-programmer-skills/

голоса

Рейтинг статьи