Подождите.
У всех был плохой год.
Все хорошо провели время.
У всех были поллюции.
Все видели солнечный свет.
Леннон и Маккартни, у меня такое чувство, пусть будет так, 1970 год
Мы люди, а это значит, что все мы делаем ошибки. Вот что такое жизнь. Мы учимся на этих ошибках, и это делает нас сильнее. Вот как мы выживаем. За 17 лет работы в качестве разработчика я испытал немало провалов. Но есть некоторые, относящиеся к профессии инженера.
Позвольте мне упомянуть три избранных случая. Я буду использовать их в качестве примера и попытаюсь объяснить, почему разработчик иногда может застревать. Зацикливание часто означает, что тщательно продуманные сметы руководителей проектов просто неуместны. Иногда могут быть нарушены даже сроки выполнения проекта. В этом эссе мы попытаемся дать ответы на вопросы о том, как подготовиться к таким случаям. Непрограммистам также может быть интересно заглянуть под капот и дать им некоторое представление о специфике работы инженера.
Обучение
В 2019 году мы работаем по принципу многослойности. Это постоянно растущая тенденция. Когда я собираюсь начать новый проект мобильного приложения, он будет содержать как минимум десять сторонних библиотек. Они нужны мне, чтобы выжить в пустыне корпоративного мира. Удивительно, но все библиотеки, которые я использую, имеют открытый исходный код и поддерживаются онлайн-сообществом. Мы все их знаем, поэтому нам не нужно тратить время на примеры, но давайте упомянем Alamofire хотя бы ради одного.
Некоторые из этих библиотек довольно тяжелые. Как реактивное программирование. Когда я работал над проектом Прага 5, я решил попробовать что-то новое, потому что у меня было удобство иметь резервную копию (спасибо моему коллеге Диме Николаенко). Это было действительно хорошей практикой для нас в iLabs. Мы всегда стараемся работать в командах ровно из двух разработчиков (так же, как немецкие летчики-истребители начали действовать во время Гражданской войны в Испании, но это уже другая история), каким бы маленьким ни был проект. Всегда хорошо иметь резервную копию.
Я решил попробовать реактивное программирование и постараюсь сделать его максимально кратким: я терпел неудачу. После недели чтения статей, понимания примитивных аспектов, таких как сигнал, событие, производитель и т. Д., Я был поражен. Я слышал все эти термины за свою карьеру, и все они казались мне знакомыми. НО - как собрать все эти чертовы штуки вместе? Это потребовало совершенно нового мышления. И я не мог так быстро измениться. Как программист старой школы, я склонен разбирать вещи и заглядывать под капот. Но с этими новыми концепциями это обычно неправильный подход. Иногда все это вызывает у вас печаль и отчаяние.
Итак, через некоторое время я сдался и принял тот факт, что объединение всех этих простых вещей, таких как сигналы и производителей сигналов, просто работает, и начал их использовать. И вдруг жизнь снова стала прекрасной. Мне удалось заменить около 100 строк тяжелой логики синхронизации всего одной строкой реактивного кода. Без шуток. Это решение:
articleService .articles(modifiedSince: date) .zip(with: articleService.types())
Это позволяет мне читать последовательно с разных конечных точек без какой-либо логики синхронизации. Результаты просто склеиваются. Всем управляет ReactiveSwift.
Вы могли бы спросить меня: окей, а для чего тогда была хороша эта неделя страданий? Во-первых, это сделало меня сильнее. Во-вторых: даже если я не совсем понял суть дела, я кое-что узнал. У меня пока нет специального использования для него, но мой опыт подсказывает мне, что я снова буду использовать его когда-нибудь, где-нибудь (возвращаясь к тому факту о немецких пилотах-истребителях, летающих парами). Новые идеи - это всегда хорошо.
Так что это один из способов застрять: изучать что-то новое. Я предполагаю, что извлеченный урок здесь следующий:
Если вы собираетесь использовать какую-то новую концепцию в своем проекте, занимайте оборонительную позицию и выделите время, чтобы отразить скорость вашего обучения. Это порадует руководителя проекта. На самом деле, это сделает всех счастливее.
Многоуровневые ошибки
Но есть и второй вид застревания. Ошибки. Работа с различными типами ошибок отнимает у программиста большую часть жизни. Большинство из них - ваша вина, но есть некоторые особые случаи. Основная причина этих особых проблем, которые время от времени возникают у вас на тарелке, - это многослойный салат, который вы употребляете каждый день. И это может пойти очень плохо, если несколько пересечений на нескольких слоях объединятся, чтобы вызвать странное, неожиданное поведение.
Мой худший кошмар длился две недели. Это было около десяти лет назад, когда я работал в бывшей компании GMC Software Technology (ныне Quadient). Моей задачей было интегрировать WebKit в наше огромное кроссплатформенное решение. Мы использовали WebKit для преобразования HTML в PDF, а затем импортировали в наше программное обеспечение. Я отвечал за OS X.
Это был кошмар. Открытый исходный код WebKit написан на Qt, отраслевом стандарте кроссплатформенного графического интерфейса пользователя (например, программное обеспечение Parallels написано на Qt). Итак, WebKit и Qt сделали два тяжелых слоя, а затем появился третий: наше программное обеспечение, которое также было кроссплатформенной структурой C ++ с собственным пользовательским интерфейсом, обработкой событий и циклом выполнения. Для наших целей назовем его Chimenix.
Это введение. А теперь сообщенная ошибка:
Иногда, когда я помещаю HTML-файл в макет, объект вставляется, но его содержимое остается пустым.
После нескольких дней отладки я понял, что проблема должна быть связана с конфликтующими циклами выполнения и обработкой событий в Chimenix и Qt. После еще одной недели размышлений и попыток мне удалось решить проблему ровно с помощью одной строчки кода. К сожалению, я не могу найти эту строку, но главное было убедиться, что цикл выполнения Qt запущен и обрабатывает события, прежде чем мы попытаемся запустить преобразование HTML в PDF. Звучит очень просто, правда? Но путь к пониманию был полон тупиков и дискомфорта.
Не думайте, что я не просил о помощи. Я обсуждал это с коллегами, гуглил как сумасшедший, искал Stack Overflow, спрашивал на форумах. Но иногда вам выпадает печальная честь оказаться первым, кто столкнется с очень специфической проблемой. Это происходит все реже и реже с увеличением количества и качества ответов, доступных в настоящее время в Интернете. Но тогда случилось гораздо больше.
Я бы сказал, что решение такого рода проблем - самая сложная часть работы разработчика. Но это само по себе очень полезно. Лучшее ощущение - это тот момент, когда вы подтверждаете свое предположение. Вы далеки от полного решения, но, наконец, вы на 100% уверены в том, что происходит. Озноб.
Урок, извлеченный здесь, таков:
Хорошо подумайте, прежде чем добавлять в проект новый слой. Слои могли пересекаться. Вы можете быть первым, кто их соединит, и вы окажетесь на неизведанной территории. Если бы мы могли нарисовать карту, эти области пересечения были бы помечены как Здесь есть ошибки.
Ошибки влево / вправо
Еще один печально известный источник бесконечных проблем, с которыми мне приходилось иметь дело в течение моей карьеры, - это байты. Это то, что сегодня сложно представить разработчикам мобильных устройств. Но когда вы храните необработанные данные, вы должны убедиться, что можете правильно их прочитать на платформах, которые по-разному обрабатывают хранение двоичных данных. Проще говоря: каждый производитель процессора должен был решить: буду ли я читать данные справа или слева? IBM выбрала левый (также известный как прямой порядок байтов), а Intel - правый (он же прямой порядок байтов). Итак, у нас есть две основные платформы на рынке, обе из которых должны поддерживаться (до 2006 года все оборудование Apple использовало процессоры с прямым порядком байтов). Первое исправление ошибок, связанных с порядком байтов, требует больших усилий. Но устранение проблемы обычно означает, что в конце концов вам нужно изменить несколько букв в коде. Вы очень быстро научитесь эффективно обнаруживать и исправлять эти ошибки. Но мой опыт подсказывает мне, что расходы, связанные с порядком байтов, могут финансировать небольшую страну в течение нескольких лет. В настоящее время для мобильных разработчиков это устаревшая проблема. Вы, вероятно, никогда больше не столкнетесь с этой проблемой, но я могу гарантировать вам, что компьютерная индустрия будет принимать новые решения влево / вправо в будущем.
Заключение
Это небольшой пример проблем, с которыми мы сталкиваемся как разработчики. Много раз в жизни я слышал это от руководителя проекта:
Я видел, что вы потеряли x часов, исправляя одну ошибку. Почему так долго? Это плохо для бизнеса. Если вы боретесь более часа, обратитесь за помощью!
Есть люди, которые могут принять это на свой счет и увидеть в этом аргумент в пользу некомпетентности. Но, честно говоря, каждый хороший руководитель проекта должен задавать этот вопрос. Одним из побочных эффектов этого эссе могло быть то, что люди, не разбирающиеся в технологиях, могли получить представление о жизни разработчика. Я пытаюсь объяснить, что иногда мы, инженеры, сталкиваемся с проблемами, с которыми еще никто не сталкивался. Не случайно наша область исследований называется компьютерными науками. Это все еще отчасти наука, а это значит, что иногда мы оказываемся на неизведанной территории.
Итак, честно: я просил о помощи. Я погуглил. Я был переполнен стеком. Я копал и наконец починил. Но мне потребовалось время, и это случилось. В конце концов, я всего лишь человек.
Это мое объяснение того, что иногда я застреваю.
Что твое?
- Валда, разработчик iOS
Примечание
Выражаем благодарность Матею Витасеку, Назарию Овчарчину, Гонзе Кржечеку, Давиду Кубачу, Роберту Крейче, Зузке Кубиновой, Любошу Карасеку, Борису Леточа, Александру Лысенкову и Диме Николаенко за чтение проекта этого эссе.
Особая благодарность Иэну Томсону за грамматические исправления.
