Сложность как основная проблема программирования доклад

Обновлено: 02.07.2024

Сидячий образ жизни, работа с устаревшим кодом и поиск багов — разработчики, как и люди других профессий, сталкиваются со сложностями в работе. Можно долго дискутировать о том, что самое сложное для программиста, а можно просто спросить мнение девелоперов. Нам было интересно узнать, что выводит разработчиков из себя, поэтому мы провели опрос и собрали результаты в этом тексте. В нашем опросе участвовали ученики и выпускники JavaRush — как те, кто еще проходит курс, так и те, кто уже устроился на работу. Это важно понимать, потому что мнение о сложностях в работе для этих категорий отличается. Вот такие, например, проблемы выделяют ученики JavaRush, которые пока что на пути к своей первой работе:Работающие программисты думают иначе: получая реальный опыт, мнение о сложностях в разработке у девелоперов меняется. Например, на первом месте для работающих программистов стоит проблема отсутствия спецификаций, а для учеников — работа с legacy-кодом.Для бэкграунда также добавим, что среди работающих выпусников JavaRush больше всего тех, кто устроился в продуктовую компанию, на втором месте — разработчики в аутсорсе и всего 3,8% девелоперов трудятся на ниве фриланса.Разберем сложности в работе подробнее — с комментариями разработчиков. А заодно узнаем, что девелоперам больше всего нравится в их работе и как сложились их отношения с удаленкой.

Отсутствие спецификаций

Отсутствие спецификаций, то есть описаний поведения программы, которую требуется разработать, — это первая проблема в списке сложностей для работающих программистов (ее отметили 69,2% разработчиков). Как мы упоминали выше, интересно то, что учащиеся и ищущие работу немного иначе представляют, какая проблема программирования будет главной. Для этой категории это работа с legacy-кодом (устаревшим кодом — ред.) — за нее проголосовали 45,5% опрошенных. Это различие в ответах говорит о том, что учащиеся не до конца понимают проблемы, с которыми столкнутся на практике. Среди учеников проблема отсутствия спецификаций стоит на втором месте (за нее проголосовали 36,4% людей).

Вот что рассказали программисты об отсутствии спецификаций: “Работаю недавно, как работает приложение пока понимаю плохо”, — говорит Денис. “Без понимания нюансов продукта и без должной спецификации, тяжело вносить изменения или рефакторить старый/специфический код”, — считает Андрей. “Сложно переключаться с задачи на задачу при отсутствии документации или спецификации”, — отмечает Роман. “Из-за неточного техзадания [приходится] придумывать решение, которое потом критикуется и требуется переделка”, — говорит Вероника. “Отсутствие внятного техзадания в 90% случаев”, — говорит Денис. “Нет четких технических заданий, заказчики сами не знают, чего хотят. Уже на стадии разработки задание может кардинально поменяться”, — добавляет Андрей.

Оценка сроков выполнения задач и работа с legacy-кодом

Невнятные дедлайны оказались на втором месте в списке сложностей работы программиста. За них проголосовали 42,3% работающих айтишников. В то же время, учащиеся поставили эту проблему всего лишь на пятое место (18,2% голосов). Чаще всего программисты жалуются на то, что работодатель неправильно оценивает сроки выполнения задач или на то, что имея мало опыта, сами не могут посчитать правильные сроки. “Иногда бываю не уверен в сроках, за которые выполню таск и ставлю больший estimate (оценку — ред.), хотя выполняю быстрее. Порой это напрягает клиентов”, — говорит Игорь. “Сроки выполнения устанавливаются с потолка и другими людьми, зачастую не имеющими отношения к разработке”, — говорит Денис. “Время на задачу, в которой нет опыта, трудно определить”, — добавляет Николай. Работа с устаревшим кодом набрала столько же голосов среди работающих программистов, сколько и размытые дедлайны — 42,3%. Напомним, что ученики поставили ее на первое место (45,5% голосов).

Слишком много митингов

Пожалуй, проблема с митингами в сфере IT-разработки усугубилась во времена пандемии. Митингов и так было много. Но из-за онлайн-формата стало еще сложнее вникать в суть разговоров. 38,5% работающих разработчиков отметили, что митинги усложняют их работу. В то же время, ученики отдали за них 18,2% голосов, вероятно потому, что не столкнулись еще с этой проблемой в реальности. “Много времени уходит на пустое общение, а дедлайны никто не отменял”, — говорит Петр.

Сидячий образ жизни

Постоянное сидение за компьютером попало на пятое место среди сложностей в работе программистов (34,6% голосов работающих девелоперов). Ученики и ищущие работу отправили эту сложность на четвертое место с 36,4% голосов. Программисты отмечали, что из-за сидячего образа жизни у них есть проблемы со здоровьем: шейный остеохондроз, “больная спина”, лишний вес.

Общение с другими людьми и поиск багов

Необходимость коммуницировать с другими людьми и искать ошибки набрали одинаковое количество голосов — по 23,1% среди работающих программистов и заняли пятое место в рейтинге сложностей. Интересно, что среди учащихся за проблему с общением не проголосовал никто. Это, скорее всего, связано с тем, что новички еще не успели поработать в айтишных командах. В то же время за поиск багов проголосовали 36,4% учеников и ищущих работу.

Офис или удаленка: что сложнее?

Хотя вначале карантина многие радовались удаленке, согласно нашему опросу недовольных этим форматом работы оказалось довольно много. Опрошенные отмечают, что им сложно сконцентрироваться в домашней обстановке, границы между работой и отдыхом размываются, трудно соблюдать work-life balance. Есть и недовольные офисом: их в основном напрягает то, что надо тратить несколько часов, чтобы добраться на работу и домой. “Недостаток офиса — время на дорогу. Недостаток удаленки — много соблазнов, которые могут отвлечь и то, что дом плавно превращается в офис”, — говорит Игорь. “В офисе большой объем лишнего общения”, — отмечает Денис. “Офис хуже, потому что я интроверт. Мне проще общаться с людьми виртуально”, — добавляет Александр. “Однозначно [труднее] удаленка. Переусложненные коммуникации, отсутствие контакта с командой. Средства удаленной связи не позволяют так же продуктивно решать поставленные задачи, как я это делаю в офисе”, — говорит Денис. “Работа в офисе сложнее в случае, если офис находится далеко, потому что долго добираться. Не хочется терять время. Но если офис под носом, то однозначно выберу офис. Там рабочая обстановка”, — говорит Владислав.

Бонусы работы программистом: высокая зарплата, творчество и карьерный рост

Для баланса мы спросили участников опроса о преимуществах работы программистом. Чаще всего разработчики отмечали высокую зарплату, хорошие условия труда, интерес к работе, перспективы карьерного роста и возможность релокейта в другие страны. “Постоянные логические задачки, комфортные условия и хорошие зарплаты”, — говорит Игорь. “Высокая зарплата в обмен на возможность решать интересные задачи. Очень серьезные возможности для роста”, — говорит Денис. “Творческая, спокойная, размеренная, а главное — интересная работа”, — Роман. “Я ощущаю радость от создания чего-либо нового или починки старого. Программирование — это вечный пазл с тысячей решений, дофаминовый наркоман во мне доволен. На текущий момент это, наверное, самое простое из созидательных занятий после жарки яичницы”, — Денис. “Интересные задачи, хорошие условия труда (заработная плата, культура и рабочая атмосфера в IT компаниях), возможности для постоянного развития и обучения”, — Алексей.

“Можно работать 24 часа в сутки, а можно работать головой. Профессия программист как раз об этом. Ты сам (в зависимости от поставленной задачи) определяешь, что тебе нужно делать, когда и в каком объеме. Все, что нужно — это компьютер, голова и эта самая задача”, — Артур. А как по-вашему, что самое сложное в работе программиста? А что самое приятное? Ждем вашего мнения в комментариях ;)

Программирование легкодоступно

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

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

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

Некоторые аспекты программирования просты

Да, в этом можно не сомневаться: отдельные аспекты просты. Существуют вещи, которые вы можете сделать, в конечном итоге получив, например, скелет приложения для блога. Любой (под опытным руководством) может сделать профессионально выглядящую веб-страницу за первые часы изучения HTML. Можно легко задать вопрос и найти решение на StackOverflow, можно запросто скопипастить решение на свои веб-страницы.

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

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

Большинство аспектов программирования сложно

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

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

Самозванство и мошенническое позитивное мышление

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

На самом деле, зависимость людей от Stack Overflow — это, вероятно, самое пугающее, что произошло с сообществом программистов за последние 10 лет. Stack Overflow — это мощный костыль, мешающий вам двигаться самостоятельно, потому что слишком легко искать ответы на нём. А когда люди перестают мыслить самостоятельно, то начинают писать неразумные вещи.

Если вы, как новичок, смотрите, что делают опытные разработчики, то это выглядит простым. Кажется, то, что делают они, может сделать каждый. Это выглядит совершенно посредственно. Существует миф о суперпрограммистах, делающих всё по-своему. Голливуд представляет их как людей, вводящих код со скоростью света, потому что единственный способ продемонстрировать высокий навык персонажа в своём деле — показать, что он справляется с работой быстрее, чем кто-либо другой (Голливуд показал бы человека, лучше всего отсчитывающего десять секунд, как того, кто справляется за пять). Смысл в том, что это выглядит просто, но на самом деле это не так. Потому что опыту новичка не хватает кругозора, сосредоточенности на действительно важном. Новичку научиться считать до десяти мешает только незнание синтаксиса цикла, для опытного разработчика синтаксис — это то, что замедляет его реализацию выполнения операций с коллекцией отфильтрованных данных.

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

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

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

Но не говорите ему, что программирование — это просто. Это не так.

На правах рекламы

Заказать у нас сервер очень просто! Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!

Сложность программного обеспечения

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

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

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

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

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

Типичная проблема офисного планктона — последствия работы в сидячем положении перед монитором. Через 3−4 года появляются боли в спине, суставах рук, сухость в глазах, потеря зрения и даже головные боли. Через 10−15 лет они приобретают хронический характер.

Решение. Простая профилактика:

каждые 30 минут отвлекайтесь от монитора и смотрите по сторонам (не на экран смартфона). 15−30 секунд достаточно;
каждые 2 часа устраивайте прогулку по офису или дому. 2−3 минуты проведите на ногах;
каждое утро — зарядка. Любите поспать? Тогда идите в зал после работы: 3−4 тренировки в неделю, одна из которых игровая. Пробежки по вечерам — еще один рецепт борьбы с проблемами мышц и суставов;
следите за питанием и выпивайте 1 стакан воды каждые 2−3 часа.

Нехватка времени

Иногда строгий тайм-менеджмент действует во вред программисту. Вот несколько причин потенциального стресса:

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

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

Полезный совет: расставьте приоритеты и отрастите толстую кожу. Руководитель просит ускорить написание кода? Спокойно и аргументировано объясните ему, что оставить вас в покое — единственный способ сделать всё быстро и качественно.

Погоня за технологиями

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

Решение. 3 простых способа развиваться без проблем:

Исправление кода

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

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

Решение. Если в ошибках виноваты не только вы — недвусмысленно донесите это до руководителя. Главное — не переборщить. Очень хорошо, что вы неравнодушны к своему коду, но исправления — естественная часть процесса разработки. Кто бы ни допустил ошибку, код все равно придется исправлять вам, так что тратить нервы ни к чему.

Чтение чужого кода

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

Решение: всё приходит с опытом. И крепкими нервами.

Работа за идею

В середине июля СМИ взорвала новость: только 11% работников получает денежные компенсации за свои переработки. Программисты — не исключение. Работодатели пользуются увлеченностью своих подчиненных, предлагая вместо фиксированной ставки сверхурочных — разовые премии по итогам проекта (который может затянуться на месяцы). Некоторые идут дальше, предлагая переработать за идею и перспективу.

Решение. Пара часов в месяц — не страшно, но вы не должны поощрять систематические нарушения ТК. Не ведитесь на красивые слова, цените себя и личное время.

Коммуникации

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

руководители разных уровней;
коллеги с разной степенью подготовки;
персонал из смежных областей.

Чтобы спокойно работать, вам необходимо найти общий язык со всеми этими людьми.

Решение. Оказавшись на новом месте, болтайте, не закрывая рот. Даже если вы интроверт, пару недель пересиливайте себя. Задавайте личные вопросы, рабочие, не стесняйтесь беспокоить по мелочам. Так вы установите контакт с окружением. Единственное ограничение — не стремитесь казаться глупее, чем вы есть, чтобы завязать разговор. Это лишь испортит к отношение.

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

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

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

Здоровье

Решение. Простая профилактика:

каждые 30 минут отвлекайтесь от монитора и смотрите по сторонам (не на экран смартфона). 15−30 секунд достаточно;
каждые 2 часа устраивайте прогулку по офису или дому. 2−3 минуты проведите на ногах;
каждое утро — зарядка. Любите поспать? Тогда идите в зал после работы: 3−4 тренировки в неделю, одна из которых игровая. Пробежки по вечерам — еще один рецепт борьбы с проблемами мышц и суставов;
следите за питанием и выпивайте 1 стакан воды каждые 2−3 часа.

Нехватка времени

Иногда строгий тайм-менеджмент действует во вред программисту. Вот несколько причин потенциального стресса:

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

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

Погоня за технологиями

Решение. 3 простых способа развиваться без проблем:

Исправление кода

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

Чтение чужого кода

Решение: всё приходит с опытом. И крепкими нервами.

Работа за идею

Коммуникации

руководители разных уровней;
коллеги с разной степенью подготовки;
персонал из смежных областей.

Чтобы спокойно работать, вам необходимо найти общий язык со всеми этими людьми.

Эта нелепая история длится и длится до тех пор, пока не назревает революция. От текущей версии проекта отказываются и все начинается с нуля. Увы, никто не может дать гарантию, что второй заход не пойдет по сценарию первого. Знакомо?

Проблема сотого кирпича

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

Что же подразумевает такая зловещая формулировка? Фактически, сложность выражается так: количество ресурсов, связей и компонентов, которые требуются для решения какой-либо задачи, растет нелинейно по мере роста размеров проекта.

Давайте рассмотрим это утверждение на примере: сравним работу каменщика и программиста.

Если каменщик строит стену, то мы можем ожидать, что первый кирпич он, допустим, положит за условные 2 минуты, второй еще за 2 минуты, а сотый — уже быстрее, потому что у него выработался навык. К тысячному он, возможно, станет кирпичным виртуозом, и будет делать все просто молниеносно, с закрытыми глазами и прямо во сне.

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

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

«Дополнительная сложность обусловливается изменением требований к программной системе уже в процессе разработки, в основном из-за того, что само существование проекта программной системы часто изменяет проблему"

Сегодня Agile получается как раз об этом: мы потратили ваши деньги, но не просто так — а с пользой, заранее мы ничего не планировали, но вот, какая удача — что-то получилось.

В программировании есть несколько проявлений проблемы сложности.

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

Читайте также: