Бизнес нанимает программиста, чтобы заработать денег. Ему не то чтобы сильно важно, что там под капотом. Поэтому когда вы придете к нему и скажете «вы хотели качества», он вас не поймет, и вы поругаетесь. Единственная причина рефакторить — сделать то же самое дешевле, чем это было бы без рефакторинга. Иначе рефакторинг бесполезен.

Я думаю, что в этом вся и проблема, что многие думают «оптимизация бизнеса — вообще не его головная боль».

Я считаю, что подход «девелоперы беспокоятся про оптимизацию бизнеса» может применяться на абсолютно любого размера проектах, начиная от ситуации, где проект делает 1 девелопер, и для этого не должно быть никаких требований по наличию или отсутствию каких-либо ролей. У нас только так не принято пока что, к сожалению. Вот и страдаем.

Немного оффтоп.

Я абслютно согласен: рефакторинг — не дело менеджеров или бизнеса. Команда сама должна решать, когда и сколько делать рефакторинг. Единственный критерий тут, и единственная причина делать рефакторинг: как быстрее и дешевле (при заданном бизнесом уровне надежности) сделать для бизнеса то, что ему надо. И тут уже это могут знать только технические специалисты.

Другое дело, что часто менеджемент не доверяет техническим специалистам в этом вопросе. И, кстати, правильно делает =). Потому что очень часто программисты подменяют «быстрее и дешевле» на «нам интереснее». И это часто можно видеть не только от новичков, но и от очень серьезных девелоперов. Когда за счет бизнеса идет обучение новым технологиям или просто развлечение со всякими крутыми штуками.

Отсюда у меня такой вывод: в извечной войне «менеджеры против рефакторинга» программисты должны для начала учиться работать с менеджементом и с бизнесом по одну сторону баррикад. Постепенно работать над этим доверием, когда если программист говорит «нам надо делать А», это значит, что программист совершенно уверен, что для бизнеса «А» будет полезно, а не это просто его прихоть изучить технологию «А».

Вы описали очень хороший способ перехода с одного фреймворка на другой. Но по моему опыту (я писал раньше на Kohana, и пишу теперь на Symfony), степень говнокода — это особенность системы, а не фреймворка, на которой все написано. Если у вас были тяжелые и непонятные контроллеры в Kohana, вас будут ждать такие же в Symfony, и поддерживать это дело на Symfony будет не обязательно проще (а чаще — сложнее, т.к. вы начнете тратить уйму времени на борьбу с фреймворком там, где раньше вы просто делали class Kohana extends Kohana_Core и вворачивали любой костыль). Я бы посоветовал вам бросить ресурсы не на переход от одного фреймворка на другой, а на рефакторинг кода в рамках одного фреймворка. Возможно, имеет смысл начать юзать высококачественные компоненты (Doctrine, symfony/form) в вашем проекте на Kohana. Или начать выносить бизнес-логику из контроллеров в отдельный слой. И это может дать намного больше профита с меньшими затратами, чем переписывать все на другом фреймворке.

И сильно, бывает, отличается конверсия? Как это замерялось? Вы брали смотрели конверсию на старом сайте и сравнивали ее с конверсией после редизайна?

А часто бывает так, что приходит клиент и хочет ну совершенно не то что ему надо, и никак не переубедить? Скажем, хочет, чтобы нарисовали дизайн, хотя можно сделать в 100 раз красивее и в 10 раз дешевле на готовом бесплатном или купленном за 15$.

Я недавно делал проект достаточно большой и сложный, там прикидывали на дизайн надо было тыщ 50-100, наверное, если делать дизайнером и потом верстать это все. В итоге мы купили за 15$ на wrapbootstrap тему и еще за 20$ сделали логотипчик. И даже без помощи верстальщика все сделали. И получилось очень норм в итоге. Есть похожие примеры у вас из вашей практики?

Возможно, вопрос не совсем в тему статьи, но все же очень связан с ней. И вы наверняка имеете все знания и данные, чтобы прокомментировать его. Когда я был школьником и фрилансил, я делал огромное кол-во недорогих сайтов на собственном велосипеде. Пусть это были не сайты на вордпрессе, но они были достаточно дешевы для клиента и делались достаточно быстро. Так вот, вспоминая то время, я начинаю понимать вот что: пользы от этих сайтов в большинстве своем было ровно 0. Как это происходило: приходит клиент в «студию» с такой мыслью: «мне нужен сайт». Как этот сайт поможет бизнесу — хз, но он должен быть. Менеджер тоже не заинтересован помочь бизнесу, его задача — продать сайт. Потом они утверждают дизайн и неделю играются со шрифтами. Потом я программирую это все. В итоге на свет рождается очередной никому не нужный сайт, пусть и не очень дорого. И мне теперь очень печально от такого, потому что все (и мы в том числе в то время) из-за конфликта интересов (бизнесу не нужен сайт, но нам нужно его продать) продавали сайты, а не помогали бизнесу.

В связи с этим такой вопрос. Есть ли у вас реальные примеры того, как дешевые быстро делающиеся сайты на вордпресс помогают бизнесу экономить деньги на разработке действительно нужных им вещей (а не очередного никому не нужного сайта-визитки)? Задумываетесь ли вы над этими вопросами, когда продаете очередному клиенту очередной сайт?

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

Поэтому gmail не подгружает автоматически картинки в письмах.

Мы, видимо, говорим о разных вещах. Вы говорите о том, как готовить данные для тестов. А я говорю о том, как хранить данные внутри тестов. Так вот если весь сценарий проходит внутри одного процесса, то можно юзать InMemoryRepository. Если нет (UI тесты, например, где надо хранить состояние между запросами), то InMemoryRepository уже не подойдет, и надо юзать что-то, что кладет коллекции энтитей в файлы. Например что-то на основе репозитория по ссылке в статье.

Как готовить данные для теста это отдельный вопрос.

Не понял, при чем тут дата-фэктори? Мы заменяем доктрин репозиторий на репозиторий, который кладет сериализованный массив энтити в файл вместо БД. Базовый класс для такого репозитория можно взять на гитхабе по ссылке в статье, кстати — оно для этого и задумывалось. Про поддержку тестов, смотря с чем сравнивать. Если сравнивать с подходом того же everzt-а Modelling By Example, то использование data-factory на его фоне выглядит так себе.

Хорошо оно ли для функциональных тестов, вопрос, конечно, спорный. Я считаю, что можно написать кучу интеграционных тестов чисто на доктрин-репозитории, а UI тесты уже с моками делать. Сам пока не пробовал такой подход.

Захотел откомментить, что интерфейс должен быть на уровне домена, а реализация на уровне приложения, через минуту об этом прочитал. Захотел добавить ссылку на либу пользователя everzet, увидел через минуту. =) Прям согласен с каждым словом в статье!

Добавлю от себя: кто-то (возможно everzet, но я не уверен) предложил очень интересный способ ускорения даже UI тестов. Нужно заменить Doctrine репозитории на репозитории на обычных файлах на время выполнения UI тестов. Т.о. у нас сохраняется persistence, но убирается лишняя нагрузка на парсинг DQL, гидрацию и пр, а так же убирается необходимость чистить БД перед каждым сценарием.

Утянул ваш конфиг себе. Надеюсь мои проблемы с NFS решатся вашими mount_options =).

спасибо! =)

Мы работали на одном проекте по samba с гостя, очень успешно. Только надо помнить, что гит должен работать на той же системе, на которой лежат файлы. Т.е. в данном случае — на госте через ssh. Все девелоперы (и верстальщики) юзали консольный гит по ssh и не парились. Но у такого сетапа есть два минуса: 1) vagrant up надо делать не в рабочей копии проекта, а в другом месте, а потом уже рабочую копию вручную маунтить на хост, что не очень удобно, 2) IDE не то чтобы сильно быстро индексирует файлы, которые доступны через шару (не очень критично на самом деле для нас оказалось, приходилось подождать изредка 30 сек, нуок).
Теперь я юзаю везде NFS (файлы на хосте), на OSX без вопросов завелся, даже на винде. Но тоже есть проблемы вечно какие-то, то файл не сразу увидит, то время изменения неверное видно, хз. Надо будет попробовать ваш способ.

Приводить такую настройку как типовой конфиг для человека, которому не хочется самому разбираться в тонкостях, жестого =)

synchronous_commit = off

разве не отключит гарантию сохранности данных?

Предположим у нас миллион записей в таблице, a = num / 1000, b = num % 1000. Тогда запрос WHERE a = X AND b = Y в случае составного индекса просто найдет одно число в индексе и вернет запись. Тот же запрос в случае двух индексов выберет тысячу записей для первого индекса, отсортирует их по адресу хранения, выберет тысячу записей из второго индекса, отсортирует их…

Моя логика подсказывает, что найти записи в дереве в случае составного индекса как ни крути должно быть намного проще и быстрее, чем пройтись по двум индексам, отсортировать в обоих (добавлено: найденные) данные по физическом расположению, сделать битовые операции. Другое дело, в каком кол-ве случаев разница действительно важна.

Разницы не может не быть принципиально. Для выборки используются разные алгоритмы, а значит сложность у них все-равно разная будет. Другое дело, что на очень большом кол-ве случаев в Postgres не нужен составной ключ, а вполне можно юзать два раздельных (по крайней мере у них так написано в книжке high performance Postgres). Но поиск по двум раздельным индексам в любом случае, насколько я понимаю, будет хуже поиска по составному индексу.