Я пришёл руководить разработкой Здоровья в момент, когда сервис был ещё страничкой с брифом на внутренней вики. В этом посте я хочу поделиться подходами к разработке, которые сформировались у нас за два с лишним года работы над сервисом.
Disclaimer:
У стартапа есть свои особенности. Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью. При этом мы должны держать качество продукта на таком уровне, чтобы за него было не стыдно. [Место для флейма про отсутствующую у некоторых совесть]. Замечу, что высокая скорость доставки фич подразумевает в том числе поддержание достаточно высокого качества кода. Иначе продукт рано или поздно захлёбывается в багах.
Все пункты ниже так или иначе выстраданы, практически на каждый есть кейс из реальной жизни.
Качество кода и архитектура
- Мы минимизируем время доведения фичи до продакшна при сохранении приемлемого качества.
- Любая задача предполагает два решения: быстрое и правильное. Для любой фичи мы продумываем оба варианта так, чтобы была возможность апгрейдить быстрое решение до правильного, делая минимум ненужной работы «на выброс». Выкатив быстрое решение, некоторое время смотрим и понимаем, нужно ли правильное.
- Критично. Зачастую, разница по времени между тем, чтобы «решить первым попавшимся способом, забив костыль» и «решить красиво и аккуратно» – десять минут. Поэтому мы всегда думаем, перед тем как писать.
- Если есть выбор между минорной оптимизацией и читабельностью / архитектурой – выбираем второе. Две миллисекунды ничего не решат, а с этим кодом нам ещё жить и поддерживать.
- Думаем о будущем. Ближайшее будущее при этом важнее отдалённых перспектив. Если решение можно сделать сложным (читай «долгим») и гибким, либо простым, но прибитым гвоздями, стоит прибивать гвоздями, а затем рефакторить по необходимости. Лучше потратить день на простое решение сейчас и месяц на возможный рефакторинг через год, чем две недели сейчас (да, именно это и называется техдолг). Важно, что такие решения стоит обсуждать с командой. В одиночку можно неверно оценить вероятность расширения этой фичи в ближайшее время.
Новые технологии
Новые технологии – это круто, давайте их использовать. Но наш продукт не испытательный полигон. Если хочется применить новый алгоритм или технологию, это можно сделать при выполнении следующих условий:
- технология несёт ощутимый профит (оптимизация, качество архитектуры, кода, масштабируемость, и всё это действительно должно быть нужно, а не притянуто за уши);
технология нормально вписывается в текущий стек (не нужно писать часть сервисов на Go, если весь код написан на Python); - технология не ухудшает качество архитектуры и читабельность кода (это субъективно, поэтому обсуждается с командой);
- времени на реализацию и поддержку новой технологии (включая поиск новых разработчиков) уходит не больше, чем на работу в рамках текущей технологии. Опять же, всё зависит от ожидаемого профита и обсуждается с командой;
- любая новая технология обсуждается с командой: если она классная, то правильно её использовать всем, если не очень, то групповое обсуждение позволяет быстрее это понять;
не надо самостоятельно реализовывать алгоритмы, уже реализованные в готовых библиотеках (кроме случая, когда это маленький кусок огромного фреймворка и не имеет смысла ради одного решения тащить его весь). - если вы сделали что-то крутое и удобное – поделитесь решением с командой (а лучше – внутри всего Яндекса).
Коммуникация
- Обсуждаем решение вместе. Чем сложнее и критичнее функциональность, тем важнее такое обсуждение. Если решение кому-то не нравится – убеждаем друг друга до тех пор, пока не появится согласие. Или время обсуждения не превысит разумные сроки.
- Если договориться не удалось – последнее слово за руководителем. У нас разумная демократия, а не польский сейм XVII века. При этом руководитель получает большой минус в карму и должен испытывать моральные страдания. И уж точно не использовать это право часто.
- После того, как определились – делаем так, как договорились. Даже если был категорически не согласен. Никаких «Я лучше всех этих продуктологов знаю, как делать сервис, поэтому сделаю то, что считаю нужным»
- «Не в проде – не сделано». Каждый сам следит за своими задачами. Если фича готова к тестированию, нужно позаботиться, чтобы она выкатилась в тестинг. Если она готова к релизу – нужно позаботиться о том, чтобы она попала в прод как можно раньше. Люди, ответственные за формирование релиза, не всегда помнят про каждую фичу. Не стесняемся напоминать про неё. [Место для флейма про распределение ответственности между ролями в команде.].
- Включать голову нужно обязательно. Если задача кажется странной, непонятной или слишком долгой, то об этом надо чётко и громко говорить ответственному менеджеру. И делать это до тех пор, пока не сложится ясного понимания, почему всё должно быть именно так. Бывает, что правильные вопросы, заданные в нужный момент, экономят недели разработки.
Управление временем
- Если задача не укладывается в разумные сроки, об этом надо громко говорить. Не стоит сидеть и несколько месяцев пилить задачу с оценкой в три дня. Если она сильно затягивается, значит что-то идёт не так. Возможно, есть недопонимание в постановке или мы недооценили объём работы. В любом случае такие задачи надо повторно обсуждать (и в результате иногда откладывать или даже закапывать).
- Появившиеся проблемы стоит решать самостоятельно. Но если понятно, что процесс затягивается, обязательно рассказывать о них и просить помощи у коллег. Залипать на несколько дней в состоянии «я должен сделать всё сам и не отвлекать товарищей» – это очень плохо.
- Никто не смотрит, во сколько каждый из нас приходит и уходит до тех пор, пока мы всё успеваем, а наш режим не начинает мешать работе команды. Но сидеть ночами только из-за того, что не успеваете что-то сделать, не нужно. Если это превращается в привычку, значит проблема более глубокая – в планировании, переоценке собственных возможностей и т.д. Пока разработчик овертаймит по ночам (и в результате всё успевает), шансы на то, что эту проблему кто-то увидит и решит, сильно снижаются.
- Бывает, что нам нужно обязательно запустить важную фичу к условленной дате (или просто как можно скорее). В этом случае мы выходим работать в овертайм. При этом руководитель получает большой минус в карму и должен испытывать моральне страдания. И уж точно не использовать эту возможность часто. Такие овертаймы компенсируются. [Место для флейма про овертаймы и компенсации].
Смертные грехи
Это отдельный раздел. Здесь я постарался перечислить то, что считаю неправильным и вредным при работе в команде. Каждый из пунктов имеет свой вес. Некоторые говорят об очень больших проблемах, другие не так критичны. Итак, чего стоит избегать всеми силами:
- Работать, не включая голову: «мне сказали сделать – я сделал». Каждый член команды должен понимать суть фичи, которую он делает и её влияние на продукт.
- Бросать не выкаченные в прод фичи со словами «я всё сделал». То, что мы делаем, должно работать в продакшне. Пока фича не в проде, она не готова.
- Договориться делать одним способом, а потом тихо сделать по-своему. Выше уже было про «я лучше всех знаю, что лучше». Но лишний раз напомнить о том, что это плохо, не помешает.
- Затягивать важные фичи, закапываясь в обсуждении редких и нереальных, но потенциально возможных проблем. Если за разумное время не удаётся придумать, как обойти минорную и редко воспроизводимую проблему – мы просто договариваемся, как с ней жить.
- Не озвучивать вовремя возникшие проблемы, пытаясь решить всё самостоятельно (обычно ночами). Такой героизм ведёт лишь к провалам сроков, усталости и чувству недооценённости: «я тут подвиги совершаю, а меня ещё и критикуют за медленную работу!»
- Болезненно реагировать на критику кода и уходить в выяснение отношений. Даже если коллега говорит, что код копролит так себе («а давайте всё перепишем!»), отнеситесь к этому с пониманием и обсудите, почему он так считает. Для вас лично это не менее полезно, чем для сервиса в целом.
- Переходить на личности. Критикуя код или решение, мы критикуем только код или решение, но ни в коем случае не того, кто его написал или предложил. С учётом предыдущего пункта не стоит бояться критиковать. Лучше разумное время поспорить с коллегами, чем отправить в прод неудачное решение.
Итого
Здесь можно написать ещё о миллионе вещей. Но чем короче пост, тем проще его дочитать до конца, а я очень на это надеюсь. И да, я не воспринимаю критику болезненно (с условием, что вы не переходите на личности ;). Так что давайте обсуждать!
Комментарии (72)
KristinaMyLife
08.10.2018 10:27Спасибо, интересно и во многом совпадает с моим опытом работы в команде. позабавил пункт из смертных грехов про «не закапываемся в очень редкие кейсы» по моим наблюдениям такое поведение больше свойство личности и иногда полезное, а иногда вредное и тормозящее работу. Как это лечите в команде? или озвученной договоренности достаточно?
Tomcat Автор
08.10.2018 11:07Спасибо! Если видим такой потенциально редкий, но сложный в обработке кейс, кто-то из команды обычно задаёт вопрос, насколько он реален и масштабен. После этого обсуждаем минут 10-15 вместе с продуктологами. Если поймём, что достаточно редкий — просто оставляем в виде техдолга. Примерно как управление рисками.
Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
RUQ
08.10.2018 11:37Чёрт его знает. Со многим я не согласен.
Абаз про «Не в проде – не сделано»
Мне кажется, это ну, дорого что ли нагружать разработчика вот такой, по сути бестолковой работой, заставлять переключаться от основной работы. Для это кажется есть CI. Мне больше импонирует ситуация когда работа разработчика заканчивает при переводе задачи в тестирование.
Да и к другим пунктам, тоже вопросы, естественно это субъективное мнение.Tomcat Автор
08.10.2018 11:49+1Насчёт прода — это ИМХО, одно из самого важного.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…
Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)RUQ
08.10.2018 12:30Ну, это же простая математика. Есть ограниченное количество времени. За это время программист может решить две задачи и отправить в тестирование, или одну но дотащить до прода. Кстати, про здоровье, мне кажется, что решить две задачи для здоровья полезнее, чем «переключения» на различные этапы по пути на прод.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу.
Всё это да. И суть даже не только в том чтобы дотащить до прода, но и думать о том, что это решение действительно решит задачу человека. Но, я больше о другом, об организации работы.
lexlocker
08.10.2018 13:18но и думать о том, что это решение действительно решит задачу человека
— пока это не на тесте, мы об этом не узнаем никак… Т.е. это только гипотеза изначально, и 9 из 10 гипотез проваливаются, но ценность десятой покрывает все временные и ресурсные затраты.
justboris
08.10.2018 16:12Это только если тестирование занимает меньше времени, чем разработка.
А в больших проектах обычно тестирование как раз самая долгая часть. В чем смысл стараться клепать как можно больше задач, если узкое место – это выкладка и тестирование?lexlocker
09.10.2018 10:09Не обязательно. Проверка гипотезы не подразумевает большого тестирования, тем более регресса (хотя все зависит от специфики теста).
Я так думаю, что речь идет о примерно такой схеме — одновременно проверяются, например, 10 гипотез (каждая по сути делается как MVP), и в разработке 1-2 фичи, которые проверены тестами.
В любом случае я согласен с тем, что тестирование всегда будет узким местом. У нас в компании я стремлюсь к соотношению 1 к 1, но пока даже 2 тестировщика на 3 разработчика не всегда получается…
koyard
09.10.2018 11:29Ваш продукт — это система, которая позволяет вам зарабатывать деньги. В навешивании на разработчика дополнительных обязанностей ничего плохого нет, это выгодно. Не понимаю, зачем прятать реальность за красивыми словами.
OlegKrasikov
08.10.2018 13:18Разработчик решает проблему, а не пишет код. «Не в проде — не сделано» == «Проблема не решена»
Femistoklov
09.10.2018 08:43Мне кажется, это ну, дорого что ли нагружать разработчика вот такой, по сути бестолковой работой, заставлять переключаться от основной работы.
Это может быть не только дорого, но и неэффективно. Подозреваю, что имеется в виду чисто админская (devops?) работа типа «подключиться к проду, развернуть там всё, настроить, проверить, пошаманить в случае необходимости». Смешение обязанностей, ничего нового. Из той же оперы: ПМ может не быть, разработчики взаимодействуют напрямую с заказчиком. Где-то нормально заходит, где-то нет — от людей зависит, что логично.
erlyvideo
09.10.2018 09:37> дорого что ли нагружать разработчика вот такой, по сути бестолковой работой,
на практике при выходе на прод может выясниться, что принятые девелопером идеи и концепции были неправильны и ошибочны.
Именно поэтому стоит это тоже вешать на девелопера.
Hardcoin
09.10.2018 09:50+1работа разработчика заканчивает при переводе задачи в тестирование
С моей стороны пули вылетели, проблема на вашей стороне, ага.
nluparev
08.10.2018 12:14+1«Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью»
а как вы проводите эксперименты и как понять какой был успешный а какой нет?Tomcat Автор
08.10.2018 23:07Опять же с дисклеймером, что это всё только про Здоровье.
Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.
Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.
Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.
Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.
Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.nluparev
09.10.2018 09:02Спасибо. В целом картину понял. Возник вопрос а как формировать метрики? Что считать и какими инструментами пользоваться? Можете кидать ссылок на ресурсы, буду очень благодарен
guility
09.10.2018 11:30Есть давным-давно сформулированный закон научности:
Если гипотеза не может быть опровергнута в рамках эксперимента(наблюдения) — она не научна.
Так называемый принцип фальсифицируемости.
Я не работаю в Яндекс.Здоровье, но как понять успешность или безуспешность эксперимента должно быть сформулировано на этапе его постановки.
Например, «Если подбросив любой объект(и не воздействовать на него другими силами) в воздух на Земле — объект упадёт, то на Земле действует сила притяжения, если не упадёт — не действует».
В такой формулировке — все ещё возможна ошибка, если бросок намагниченного предмета произойдёт над линиями электропередач, которые сработают как магнит и оттолкнут его, но это поведение явно будет не вписываться в постановку эксперимента, а значит будет все ещё полезно, т.к. приведёт к пересмотру гипотезы.nluparev
09.10.2018 11:48спасибо за ликбез))
я наверно не достаточно четко сформулировал вопрос. меня интересуют именно стартаперские инструменты. Как проводить эксперимент. как оценивать его успешность/неуспешность. как строить и проводить анализ и прочее.
EgorZanuda
08.10.2018 12:55Все это хорошо, может даже отлично, но вопрос остается зачем?
Вам точно нужно из названия убрать слово «Яндекс».
jetcar
08.10.2018 14:31это вроде как всё называется аджайлом, делать как можно больше и из того что приносит как можно больше прибыли, но как всегда это не может продолжаться вечно, если расти то в конце концов со всеми долгами придётся разбираться, для стартапов нормальная стратегия, а для развитого бизнеса означает что может настать жопа в неожиданый момент, тут не продумал там недоделал, дыр кучу оставили и опа утащили базу данных, а всё потому-что не выполнялись правила, они же не просто так придуманы, уже сколько лет все пишут, а понятие что всегда надо делать хорошо никак не доходит, надо чтоли регуляцию какую-то ввести и лицензию выдавать только тем кто знает правила и использует их :)
Ad_xname
08.10.2018 17:13А как Вы вообще меняете стек? Если все нужно уложить в текущий? Или есть какие-то критерии для этого?
Tomcat Автор
08.10.2018 23:10Очень нечасто такое случается. Обычно — при старте какого-то нового проекта. И стек должен быть очень понятно обоснован. Например, сейчас пилим новый проект в инфраструктуре большого Яндекса, поэтому технологии там немного другие. В основном касается внутренних решений и ограничения, которое они накладывают на компоненты.
Ad_xname
09.10.2018 00:30Просто в случае продукта, который разрабатывают достаточно долго, рано или поздно технологии и средства разработки устаревают, разработчикам такие проекты становятся не интересны (например, писать код на Delphi 6)
Встречались некоторые предприятия, где стоят древние машины с соответствующим ПО. И чем дальше, тем хуже. Вроде бы очевидно, что что-то нужно менять, но к чему это привязать?Tomcat Автор
09.10.2018 01:11Тяжёлый вопрос, да. Просто оставлю ссылку на Джоэля здесь: habr.com/post/219651 — она очень в тему.
От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.Ad_xname
09.10.2018 11:43Вопрос тяжелый, в самом деле. Проблема в том, что при полном «исчерпании» технолологии делать что-то уже поздно. Как раз «проблема Джоэля» и встанет — «Нужно все переписать» )
Разве модульная архитектура не могла бы тут помочь? Чтоб не все сразу, а частично? Те же микросервисы неплохо ложатся в эту парадигму.
Впрочем, это скорее тема для отдельной статьи ;)
c0f04
08.10.2018 19:43Как-то слишком много компромиссов между быстрыми решениями и правильными. На моей практике быстрые решения нужны только в крайних случаях, обусловленных сроками. Технические долги потом начинают становиться сильной обузой в условиях множества новых задач и отсутствия времени.
- Код можно абстрагировать для будущего повторного использования. Это может сильно увеличивать время на текущую творческую разработку, но на порядок уменьшает будущую в рамках компании, если в компании заведена и задокументирована библиотека внутренних наработок. Очень хорошо в этом плане подходят подмодули git, если их научиться правильно готовить. В качестве примера наработок, сильно сокращающих расходы компании, можно привести рождение хотя бы те же Golang или Protobuf у Google.
- Любое быстрое решение должно быть продумано так, чтобы в будущем его можно было легко подменить на правильное. Например, если все привыкли к XML и его выбрали в качестве формата для обмена между клиентом и сервером, где предвидится огромный объём траффика, фичу можно быстро и легко реализовать. Но когда-нибудь это может стать узким местом производительности и пойдут расходы по всевозможным оптимизациям legacy-кода, или вырастет в обслуживание дорогостоящего оборудования. В то время как можно было завязаться на те же Protobuf или Flat Buffers, или на крайний случай свою систему сериализации с самого начала. Всё потому, что принципы работы у технологий в корне отличаются, а быстрые решения обычно не предполагают лишние слои абстракций.
- Иногда имеет смысл отказаться от целой фичи, если её быстрое решение будет приводить в дорогостоящей будущей поддержке. Например, если кнопочка с небольшим удобством для клиента, которую он упорно просит, создаёт 24-й слой архитектуры, который потом не даст сделать для другого клиента более выгодный и масштабный 24-й слой архитектуры, то лучше не делать кнопочку (или подождать переработки архитектуры, когда не будет конфликтов).
Tomcat Автор
08.10.2018 23:24Я с вами очень во многом согласен.
Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.
Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.
В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.c0f04
09.10.2018 19:14Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну раз готовы. :) Выскажу свои предположения. Как мне кажется, в крупных компаниях практически исключается любой серьёзный рефакторинг из-за большого количество разработчиков. Поэтому проекты пишутся наслаиваниями. Это как в deb-пакетах, система уже устоялась, а все доработки ведутся через всякие прослойки и дополнения, как то: dh_*, debuild, dpkg-buildpackage. Хотя по сути — просто архив со стандартизированным содержанием.
Наслаивание увеличивает время разработки. То есть всё то же самое можно было бы написать с нуля в несколько раз быстрее. Если выражать это в ресурсах компании, то это большие средства. Другое дело, что это уже потраченные средства, и они приносят прибыль, хотя и создают будущую поддержку кода.
То есть в перспективе может оказаться выгоднее переписать с нуля какую-либо систему, начать поэтапно внедрять новую, а старую объявить legacy и по возможности уходить с неё. И для крупных компаний это может быть вполне рентабельно.
Если рассматривать Вашу компанию, бэкенд базы лекарств Яндекс.Здоровья и бэкенд БД Яндекс.Маркета могли бы быть одной и той же программной системой. И там, и там требуется поиск (собственно движок поиска уже есть). Если есть какая-то разница в представлении, то эту разницу можно либо параметрами систем задавать, либо генерировать исходные тексты, если требуется очень сильная оптимизация производительности. А вот фронтенд уже разрабатывается разный. Но и тут по части скрпитов, элементов интерфейса, всё можно свести к единым кастомизируемым проектам. Остальное останется за дизайнерами.
Это моё видение. Я никогда не работал в крупных компаниях, поэтому мне любопытно узнать, насколько кардинально различается разработка в небольших и крупных компаниях. В мелких иногда бывает выгоднее написать сложную систему, чтобы сэкономить на найме нового сотрудника для поддержки разрастающегося проекта. Максимальное переиспользование кода позволяет конкурировать с крупными и держаться на плаву, хотя выглядит это как будто программисты долгое время ничего не делают, а результаты нельзя пощупать. :)
Paskin
09.10.2018 01:43Для абстрагирования кода нужны хотя бы два-три клиента для потенциальной библиотеки — если же начать абстрагирование сразу, через год у библиотеки будут пять несовместимых версий.
c0f04
10.10.2018 22:41Если разрабатывается собственный продукт, то там тоже библиотека наработок может развиваться. Продукт — это не обязательно маленькое приложение, это может быть сложная комплексная система. Соответственно, в разных её частях можно использовать одни и те же технологии.
fzn7
08.10.2018 20:17-5Менеджменту, наверное, удобно стало. Вместо разговоров всегда можно тыкнуть носом в нужный пункт правил.
aslepov78
08.10.2018 21:07-3Каждый сам следит за своими задачами
Ага… мечта управленца.
Включать голову нужно обязательно
Мыть руки перед едой, и слушаться маму.
stepik777
09.10.2018 00:53Это всё конечно интересно, но зачем вы в свой справочник лекарств добавляете фэйковые лекарства в описании которых написана ложь?
Tomcat Автор
09.10.2018 01:20Напишите в личку, пожалуйста — обязательно разберёмся.
stepik777
09.10.2018 01:48Ну, например, у вас там куча гомеопатических лекарств описаны как реально действующие. Или римантадин, который не эффективен против современных вирусов гриппа и не рекомендуется к применению, но у вас об этом ничего не написано. Ну и конечно всеми любимые кагоцел и анаферон. Это я только самые очевидные посмотрел, но российский рынок завален сомнительными лекарствами и вы, видимо, решили просто воспроизводить весь этот bullshit, вместо того, чтобы попытаться предоставить правдивую информацию.
c0f04
09.10.2018 08:04-1Вы по Анаферону по википедии судите? Если да, то должны понимать, что о нём судили только по этикетке, данные о концентрации на которой уже давно поменялись. Они могли просто неверно указать данные. Сейчас данные на этикетке больше похожи на правду. Лекарство может вполне оказаться эффективным.
KoToSveen
09.10.2018 09:32+1данные о концентрации на которой уже давно поменялись
На wiki: в 1 грамме анаферона содержится не более 10-24 граммов антител к интерферону
На сайте производителя: не более 10-15нг/г активной формы действующего вещества
На сайте препарата: не более 10-15 нг/г активной формы действующего вещества
Приставка нано: 10-9
т.е. 10-24 граммов и 10-15 нг
Ничего не смущает?
п.с. На сайте препарата именно так и написано 10-15 нг/г, а не 10-15 нг/гc0f04
09.10.2018 18:34Человеческий фактор на лицо. Не могут никак правильно указать концентрацию. А о фактической концентрации мы не узнаем, увы.
KoToSveen
10.10.2018 04:11Применяемые в лечебных целях препараты гамма-глобулинов состоят преимущественно из IgG.
Там же: молекулярная масса IgG = 140 000 а.е.м.
Тут смотрим как перевести а.е.м. в граммы: 1 а. е. м. = 1,6605402 ? 10?24 г.
Масса молекулы белка антитела: 140000 ? 1,6605402 ? 10?24 = 232475,628 ? 10?24 г.
С сайта препарата: Антитела к гамма интерферону человека аффинно очищенные вводятся в виде водно-спиртовой смеси активной формы действующего вещества с содержанием не более 10–15 нг/г (10–24 г/г) действующего вещества, то для нанесения одной молекулы потребуется раствора: 232475,628 ? 10?24 / 10–24 = 232475,628 г (232,475628 кг).
Или я в расчётах налажал, или каждую таблетку необходимо обливать 230-ю кг раствора для нанесения на неё хотя бы одной молекулы активного вещества.c0f04
10.10.2018 08:01В википедии не всегда актуальные данные. Если хотите, обновите их, сделаете полезное дело, уменьшив количество бессмысленных споров. А я был не прав, это не ошибка, а перерегистрация у них была. Писал же, что этикетка у них другая уже, да Вы и сами кидали ссылку на сайт препарата.
www.pravda.ru/news/health/13-07-2015/1263490-flu-0
Активное вещество: антитела к гамма-интерферону человека аффинно очищенные 0,003 г, наносятся на лактозы моногидрат в виде водно-спиртовой смеси с содержанием не более 10-15 нг/г активной формы действующего вещества, детская форма 10-16нг/г активной формы действующего вещества.
Вышел на рынок в 2002 г. в качестве гомеопатического средства. Начиная с 2009 г., Анаферон перерегистрирован как стандартное противовирусное и иммуномодулирующее лекарственное средство.
Содержание — от 10 до 15 нг/г, а не 10-15 нг/г.
ggo
09.10.2018 09:47Кто девушку ужинает…
Сервис не существует сам по себе, в пустоте.
Есть правовое поле в рамках которого существуют:
— изготовители бадов, гомеопатики и пр.
— продавцы этого
— врачи
— наверно кто-то еще.
Если начать отрицать реальность, и пытаться брать на себя несвойственные тебе функции, типа модерации бадов и гомеопатии, то твой сервис проиграет тем, кто занимается только развитием сервиса, и к которому уйдет аудитория.
Ни разу не сторонник бадов и гомеопатии, но проблемы в этой области должны решаться экспертами этой области.Newbilius
09.10.2018 10:55+1В крайнем случае можно не модерировать, но информировать: плашку повесить типа «бад», «гомеопатия» и т.п. Всё корректно и опять таки по закону, каталогизация и сортировка ничему не противоречит.
Hardcoin
09.10.2018 11:09Имхо, странно было бы от них ожидать какой-то особой фильтрации. Им же источник нужен. Откуда они возьмут, что Кагоцел не работает? Вот они и берут просто информацию, которую даёт производитель. Если у вас есть хороший систематизированный источник информации, поделитесь, пожалуйста.
Tomcat Автор
09.10.2018 11:43Наши врачи и мы сами придерживаемся принципов доказательной медицины. Поэтому ваш вопрос мне понятен и закономерен. Задача, как правильно отделять препараты с клинически доказанной эффективностью от препаратов, для которых двойное слепое плацебо-контролируемое исследование не проводилось, актуальна и обязательно будет решаться.
advance
09.10.2018 02:06Кстати, на станицах гомеопатических препаратов нет, на данный момент, ни одного упоминания того, что они таковыми являются. Как и отдельного раздела. Лично я бы не рассматривал сервис, который не предоставляет подобной информации, в качестве полезного. И, как мне кажется, многие люди тоже.
Ладно люди, если сервис раскрутится- им начнут пользоваться медики в качестве справочника. А это уже страшно…
maep
09.10.2018 07:27+1За гомеопатию давно пора расстреливать.
А статья хорошая.
И комментарии изящно подчеркивают проблему разных подходов разработчиков-перфекционистов и управленцев нацеленных на результат к вопросу.Ad_xname
09.10.2018 16:01За распространение гомеопатии статьи пока нет ;)
К Яндексу вряд ли могут быть тут претензии, раз это в аптеках продается.
А вообще, идея «лечения онлайн» довольно спорная.
Я бы эту мысль сделал центральной — «никакой онлайн не заменит полностью личного общения с врачом».
Понимаю, что сейчас вообще проблема с доступностью медицины, но иллюзий что теперь поликлиники и больницы не нужны, быть не должно. Человек все же — это не айфон и не автомобиль.maep
09.10.2018 16:03Заметьте, про предметную область я ничего не писал. Ну, кроме расстрелов за гомеопатию, которые спасли бы какое-то количество жизней и сэкономили бы миллиарды честным, но неграмотным гражданам.
Ad_xname
09.10.2018 16:57Просто статья затрагивает очень тонкие факторы. Например, вопросы этики в разработке. Должны ли разработчики вникать в предметную область и изучать такие вещи?
Мне кажется, что разработчики — нет, но параллельно должны привлекаться консультанты-профессионалы, которые все это учтут.
А так получается, что статья про организацию разработки вызывает вопросы по предметной области.maep
10.10.2018 04:11Гражданская позиция может и должна быть у каждого гражданина. Если бы химики в нацистской германии все дружно саботировали разработку хим оружия, то не было бы хим оружия у фашистов. Пример нарочито упрощенный, но суть ясна.
Я не к тому, что разрабы яндекса должны отказаться от проекта, а лишь отвечаю на ваш вопрос «должны ли смотреть, что делают».
erlyvideo
09.10.2018 09:35> я не воспринимаю критику болезненно (с условием, что вы не переходите на личности ;)
ну вот, вроде же всё так хорошо было, а начинаются какие-то пометки мелким шрифтом =))
Спасибо за пост. Простой, внятный, по делу. Вроде все истины прописные, но ещё один взгляд на важный вопрос оказывается с новыми деталями.
slamon
09.10.2018 09:42Две миллисекунды ничего не решат
Прям аж покоробило :(Alozar
09.10.2018 11:19+1Если у вас есть узкое место, которое можно ускорить на две секунды, оптимизация другого места на миллисекунды ничего не даст. Всегда нужно смотреть на алгоритм в целом.
У меня был случай, когда нужно было сделать выгрузку из учётной системы, которая могла работать порядка 30 секунд. Проблема заключалась в получении данных из самой системы, т.к. это можно было сделать только вызывая определённую функцию, которая была написана через одно место, как и вся система. Из-за этого получение данных могло занимать 5 секунд, а могло все 28. И переписать это место, подменяя своим кодом, нельзя было, т.к. система покупная и разработчики могут в коде что-то поменять без предупреждения.
Tomcat Автор
09.10.2018 16:44В нашем сервисе две миллисекунды, действительно, ничего не решают. В системах, для которых 2ms критичны, очевидно, совсем другие подходы и правила.
ayevdoshenko
09.10.2018 15:47А сколько времени проект существует с таким подходом к разработке?
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.Tomcat Автор
09.10.2018 15:53В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Ошиблись. Два с половиной ;)
Контроль за архитектурой, периодические рефакторинги слабых мест — это очень важно, и мы их делаем. Если приводить аналогию — испачкаться не страшно. Плохо — не мыться и зарастать грязью. Мы периодически моемся :)
Для сравнения, есть у нас пара мест в проекте, где за этим следили плохо — и там, да, ад. Но это не зависит от времени жизни проекта. Ад там появился буквально за пару месяцев.ayevdoshenko
09.10.2018 18:41Ну, раз вы за эти два с половиной года еще не устали, значит либо не всегда такой подход был, либо действительно за архитектурой приглядывают. Потому что говнокод — здесь я под говнокодом подразумеваю не забагованный и/или криво писаный код, а код, который пишется не в какую-то хорошо продуманную структуру, а произвольно лепится — неизбежно приводит к тому, что в продукте начинаются суровые проблемы согласованности работы компонентов. Это как строить здание без плана, прифигачивая, что в голову пришло. Я поэтому не люблю «хакеров», которые могут — да — сделать финт в каком-то фрагменте, но этот финт на самом деле часто представляет собой сокрытие проблемы архитектуры, в виду чего и приходится изворачиваться; да и даже будучи к месту — зачастую наращивается сложность проекта без крайней на то необходимости — а это, как говорят знающие люди, самое «дорогое» в разработке — сложность.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
PMVyatkin
09.10.2018 16:29Вроде как яндекс.здоровье — это не проект, это продукт. Судя по всему — не совсем успешный, по сравнению с едой или такси или картами или чем то еще. Может быть, дело в том что сама по себе идея продать разговор с врачом по скайпу в России за 2,5 тысячи рублей, при цене посещения специалиста в регионе меньше тысячи рублей ну никак не пахнет большими посещениями сервиса. Может быть, дело в том, что когда у тебя болит зуб, ты какой то частью интуиции понимаешь, что сходить и запломбировать к самому плохому врачу, будет лучше, чем писать в скайп самому хорошему. Может быть, дело в том, что медицина конкретной страны вообще заслуживает мало доверия со своей гомеопатией, а может дело в обскурантизме большинства болеющих, все еще верящих в хиропрактиков и бабок.
В любом случае — ИМХО — с разработкой у вас все отлично, но вот именно продуктового и проектного менеджмента грамотного не хватает.
ThisMan
Может главная проблема в этом: «Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью.»
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )
domix32
На самом деле лучше иметь такие правила в явном виде и периодически их перечитывать, чтобы можно было как-то более-менее адекватно оцениваться самого себя. На прошлой работе иногда случались факапы когда кто-то держал смертный грех при себе.
achekalin
Понимаю, что это чисто сотовый, сервисный проект (мы вас своими, берём деньги, ни за что не отвечаем — но поблагороднее, конечно), но мысль о том, чтобы делать быстро рядом с медициной — коробит
alshch
Но ведь сервис не делает пересадку мозга через интернет, по сути — это узкоспециализированный скайп, он мог быть для консультации с юристами, программистами или сантехниками с такой же ценой бага.
achekalin
Вот тут есть тонкий вопрос: если разработка где-то скосячит, и «скайп» что-то не так и не тому донесет, то эффект для данного конкретного консультируемого может быть и неприятным.
Я понимаю, что Я последнее время все больше пытается сделаться посредником, ни за что не отвечая по сути: Такси — они только передают вызов, Еда — она (правильно) только передают вызов, Здоровье — они опять только передают вызов и сводят людей. Интересно при этом, что в более денежных делах (та же недвижка) дело не так хорошо идет — там за результат надо бы отвечать, а еще один сайт-компилятор объявлений почти никому не нужен, так что деньги не взять.
Но если в Такси, если будет глюк (реальный случай: я стою на улице и вижу вызванное мною такси, оно кружит вокруг точки в 2 (!) кварталах от меня, причем на карте в приложении оно рядом со мной — а у водителя на карте в приложении я «стою» там, где он меня ждет; в общем, перекрестный глюк приложения; «нашлись», только 10 минут потратили своего времени), то этот сбой софта (написанного, возможно, по тем же принципам «бери больше, кидай дальше») приведет к опозданию (на работу, учебу, в аэропорт, в больницу), то у Здоровья, кажется, был бы уместнее принцип «лучше меньше, да лучше». Потому что для пользователя цена ошибки передачи (этим же этот «скайп» занимается) выше.
perfect_genius
Водитель скорой тоже может по ошибочной карте приехать не туда.
Hardcoin
Вообще-то они обеспечивают связь с врачами. И обеспечивать её быстро, быстро добавлять возможности — это хорошо. Они же не указывают врачам, как лечить (я надеюсь).
finlandcoder
Описание процессов очень похоже на ААА-студии и компании запада. Да, есть разные бадишопы типа Люксофта и Епама. Но компании, которые делаю свои продукты и кранчат бигдату — так и живут. У вас нет времени думать, вы должны успевать еще и делать. Пока вы не поработаете в такой среде — не поймете. Много кода, много данных, много уровней абстракции (SOLID/GRASP/TDD/REST, OOP/OOD, DOD/SOA). Вы должны не только решить задачу аналитически, но и интегрировать её в код и данные. То есть каждая задача это:
1) аналитическое решение
2) оптимизация по памяти и времени
3) интеграция в код, в данные, в сервисы