Выступление: инструменты и методы эффективной удалённой работы
Upcoming SlideShare
Loading in...5
×
 

Выступление: инструменты и методы эффективной удалённой работы

on

  • 284 views

Выступление на Сибирских Интернет-Неделях, 25.9.11

Выступление на Сибирских Интернет-Неделях, 25.9.11

Statistics

Views

Total Views
284
Views on SlideShare
284
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Выступление: инструменты и методы эффективной удалённой работы Выступление: инструменты и методы эффективной удалённой работы Presentation Transcript

  • Инструменты и методы эффективной удалённой работы Дмитрий Лебедев [email_address] obnob.com
  • Чего в этом докладе не будет
  • Чего в этом докладе не будет
    • Как запустить стартап
  • Чего в этом докладе не будет
    • Как запустить стартап
    • Как стать фрилансером
  • Чего в этом докладе не будет
    • Как запустить стартап
    • Как стать фрилансером
    • Как искать заказчиков и работать с ними
  • Чего в этом докладе не будет
    • Как запустить стартап
    • Как стать фрилансером
    • Как искать заказчиков и работать с ними
    • Как перейти с ADD* на Agile
    • * Asshole Driven Development
  • Чего в этом докладе не будет
    • Как запустить стартап
    • Как стать фрилансером
    • Как искать заказчиков и работать с ними
    • Как перейти с ADD* на Agile
    • Как довести проект до релиза
    • * Asshole Driven Development
  • Что в этом докладе будет
  • Что в этом докладе будет
    • Укажу на проблемы
  • Что в этом докладе будет
    • Укажу на проблемы
    • Расскажу про их решения:
  • Что в этом докладе будет
    • Укажу на проблемы
    • Расскажу про их решения:
      • Как звонить по скайпу
      • Как делать работающие скетчи компонент
      • Как делать качественный обзор кода
  • Что в этом докладе будет
    • Укажу на проблемы
    • Расскажу про их решения:
      • Как звонить по скайпу
      • Как делать работающие скетчи компонент
      • Как делать качественный обзор кода
    • Назову полезные инструменты
  • Чем хороша удалённая работа
    • Консервативный подход: удалённая работа между офисами
      • Не нужно гонять специалистов в командировки
      • Можно следить за работой ПО круглые сутки
      • Можно обмениваться опытом на бо́льшие расстояния
    • Полностью автономная работа без офиса:
      • Свободный график (есть плюсы и минусы), свобода передвижения
      • Учит терпению, самоорганизации и самостоятельности
  • Чем плоха́ удалённая работа
    • По умолчанию ты – в четырёх стена́х
    • Ночная работа и подъём в полдень
    • В общении с коллегами есть лаги
    • Общение:
      • – Вот есть проблема
      • – Исправили, проверяйте
      • – Всё равно не работает
      • – А теперь?
      • – Работает. Спасибо!
    • Вопрос залу: что здесь не так?
    Проблема №1
    • Общение:
      • – Вот есть проблема
      • – Исправили, проверяйте
      • – Всё равно не работает
      • – А теперь?
    • Пауза между репликами – 12 часов.
    • Этот диалог шёл всю неделю, потому что две стороны находились в 12 часовых поясах, и их рабочее время не пересекалось.
    Проблема №1: лаги
  • Решение проблемы №1: звонки
    • Звонок проще почты
    • Назначаем регулярные звонки в определённое время, удобное всем
    • Общение голосом намного быстрее, чем почта или мессенджеры
      • Мессенджеры несут только вспомогательную функцию (например, послать ссылку)
  • Проблема №2: пустая болтовня
    • Звонки по телефону или скайпу не приносят ясности
    • Письма влом писать
  • Решение проблемы №2
    • Звонки по телефону или скайпу не приносят ясности
    • Письма влом писать
    • Общение по Гугло-Толку бестолковое
    • Решение: звонить и писать одновременно.
      • Etherpad (openetherpad.com), Collabedit, Emacs Rudel, Unix Screen (ssh, screen -x)
  • EtherPad
  • EtherPad: подсветка
  • EtherPad: опции
  • EtherPad: история правок
  • Важный навык
      Важное умение для решения проблемы №2:
    • Все умеют кивать и говорить ”понятно”
    • Потом становится непонятно
    • Не все умеют спрашивать, но этому можно научиться
      • Для начала можно попробовать задавать вопросы обо всём, что непонятно
  • Проблема №3
    • На почиркушках всё красиво, а в коде не выходит
    • ”Вот, всё ж просто, делай.”
    • Рядовые разработчики оставлены один на один с трудными задачами
    • Не идёт обмен опытом
    • Ошибки, рефакторинг
  • Отступление: авиация
    • Программисты, как и пилоты, принимают много решений
    • Мозг фокусируется на решении задачи и отбрасывает ”помехи”
    Иллюстрация: http://www.airliners.net/photo/1958210/L/
  • Решение проблемы №3
    • Парное программирование
      • Звоним голосом, пишем в редакторе
      • Одновременно пишет только один
      • Тот, кто должен будет продолжать задачу дальше, пишет больше (иначе тот, кто долго не пишет, заснёт)
    • Обмен опытом происходит мгновенно
    • Посмотрел-повторил – особенность поведения homo sapiens, она зашита в мозг. Чтение книг по паттернам – нет.
  • Инструменты для ПП
    • Emacs Rudel
    • SSH + Unix Screen + любой редактор типа Emacs/Vim
    • Попробовать туннелировать окно Gedit через SSH (не делали)
    • OpenEtherPad, collabedit (есть подсветка синтаксиса)
    • Mercurial или Git
  • Проблема №4
    • Обзор кода проводится так:
      • Ведущий программист смотрит диффы (пакеты изменений) и выявляет ошибки:
        • Говнокод
        • Плохой нейминг
        • Код без комментариев
        • Копипаст
      • Насколько это эффективно?
  • Упражнение: обзор кода
  • Ответ
    • Этот код корректен (комментарии, имена переменных)
    • Он проходит статический тест pyflakes
    • Проходит тест pep8 (стандарт форматирования в Питоне)
    • Код находится не на своём месте
    • Я это заметил, когда объяснял принципы работы приложения своему коллеге
  • Решение проблемы №4
    • Тот, кто писал код знает его лучше всего
    • Во время работы он фокусируется на решении задачи, не качестве решения
    • Поэтому обзор делаем так:
      • Ведущий и рядовой программисты садятся и смотрят новый код
      • Тот, кто писал его, объясняет, что и где делается (и смотрит на свой код чужими глазами)
      • Исправления пишем сразу же на месте
  • Звонок с Кевином
    • Пора звонить
  • Системы управления версиями
    • Пара примеров работы в РСУВ
  • Обходим проблемы на главной ветке bug Рабочая ревизия
  • Совет: интеграционные ветки
    • В Mercurial мы используем интеграционные ветки
    • Большие изменения, которые затрагивают много чужого кода ведутся в своей ветке
    • Вместо вливания в основную ветку, мы сливаем две ветки, но коммитим в новую
    • Получаем то, каким был бы проект после слияния веток.
    • Если проект работает, вливаем интеграционную ветку обратно в основную
  • Merge with default Fix Merge with feature Merge with default Merge with feature-integration Work Work Work Work Интеграционная ветка Ветка feature Ветка default Ветка feature-integration
  • Проблема №5
    • Кто чем занимается? (Кому на Руси...)
    • Обычно:
      • Ведущий программирует API и архитектуру и кайфует
      • Рядовые пытаются встроить всё это в сайт и заставить работать
    • Результат:
      • Пишем на деньги инвестора свои фреймворки
      • Фреймворки не работают, потому что их автор сам не использует их в деле. Фактически он разрабатывает стороннюю библиотеку.
  • Решение проблемы №5
    • Ведущий программист
      • занимается архитектурой сервера
      • ищет инструменты для программирования (дебагеры, библиотеки)
    • Рядовые
      • Пишут крупные компоненты в паре с ведущим или друг с другом и кайфуют. (Людям инстинктивно нравится заботиться о том, что они построили сами.)
      • Несут за свои архитектурные решения ответственность, то есть исправляют баги
  • Полезная деятельность
    • Выделяйте внутренние компоненты в отдельные опенсорсные проекты
      • Очень просто делать на Mercurial Subrepo
    • Выкладывайте их на GitHub, ButBucket
    • Пусть авторами компонент будут рядовые программисты, они будут тратить и свободное время на эти проекты
  • Вариация проблемы №5
    • ”Зачем нам умный тестировщик, знающий Git/Mercurial, а тем более X, Y, Z? Он же убежит!”
    • Решение: не держите его за быдло.
    • ”Тупые” задачи решаются автоматизацией тестов (buildbot, django-coverage, selenium), пусть он пишет скрипты
  • Как быть командой
    • Регулярно проводить встречи всей команды, например, программистов.
    • На встречу выносим вопросы, касающиеся всех. Кто что сделал – обсуждаем поменьше, это не интересно.
    • Приветствуем сообщения о плохих решениях и плохом коде
    • Приветствуем обсуждение новых технологий, случайно найденных в Сети
    • Документ из встречи для архива отправляем в почтовую рассылку
  • Общие советы
    • Удалённо можно работать только небольшой командой.
    • Рабочих рук мало, поэтому минимум собственного кода. В Сети уже много готовых компонент
    • Люди работают над разными частями, чтобы избежать конфликтов правок, но помогают друг другу по запросу
  • Общие советы
    • Окружение проекта должно быть как можно более одинаковым
      • У кого система Windows, запускает VMWare
      • Buildout
        • $ python bootstrap.py [--distribute]
        • $ bin/buildout
      • Конфигурация проекта и рецепты – в buildout.cfg
      • virtualenv
    • Автоматизируйте работу
      • buildbot
  • Вёрстка задом наперёд
    • В веб-проекте мы попробовали делать вёрстку задом-наперёд
      • Делаем работающий макет на JavaScript
      • Делаем обслуживающий его серверный код
      • Делаем дизайн
      • Делаем вёрстку
    • Не проходите мимо: Object Oriented CSS (oocss.org)
      • Сокращаёт вёрстку, позволяет не верстальщикам верстать неплохие страницы
  • PivotalTracker
  • Dropbox
  • Культура работы
    • Обратите внимание на регулярные ошибки и решите, как их можно исправить автоматически, не полагаясь на ”культуру работы” (к вопросу Mercurial vs Git)
    Иллюстрация: codinghorror.com
  • Культура работы
    • Наша психика – не компьютер. Можно приблизиться к этому через повышение культуры работы, но это будет болезненно.
  • Выводы
    • Удалённая работа – это
      • обмен опытом на большие расстояния и значительное расширение кругозора
      • защитный экран для самолюбия: меньше опасность показаться глупым, задавать вопросы – поощряется.
    • В удалённой работе многие плохие привычки из офиса развалили бы работу
    • Решения этих проблем применимы и в офисе