Я близок к завершению своей двухмесячной летней стажировки в самой клиентоориентированной компании Земли. Мне повезло, что я смог провести лето, изучая все изнутри культура и работа в одной из крупнейших компаний на планете - вот чему я научился за два месяца.
ПРИМЕЧАНИЕ. Хотя эта статья посвящена моему времени в Amazon, она не отражает идей или отношения моего работодателя. Я также изо всех сил стараюсь не отказываться от вещей, которые потенциально не подлежат разглашению, поэтому я не буду говорить о внутренних инструментах или о том, какую именно работу я сделал, а только об опыте, стоящем за ними.
1. В мире полно действительно умных и добрых людей.
Я мог бы назвать этот пункт «Amazon полон действительно, действительно умных людей», но на данный момент я считаю, что область разработки программного обеспечения обычно полна невероятно умных людей.
Я не первый стажер, но это моя первая стажировка в компании FAANG. Не думаю, что что-то могло подготовить меня к масштабам, которые я собирался стать свидетелем: все в Amazon было огромным и построено для масштабов всей планеты. У внутренних инструментов больше пользователей, чем у многих стартапов SaaS когда-либо будет.
За подобным масштабом скрывается много сложностей. К счастью, совершенно очевидно, что никто не хочет, чтобы вы справлялись со всей этой сложностью в одиночку. Каждый раз, когда мне требовалась помощь с каким-либо инструментом или программным обеспечением, моя команда находилась на расстоянии одного клика - и, черт возьми, они хороши в том, что они делали.
Были времена, когда я задавал вопрос, и ответ был быстрым, не у них в голове - эти моменты были впечатляющими, но еще более впечатляющими, когда моменты, когда я спрашивал коллегу о проблеме, которую я не мог понять, и они быстро добрался до отладки. Их методы были быстрыми и эффективными - быстрыми, точными и безжалостно логичными.
Поскольку я стажусь во второй раз, я не привыкать задавать много вопросов и получать много отзывов. Каждый человек в области программного обеспечения, с которым я работал, будь то в Amazon, DAIS или в сообществе разработчиков ПО с открытым исходным кодом, был людьми выдающегося характера. Хотя, очевидно, есть исключения из этого правила, спасибо разработчикам программного обеспечения не только в Amazon, но и повсюду за то, что они классные и отзывчивые люди.
2. AWS огромен
Приступая к работе в Amazon, я думал, что довольно много узнал об AWS и предлагаемых ею инструментах. Я раскрутил EC2, потратил время на изучение RDS и Aurora, заплатил из своего кармана за API-шлюз и даже немного поработал с Texttract.
Список инструментов AWS, которые я использовал ранее, был карликом даже из-за количества инструментов, которые моя команда, небольшая часть гиганта Amazon, использует ежедневно.
Есть несколько сервисов, которые, как я узнал, почти единодушны: AWS CDK и Cloud Formation великолепны, и я буду использовать их в будущем для личных проектов. Даже в гораздо меньшем масштабе IaaC и гибкость, которую дает AWS CDK, не имеют себе равных.
Другие службы используются реже, но все еще используются во многих инструментах инженеров. Одним из этих инструментов, которые бесконечно полезны в правильном контексте, являются пошаговые функции. Последовательность действий (в основном лямбда-выражения, но могут содержать и другие службы, такие как Glue Jobs), которые запускаются последовательно, что позволяет разбивать сложные задания и отслеживать мелкие кусочки большой головоломки.
AWS не просто так работает в Интернете. Потрясающий масштаб инструментов и приложений для каждого случая использования бесконечно удобен.
Если у вас есть сценарий использования программного обеспечения, он описан в AWS. Если еще нет, то скоро будет.
3. Вопреки распространенному мнению, структуры данных и алгоритмы используются не только в качестве шлюзового механизма.
Это скорее нишевый и спорный момент, но это вывод, который, на мой взгляд, имеет конкретную ценность.
Я думаю, что большинству разработчиков программного обеспечения не нравятся вопросы на собеседовании в стиле Leetcode. Чтобы не потворствовать моим повелителям FAANG, я никогда не разделял этого убеждения - в худшем случае, это было мерило усилий или того, сколько времени вы посвятили тренировкам и, в свою очередь, сколько вы хотите Быть в компании и масштабируемый механизм собеседования.
Тем не менее, я буду первым, кто признает, что общее количество раз, когда было полезно знание оптимального количества монет для создания определенного количества сдачи, было довольно мало. Но я прошел через процесс собеседования в Amazon, и я потратил много часов на практику Leetcode для своих собеседований.
Когда я добрался до Amazon, я начал копаться в коде в своем приложении. Только в моем проекте у меня была возможность использовать извлечение кучи, связанные списки и карты поиска. Я не думаю, что мой проект можно было бы поддерживать без извращенного использования объектно-ориентированного программирования. Пространство проблем было слишком сложным, чтобы можно было эффективно решить проблему без хорошего программирования.
Это не значит, что я пытался придумать, как уместить мою программу в одну строку. Читаемость и ремонтопригодность всегда были и всегда будут важнее чистой производительности (в большинстве случаев! Amazon настолько велик, что ни один абсолют никогда не выдержит, включая этот), но мне много раз удавалось оптимизировать свой код для лучшего пользователя. опыт использования ненавистных DSA и методов кодирования.
Считаю ли я, что инженеры должны тратить часы в день на изучение динамического программирования в 3-м измерении? Нет. Думаю ли я, что некоторые разработчики тратят столько времени, ненавидя DSA, что упускают из виду их практическое применение? Абсолютно.
Итак, это все! Это три моих вывода (из которых, я думаю, может быть написана хорошая статья) из летней стажировки.
Если у вас есть какие-либо вопросы или сомнения, или вы не согласны со мной в какой-либо момент, не стесняйтесь оставлять комментарии! Я всегда читаю и отвечаю на них. Я всегда учусь у своих читателей.
Если вы являетесь членом моей команды и читаете это, спасибо за отличное лето - я узнал намного больше, чем мог бы уместить в 7-минутной статье, и не все это было о разработке программного обеспечения (хотя и этого тоже много.)
Спасибо за прочтение!
