Блог Хекслета

Это перевод статьи 7 Ways to Improve Your Code Reading Skills от A. N. M. Bazlur Rahman.

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

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

Чтение исходного кода даёт множество преимуществ. И эти преимущества очень выразительные. Код можно сравнить с литературой. Большинство писателей фокусируется на чтении литературных шедевров в процессе работы над чем-то своим. Причина в том, что невозможно создать что-то из вакуума. Нужно впитывать разные штуки из различных источников и работать с ними, создавая свой шедевр. Писать код — очень похожий процесс.

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

Если сказать проще — навыки чтения кода совершенствуют навыки написания кода.

Специалисты Facebook обнаружили, что их боты общаются на новом языке. И остановили их.

Боб: “I can can I I everything else.”

Элис: “Balls have zero to me to me to me to me to me to me to me to me to.”

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

Этот разговор произошел между двумя агентами искусственного интеллекта (ИИ), разработанными компанией Facebook. Изначально они переговаривались друг с другом на английском. Но позже инженеры поняли, что ошиблись, программируя их.

«Не было никакого смысла придерживаться английского», — говорит Дхрув Батра, инженер Georgia Tech из Facebook AI Research (FAIR). Учитывая то, что эти два агента конкурировали за лучший результат — это такая высокоэффективная схватка ИИ против ИИ — инженеры модифицировали «генеративно-состязательную сеть», и ни у одного из ботов не стало стимула общаться как люди. Поэтому они стали отклоняться от нормы и смешивать реальные слова в кажущиеся бессмысленными предложения.

«Агенты будут отклоняться от понятного языка и изобретать кодовые слова для себя», — говорит Батра, высказываясь в пользу уже предсказуемого явления, которое встречается тут, тут, и тут. «Как если бы я сказал «оно» пять раз, а вы бы поняли, что мне нужны пять копий определённого предмета. Это не сильно отличается от того, как сообщества людей придумывают сокращённые понятия».

Одно из самых проблемных мест в программировании — mutable state — изменяемое состояние. Оно делает код сложным, и как только вы ввязались в него, всё со временем становится более запутанным. Сокращение глобального изменяемого состояния в программе — один из лучших способов повысить качество кода, независимо от того процедурный он или функциональный.

Определение

Global mutable state содержит в себе три слова, каждое из которых имеет важное значение:

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

Mutable — означает изменяемый (в русскоязычной среде часто говорят «мутабельный», — прим. ред.). Часто можно заметить: все, что может прочитать значение, может так же и изменить его. Два считывания данных, следующих одно за другим, могут возвращать разные значения. Или, что еще хуже, сами возвращаемые структуры данных изменяются после чтения.

Дать определение состоянию (State) сложнее. Но, по существу, смысл в том, что значение зависит от истории программы. Насколько глубокой истории? В худшем случае (при наличии глобального изменяемого состояния) полной истории, от начала программы. Вам нужно знать всё об исполнении программы, включая то, как чередовались треды.

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

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

Григорий Грудинин прошел все 4 проекта на Хекслете и рассказал о своем интересном опыте. Вот его история:

Всем привет! Хочу рассказать о своем опыте прохождения проектов. Сразу оговорюсь, что узнав о таком интересном нововведение, бросил свой почти законченный путь по стеку PHP и окунулся в мир nodejs. Сделал я это только по одной причине: проекты - это самое важное, что даёт этот образовательный ресурс. Можно долго решать какие-то задачки, проходить курсы, без этого никуда, но основной толчок в собственном понимании того, к чему всё это идёт, дают именно проекты. Признаюсь честно, после прохождения курсов по PHP, курсы по nodejs казались гораздо более продуманными, более ориентированными на новичка. Проходил их достаточно быстро (никогда не делал больше 1-2 шагов в день, иначе решение дается очень легко, но в голове ничего не остается), кроме нескольких довольно сложных моментов, на уроки по которым запросто могло уйти несколько дней, а то и неделя.

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

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

Начнем с плохого...

1. Работа никогда не заканчивается

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

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

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

Спецификации и требования — заранее, пожалуйста!

2. Люди (до сих пор) не понимают, чем вы занимаетесь

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

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

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

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

Подсказка: Вычитайте резюме на предмет таких странностей, как «умею “гуглить”», - в умении ничего плохого нет, а вот в этих кавычках вверху - есть. Или Google как название компании и поисковика, или гугл как нарицательное для источника знаний и ответов на вопросы, забудьте про остальные вариации, не заключайте название компаний в кавычки, если речь не идет об ООО “Рога и копыта”. Если просто: у любой компании есть имя “по документам” (ООО “Рога и копыта”), и есть имя для печати и разговорной речи (Предприятие рогокопытных). Давно вы слышали, чтобы в разговоре без обсуждения документов название компании сочеталось с ООО? То-то же.

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

Зачем? Привлеките внимание, покажите заинтересованность в работе именно в этой команде и банальную внимательность к деталям, которая в IT никогда не бывает лишней. Заодно повысите число ответов и качество фидбэка, так как отношение HR’а может стать более личным.

Подвижка в сторону функционального программирования произошла, признаться честно, около десяти лет назад. Мы заметили, что языки вроде Scala, Clojure, and F# начали привлекать внимание. Это было больше, чем приычный энтузиазм — "О, круто, новый язык!". Было что-то выделявшее его, по крайней мере мы так думали.

Закон Мура обещал нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Этот закон работал с 1960 до 2000. А затем остановился. Вообще. Частота тактовых импульсов достигла 3Гц и перестала подниматься. Скрорость света была достигнута. Сигналы не могли проходить сквозь поверхность чипа настолько быстро, чтобы реализовать более высокие скорости.

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

Это перевод статьи Брэндона Морелли "JavaScript: What the heck is a Callback?"

Что такое коллбэк?

Простыми словами: коллбэк – это функция, которая должна быть выполнена после того, как другая функция завершила выполнение (отсюда и название: callback – функция обратного вызова).

Чуть сложнее: В JavaScript функции – это объекты. Поэтому функции могут принимать другие функции в качестве аргументов, а также функции могут возвращать функции в качестве результата. Функции, которые это умеют, называются функциями высшего порядка. А любая функция, которая передается как аргумент, называется callback-функцией. Чтобы лучше разобраться, давайте посмотрим на примерах, как это выглядит.