Будь то разработка, тестирование или эксплуатация, у каждого технического специалиста более или менее есть мечта стать техническим мастером. В конце концов, «Надо иметь мечту, а вдруг она сбудется»! Именно стремление к этой технической мечте заставляет нас постоянно усердно трудиться и совершенствоваться.


Однако «мечты прекрасны, а реальность жестока». Многие учащиеся после начала реальной работы обнаруживают, что мечта — стать мастером, но то, чем они занимаются, кажется совершенно не связанным со становлением мастером. Например, программисты говорят: «Пишешь бизнес-код каждый день и работаешь сверхурочно — как тут стать техническим мастером?» Тестировщики говорят: «Каждый день нужно выполнять бесконечные тест-кейсы». Сотрудники эксплуатации говорят: «Таскать машины, подключать сетевые кабели и вводить shell-команды — это не та жизнь в эксплуатации, которую я хотел». ...... На Zhihu похожий вопрос: «Программисты, которые каждый день пишут бизнес-код, как им стать техническими мастерами и начать писать технический код?» имеет 6K+ подписчиков и 120+ ответов. Тогда я тоже ответил и получил больше всего голосов. Позже, проводя оценки и коммуникации по повышению карьерного уровня, я получил новые выводы и идеи, поэтому у меня появилась идея систематически оформить статью в надежде помочь большему числу учащихся избежать лишних обходных путей на пути к становлению техническим мастером.


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


Несколько типичных заблуждений


1. Взять технического мастера в учителя


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


Лично я против такого подхода по нескольким основным причинам:


  • Мастера очень заняты, и маловероятно, что они будут проводить с вами индивидуальные занятия, не говоря уже о часовых занятиях каждый день. Более того, внутри команды, если мастер часто проводит с вами отдельные занятия, это неизбежно вызовет подозрения у других членов команды. Лично я считаю, что если мастер действительно заботится, лучше всего проводить больше обучения для команды. Однако любой, кто проводил обучение, знает, что подготовка занятия отнимает очень много времени. Методички и материалы занимают минимум 2 часа (и их нельзя делать урывками), а объяснение занимает 1 час. Для мастеров проводить обучение раз в месяц — это уже очень часто.
  • Из-за первой причины, когда вы обычно хотите проконсультироваться с мастером, вам следует идти с конкретными вопросами, чтобы попросить совета или обсудить. Поскольку ответы на вопросы или их обсуждение не требуют слишком много времени и больше опираются на опыт и накопленные знания, мастера обычно рады это делать — в конце концов, влиятельность является важным показателем мастера. Однако нужно быть особенно внимательным: если вы часто спрашиваете о знаниях, которые легко можно найти в книгах или в Google, мастера тоже начнут раздражаться, потому что время дорого. Часто пользователи сети задают мне вопросы вроде: «Как настроить параметр JVM -Xmn?», и я прямо отвечаю: «Пожалуйста, просто поищите в Google», потому что таких вопросов слишком много. Если вы не учитесь систематически самостоятельно, то задавать каждый вопрос по отдельности — это пустая трата и вашего времени, и чужого.
  • Мастеров мало; маловероятно, что в каждой команде есть технический мастер. В лучшем случае в команде есть люди, более умелые, чем вы. Даже если он будет наставлять вас каждый день, вы сможете в лучшем случае подняться лишь до его уровня. Если технический мастер из другой команды, из-за рабочего распорядка и распределения задач возможностей для прямых консультаций и наставничества относительно мало. Одного лишь посещения нескольких обучающих занятий мастера вряд ли достаточно, чтобы самому стать техническим мастером.

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


2. Бизнес-код тоже может быть крутым


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


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


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


3. Работа слишком загружена, и нет времени на самообразование


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


Эта причина отчасти объективна. В конце концов, по сравнению с Европой и США мы действительно работаем сверхурочно больше, но этот фактор — всего лишь проблема, которую нужно преодолеть, а не непреодолимый разрыв. В конце концов, вокруг нас всё ещё много мастеров, которые выросли в этой китайской среде.


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


1) Работа в офисе вся состоит из повторяющихся задач; чтобы совершенствоваться, нужно дополнительно учиться вне работы.


Основная причина этого заблуждения всё ещё в убеждении, что «написание бизнес-кода не имеет технического содержания», а поскольку я пишу бизнес-код на работе, я не могу совершенствоваться на работе.


2) Для обучения нужны длительные непрерывные блоки времени


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


На самом деле подход прямо противоположный: во-первых, нам следует учиться и совершенствоваться на работе, потому что обучение через применение или наличие реальных примеров даёт лучшие результаты; во-вторых, после работы для обучения не нужны большие блоки времени, а нужно выкраивать время и использовать фрагменты времени для учёбы.


Правильный подход


1、Делайте больше


Делайте больше — делайте больше, чем задачи, которые поручает вам руководитель.


Когда я работал в HW, я отвечал за разработку одной версии. Объём работ по этой версии составлял около 2 000 строк, но помимо реализации функциональности я также досконально разобрался во всех связанных функциях и прочитал весь код (около 10 000 строк). После завершения этой версии я был знаком со всем набором бизнеса, связанного с этой версией. После одной-двух встреч все обнаружили, что лучше всех в этой области знаю я. Затем стало интересно: на обсуждениях продукта звали меня, тестировщики приходили ко мне с проблемами, начальник приходил ко мне за внешней поддержкой. Позже даже по функциям, за которые я не отвечал, обращались ко мне. Даже если я не знал ответа в тот момент, я читал код или находил документы, чтобы помочь им ответить... В конце концов я стал «экспертом» по этой системе. Хотя в то время я всё ещё занимался бизнесом и писал бизнес-код, я уже освоил весь этот бизнес.


Выше приведён всего лишь простой пример. На самом деле он показывает, что чтобы иметь возможности, нужно сначала выделиться из толпы. Чтобы выделиться, нужно отличаться. Чтобы отличаться, нужно делать больше!


Как делать больше? Можно начать со следующих аспектов:


1) Изучайте больше бизнеса — своего или нет; изучайте больше кода — написанного вами или нет.


Это даёт много преимуществ. Вот несколько простых примеров:


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

2) Освойте сквозной процесс


Например, если вы отвечаете за разработку серверной части веб-приложений, в действительности, когда пользователь инициирует HTTP-запрос, он проходит множество промежуточных этапов, прежде чем достигнет вашего сервера (например, кеш браузера, DNS, nginx и т. д.). Сервер обычно проходит множество этапов обработки, прежде чем достигнет той части кода, которую написали вы (маршрутизация, права доступа и т. д.). Во многих системах или на многих этапах всего этого процесса подавляющее большинство людей не могут участвовать в написании кода, но владение этими знаниями оказывает большое влияние на ваш общий уровень. Например, более ценная техническая работа, такая как проектирование решений и устранение онлайн-сбоев, требует комплексного технического уровня.


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


3) Самостоятельное обучение


Обычно в относительно зрелой команде, поскольку фреймворки или компоненты сильно инкапсулированы, технологий, используемых для написания бизнес-кода, действительно ограниченное количество. Но мы должны понимать, что «единственная постоянная — это изменения». Фреймворк может потребовать доработки, компоненты могут потребовать замены, или вы можете перейти в компанию, где нет ни компонентов, ни фреймворков, и вам придётся начинать с нуля. Это одновременно и возможности, и вызовы, а возможности и вызовы даются только тем, кто подготовлен. Поэтому в таком случае нам нужно ещё больше заниматься самообразованием, потому что к моменту, когда это действительно понадобится, учиться будет уже слишком поздно.


Возьмём Java в качестве примера. Большая часть бизнес-кода — это просто if-else плюс операция с базой данных, но мы вполне можем самостоятельно изучать больше знаний о Java, например, сборку мусора, тюнинг, сетевое программирование и т.д. Возможно, сейчас они бесполезны, но когда они действительно понадобятся, недостаточно просто загуглить. В тот момент возможность получит тот, кто уже освоил соответствующие знания и навыки.


Возьмём сборку мусора в качестве примера: я лично нашёл время, чтобы изучить эти знания в свободное время, и не использовал их в течение года. Но позже я использовал их несколько раз, и каждый раз они решали серьёзные проблемы с зависанием системы. В то же время некоторые студенты, которые пишут код на Java уже несколько лет, даже не знают, что такое концепция stop-the-world, не говоря уже о том, как её оптимизировать.


2、Делайте лучше


Знайте, что в этом мире нет ничего идеального. Системы и бизнес, за которые вы отвечаете, всегда будут иметь необоснованные аспекты и области для улучшения. Эти «необоснованные» и «улучшаемые» места — всё это монстры более высокого уровня — побеждая их, вы получаете больше очков опыта. Определите эти области, придумайте решения и предложите их своему руководителю. Если не получится с первого раза, предложите снова. Как только одно предложение будет реализовано, это ваша возможность.


Например:


  • Слишком много дублирующегося кода — можем ли мы внедрить паттерны проектирования?
  • Производительность системы средняя — можно ли её оптимизировать?
  • Сейчас это односерверная конфигурация — не лучше ли сделать двухсерверную?
  • Качество разработки версий невысокое — можем ли мы внедрить эффективные решения для модульного и интеграционного тестирования?
  • Текущая система слишком большая — можно ли её отрефакторить и разделить на три системы?
  • Некоторые системы промежуточного ПО Alibaba кажутся чем-то, что мы тоже могли бы использовать — можем ли мы их внедрить?
  • 。。。。。。。。。。。。。。。。。。。

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


В 2013 году меня перевели в Jiuyou. Сначала я принял простую бэкенд-систему. Каждый день я занимался только CRUD-операциями с данными для фронтенда. Это казалось совершенно неинтересным, правда? Если делать только это, то действительно скучно. Но после того как мы приняли её, мы сделали много всего:


  • Разделение: разделили один бэкенд на два бэкенда, чтобы повысить масштабируемость и стабильность;
  • Двухмашинная схема: превратили одномашинную конфигурацию в двухмашинную систему, чтобы повысить надёжность;
  • Оптимизация: сократили время выполнения интерфейса с изначальных 5 часов до 5 минут;

Было много и других оптимизаций. Позже наша группа взяла на себя больше систем. В итоге эта небольшая команда из 5 человек отвечала за 6 систем.


3、Занимайтесь практикой


Во время обсуждений карьерного уровня я обнаружил, что многие действительно старались делать больше и лучше, но в процессе выполнения почти все сталкивались с одной и той же проблемой: от простого чтения без применения мало пользы — что же делать?


Например:


  • Я изучил сборку мусора в JVM, но в продакшене редко бывают проблемы с задержками, вызванные FGC. Даже если такое происходит, восстановление бизнеса — главный приоритет. Маловероятно, что произойдёт проблема в продакшене и всем дадут на ней практиковаться. Так как же мне практиковать эти знания и навыки по JVM?
  • Я также читал о Netty и понимаю принципы Reactor, но не могу участвовать в разработке Netty. Как мне по-настоящему освоить асинхронный шаблон Reactor?
  • Я читал «High Performance MySQL», но продакшен-базами управляют DBA, а базы в тестовой среде ощущаются так, будто их настроили как попало. Как мне проверить эти приёмы?
  • Фреймворк инкапсулирует слой DAL, поэтому нам не нужно беспокоиться о доступе к базе данных. Как же нам изучить реализации шардирования и секционирования таблиц?
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Таких вопросов много. Позвольте мне поделиться здесь своим личным опытом. Всё сводится к трём словам: изучение, проба, преподавание!


1）Изучение


Это первый этап. Чтение книг, поиск в Google, просмотр видео и чтение чужих блогов — всё это работает, но следует отметить одну вещь: «систематизация», особенно для фундаментальных тем, таких как принципы JVM, программирование на Java, сетевое программирование и протокол HTTP... и так далее. Эти фундаментальные технологии нельзя изучить только через Google или блоги. Мой подход обычно таков: сначала прочитать полную книгу, чтобы получить всестороннее понимание, а затем использовать Google, видео и блоги, чтобы уточнить конкретные области сомнений или некоторые советы и приёмы.


2）Проба


Этот шаг — ключ к ответу на сомнения, о которых ранее говорили многие. Образно говоря, это «сделай сам — и у тебя всего будет вдоволь» — то есть создай свои собственные смоделированные среды и напиши свои тестовые программы. Например:


  • Сборка мусора в JVM: можно написать простую тестовую программу, которая выделяет память и не освобождает её, затем настроить различные параметры запуска JVM и во время выполнения использовать такие команды, как jstack и jstat, чтобы проверить распределение памяти в куче JVM и состояние сборки мусора. Такую программу очень просто написать — простой вариант занимает всего несколько строк, а более сложный — лишь несколько десятков строк.
  • Принципы Reactor: попробуйте сами написать демонстрационный пример паттерна Reactor. Не думайте, что это слишком сложно — простейшая реализация паттерна Reactor вместе с комментариями занимает не более 200 строк. Можно обратиться к PPT Дага Ли. После того как напишете сами, посмотрите, как это реализовано в Netty. Сравнив два варианта, вы гораздо глубже поймёте тему.
  • MySQL: поскольку есть производственная конфигурация, на которую можно ориентироваться, можно напрямую попросить DBA прислать нам производственную конфигурацию (не забудьте удалить конфиденциальную информацию) и учиться непосредственно по ней. Затем разверните собственное окружение MySQL и запустите его с производственной конфигурацией. Следует знать, что многие используют MySQL годами, но даже не могут настроить простое окружение MySQL.
  • Фреймворк инкапсулирует слой DAL: попробуйте написать простую реализацию шардирования базы данных/таблиц с использованием JDBC, а затем сравните её с реализацией во фреймворке, чтобы увидеть, в чём различия.
  • Используйте инструменты браузера, чтобы изучить реализации HTTP-кэша и посмотреть, как разные типы сайтов и разные типы ресурсов управляют кэшированием. Также можно написать простой HTTP-сервер на Python, который возвращает различные HTTP-заголовки, чтобы наблюдать за поведением браузера.
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

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


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


3）Обучение


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


Таких примеров много, в том числе когда я пишу свой блог — я часто с этим сталкиваюсь. Изначально мне кажется, что я всесторонне освоил что-то, но стоит начать писать, как я обнаруживаю множество моментов, которые не учёл. Я также часто вижу это на внутреннем обучении команды: кто-то пишет PPT, но при презентации, как только все начинают задавать вопросы или обсуждать, выясняется, что многие моменты не были ясно объяснены или некоторые моменты поняты неправильно. Прохождение всего процесса — написания PPT, презентации и обсуждения — в основном даёт довольно полное понимание конкретного знания.


Послесловие


Мечта стать техническим экспертом прекрасна, но требует много усилий. Будь то «Делать больше», «Делать лучше» или «Делать упражнения», всё требует времени и энергии. Этот процесс может быть болезненным или скучным. Здесь я хочу подчеркнуть: то, чем я поделился выше, — это методологии, но поистине решающую роль на самом деле играют наша страсть и интерес к технологиям!