ICL Services
Новости
14 июля 2021
Новости

Готово!

Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook

Ok

ТОП-5 проблем программистов: как решать?

В работе над проектами приходится сталкиваться с разными ситуациями, в том числе экстренными и непрогнозируемыми. Со временем они становятся привычными, а для их решения вырабатывается эффективный алгоритм действий. Но всё равно отнимают силы и. время. Рассмотрим самые распространенные ошибки и проблемы программистов:
Проблема № 1:
Программист ошибся в оценке объема работ и просит расширения
Такие ошибки традиционно возникают из-за неверной первоначальной оценки масштаба проекта — когда ориентация идет на лучший сценарий, без адекватной оценки потенциальных рисков и сложностей, объёма задач и взаимовлияния выполняемых функций.

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

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

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

Решение
Правильный выбор технологического набора инструментов и фреймворков, используемых при разработке программного обеспечения, может гарантировать стабильную базовую производительность вашего продукта и ПО. И позволит избежать выгорания и авралов. И стоит помнить, что оптимальный объём знаний тот, который отвечает конкретному составу работ.
Проблема № 3:
Код, написанный одним программистом, непонятен другому и требует много времени на изучение
Большая часть программирования — это работы по улучшению существующей кодовой базы или её полное переписывание. Самые успешные кодовые базы в мире были разработаны сотнями людей, которые никогда не встречались друг с другом. У многих из этих проектов было очень мало документации (или вообще не было), отсутствовали комментарии в кодовой базе, рекомендации или помощь.

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

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

Проблема № 4:
Новый программист на проекте критикует предыдущего и рекомендует переделать всё с нуля
Работа на проектом носит командный характер, и новым участникам важно это понимать. Если критика неконструктивна и затратна, то она никак не скажется на прогрессе.
Решение
В данной ситуации нужны шаги с обеих сторон. Новички должны влиться в команду и помочь ей работать продуктивнее. А, рекрутёрам или менеджерам проекта — если они заметили в сотруднике такие черты — лучше изначально отказаться от услуг «критикана» и поменять его на другого специалиста.

Проблема № 5:
программист просит выделить время на переработку своего кода и устранение дефектов, которые не видны пользователям системы
Основная цель переработки или перепроектирования (рефакторинга) кода — сделать его более эффективным и удобным в обслуживании. Это помогает снизить затраты на будущее обслуживание и поможет предотвратить новые ошибки.

Решение
Делать переработку кода медленно, но неуклонно. И при планомерной работе вы увидите, что постепенно код становится более компактным и читаемым. Люди увидят изменения, но на это требуется время.

Из опыта и рекомендаций:
не забывайте повторно факторизовать код, которого вы касаетесь;
удаляйте устаревший код;
просите перефакторинг каждый раз, когда вас просят проверить изменение кода.
Несмотря на разнообразие ошибок, объединяющим их начало — профилактика. Эта задача стоит и перед программистами, и перед менеджерами проекта. Регламент внутренних коммуникаций в команде или единая стратегия работы технических специалистов помогут предотвратить непредвиденные потери.

Автор: Андрей Крехов - директор по специальным программам компании ICL Services.

Статья размещена на Tproger.
Поделиться:

Новости по теме

    Свяжитесь с нами

    Контакты Пресс-службы
    Телефон 8 (800) 333-98-70

    pr@icl-services.com

    Будьте в курсе новостей

    Подпишитесь на рассылку и будьте в курсе наших последних новостей

    Подписаться на рассылку
    Спасибо, что подписались на рассылку новостей! Адрес подписки успешно добавлен! Ok
    На сайтах icl-services.com используются cookie-файлы. Оставаясь на сайте, вы даете свое согласие на использование нами cookie-файлов. Если, прочитав данное сообщение, вы не согласны, просим вас покинуть сайт.

    Задать вопрос эксперту

    Ф.И.О*
    E-mail*
    Наименование организации*
    Должность*
    Телефон*
    Вопрос*

    Заказать звонок

    Ф.И.О*
    Контактный телефон*
    E-mail
    Компания*
    Наверх