Точка зрения Яо Дуна

Способность к обучению, особенно способность к самообучению, когда вы когда-либо видели, чтобы те известные эксперты по программированию спрашивали на форумах: «Какую книгу мне прочитать, чтобы изучить XX,как быстро изучить XXX,какой код вы посоветуете для изучения XXX»? Что бы они ни захотели изучить, они могут быстро найти соответствующие материалы самостоятельно. Эта отрасль развивается слишком быстро, и технологии очень быстро устаревают. Если не изучать новое 3 года, можно отстать.

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

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

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

А что насчёт технических навыков? Технические навыки не важны. Обладая вышеперечисленными способностями, какую бы технологию ни потребовал рынок, вы сможете быстро её освоить.

Наконец, поговорим о зарплате. Запомните две фразы:

• Зарплата — это не награда начальника за ваши прошлые заслуги, а его ожидание вашего будущего вклада.
• Текущий босс никогда не даст вам удовлетворительной зарплаты; только следующий босс даст её.

Мнение Цао Чжэна

Яо Дун ответил очень хорошо. Позвольте мне добавить несколько слов в качестве продолжения.

Мы все знаем, что способность к обучению очень важна, но откуда берётся способность к обучению? Помимо чтения книг и посещения курсов, как вы учитесь и растёте в практической работе?

Раньше я высказал на Weibo общую мысль: что такое способность? Это ваше отношение к проблемам, а также ваш подход и методы их решения.

Во-первых, отношение

Ваш сервер иногда возвращает ошибки 501, возможно, нечасто (у Zhihu такое тоже случалось много раз). Многие программисты — да, многие — делают вид, что не замечают этого, не обращают внимания или списывают это на невезение. Это проблема отношения.

Позже, когда нагрузка становится высокой или по какой-то другой причине, ошибки 501 внезапно начинают возникать часто. Вместо того чтобы искать первопричину, они ищут всевозможные оправдания: IDC-провайдер плохой, марка сервера плохая, операционная система плохая, база данных плохая, CDN плохой, состояние сети плохое, веб-сервер плохой, или даже прямо говорят боссу: «Нас DDoS-ят!» (Я с этим сталкивался — я помог его боссу найти нескольких экспертов по безопасности для совместной консультации, и в конце концов мы выяснили, что это вовсе не DDoS; программист был просто слишком никудышным.)

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

Второе отношение — это отношение к решению проблем. Некоторые люди полны уверенности в своих решениях и считают, что они безотказны, а другие оставляют себе запасной путь. Например, когда вы говорите: стоит ли мне усилить защиту сервера? Определённо стоит, верно? Нужно быть как можно более строгим и тщательным. Но стоит ли всё равно шифровать пароли при сохранении их в базе данных? И использовать случайную соль? Разве это не именно для предотвращения худшего случая, когда всё ещё есть уязвимость и кто-то завладеет базой? То же самое касается программ. Некоторые серверные демоны, которые я писал в прошлом, имели ошибки и необъяснимо завершались. Конечно, эту ошибку нужно найти и исправить, но в то же время напишите cron для проверки состояния демона и автоматического восстановления, как только он завершится. Это запасной план. Даже если вы действительно не хотите, чтобы он срабатывал, всё равно нужно сделать эту подготовку. Наличие двух или даже трёх планов решения проблемы — тоже ключевое качество превосходных программистов и архитекторов.

Третье отношение основано на коммуникации и понимании. Когда команда продукта или команда эксплуатации выдвигает неразумное требование, отклонить его одной фразой, конечно, приятно и производит впечатление. Но тщательно ли вы общались и анализировали, какая реальная потребность лежит в основе этого требования и есть ли у этой реальной потребности более разумный способ реализации? Резкое «это невозможно сделать, стоимость реализации слишком высока» — неверное отношение к коммуникации. Более того, лучшие продукты часто оказываются теми, которые реализовали потребности, которые люди изначально считали нереализуемыми.

С таким отношением у вас есть основа для непрерывного прогресса. Теперь поговорим о подходах и методах.

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

Самый базовый момент: проверяйте логи выполнения, проверяйте всевозможные логи — логи веб-сервера, логи базы данных, логи медленных запросов, логи binlog, логи ошибок PHP и так далее. Когда в продакшене возникают проблемы, много людей начинают гадать наугад, даже не взглянув на логи. Также много тех, кто не читает логи внимательно или полностью. Если вы умеете серьёзно изучать логи, вы уже превзошли многих.

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

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

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

Что касается обобщения, позвольте мне поделиться одним случаем.

Раньше у нас была система с очень большим объёмом запросов и очень высокой нагрузкой. За это взялся довольно хороший технический менеджер. Он перечислил несколько планов модернизации, все надёжные, выполнил их, и результаты были очень хорошими. Затем, когда мы разбирали отчёт, он рассказал о выполненных им модернизациях и общих результатах. Тогда я его покритиковал.

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

Вот, пожалуй, и всё.

И напоследок позвольте мне ещё раз повторить.

Что такое способность?

• Ваше отношение к возникающим проблемам
• Ваш подход и методы решения проблем

Это и есть способность

Первоисточник:Zhihu