Жемчужины мудрости за 4 десятилетия работы инженера по разработке программного обеспечения

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

Вступление

Я профессионально работал разработчиком программного обеспечения в течение четырех десятилетий карьеры, и я продолжаю активно разрабатывать программное обеспечение без каких-либо планов по снижению темпов роста. Оглядываясь назад на десятилетия моей карьеры, включая 80-е, 90-е, 2000-е и 2010-е, я могу поделиться некоторыми практиками и принципами, которые принесли мне пользу и которые, я уверен, вам пригодятся. Эта статья будет полезна не только тем, кто только начинает карьеру инженера-разработчика программного обеспечения, но и тем, кто имеет многолетний опыт работы. Итак, вот несколько жемчужин мудрости!

ВЫ ЧТО-ТО НЕ ПОНИМАЕТЕ, пока не напишете об этом

Пока я работал в Microsoft, я посетил выступление блестящего архитектора программного обеспечения, который там работал. Он говорил о структуре программирования, которую недавно построил. После его выступления я подошел и спросил его, как он стал таким опытным архитектором программного обеспечения. Я сказал ему, что был глубоко впечатлен его пониманием многих технических областей и элегантной архитектурой, которую он создал. Вот что он сказал: «Это просто. Яростно пишите. Вы действительно ничего не понимаете, пока не напишете об этом ». Он сказал, что пишет много статей для публикаций и что-то пишет только для себя, чего больше никто не видит, и что это помогает ему организовать и обобщить то, что он изучает.

С того дня я серьезно воспринял его совет. Я начал писать статьи для нескольких технических публикаций и даже написал две книги по разработке JavaScript Fullstack. И чтобы убедиться, что у меня еще больше практики в написании, я работал техническим писателем на срок чуть больше года. Я определенно обнаружил, что знания будут оставаться в моем мозгу все глубже и дольше, и что технология внезапно стала для меня более понятной.

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

Когда я покинул Microsoft в 2015 году, я был очень хорошо знаком с их предпочтительным языком и технологическим стеком (C # .Net и т. Д.), Но я действительно хотел заново изобрести себя и оставить все это позади и посвятить остаток своей карьеры все на JavaScript. Я уже изучал JavaScript около двух лет назад, но все еще чувствовал себя новичком. Я решил взяться за простой проект, чтобы отточить свои навыки и написать книгу, чтобы объяснить, что такое современное приложение MERN на JavaScript. Написание книги было отличным способом помочь мне учиться, а также знать, что это поможет другим на этом пути. Эта книга была только началом этого пути. С момента публикации этой книги я узнал гораздо больше.

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

ЗАМЕДЛЕННО ДЛЯ Ускорения

Другой способ сказать это - «потратьте время, чтобы сэкономить время». Держитесь подальше от технического долга! В конечном итоге это доставит вам неприятности. Требуется время, чтобы продолжать расплачиваться, поэтому лучше вообще не платить. Я понимаю, что некоторые технические долги, возможно, нуждаются в замене устаревшей устаревшей структуры. Вероятно, это был отличный выбор, который был сделан в прошлом, но теперь по той или иной причине он достиг своего предела. Или, возможно, вы торопились что-то вытолкнуть, и это заставило вас срезать углы, которые теперь вызывают у вас горе.

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

«Хождение по медленной и устойчивой прямой каждый раз лучше, чем быстрый бег в случайных направлениях». - меня

Я знаю, что подобные утверждения могут оскорбить некоторых людей, которые действительно считают, что скорость написания кода важнее всего остального. Так что позвольте мне убедиться, что я четко понимаю то, что защищаю. Я большой поклонник Канбана и работаю просто над тем, чтобы все было сделано, и делаю их правильно. Разбейте работу на должным образом сформулированные и управляемые результаты, каждый из которых займет столько времени, сколько потребуется. Мы будем делать все правильно, и у нас будет больше шансов получить согласованный продукт высочайшего качества сейчас и в будущем - поддерживаемый, тестируемый, расширяемый, безопасный, производительный и т. Д.

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

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

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

«Если вы не знаете, куда идете, любая дорога приведет вас туда». - Чеширский кот в рассказе Льюиса Кэрролла «Алиса в стране чудес».

РАБОТА С ПИКОВОЙ ПРОИЗВОДИТЕЛЬНОСТЬЮ

Знайте, когда вы делаете свою работу лучше всего, а также когда другие в вашей команде делают свою работу лучше всего. Следите за тем, чтобы в это время не беспокоить друг друга. Некоторые люди работают лучше в ранние утренние часы. Другие вечером могут подумать яснее. Знайте свои собственные возможности и ограничения. Не программируйте, когда вы не эффективны, так как вы принесете больше вреда, чем пользы.

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

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

СОЗДАЙТЕ POC, ЕСЛИ СОМНЕВАЕТСЯ

Верный способ увидеть провал программного проекта - это бросить кучу людей на систему без особого направления и заставить их начать писать код (это похоже на то, что было сказано здесь много лет назад). Все мы, возможно, знаем, что водопадный большой фронтальный дизайн работает только в некоторых особых случаях. В большинстве случаев успешным оказывается написание небольших итераций кода. Вы не можете просто сесть и начать писать основную функциональность без какого-либо прототипа. Я написал сложный тестер нагрузки с нуля и не смог бы справиться с этим без начального POC и множества более мелких POC (см. Apizapi.com и эту Medium article).

Не позволяйте другим заставлять вас начать работу, не получив времени, чтобы убедиться, что это реалистично, учитывая временные рамки, и что это даже возможно. С помощью POC вы сможете гораздо точнее оценить, когда вы действительно можете выполнить работу и что он действительно может сделать. Вы также сможете лучше организовать свой код после первой попытки создания прототипа. После этого вы сможете проектировать и проектировать так, чтобы они были чистыми, поддерживаемыми и расширяемыми. Выполнение POC сродни известной цитате Эйба Линкольна.

«Дайте мне шесть часов, чтобы срубить дерево, а первые четыре я потрачу на то, чтобы точить топор». - Абрахам Линкольн

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

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

ЭЛЕГАНТНОСТЬ, ЭЛЕГАНТНОСТЬ, ЭЛЕГАНТНОСТЬ

В розничной торговле кирпичом и минометом или в сфере недвижимости одну проверенную формулу успеха можно резюмировать как «Местоположение, Местоположение, Местоположение». В разработке программного обеспечения одним из ключевых критериев успеха является измерение того, насколько хорошо была спроектирована система. Говоря об архитектуре, вы должны стремиться к «элегантности, элегантности, элегантности».

Всегда визуализируйте проблему, изображая ее в виде схемы, а затем упрощая ее. Мне нравится представлять, как разработчик сидит, потягивая чай и обсуждая на вежливом английском, акцентируя внимание на проблеме. Мы всегда должны искать «Элегантное» решение. Учитесь на своих ошибках и руководствуйтесь здравым смыслом в развитии.

Я часто подозревал, что некоторые разработчики пытаются сделать свой код слишком сложным, и на самом деле делают это намеренно! Я боялся делать обзоры кода для людей с таким отношением. Для них это казалось игрой, или, может быть, они думали, что у них будет гарантированная работа, если никто другой не сможет понять их код. Написание сжатого или непонятного кода не так важно, как написание кода, понятного другим. Нам нужно написать код, который могут взять на себя другие. Я видел, как разработчики писали код, который мог бы легко использовать программное обеспечение с открытым исходным кодом или лицензионное программное обеспечение, что позволило бы им тратить время на важные функции. Как сказал Эйнштейн:

«Все должно быть сделано как можно проще, но не проще» - Альберт Эйнштейн.

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

НАУЧИТЬСЯ ЧИТАТЬ КОД

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

Чтобы вы знали, откуда я и почему я считаю, что это потерянное искусство, я дам вам некоторую предысторию. Мой первый опыт программирования был в 1978 году, когда я учился на курсе колледжа, который охватывал концепции программирования и знакомил с языком Fortran 77. У отдела CS был огромный мэйнфрейм IBM. Прямо рядом с комнатой мэйнфрейма была комната, в которой была пишущая машинка, похожая на механические машины, для печати перфокарт. Первое, что вы должны сделать, это записать свой код на листе бумаги, а затем ввести инструкции по строкам на перфокартах. Затем вы подойдете к стойке в комнате мэйнфрейма и передадите свою стопку карточек дежурному. Были бы скопированы стопки карточек, ожидающие, чтобы их прогнали. Я ходил в класс и время от времени возвращался. Обычно я мог сделать одну пробежку утром, а затем - днем. Когда мои карты будут загружены в считыватель, код будет скомпилирован и выполнен. Я бы получил распечатку с набранными строками, а также увидел бы вывод оператора печати. Затем я очень внимательно читал код и представлял себя компьютером со всей его обработкой, регистрами и т. Д.

Перенесемся в конец 80-х, когда я работал в Tektronix и Mentor Graphics. Теперь у меня была собственная графическая рабочая станция (рабочие станции Apollo и MicroVAX). Какая роскошь - иметь специальный компьютер и терминал с графическим интерфейсом. Я работал над программным обеспечением для проектирования микросхем и схем. Одна из систем, которые я программировал, была крупнейшим приложением на C ++ своего времени и содержала около миллиона строк кода. Но, опять же, мы полагались на распечатки на фальцованной бумаге, чтобы обрисовать наш код. Чтобы сделать сборку и запустить приложение, потребовалось более 30 минут! Следовательно, мы потратили много времени на чтение нашего кода.

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

ПЕРЕЙДИТЕ В СТАБИЛЬНОЕ СОСТОЯНИЕ И ОСТАВАЙТЕСЬ В нем

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

Я думал, что работал в командах, которые серьезно относились к тестированию, пока я не проработал год в Walmarts Labs на веб-сайте walmart.com (написанном на React) и некоторых серверных HTTP-API Node.js для мобильных приложений. Тестового кода должно было быть в два раза больше, чем было производственного кода. Требовалось поддерживать покрытие кода и путь на очень высоком уровне и проводить тестирование со всех мыслимых сторон. Были тесты с реальными сетевыми вызовами, тестирование отдельных фрагментов кода, тестирование точек интеграции, тесты с известными фиктивными данными для проверки ожидаемых результатов и так далее.

Инженеры Walmart известны своей смелостью, чтобы внести серьезные изменения в код накануне Черной пятницы, и полной уверенностью, что все будет работать гладко. Мне довелось побывать там во время одного курортного сезона, и я был поражен тем, что практически с первого дня моего пребывания там отдельному разработчику доверяли не нарушать работу сайта. На своем ноутбуке я мог выполнить развертывание и мониторинг DevOps, а также наблюдать за развертыванием, пока все машины не внесут изменения. Я немного нервничал, когда делал это впервые, зная, что 10 миллионов запросов в день будут выполняться через написанный мной код. Это могло быть сделано только благодаря тому пристальному вниманию, которое уделялось обеспечению устойчивости и устойчивости благодаря превосходному автоматизированному тестированию, обзорам кода, стандартам кодирования и, конечно же, блестящим разработчикам.

Представьте себе все время и деньги, которые можно сэкономить, если платформы будут постоянно поддерживаться стабильными! Другие разработчики не будут бороться с чужими проблемами. Никого не задерживают в любое время. Продажи и маркетинг могут быть уверены в том, что в любой момент создадут сборку и поиграют с продуктом. Демонстрации можно давать с уверенностью. Это, конечно, достигается только в том случае, если все будут дважды проверять все перед каждой регистрацией, а слияние основных ветвей требует запуска полных наборов тестов перед любым производственным развертыванием, включая тесты производительности. Тесты производительности фиксируют базовый уровень, а затем последующие тестовые прогоны гарантируют, что не вернутся назад (см. Apizapi.com). Всегда думайте о последствиях нового кода и о том, повлияет ли он на другие части системы в целом. Тогда вы сможете лучше выспаться и не всегда оглядываться через плечо, задаваясь вопросом, когда вам придется вскочить, чтобы исправить повреждение.

Заключение

Мы все можем улучшить практику и принципы, которым мы следуем, и применить их в нашем ремесле разработки программного обеспечения. Это сделает каждый день более приятным и позволит каждому из нас сделать более продолжительную карьеру. Продолжайте преследовать свою мечту, будь то написание кода для компании, в которой вы работаете, или для себя. Написание кода на стороне позволяет вам оставаться в курсе последних событий, например, мой побочный проект, который поддерживает меня (см. Apizapi.com и эту статью среднего размера).

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

«Но в целом, хотя я так и не достиг совершенства, которого так стремился достичь, но все же далек от него, тем не менее я, благодаря своим усилиям, стал лучше и счастливее, чем должен был бы быть в противном случае, если бы не попытался это сделать; " - Бенджамин Франклин

Больше контента на plainenglish.io