О том, как решать сложные задачи простыми способами. Так, чтобы и перед коллегами не было стыдно
Даём систему, по которой можно писать простой код — чтобы коллеги поняли даже через несколько лет
С чек-листами для себя и команды
15 октября в17:00 по Мск
простой
(3) Если работаете в домене с высоким уровнем ответственности (транспорт, медицина, платежные формы и т. д.)
(1) Если делаете проект дольше, чем за один вечер

(2) Если в проекте участвует больше одного разработчика
когда подойдёт
Типичные сценарии,
(4) Сложная кодовая база ухудшает сама себя — пока въедешь, что понаписано в репе, времени на рефакторинг уже не останется
(5) Простой код легче подстраивать под внезапно изменённые требования
(6) Меньше багов откладываете на будущее
Запускаете проект не на один вечер, а на много месяцев или лет
Надолго:
(7) Когда пишешь проект сам, более-менее помнишь, где что лежит и как называется. Как только появляется второй человек — телепатия не срабатывает: непременно что-то будет понято не так, как задумывалось автором
(8) Явный код без сюрпризов понятен сразу, без комментов и документации. Даже новые люди поймут, как устроены данные и что делают функции
— Почему функция update_customer списывает деньги?

Пишем проект не в одно лицо, а командой — от двух и более человек
с Командой:
(9) Чтобы разобраться в сложной предметной области вроде медицины или бухгалтерии, уходит год. Держать такие знания в голове одновременно со всеми идиосинкразиями кодовой базы — невозможно
(10) Если код в проекте помогает понять предметную область — решать задачи становится проще и быстрее. Появляются силы для создания новых фич, чтобы обставить конкурентов
Мы пишем систему бронирования авиабилетов. Нужно учесть пассажиров, авиакомпании, продавцов, аэропорты, границы, визы, тарифы, чекины, отмены, переносы, стыковочные рейсы, доплату за багаж, особое питание, личные кабинеты, … — а get_bank() всё ещё возвращает email
Программисты не всегда успевают думать о коде
Предметная область:
(11) В НАСА и JPL запрещено писать функции длиннее одной печатной страницы, использовать goto, рекурсию и динамическое выделение памяти. Потому что стоимость ошибки слишком высока
(12) Хотя мы и не НАСА, у нас тоже большая ответственность: наш код обрабатывает платежи и взаимодействует с клиентами. В простом коде накосячить сложнее
Ответственность
(13) Те, кто придёт после вас, скорее всего, не захотят выкидывать ваш код, если вы напишете его по правилам, которые мы даём
(15) Простой код не захочется выкинуть. Проект будет двигаться вперёд без остановок, чтобы переписать всё с нуля
(14) Делать запутанные вещи легко, а вот чтобы сделать сложное простым — надо приложить усилия. В случае с кодом, к счастью, можно развить насмотренность — научиться замечать тонкие места и заранее устранять сложности
Легаси — это не когда много кода, а когда нифига не понятно
Наследие:
(2) Вы ещё не участвовали в коммерческих или масштабных проектах — вы ещё не сталкивались с проблемами, которые мы решаем
(1) Вы решаете только задачи с лит-кода и олимпиад — это write-only-код, он может быть каким угодно, всё равно его никто не прочтёт
(3) Хотите узнать десять самых неожиданных странностей JavaScript — мы не погружаемся в конкретные языки
Вебинар не для вас,
если
Больше всего
(1) Крепким джунам и мидлам, которые уже идеально изучили основные инструменты и применяют их для решения реальных задач. Теперь хочется делать это качественно
Тоже полезно
(2) Синьорам и тимлидам. Во-первых, это система. Во-вторых — вам уже пора заботиться о качестве не только у себя, но и у коллег или в своей команде. А простой код — это повышение надежности и снижение time-to-market
подойдёт меньше
Если вы только начинаете писать код и ещё испытываете сложности сложности в решении простых задач. Скорее всего, вам пока не хватит внимания, чтобы обращать внимание ещё и на качество.

Но мы верим, что вебинар вам всё равно поможет избежать совсем уж очевидных проблем со сложностью и даст пищу для роста
подойдёт Мидлам и джунам
чего ждать
а чего не стоит
(2) Обсуждаем конкретные примеры простых структур данных и алгоритмов, наименование сущностей и принципы оформления кода. Сравниваем хорошие и плохие решения
(1) Рассказываем общие принципы, даём системный подход, показываем, от какой сложности можно избавиться, а с какой придётся смириться
(2) Не говорим об архитектуре, не разбираем паттерны проектирования, не рассматриваем случаи, когда лучше обойтись зерокодом или ЛЛМ
(1) Не изучаем конкретные языки программирования и фреймворки
(1) Почему с одним кодом приятно работать, а другой хочется выкинуть. Как это измерить: объективные и субъективные способы

(2) Откуда в коде берётся сложность (не потому же, что мы глупые?). Accidential vs Essential complexity. Какую сложность можно выкинуть, а какую остаётся только прятать

(3) Когда сложность надо чинить, а когда — можно забить

(4) Коммуникация при помощи кода. Как не обманывать и сделать, чтобы вас нельзя было понять неправильно
(5) Инструментарий, чтобы моделировать доменную область: фракталы, функциональщина, конечные автоматы

(6) Лингвистика и нейминг: синонимы, омонимы, двойные отрицания, части речи

(7) Как продавать хороший код команде и бизнесу

(8) Как начать работу над качеством кода в проекте


  • Существенная и случайная сложность
  • Метрики сложности
  • Код как язык коммуникации
  • Принципы наименования сущностей
  • Простые и составные структуры данных
  • Функциональный подход
  • Конечные автоматы
О чём говорим на вебинаре
Принципы и термины, за которые можно зацепиться
15 октября в17:00 по Мск
ПРОДАНО
ПРОДАНО
ПРОДАНО
В тусовке
— Всё, что у «Только послушать»

— Q&A-сессия через пару недель, чтобы обсудить то, что улеглось

— Чат своих: чтобы было где страдать, хвалиться и задавать вопросы. Остаётся навсегда

— Доступ к записи в течение девяти месяцев после Q&A-сессии

— Доступ к комьюнити выпускников

— Позовём до десяти ваших сотрудников на вебинар в формате «В тусовке»

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


Для общительных и тех смелых интровертов, которые решились вылезти из пещеры и расширить свой нетворк
Для компаний, которые понимают важность того, чтобы все программисты общались на одном языке
Продвинутый юрик
Несите
ваши деньги
Если возникли вопросы или хотите оплатить от юрлица — напишите на support@tough-dev.school, отвечаем в течение суток. Если сомневаетесь, подойдёт ли вам курс, — тоже пишите на почту свой кейс, и мы отговорим, если поймём, что он не решит вашу задачу.
в рублях и в долларах
За обучение можно получить налоговый вычет 13%
За обучение можно получить налоговый вычет 13%
За обучение можно получить налоговый вычет 13%
За обучение можно получить налоговый вычет 13%
Присылаете реквизиты
Согласовываете
Согласовываете с руководителем обучение или знакомите нас с руководителем, чтобы мы вам в этом помогли.
Обмениваемся документами
Мы выставляем счёт и отправляем приглашение для обмена документами в Диадок.
Ваша компания оплачивает, а мы добавляем вас в участники и передаём контент.
Присылаете нам на почту реквизиты компании. Обычно их можно взять у HR, на сайте компании в разделе «Контакты» или в бухгалтерии. Если ваша бухгалтерия просит какой-то набор документов — приложите список, чтобы мы сразу прикрепили.
Если чувствуете, что в вашем случае нужны другие аргументы, — напишите нам на support@tough-dev.school свой кейс: мы подскажем или отговорим от покупки.
Даём доступ
По окончании присылаем закрывающие документы в Диадоке, а ваша бухгалтерия подписывает.
2
Хочу учиться
за счёт компании
1
3
4
(1) Растёт производительность за счёт уменьшения когнитивной сложности. Програмисты меньше думают о коде и больше думают о бизнесе — в результате пилят фичи быстрее
(2) Разработка становится более прозрачной. Мы учим писать код, который читается, как книга. Если соблюдать наши правила, продакт-менеджер сможет залезать в репозиторий и смотреть, как работает каждая конкретная user-story
Мы подготовили для вас аргументы, что получит компания после того, как вы внедрите полученные на вебинаре знания
(4) Ускоряется онбординг. Новичкам не надо тратить несколько недель, чтобы вкатиться в проект. А значит, команду можно масштабировать гораздо быстрее
Если аргументы помогли — дальше всё просто:
(3) Код получается более надёжным. Простой коде легче тестировать, в нём меньше багов, а исправление старых недочётов не приводит к появлению новых. Поддерживать его легко даже через несколько лет
Федя бoрщёв
Независимый CTO, 14 лет руководит программистами. В курсе приземляет полёт мысли на практику и помогает держать фокус.
Анатoлий Буров
Соосновал Главред, Таймстрайп и Конспект. Работал дизайнером и технологом в Студии Лебедева, в компании Tunnel Technologies программировал, дизайнил и руководил (вырос от программиста до CIO).
Эксперты
Комьюнити Школы
Все выпускники собираются в чате, где помогают друг другу — от бытовых советов по релокации до советов по выбору стека. Сейчас в чате 9 топиков и более 1000 активных участников.
По окончании курса добавим вас в наше
Где работают
наши ученики
ВОПРОСЫ-ОТВЕТЫ
Если не нашли ответа на вопрос, напишите на support@tough-dev.school. Отвечаем в течение суток.

Учавствовать в курсе

Обязательное поле

Обязательное поле

Обязательное поле

Заполните обязательные поля

Нажимая на кнопку, я соглашаюсь на обработку персональных данных, с Политикой конфиденциальности и с офертой