В пятницу, 26 июля 2019 года, я принял участие в Спроси меня о чем угодно (AMA) на канале Slack Вентури. Я получил несколько отличных вопросов, касающихся разработки программного обеспечения, эффективных подходов к обучению, моей работы в инженерном сообществе и эффективной реализации, и записал их ниже вместе с моими ответами для вашего собственного прочтения.

Лиам [10:58 AM]
Добро пожаловать в AMA! Джеймс, не могли бы вы дать нам краткую биографию, чтобы начать мероприятие?

Конечно, Лиам! Как уже говорилось, я Джеймс и разработчик в YLD. Я провожу время, консультируя различных клиентов по проектам JavaScript, используя такие как React, Node.js, TypeScript, React Native, RxJS и другие части. В тандеме я пытаюсь открыть офис и развитие в Манчестере; сейчас только я и один замечательный коллега, но мы надеемся на органический рост по мере необходимости, чтобы позволить нам поддерживать высокий уровень инженерии, которым мы известны. В рамках этих усилий я также являюсь соорганизатором Manchester Web Meetup с нашей замечательной командой по мероприятиям и маркетингу; вы можете найти нас в Твиттере - @manc_web.

Лиам [11:10 AM]
Я отвечу на вопросы! В настоящее время я изучаю объекты в JavaScript, и нахожу их довольно сложно (они тают мне мозг сильнее, чем эта погода, ха). Когда вы видите, что кто-то борется с концепцией в JavaScript, как вы посоветуете им подойти к проблеме, чтобы они могли ее преодолеть?

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

Сэм [11:13 AM]
На днях я послушал небольшой ваш подкаст; это было действительно хорошо. Когда вы разговариваете с кем-то, кто хочет заняться программированием, с чего вы им говорите, чтобы начать? Вы упомянули SitePoint, freeCodeCamp, Udemy и т. Д. Есть ли у вас личные предпочтения или подход к обучению?

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

Я бы резюмировал так: читай, но создавай и ломай что-то, чтобы по-настоящему прожечь свою лимбическую систему!

Энди [11:16 AM]
Я повторно послушал наш подкаст перед этим мероприятием и хотел бы подробнее рассказать о том, что вы отметили в шоу о плоских иерархиях. Вы упомянули преимущества плоской иерархии, но не могли бы вы подробнее рассказать о том, как создать плоскую иерархию в вертикальной компании?

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

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

Стив [11:29 AM]
Есть ли у вас какие-либо рекомендуемые материалы для чтения как по программированию, так и по другим вопросам, * выходящим за рамки * программирования (например, в отношении бизнес-ограничений / технических ограничений и создания вещей, которые масштабируются и имеют долгий жизненный цикл)?

Эй, Стив! Мои рекомендации по программированию:

  • Чистый код - довольно много Java и ООП, но это была отличная отправная точка, когда я был младшим, переходя на роль среднего уровня.
  • JavaScript: хорошие части - ориентирован на ECMAScript 5, но все же охватывает множество полезных концепций JS, которые применяются сегодня (например, прототипное наследование, замыкания и т. д.)
  • Математика и физика для программистов - как человек, который не изучал математику во время учебы, я нашел эту книгу чрезвычайно полезной для изучения элементарной линейной алгебры и исчисления. Хотя я определенно не хочу в ближайшее время заниматься наукой о данных, понимание этого сделало меня более эффективным программистом, особенно с учетом пересечения между расчетами и ФП. Кроме того, программирование игр может быть интересным
  • Game Engine Black Book: Doom - это действительно весело. Опять же, это не критический фолиант, но невероятно унизительно читать о революционной работе, которая вошла в эту игру, а также думать об усилиях автора.

Теперь о некоторых работах, не связанных с программированием:

  • От худшего к первому: за кулисами замечательного возвращения Continental - хроника удивительной трансформации Гордона Бетьюна в компанию Continental Airlines, которая была наихудшей в США, когда он присоединился к компании, и находилась на грани банкротства. Предприняв небольшие, достижимые действия, чтобы продемонстрировать, что изменения возможны в жесткой среде, а также побудив недовольных сотрудников участвовать в денежных и символических вознаграждениях, Continental стала самой эффективной авиакомпанией, по мнению федерального правительства, всего за два года.
  • Начните с того, почему - возможно, слишком раздутый и повторяющийся, но в остальном отлично подчеркивает важность видения - цели - при создании и управлении компанией. Заработок - это результат, а не главная цель
  • Структура научных революций - очень сухой и философский, но не менее интересный взгляд на то, как возникают революции и какое влияние они оказывают.

Холли [11:29 AM]
Как вам удалось развить Manchester Web Meetup за такое короткое время? И какие-нибудь советы, как максимально использовать отношения наставника / подопечного?

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

Кроме того, у YLD есть отличная команда по маркетингу и организации мероприятий, без которой все это было бы невозможно.

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

Сквоши [11:31 AM]
Я начинаю изучать C #, и моя проблема заключается в том, чтобы найти проект… вроде того. Я обнаружил, что я недостаточно креативен, чтобы знать, как должен выглядеть конечный продукт. Так что когда я врезаюсь в стену, она действительно кажется непроходимой. Думаю, я спрашиваю, как лучше всего узнать, что, вероятно, не основано на проектах? Или это просто глупая идея ?!

Что ж, если вы до сих пор наслаждаетесь этим, но изо всех сил пытаетесь создать продукт, который будет напрямую обращен на публику, возможно, вам подойдет создание какого-то API. С помощью ASP.NET Core вы можете создать службу REST, которая возвращает JSON для определенных фрагментов данных, которые затем могут быть использованы каким-либо внешним проектом в другом месте. В противном случае вы даже можете написать библиотеку (то есть неисполняемый пакет кода), функциональность и поведение которой вы можете проверить с помощью разработки, управляемой тестами.

Если это покажется вам низкоуровневым, возможно, вы могли бы начать с решения C # kata, подобного Codewars, и постепенно расширять свои знания в полностью интерактивной среде.

Джеймс [11:43 AM]
Я застрял между путями Angular и React / Redux. Многие компании, в которых я проводил собеседование в последние месяцы, предъявляют требования к работе для Angular с опытом работы с PHP и MySQL, но они регулярно выражают желание перейти к разработке на React / Redux или Vue.js в интерфейсе и Node.js в интерфейсе. задний конец. Как возможно на этом быстро развивающемся рынке труда иметь дело с обоими, не оказывая серьезного влияния на мою способность сосредоточиться на одном пути развития и вернуться к работе?

Я мог бы легко предложить вам изучить React в свободное время, и было бы неразумным с моей стороны предполагать, что не поможет. Однако у всех разные потребности и цели вне работы, поэтому я считаю, что если компания нанимает вас для получения одного набора навыков, но хочет перейти на другой технологический стек, то ответственность за то, чтобы дать своим инженерам время, ложится на работодателя. поддержка и обучение для изучения указанного стека как часть их работы. Если вы делаете это в свободное время исключительно для их пользы, то вы фактически работаете сверхурочно бесплатно.

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

Дебаншу [11:49 AM]
Как дела? Мои вопросы: я прочитал статью, в которой говорилось, что ООП - это катастрофа на триллион долларов, и я так и не понял причину. Также было сказано, что функциональное программирование лучше ООП. Каково ваше мнение?

Привет, Дебаншу! Я хорошо, спасибо! Как дела?

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

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

Я написал статью об этом, которая может вас заинтересовать.

JD [11:55 AM]
Я разработчик JS / .NET. Имея большой опыт самостоятельной разработки для крупного бизнеса, я обнаружил, что компания / руководство стремятся к более быстрой разработке новых функций. затмевает попытки следовать твердым принципам разработки, что неизменно ведет к замедлению разработки и большему количеству ошибок.
Однако казалось почти невозможным найти время и ресурсы для решения такой технической проблемы. Есть ли у вас какие-либо советы или подсказки для таких ситуаций, или даже, возможно, проверенный временем способ отчетности и сообщения о дополнительных расходах, возникших из-за указанного технического долга, таким образом, чтобы не отвлекать внимание технического руководства?

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

Что меня соблазняет, так это возможность послать открытое сообщение любым владельцам продуктов или руководителям, которые могут это читать: пожалуйста, послушайте нас, технарей. Я понимаю необходимость быстрого внедрения инноваций, но, позволив нам устранить существующие технические препятствия (например, плохо написанные области кодовой базы, вертикальное масштабирование и т. Д.) И улучшить конвейер доставки (я смотрю на вас, непрерывная интеграция), мы можем создавать новые ценности с еще меньшим трением. Дай нам шанс!

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

Will [12:21 PM]
Послушал ваш подкаст в дороге. В шоу вы упоминаете, что выступление с речью может помочь вам критически проанализировать ваш собственный подход к кодированию. Вы когда-нибудь заново изучали то, что, как вы думали, узнали после выступления?

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

Томми [12:33 PM]
Как проведение мероприятий и наставничество помогли вам развиваться как разработчику?

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

Еще одно преимущество, о котором стоит упомянуть, - это то, что это повысило мою сопротивляемость. При организации Web Meetup я сталкивался с различными проблемами, например, с решением организаторов бросить учебу; Как разработчик, я умею решать проблемы, но решение проблем в совершенно новом контексте только укрепило эти навыки. Я многому научился!