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

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

Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитным кодом на PHP.

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

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

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

Проблема хрупкого базового класса

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

tl;dr

Cжатие изображений всегда должно быть автоматизировано

1. «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» / Дорофеев Максим

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

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

• Типизированные свойства классов
• Предзагрузка для улучшения производительности
• Стрелочные функции для короткой записи анонимных функций
• Присваивающий оператор объединения с null (??=)
• Ковариантность/контравариантность в сигнатурах унаследованных методов
• Интерфейс внешних функций, открывающий новые возможности для разработки расширений на PHP
• Оператор распаковки в массивах

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

• атомарных операциях в memcached;
• реализации счетчиков просмотров и онлайнеров.