Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов. Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня. Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку. Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине. Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат! * оценим перспективы унификации и рассмотрим альтернативы; * рассмотрим типовые препятствия, и откуда они берутся; * поговорим о сути изменений, и какие они бывают; * познакомимся с реальностью на основе моего личного опыта; * обсудим, что есть "похожесть" проектов и что с этим делать.

1. Кластер или
конгломерат
Как поддерживать и развивать пачку "похожих" проектов.

2. Стас Михальский
Mail.Ru (технический директор медиапроектов)
Новости Mail.Ru, Леди Mail.Ru, Авто Mail.Ru, Здоровье Mail.Ru, Дети
Mail.Ru, Hi-Tech Mail.Ru
Rambler (руководитель группы разработки)
news.rambler.ru, sport.rambler.ru
РБК (perl-программист)
news.rbc.ru, utro.ru

3. Контентные/информационные сайты

9. Почти одно и то же
• Страница списка новостей
• Страница новости
• Блок «читайте также»
• Блок «топ-новости»
• Комментарии
• Дополнительные информационные разделы
• Сервис консультаций
• Интерфейс управления содержанием сайта (админка)

10. Почти одно и то же
блоки, блоки…
материалы
листинги
блоки, блоки…
материалы
листинги
блоки, блоки…
материалы
листинги

11. Почему не так?
блоки, блоки…
материалы
листинги

12. Цель доклада
• Обсудить перспективы тотальной унификации
• Рассмотреть альтернативный сценарий

14. Правильное решение очевидно
• Унифицировать
• Перевести на одну платформу
• Развивать и поддерживать единое техническое решение

15. Перспективы завораживают
• «семерых одним ударом»
• best practices: сразу на всех
• «служба единого окна»
• быстрая сборка
• «свободная консоль!»

16. (англ. cluster — скопление, кисть, рой) —
объединение нескольких однородных элементов,
которое может рассматриваться как самостоятельная
единица, обладающая определёнными свойствами

17. Сейчас быстро перепишем методы!

18. Попытка #раз: было не совсем просто
• Один результат – разные процессы
• Одинаковая функциональность – разная реализация
• Одно отображение – разная логика
• Унификации логики – решение менеджмента
• Сколько менеджеров – столько мнений

19. Первые выводы
• Наскоком не вышло – работы много!
• Нужны руки – надо вовлекать разработчиков
• Нужны согласования – надо вовлекать менеджмент
• Надо делать отдельное решение

20. Соберем требования и подумаем…

21. Попытка #2: стало сложнее
• Везде всё «немного по-разному»
• Приходится отвлекаться на основную работу (блин)
• Когда возвращаешься к «нетленке», она уже почти истлела

22. Новые выводы
• Писать в стол бессмысленно
• Работа без результата демотивирует
• Нужно физическое свидетельство правильности пути
• Стоит умерить амбиции и начать с чего-то попроще

23. Тренируемся на кошках

24. Концепт «муравейник»
• Одна инкарнация framework’а на всех
• Диспетчер для определения шаблонов
• Диспетчер для доступа к БД
• Уровень абстракции plug-in

25. Попытка #3: «победа сферического
коня»
• На упрощенной аналогии идея реализуема!
• Основные предположения подтвердились
• По крайней мере, в начале…

26. Больше мудрости для бога мудрости
• В отрыве от продуктовых задач работать не получается
• Ждем повода начать делать «Как надо!»

27. Вместе с редизайном строим
framework

28. Попытка #X
• Сроки сжимаются и внутрь попадает «мусор»
• система разрастается из-за альтернативных решений
• Не хватает времени «делать правильно»

29. Иллюзия унификации

30. Промежуточные итоги

32. Промежуточные итоги
• Общее решение требует постоянной доработки и актуализации
• Главный вызов - не проектирование, а организация
• Больше изменений – больше работы по актуализации
• Зависимость нелинейна!

33. мы просто недостаточно быстро
бежим

34. То, что нас не убивает, делает нас сильнее
Бежим дальше!

35. Ошибка в определении причины
неуспеха

36. Ошибочные предположения
• Высокое сходство – залог архитектурной унификации

37. Ошибка похожести
• Один результат – разные процессы
• Одинаковая функциональность – разная реализация
• Одно отображение – разная логика

38. Ошибочные предположения
• Высокое сходство – залог архитектурной унификации
• Продукт не меняется

39. Это не форсмажор!

40. Это реальность!

41. Механика: Продукт и изменения

42. Механика: Продукт как слоеный пирог
• Дизайн
• Данные (результаты выборок, сортировки, группировки и т.п.)
• Методы (код)
• Framework
• Базовое ПО (БД, web-сервер и т.д.)
• OS, FS …

43. Механика: реактивные изменения
• Масштаб
• Вероятность возникновения

44. Механика: проактивные изменения
• Масштаб
• Вероятность реализации

45. Проактивные vs Реактивные

46. Проактивные vs Реактивные
• Масштаб реактивного изменения – степень угрозы
• Масштаб проактивного изменения – размер потерь

47. Поможем «нашим»?
• Диктатура технарей
• Синдром горничной С. Лукьяненко
• Продукт или идеальная система?

49. Принять и смириться

50. Чем опасен недостроенный кластер?

51. Теория разбитых окон

52. Поэтому принять и смириться!

53. Конгломерат (лат. conglomeratus — скученный,
уплотнённый) — соединение чего-либо
разнородного, беспорядочная смесь, ассорти

54. «Я не строю кластер, значит
у меня уже конгломерат?»

55. Осознать и действовать 

57. Все не так плохо ;)
• Появилось время
• Появилась возможность проверять
• Появилась возможность сравнивать
• Появилась возможность выбирать
• Появилась возможность наблюдать

58. Эволюционное развитие

59. А что же с изменениями?

60. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения

61. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения
Данные Очень высокая Очень низкая

62. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения
Данные Очень высокая Очень низкая
Mетоды Высокая Низкая

63. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения
Данные Очень высокая Очень низкая
Mетоды Высокая Низкая
Framework Средняя Средняя

64. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения
Данные Очень высокая Очень низкая
Mетоды Высокая Низкая
Framework Средняя Средняя
Базовое ПО Низкая Высокая

65. Играем там, где можно выиграть
Уровень
Вероятность появления
реактивного изменения
Вероятность реализации
проактивного изменения
Данные Очень высокая Очень низкая
Mетоды Высокая Низкая
Framework Средняя Средняя
Базовое ПО Низкая Высокая
OS, FS Очень низкая Очень высокая

66. Проактивные глубинные изменения

67. Оседлать волну реактивных
изменений

68. «Экспериментально-эпидемическое»
внедрение изменений
• Первый раз – это интересно
• Охват <50% – это модно и актуально
• Охват >50% – по-другому неприлично
• А если не распространяется? Откажитесь или мужайтесь)

69. Унификация возможна
• На уровне стека технологий
• На уровне функциональности продукта

70. Итоги и выводы

72. Реальность кластера
• Высокая чувствительность к изменениям
• Шаткость достигаемой унификации
• Обветшание активов
• Демотивация из-за отсутствия видимых успехов

73. Перспективы конгломерата
• Эволюционный выбор
• Унификация функциональности через лучшие практики
• Высокий уровень качества как ключевая цель

74. Что делать?
• Развивать стек технологий
• Унифицировать стек технологий
• Поддерживать уровень качества

75. Как делать?
• Выбирать и оставлять лучшее
• Глобальные свершения на нижних уровнях
• Точечные изменения на верхних уровнях
• Глобальные свершения на верхних уровнях («под шумок»)

76. Спасибо за внимание!
Стаc Михальский
mikhalskiy@mail.ru