День 1182. #Карьера Как Разработчики Проваливаются «Разработчики терпят неудачу по двум причинам: либо делают не так, либо делают не то». Поразительно, что большинство разработчиков уделяют больше внимания первой части проблемы и забывают про вторую. Младшие программисты больше озабочены тем, как создать продукт. Есть техническая задача, и многим из нас нравится решать её, как головоломку. Но по мере накопления опыта вы обнаружите, что часто то, что вы создали, на самом деле не то, что хотел заказчик. А такой дефект труднее обнаружить, и часто дороже устранить. Сделать не так Определение намеренно расплывчато. Под неправильным в данном случае понимается любой технический дефект, в результате которого система не удовлетворяет потребностям пользователей. Критическая ошибка, архитектура не масштабируется, есть серьезные проблемы с производительностью, утечки памяти, может быть даже брешь в системе безопасности. Это все те вещи, о которых мы склонны думать, когда думаем о недостатках, дефектах или ошибках в приложениях. Зачастую эти ошибки незначительны. Они могут быть обнаружены во время тестирования ещё до того, как их увидят конечные пользователи. В других случаях они могут быть довольно дорогими, и их нелегко исправить. Некоторые ошибки неизбежны, поэтому мы разрабатываем программные процессы таким образом, чтобы их можно было ожидать, обнаруживать и исправлять. Наша практика очень часто направлена ​​на максимально быстрое обнаружение дефектов, поскольку мы знаем, что исправление дефекта сразу после его появления обходится на порядки дешевле, чем после его отправки в производственную среду. Предотвращение попадания дефектов в продукт — очень полезная деятельность для разработчиков ПО. Ещё один способ создавать что-то неправильно связан с архитектурой или качеством. Некоторые решения, принятые на ранней стадии в отношении системной архитектуры, могут оказаться неправильными позже, когда они не позволят нам реагировать на запросы клиентов. Технический долг в виде костылей может иметь аналогичные последствия в перспективе. Хотя это и более коварно, чем выпуск видимых пользователями дефектов, это тоже примеры неправильного построения. Сделать не то Зачем мы делаем не то? Оказывается, общение – это трудно. Клиенты и пользователи не всегда чётко сообщают, чего они хотят. Мы не всегда хорошо слушаем или забываем. Или делаем то, что, как мы думаем, они хотят, или то, что хотели бы мы, вместо того, что требуется. Иногда это даже работает, но в большинстве случаев это пример того, как мы забываем, что мы не пользователи. Часто пользователь хочет решить проблему, но, когда видит часть решения, это порождает новые идеи о том, как лучше её решить. Дело не в том, что они не знали, чего хотят, а в том, что итеративный процесс разработки решения выявил лучший подход. Худшее, что мы можем сделать как разработчики — это продавить посредственное решение, потому что мы не открыты для отличного, которое мы же нашли в процессе разработки. Поэтому важно часто обмениваться информацией, подтверждать наши предположения и позволять клиентам и заинтересованным сторонам реагировать на нашу работу по мере её продвижения. Будьте готовы изменить направление и быть открытыми для новых идей, чтобы максимизировать ценность предлагаемого вами решения. Способность построить что-то правильно — это, как правило, вопрос технической компетентности. Как только вы достигнете определенного порога мастерства, вы будете уверены в своей способности сделать это. Создание правильной вещи требует дополнительных навыков и может зависеть от этой технической компетенции. Помимо правильного создания ПО, теперь вы должны иметь возможность быстро и эффективно общаться и изменять направление вашего решения по мере необходимости на основе актуальной информации. Только тогда вы можете быть уверены, что создаёте правильные вещи правильно. Источник: weeklydevtips.com/episode…ipx3u5cw Автор оригинала: Steve "Ardalis" Smith