Вот тут я примерно минуты с 7 по 16 в общих чертах рассказываю, как работает в фейсбуке. Очень много подробностей там опущено, т.к. тема доклада не совсем об этом, но все же должно дать общее представление.
Еще вот тут общее описание, как сайт фейсбука релизится.
> Фиксим в мастере, быстро катим по пути зацепив все что туда намерджили и молимся. Заодно код ревью игнорируется.
В целом, чтоб релиз с критичной ошибкой дошел до 100% публики, должно много плохих событий наложиться. Понятие «зацепили все, что намержили» не очень тут применимо, особенно для сайта, где нет вообще бранчей (в случае релиза мобильных приложений несколько сложнее). Да, вместе с хотфиксом пойдет новая порция изменений, но она бы и без хотфикса прошла бы, раз релиз автоматический.
Очень интересно и странно, по состоянию на май 2016 ничего того, что можно было назвать системой перформанс ревью, в ABBYY не было, по крайней мере в тех департаментах, где я работал. (То, что было, было совсем не перформанс ревью и решало другие задачи).
А вот в компании, где я работаю сейчас (Facebook) система перформанс ревью действительно есть, и она действительно очень похожа на то, что описано в статье.
Вот как раз сравнивая два мира — с и без перформанс ревью, я могу сказать, что это действительно две очень большие разницы. Совершенно разные ритмы и стили работы, которые оказывают непосредственное влияние на рабочую культуру и отношение к работе. (Я не говорю «лучше» или «хуже», я лишь говорю «вообще по-другому»).
Конечно, за O(N) все равно не получится из-за того, что большие числа все равно надо умножать, а это делается, хоть и не квадратично, но и не линейно. Если использовать умножения Шёнхаге — Штрассена для быстрого умножения чисел, то получим асимптотику чуть похуже O(N*log(n))
Почему возвращает? Прямая итеративная реализация алгоритма поиска чисел Фибоначчи работает за O(N^2). Поэтому, если надо вывести в файл десятимиллионное число Фибоначчи, то обычная реализация будет работать на порядки дольше предложенной в решении. Поэтому алгоритм имеет смысл.
Мы на самом деле совещались, как сформулировать задачку одновременно корректно и интригующе, и пришли к формулировке в виде указания числа операций над числами, а не асимптотики. Ибо, если бы попросили найти за O(N), все бы удивились.
Вы не совсем верно поняли. Там, где можно обойтись без эвристик, следует обходиться без них. Например, для анализа объектов на изображении мы используем основанные на машинном обучении классификаторы. Но для повышения качества работы классификатора изображение требуется предобработать, и делается это большей частью эвристическими способами.
К тому же обилие эвристик не означает, что программа представляет собой аморфный кусок кода. Система должна иметь четкую архитектуру; разработка должна вестись в рамках какой-то общей стратегии; перебор на верхнем уровне должен быть грамотно организован и так далее. Просто статья посвящена именно эвристикам.
Термин «грязное» в рамках этой статьи обозначает эвристическое. Грязное не в том смысле, что код неаккуратно пишут, или что классы не выделяют, или что goto используют, и вообще не как антоним чистому коду. Имелось в виду, что эвристики сами по себе, безотносительно воли разработчика, создают определенные сложности с поддержкой и развитием программы.
По поводу ИИ — это настолько широкое и расплывчатое понятие, что каждый волен сам для себя решать, считать ли обсуждаемый вид деятельности имеющим отношение к ИИ или не считать.
Что касается качества кода, то я не писал, что хорошее оформление кода для эвристических алгоритмов не нужно; более того, я утверждал обратное.
По поводу «экспериментального кодирования» — в статье речь не об экспериментах, а о создании промышленного образца, решающего задачу. Соответственно, код предполагается довольно долгоживущим.
На самом деле я слукавил: дело не в стеснении, а в том, что как раз не нашлось простого и поучительного примера.
Было неполное понимание «духа» системы, поэтому поначалу, пока не вошел в ритм, многое делал не совсем в тему. Как минимум один раз просто перепутал два понятия (класса), использовав один вместо другого. Проблема эвристической системы в том, что, вместо того чтобы сразу настучать по пальцам за косяк, она иногда проглатывает обиду. И все работает, причем по метрикам даже лучше, чем было.
Если же говорить в целом о периоде адаптации, то лично моя основная проблема была в склонности к переусложнениям не в тех местах, где это действительно надо. В итоге получается сложный и правильный код, решающий подзадачу, но затраченные усилия того не стоили. Потому что, например, для требуемого качества надо было всего лишь грубо решить один важный частный случай. А сэкономленное время надо было бы направить на по-настоящему узкое место. Своего рода преждевременная оптимизация.
Еще вот тут общее описание, как сайт фейсбука релизится.
> Фиксим в мастере, быстро катим по пути зацепив все что туда намерджили и молимся. Заодно код ревью игнорируется.
В целом, чтоб релиз с критичной ошибкой дошел до 100% публики, должно много плохих событий наложиться. Понятие «зацепили все, что намержили» не очень тут применимо, особенно для сайта, где нет вообще бранчей (в случае релиза мобильных приложений несколько сложнее). Да, вместе с хотфиксом пойдет новая порция изменений, но она бы и без хотфикса прошла бы, раз релиз автоматический.
Возможно: напр. Google и Facebook сидят на trunk-driven development, хот-фиксы вполне себе делаются.
Очень интересно и странно, по состоянию на май 2016 ничего того, что можно было назвать системой перформанс ревью, в ABBYY не было, по крайней мере в тех департаментах, где я работал. (То, что было, было совсем не перформанс ревью и решало другие задачи).
А вот в компании, где я работаю сейчас (Facebook) система перформанс ревью действительно есть, и она действительно очень похожа на то, что описано в статье.
Вот как раз сравнивая два мира — с и без перформанс ревью, я могу сказать, что это действительно две очень большие разницы. Совершенно разные ритмы и стили работы, которые оказывают непосредственное влияние на рабочую культуру и отношение к работе. (Я не говорю «лучше» или «хуже», я лишь говорю «вообще по-другому»).
Мы на самом деле совещались, как сформулировать задачку одновременно корректно и интригующе, и пришли к формулировке в виде указания числа операций над числами, а не асимптотики. Ибо, если бы попросили найти за O(N), все бы удивились.
Вы не совсем верно поняли. Там, где можно обойтись без эвристик, следует обходиться без них. Например, для анализа объектов на изображении мы используем основанные на машинном обучении классификаторы. Но для повышения качества работы классификатора изображение требуется предобработать, и делается это большей частью эвристическими способами.
К тому же обилие эвристик не означает, что программа представляет собой аморфный кусок кода. Система должна иметь четкую архитектуру; разработка должна вестись в рамках какой-то общей стратегии; перебор на верхнем уровне должен быть грамотно организован и так далее. Просто статья посвящена именно эвристикам.
Что касается качества кода, то я не писал, что хорошее оформление кода для эвристических алгоритмов не нужно; более того, я утверждал обратное.
По поводу «экспериментального кодирования» — в статье речь не об экспериментах, а о создании промышленного образца, решающего задачу. Соответственно, код предполагается довольно долгоживущим.
Было неполное понимание «духа» системы, поэтому поначалу, пока не вошел в ритм, многое делал не совсем в тему. Как минимум один раз просто перепутал два понятия (класса), использовав один вместо другого. Проблема эвристической системы в том, что, вместо того чтобы сразу настучать по пальцам за косяк, она иногда проглатывает обиду. И все работает, причем по метрикам даже лучше, чем было.
Если же говорить в целом о периоде адаптации, то лично моя основная проблема была в склонности к переусложнениям не в тех местах, где это действительно надо. В итоге получается сложный и правильный код, решающий подзадачу, но затраченные усилия того не стоили. Потому что, например, для требуемого качества надо было всего лишь грубо решить один важный частный случай. А сэкономленное время надо было бы направить на по-настоящему узкое место. Своего рода преждевременная оптимизация.