Месяц: Октябрь 2022

👥 Парное программирование — это способ организации командной разработки кода. В классическом варианте один программист, драйвер, пишет код, а второй, штурман, «на ходу» проверяет его решения.

Драйвер занят тактикой — концентрируется на частных задачах, а штурман мыслит стратегически, смотрит на картину в целом и комментирует то, что делает драйвер.

👨🎓 Как бы это ни казалось странным, исследования работы мозга во время парного программирования показали, что именно у штурмана уровень концентрации выше.

🤨 Впрочем, есть и недостатки:

🔹 Это сложно! Парное программирование требует от участников высочайшей концентрации. Нужны перерывы, смена ролей, и не каждый сможет работать в таком режиме больше нескольких часов.

🔹 Привыкнуть к такому стилю работы нелегко, и этот навык должен быть у обоих участников. К тому же они оба должны обладать одинаковыми компетенциями, подходить друг другу по стилю кодинга, сходиться темпераментами и уметь работать в команде.

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

📖 В 2006 году в своей книге «Терапия беспокойства. Как справляться со страхами, тревогами и паническими атаками без лекарств» психолог Дэвид Бернс предложил технику «Маленькие шаги к большим целям». Она помогает справиться с прокрастинацией, когда вы работаете над большим проектом и боитесь, что задача окажется очень сложной.

Чтобы втянуться, разбейте процесс выполнения на несколько шагов:
1. Изучить тему домашнего задания. Внимательно посмотреть, что именно нужно сделать.
2. Посмотреть видеоурок по теме.
3. Сделать краткий конспект.
4. Отметить те места, которые вам непонятны.
5. Поискать дополнительную информацию в интернете.
6. Набросать идеи решения.
7. Выбрать из них лучшие.
8. Начать выполнять задание.

🍫 Не забывайте про вознаграждение после каждого выполненного шага, например, съешьте что-нибудь вкусное, пройдитесь, сделайте перерыв.
Это, конечно, очень примерный план — ваш может быть другим. Маленькие шаги позволят вам постепенно включиться в работу и испытать приближающееся чувство завершенности. Желаем удачи!

📦 Представьте, что вы написали программу и готовы выпустить ее на рынок. Это не веб-приложение, код программы исполняется прямо на клиенте: покупатель платит деньги, получает файл программы и пользуется ей.

🕵️ ♂️ Но в тот момент, когда ваш файл попадет в руки технически подкованного пользователя, он получит доступ к вашему коду и сможет понять, как он работает. После этого он сможет, например, сломать защиту и пользоваться программой бесплатно, а если это ваш конкурент — скопировать код.

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

😓 Вам знакома ситуация, когда нужно сделать что-то важное, но вы не можете подступиться к задаче? Вариантов и неизвестных факторов много, выбрать сложно — и в итоге вы просто ничего не делаете?

🗿 Эта ситуация хорошо известна и изучена, в том числе в разработке. Аналитический паралич — состояние, когда чрезмерное обдумывание ситуации приводит к неспособности принять решение. За каждым вариантом решения вы видите потенциальные осложнения, и в итоге не выбираете никакого.

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

🌊 Риск аналитического паралича — один из известных недостатков методологии разработки Waterfall.
Продукт по ней разрабатывается последовательно, переходя к новой фазе только после полного завершения предыдущей. Сначала анализ требований, потом проектирование, реализация и так далее. Вариантов решения много, и если ошибиться в начале, пострадает весь проект целиком, поэтому выше риск застрять на этапе анализа и планирования.

〰️ Сейчас более популярны гибкие методологии разработки, например Agile, с сериями коротких циклов, спринтов, от одной до трёх недель. Каждый спринт завершается выпуском работающего продукта с новыми функциями, на котором любые ошибки видны сразу же. Неверное решение повлияет только на один спринт, а быстрая обратная связь поможет выбрать правильное направление. И перед вами не бесконечное число вариантов, а конкретные задачи на ближайшую неделю.

🤝Поэтому не поддавайтесь аналитическому параличу — даже не самое оптимальное решение часто лучше, чем никакого, особенно во время учебы!