9 главных проблем в работе программиста

2013-10-29

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

Итак, приступим.

Поиск решения

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

Проблема: Найти такое решение, которое и удовлетворит клиента, и будет ему понятно, и которое реально воплотить в установленные сроки.

«Самое зубодробительное это думать о том, как начать с точки А и прийти к точке Z».

«Если решение окажется слишком тяжеловесным, оно загнётся под собственной массой, если слишком скудным – оно попросту бесполезно».

«Трудно представить, как что-то будет работать, пока не начнёшь работу над этим».

 

Написание тестов  

Задача: написать модульные тесты (программируемые тесты небольших кусков кода, проверяющие их правильное функционирование). Эти тесты помогают выявить баги на ранних стадиях разработки, а в будущем упрощают регрессионное тестирование. В некоторых методологиях разработки модульные тесты пишутся до разработки самого кода.

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

«Писать тесты несложно, но так муторно…»

 

Написание документации

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

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

«Ненавижу писать документацию, которую всё равно никогда никто не читает, но это нужно делать, потому что так надо».

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

 

Работа над деталями, которые вам не нравятся

Задача: реализовывать опции, которые вам по каким-то причинам не по душе или попросту не имеют смысла, но на них настаивает заказчик.

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

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

 

Работа с чужим кодом

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

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

«Что меня бесит больше всего  работать с кодом, который лучше бы не был написан совсем…»

«Это девятый круг ада Данте  разбирать тысячи строк кода без единого комментария».

 

Общение с другими людьми

Задача: собирать требования от клиентов, предоставлять статусные отчёты менеджерам, работать с тестировщиками и другими инженерами.

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

«Да процессор проще убедить в чём-то, чем других людей».

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

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

 

Определение крайних сроков

Задача: определить срок сдачи проекта.

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

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

«Оценка сроков и постановка дедлайна  очень трудная задача, потому что эту приблизительную оценку люди воспринимают как обещание».

 

Объяснение своей деятельности

Задача: донести до неразработчиков (родственникам, друзьям, коллегам), в чём заключается ваша работа.

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

«Почему-то часто приходится объяснять своим друзьям, что я действительно не знаю, что у них с компьютером».

 

Давать названия

Задача: дать названия различным переменным, процедурам, функциям, классам, объектам, элементам баз данных и т.д.

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

«В программировании вообще две беды: актуальность кэша и как назвать переменную».

Перевод: Люся Ширшова. По материалам ITworld.   


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

15 признаков отличного IT-лидера

Программирование: быстро мыслить или быстро печатать?

Какие языки программирования сводят разработчиков с ума?