Попался мне достаточно крупного размера проект написанный на React + Typescript.
Покопался в коде. Всё круто, контейнеры, компоненты, типы везде стоят, линтер настроен, styled-components, даже storybook есть и некий react-query.

Ну просто счастье, а не проект!

Сажусь делать простую таску – какую-то страничку собрать из компонентов.
Пишу в коде But… и IDE мне предлагает 16 Button компонентов.

Блииин…

(Хабр-Статья представляет собой авторский перевод доклада, представленного автором на Scheme Workshop 2020, проводившегося в рамках Международной Конференции по Функциональному Программированию, 28 августа 2020 года)

Эта статья -- своего рода "отчёт" по самому большому проекту, который я сделал в своей жизни по собственной инициативе. Я сделал полное, исчерпывающее решение всех задач из одной из самых извесных книг по программированию в мире "Структура и Интерпретация Компьютерных Программ" (Structure and Interpretation of Computer Programs -- SICP), за авторством Абельсона, Сассмана и Сассман.

В ходе выполнения проекте я собрал довольно много данных о том, как решалось это задание в частности, и сформулировал несколько эвристик, помогающих выполнять проекты вообще, а именно:

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

→ Пока что написал первую часть — о принципах проектирования API «сверху вниз»

→ PDF-версию можно скачать отсюда

Вопросы, пожелания и предложения принимаются. Книга распространяется бесплатно на условиях CC-BY-NC. You're welcome!

Сегодня хочу поговорить о том, как проводить one-to-one встречи. 

Сначала о том, зачем они вообще нужны. One-to-one встречи – это один из инструментов развития команды. На этих встречах вы постепенно, планомерное выстраиваете отношения с сотрудником. Прозрачные, ясные отношения, в которых становится возможным сотруднику развиваться. В итоге эти встречи работают на адаптацию сотрудников, на их мотивацию и удержание. 

На встрече важно обсудить не только задачи. Вот примерная схема проведения one-to-one встречи.

 1. О сотруднике. С этого стоит начать. Спросите, как у него дела, что у него в жизни происходит.  

 2. Задачи. Какие сейчас у него задачи, какие у них сроки, какие есть проблемы. 

 3. Мотивация. Важный пункт, не игнорируйте его, пожалуйста. Необходимо прояснять мотивацию сотрудника на каждой встрече. Спросите, как ему его задачи, что нравится, что нет. 

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

 5. Работа с тимлидом. Самый неудобный вопрос) Можно задавать в лоб: «Как тебе работается со мной?» или окольными путями: «Что бы ты хотел в нашем взаимодействии улучшить, как тебе one-to-one, что бы ты хотел вынести на one-to-one», и т.д.

 6. Кризисы. Если в команде возник конфликт, пертурбация (например, когда из-за вируса все стали работать из дома), не старайтесь делать вид, что ничего не изменилось. Разъясните сотруднику происходящее, спросите, как он чувствует себя внутри всего этого. Вы таким образом можете снизить его тревогу. Сейчас достаточно много вызовов мира, которые заставляют сотрудников поступать по разному. И для нас важно понимать, не останется ли завтра проект без важного сотрудника, по его личным причинам.

На одном из потоков курса «PSYvIT для управленцев» меня спросили, надо ли на каждой встрече говорить про компанию. Разве может отношение к компании меняться раз в неделю? Нет, не обязательно каждый раз, но раз в 2-3 недели спросите. Вопросы могут меняться: держите в фокусе компанию, а спросите про продукт, про новый релиз. Компания – это вообще про окружение сотрудника, про команду. Опять же, многое зависит от того, что в вашей компании происходит сейчас. Кроме вопросов, рассказывайте об успехах и изменениях, которые происходят. Очень важно, чтобы новости компании сотрудники узнавали от вас, а не из новостной ленты социальных сетей.

1. Человеческим языком объяснить, что такое интерфейсы.
2. Объяснить, чем они полезны и как вы можете использовать их в своём коде.
3. Поговорить о том, что такое interface{} (пустой интерфейс).
4. И пройтись по нескольким полезным типам интерфейсов, которые вы можете найти в стандартной библиотеке.

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

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

Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.

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

«Сначала неизбежно идут мысль, фантазия, сказка; за ними шествует научный расчет и, в конце концов, исполнение венчает мысль.»
— К.Э. Циолковский

Сегодня у нас в виртуальной студии самый известный в мире докладчик по Spring — Джош Лонг.

Именно его докладами открываются Java-конференции по всему миру. Именно он отвечает на вопросы сообщества, делает Spring Tips на YouTube, именно его «This week in Spring» мы читаем каждую неделю и многое другое.

Кстати, Джош разрешил использовать все материалы в нашем собственном «This week in Java», но он делает их в таком объеме и глубине, что эти данные ни разу не получилось сжать до формата «дайджеста на 15 минут».

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

Участники

Josh Long, Spring Developer Advocate at Pivotal

Евгений Трифонов, Олег Чирухин — редакция JUG.ru Group