Для тех, кто тратит много времени на написание кода пользовательского интерфейса, оптимизация представления сразу вызывает в воображении образы окон, хитрых маленьких гаджетов пользовательского интерфейса, проблем с юзабилити и длинной цепочки дизайнерских встреч с возбужденными программистами и программистами с чрезмерным содержанием кофеина. Тот факт, что в этих небольших встречах вполне могут участвовать воздушные ластики для белой доски, путешествующие с большой скоростью и целеустремленностью, является еще одним свидетельством того, насколько мы ценим то, как наше программное обеспечение представляется нашим клиентам.
Действительно, портал, через который пользователь заглядывает в глубины нашего кода, часто, кажется, определяет само программное обеспечение, по крайней мере, в глазах смотрящего. Следовательно, мы признаем, что проблемы пользовательского интерфейса — это не просто вопрос красивости лица, а фактическое определение границ, в которых будут работать наши пользователи. Поместите неуклюжее представление о хорошем программном обеспечении, и вы получите неуклюжий программный продукт.
Тем не менее, те из вас, кто уже запустил редактор вашего программиста и заказал пиццу с пепперони в ожидании очередного захватывающего сеанса кодирования, вероятно, немного опережают игру. Мы здесь не для того, чтобы говорить о битах и байтах кодирования. Мы здесь, чтобы поговорить о чем-то гораздо более важном — о вашем будущем в качестве профессионального разработчика программного обеспечения. Таким образом, вам не понадобится редактор этого программиста на данный момент. Пицца, вероятно, все еще хорошая идея. Некоторые традиции никогда не должны быть изменены.
Установка приоритетов
Если мы не собираемся говорить о функциях и объектах и о ворчливых маленьких строках непонятного текста, то для чего мы здесь? Что может быть важнее для разработчика, чем детали написания кода? Ответ очевиден и неуловим на одном дыхании. Для программистов во всем мире важнее всего не написание кода, а предоставление качественного программного обеспечения.
Вы только что остановились, покачали головой и снова прочитали последнее предложение? Ты не одинок. Практически повсеместно хорошие программисты рефлексивно отождествляют написание кода с поставкой программного обеспечения, как если бы они были одним и тем же. Они не. Фактически, именно эта точка зрения в значительной степени ответственна за катастрофы, связанные с выбросами во всем мире.
Если вы не знаете, что такое релизная катастрофа, вы вели очарованную жизнь. Возьмите два пончика из мелких денег и вернитесь к тому, что вы делали. Остальные из нас слишком хорошо знакомы с деталями испорченных хороших выпусков, включая произвольные сроки, бесконечные сверхурочные, высокие уровни стресса, кратковременный отпуск и мониторы, вылетающие из окон пятого этажа, — все это для продукта, который поставляется задолго до того, как он будет готов из-за давления на рынке. Когда ваше программное обеспечение выходит на улицу с большим количеством ошибок, чем дешевый мотель и менее стабильно, чем программист, который не спал неделю, действительно ли технические детали кодирования являются виновной стороной? Скорее всего, не. Уверяю вас, некоторые из худших выпусков программного обеспечения, которые я видел, были продуктом абсолютно блестящих технических специалистов. Позвольте мне представить эту мысль еще раз, для акцента. Выпуски программного обеспечения низкого качества почти никогда не происходят из-за отсутствия технических навыков.
Итак, если проект, над которым вы работаете, приветствуется сообществом пользователей с этими двумя бессмертными словами, которых везде боятся программисты («это отстой!»), То кто виноват, если не код? Программисты, конечно. Эй, ты же не думал, что так легко сорвешься с крючка?
Обычные подозреваемые
Я начинаю видеть застекленные глаза в глубине комнаты. Если плохие релизы не вызваны плохими техническими навыками, то как это может быть ошибкой программистов? Ну, на самом деле, мы собираемся здесь использовать небольшую логику кренделя. Не прямые, размером со спички, которые также хороши для размешивания вашего напитка, но те извилистые, извилистые крендели, которые делают много оборотов, но всегда заканчивают тем же, с чего начинали. Мы начнем с того, что соберем всех обычных подозреваемых, но поверьте мне, в конце концов, все вернется домой, чтобы отдохнуть прямо на наших маленьких ноутбуках, заполненных маленькими кругами. Крендели такие.
Фактически, многие из ветеранов здесь уже составили список сторон, ответственных за провал совершенно хорошего проекта, и даже внесли предложения относительно того, против какой именно стены они должны быть установлены, когда придет революция. Некоторые из более опытных из вас, возможно, даже предположили, что адвокаты должны ждать своей очереди или использовать другую стену.
Кто эти злодеи, эти люди, достаточно сильные, чтобы отвергнуть возможности даже самого блестящего программиста? Маркетинг и менеджмент, безусловно, приходят на ум первыми, их часто называют Ласками и Костюмами, когда программисты тусуются на машине для приготовления капучино поздно ночью. Когда команда разработчиков программного обеспечения ничего не подозревает, результаты неизбежно включают неопределенные и меняющиеся требования, произвольные сроки, объявленные без представления о технических реалиях, проскальзывание области действия, управляемое кризисом управление, полное отсутствие профессионального отдела тестирования и, в конце концов, программного обеспечения. это было выпущено задолго до того, как должно было быть.
Это не моя работа
Что ты говоришь? Я просто четко доказал, что это не твоя вина? Хорошая попытка. И передай мне крендель, ладно? Проекты проваливаются по невероятно простой причине. Чрезвычайно умные и талантливые программисты снова и снова делают наивное предположение, что если речь не идет о коде, то это не их работа. В современном воздушном бою пилот реактивного истребителя, который оказывается достаточно близко к своему противнику, чтобы бороться с ним из пулеметов, уже упустил критические возможности для решения проблемы с безопасного расстояния с помощью ракет большой дальности. И так с программистами. Если вы окажетесь в Овертайм-Сити с гарантированным выходом из строя прямо за углом, вы облажались задолго до того, не сумев контролировать свою ситуацию, пока она не контролировала вас. Уч. Могу я это сказать? Ну, может, мне стоило хотя бы сначала предложить тебе крендель.
Ваш взгляд на процесс разработки программного обеспечения диктует, что вы делаете, а что не делаете в течение рабочей недели. Если вы считаете, что все, что находится за пределами кодирования, «не моя работа», то вы и ваш проект, несомненно, станете жертвой сильных и нелогичных сил, которые охватывают корпоративный мир. Однако опытный программист может свести к минимуму глупости маркетинга и управления. Для каждой вещи с костью, которую эти ракетостроители могут бросить в нас, есть счетчик. Управляйте проблемами на ранней стадии игры, и ваша катастрофа для релиза вместо этого становится релизной стороной. Они, вероятно, даже весной для пиццы.
Дорога впереди
Вам не нужно иметь MBA или быть торговцем, чтобы эффективно справляться с этими проблемами. Вам просто нужно расширить представление о процессе разработки программного обеспечения, включив в него все, что может повлиять на ваш выпуск, и сделать все необходимое для защиты кода, который вы так усердно создавали. Конечно, это не всегда так сексуально, как написание яркого пользовательского интерфейса на классном языке дня, но когда это 4 часа утра, вы не спали в течение 3 дней, и плохие управленческие решения почти гарантируют, что завтра ваш продукт будет выпущен в менее совершенной форме, ничего сексуального.
Пришло время программистам восстановить контроль над процессом разработки программного обеспечения. Изучение хитрых и не очень хитрых уловок, чтобы справиться со всеми проблемами некодирования, которые угрожают нашим программам, нашему свободному времени и нашему здравомыслию — вот что мы будем делать в предстоящие месяцы. Шаг за шагом, вопрос за вопросом, мы рассмотрим способы увидеть катастрофу до ее наступления и предпринять упреждающие шаги. Конечным результатом будет больше времени на то, что вы действительно любите — написание классного кода, который станет следующим приложением Killer. И разве это не то, на что вы подписались, когда выбрали эту профессию?