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

1. Инструменты и методы эффективной удалённой работы Дмитрий Лебедев [email_address] obnob.com

2. Чего в этом докладе не будет

5. Как стать фрилансером

7. Как стать фрилансером

8. Как искать заказчиков и работать с ними

10. Как стать фрилансером

11. Как искать заказчиков и работать с ними

12. Как перейти с ADD* на Agile

13. * Asshole Driven Development

15. Как стать фрилансером

16. Как искать заказчиков и работать с ними

17. Как перейти с ADD* на Agile

18. Как довести проект до релиза

19. * Asshole Driven Development

20. Что в этом докладе будет

23. Расскажу про их решения:

26. Как делать работающие скетчи компонент

27. Как делать качественный обзор кода

30. Как делать работающие скетчи компонент

33. Можно следить за работой ПО круглые сутки

35. Учит терпению, самоорганизации и самостоятельности

37. Ночная работа и подъём в полдень

38. В общении с коллегами есть лаги

40. – Исправили, проверяйте

41. – Всё равно не работает

42. – А теперь?

45. – Исправили, проверяйте

46. – Всё равно не работает

48. Этот диалог шёл всю неделю, потому что две стороны находились в 12 часовых поясах, и их рабочее время не пересекалось. Проблема №1: лаги

50. Назначаем регулярные звонки в определённое время, удобное всем

53. Письма влом писать

55. Письма влом писать

56. Общение по Гугло-Толку бестолковое

58. EtherPad

59. EtherPad: подсветка

60. EtherPad: опции

61. EtherPad: история правок

63. Потом становится непонятно

66. ”Вот, всё ж просто, делай.”

67. Рядовые разработчики оставлены один на один с трудными задачами

68. Не идёт обмен опытом

69. Ошибки, рефакторинг

71. Мозг фокусируется на решении задачи и отбрасывает ”помехи” Иллюстрация: http://www.airliners.net/photo/1958210/L/

73. Одновременно пишет только один

75. Посмотрел-повторил – особенность поведения homo sapiens, она зашита в мозг. Чтение книг по паттернам – нет.

77. SSH + Unix Screen + любой редактор типа Emacs/Vim

78. Попробовать туннелировать окно Gedit через SSH (не делали)

79. OpenEtherPad, collabedit (есть подсветка синтаксиса)

80. Mercurial или Git

82. Плохой нейминг

83. Код без комментариев

85. Упражнение: обзор кода

87. Он проходит статический тест pyflakes

88. Проходит тест pep8 (стандарт форматирования в Питоне)

89. Код находится не на своём месте

90. Я это заметил, когда объяснял принципы работы приложения своему коллеге

92. Во время работы он фокусируется на решении задачи, не качестве решения

94. Тот, кто писал его, объясняет, что и где делается (и смотрит на свой код чужими глазами)

95. Исправления пишем сразу же на месте

98. Обходим проблемы на главной ветке bug Рабочая ревизия

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

101. Вместо вливания в основную ветку, мы сливаем две ветки, но коммитим в новую

102. Получаем то, каким был бы проект после слияния веток.

103. Если проект работает, вливаем интеграционную ветку обратно в основную

104. Merge with default Fix Merge with feature Merge with default Merge with feature-integration Work Work Work Work Интеграционная ветка Ветка feature Ветка default Ветка feature-integration

108. Фреймворки не работают, потому что их автор сам не использует их в деле. Фактически он разрабатывает стороннюю библиотеку.

111. Несут за свои архитектурные решения ответственность, то есть исправляют баги

113. Пусть авторами компонент будут рядовые программисты, они будут тратить и свободное время на эти проекты

115. Решение: не держите его за быдло.

116. ”Тупые” задачи решаются автоматизацией тестов (buildbot, django-coverage, selenium), пусть он пишет скрипты

118. На встречу выносим вопросы, касающиеся всех. Кто что сделал – обсуждаем поменьше, это не интересно.

119. Приветствуем сообщения о плохих решениях и плохом коде

120. Приветствуем обсуждение новых технологий, случайно найденных в Сети

121. Документ из встречи для архива отправляем в почтовую рассылку

123. Рабочих рук мало, поэтому минимум собственного кода. В Сети уже много готовых компонент

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

130. Делаем обслуживающий его серверный код

131. Делаем дизайн

133. PivotalTracker

134. Dropbox

139. Решения этих проблем применимы и в офисе