Comments 72
Может главная проблема в этом: «Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью.»
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )
На самом деле лучше иметь такие правила в явном виде и периодически их перечитывать, чтобы можно было как-то более-менее адекватно оцениваться самого себя. На прошлой работе иногда случались факапы когда кто-то держал смертный грех при себе.
Понимаю, что это чисто сотовый, сервисный проект (мы вас своими, берём деньги, ни за что не отвечаем — но поблагороднее, конечно), но мысль о том, чтобы делать быстро рядом с медициной — коробит
Но ведь сервис не делает пересадку мозга через интернет, по сути — это узкоспециализированный скайп, он мог быть для консультации с юристами, программистами или сантехниками с такой же ценой бага.
Вот тут есть тонкий вопрос: если разработка где-то скосячит, и «скайп» что-то не так и не тому донесет, то эффект для данного конкретного консультируемого может быть и неприятным.
Я понимаю, что Я последнее время все больше пытается сделаться посредником, ни за что не отвечая по сути: Такси — они только передают вызов, Еда — она (правильно) только передают вызов, Здоровье — они опять только передают вызов и сводят людей. Интересно при этом, что в более денежных делах (та же недвижка) дело не так хорошо идет — там за результат надо бы отвечать, а еще один сайт-компилятор объявлений почти никому не нужен, так что деньги не взять.
Но если в Такси, если будет глюк (реальный случай: я стою на улице и вижу вызванное мною такси, оно кружит вокруг точки в 2 (!) кварталах от меня, причем на карте в приложении оно рядом со мной — а у водителя на карте в приложении я «стою» там, где он меня ждет; в общем, перекрестный глюк приложения; «нашлись», только 10 минут потратили своего времени), то этот сбой софта (написанного, возможно, по тем же принципам «бери больше, кидай дальше») приведет к опозданию (на работу, учебу, в аэропорт, в больницу), то у Здоровья, кажется, был бы уместнее принцип «лучше меньше, да лучше». Потому что для пользователя цена ошибки передачи (этим же этот «скайп» занимается) выше.
Я понимаю, что Я последнее время все больше пытается сделаться посредником, ни за что не отвечая по сути: Такси — они только передают вызов, Еда — она (правильно) только передают вызов, Здоровье — они опять только передают вызов и сводят людей. Интересно при этом, что в более денежных делах (та же недвижка) дело не так хорошо идет — там за результат надо бы отвечать, а еще один сайт-компилятор объявлений почти никому не нужен, так что деньги не взять.
Но если в Такси, если будет глюк (реальный случай: я стою на улице и вижу вызванное мною такси, оно кружит вокруг точки в 2 (!) кварталах от меня, причем на карте в приложении оно рядом со мной — а у водителя на карте в приложении я «стою» там, где он меня ждет; в общем, перекрестный глюк приложения; «нашлись», только 10 минут потратили своего времени), то этот сбой софта (написанного, возможно, по тем же принципам «бери больше, кидай дальше») приведет к опозданию (на работу, учебу, в аэропорт, в больницу), то у Здоровья, кажется, был бы уместнее принцип «лучше меньше, да лучше». Потому что для пользователя цена ошибки передачи (этим же этот «скайп» занимается) выше.
Вообще-то они обеспечивают связь с врачами. И обеспечивать её быстро, быстро добавлять возможности — это хорошо. Они же не указывают врачам, как лечить (я надеюсь).
Описание процессов очень похоже на ААА-студии и компании запада. Да, есть разные бадишопы типа Люксофта и Епама. Но компании, которые делаю свои продукты и кранчат бигдату — так и живут. У вас нет времени думать, вы должны успевать еще и делать. Пока вы не поработаете в такой среде — не поймете. Много кода, много данных, много уровней абстракции (SOLID/GRASP/TDD/REST, OOP/OOD, DOD/SOA). Вы должны не только решить задачу аналитически, но и интегрировать её в код и данные. То есть каждая задача это:
1) аналитическое решение
2) оптимизация по памяти и времени
3) интеграция в код, в данные, в сервисы
1) аналитическое решение
2) оптимизация по памяти и времени
3) интеграция в код, в данные, в сервисы
Спасибо, интересно и во многом совпадает с моим опытом работы в команде. позабавил пункт из смертных грехов про «не закапываемся в очень редкие кейсы» по моим наблюдениям такое поведение больше свойство личности и иногда полезное, а иногда вредное и тормозящее работу. Как это лечите в команде? или озвученной договоренности достаточно?
Спасибо! Если видим такой потенциально редкий, но сложный в обработке кейс, кто-то из команды обычно задаёт вопрос, насколько он реален и масштабен. После этого обсуждаем минут 10-15 вместе с продуктологами. Если поймём, что достаточно редкий — просто оставляем в виде техдолга. Примерно как управление рисками.
Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
Были случаи, когда мы сильно ошибались, и приходилось всё-таки придумывать, как обрабатывать такие недоделки. Уже на ходу и в менее комфортных условиях. Но таких ситуаций на два порядка меньше, чем случаев, когда кейс так и не возник.
Чёрт его знает. Со многим я не согласен.
Мне кажется, это ну, дорого что ли нагружать разработчика вот такой, по сути бестолковой работой, заставлять переключаться от основной работы. Для это кажется есть CI. Мне больше импонирует ситуация когда работа разработчика заканчивает при переводе задачи в тестирование.
Да и к другим пунктам, тоже вопросы, естественно это субъективное мнение.
Абаз про «Не в проде – не сделано»
Мне кажется, это ну, дорого что ли нагружать разработчика вот такой, по сути бестолковой работой, заставлять переключаться от основной работы. Для это кажется есть CI. Мне больше импонирует ситуация когда работа разработчика заканчивает при переводе задачи в тестирование.
Да и к другим пунктам, тоже вопросы, естественно это субъективное мнение.
Насчёт прода — это ИМХО, одно из самого важного.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…
Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу. И я изо всех сил мотивирую команду мыслить именно решением задач пользователя. А код, который не в проде, задач пользователя решить не может…
Другой вопрос — имеет ли смысл «навешивать» на программиста ещё и ответственность за «дотащить релиз». Я считаю, что да, это — часть мотивации думать не только о коде, но и о продукте. Но моё мнение тоже абсолютно субъективное ;)
Ну, это же простая математика. Есть ограниченное количество времени. За это время программист может решить две задачи и отправить в тестирование, или одну но дотащить до прода. Кстати, про здоровье, мне кажется, что решить две задачи для здоровья полезнее, чем «переключения» на различные этапы по пути на прод.
Всё это да. И суть даже не только в том чтобы дотащить до прода, но и думать о том, что это решение действительно решит задачу человека. Но, я больше о другом, об организации работы.
Наша работа не ценна сама по себе. Продукт нашей работы — это не код и не архитектура. Наш продукт — это система, которая позволяет пользователю решить свою задачу.
Всё это да. И суть даже не только в том чтобы дотащить до прода, но и думать о том, что это решение действительно решит задачу человека. Но, я больше о другом, об организации работы.
но и думать о том, что это решение действительно решит задачу человека— пока это не на тесте, мы об этом не узнаем никак… Т.е. это только гипотеза изначально, и 9 из 10 гипотез проваливаются, но ценность десятой покрывает все временные и ресурсные затраты.
Это только если тестирование занимает меньше времени, чем разработка.
А в больших проектах обычно тестирование как раз самая долгая часть. В чем смысл стараться клепать как можно больше задач, если узкое место – это выкладка и тестирование?
А в больших проектах обычно тестирование как раз самая долгая часть. В чем смысл стараться клепать как можно больше задач, если узкое место – это выкладка и тестирование?
Не обязательно. Проверка гипотезы не подразумевает большого тестирования, тем более регресса (хотя все зависит от специфики теста).
Я так думаю, что речь идет о примерно такой схеме — одновременно проверяются, например, 10 гипотез (каждая по сути делается как MVP), и в разработке 1-2 фичи, которые проверены тестами.
В любом случае я согласен с тем, что тестирование всегда будет узким местом. У нас в компании я стремлюсь к соотношению 1 к 1, но пока даже 2 тестировщика на 3 разработчика не всегда получается…
Я так думаю, что речь идет о примерно такой схеме — одновременно проверяются, например, 10 гипотез (каждая по сути делается как MVP), и в разработке 1-2 фичи, которые проверены тестами.
В любом случае я согласен с тем, что тестирование всегда будет узким местом. У нас в компании я стремлюсь к соотношению 1 к 1, но пока даже 2 тестировщика на 3 разработчика не всегда получается…
UFO just landed and posted this here
Разработчик решает проблему, а не пишет код. «Не в проде — не сделано» == «Проблема не решена»
Мне кажется, это ну, дорого что ли нагружать разработчика вот такой, по сути бестолковой работой, заставлять переключаться от основной работы.Это может быть не только дорого, но и неэффективно. Подозреваю, что имеется в виду чисто админская (devops?) работа типа «подключиться к проду, развернуть там всё, настроить, проверить, пошаманить в случае необходимости». Смешение обязанностей, ничего нового. Из той же оперы: ПМ может не быть, разработчики взаимодействуют напрямую с заказчиком. Где-то нормально заходит, где-то нет — от людей зависит, что логично.
> дорого что ли нагружать разработчика вот такой, по сути бестолковой работой,
на практике при выходе на прод может выясниться, что принятые девелопером идеи и концепции были неправильны и ошибочны.
Именно поэтому стоит это тоже вешать на девелопера.
на практике при выходе на прод может выясниться, что принятые девелопером идеи и концепции были неправильны и ошибочны.
Именно поэтому стоит это тоже вешать на девелопера.
работа разработчика заканчивает при переводе задачи в тестирование
С моей стороны пули вылетели, проблема на вашей стороне, ага.
«Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью»
а как вы проводите эксперименты и как понять какой был успешный а какой нет?
а как вы проводите эксперименты и как понять какой был успешный а какой нет?
Опять же с дисклеймером, что это всё только про Здоровье.
Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.
Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.
Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.
Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.
Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.
Сначала понимаем, что конкретно хотим проверить, как это посчитать, и минимальное количество работы, которое для этого сделать надо. В общем, готовим дизайн эксперимента. Это делает продуктолог и техлиды в части аккуратного выбора костылей, чтобы они потом максимально пригодились.
Потом собираем MVP из этих костылей, запускаем на пользователей и смотрим, соответствует ли поведение метрик нашей гипотезе. В зависимости от результатов, решаем — заменяем костыли на нормальное решение или выпиливаем всё навиг.
Критерий (выпиливать / не выпиливать), кстати, довольно сложно формализуется, и (есть такой грех) не всегда устанавливается при старте эксперимента. Иногда и постфактум смотрим.
Если фича совсем простая, но мы в неё верим — просто делаем, выкатываем и наблюдаем ступеньки на соответствующих графиках. Если ничего важного не упало, то оставляем.
Ну и третий — самый неприятный случай, когда для эксперимента, действительно, надо много разработки разработать. Иногда и так случается, но крайне редко.
Есть давным-давно сформулированный закон научности:
Если гипотеза не может быть опровергнута в рамках эксперимента(наблюдения) — она не научна.
Так называемый принцип фальсифицируемости.
Я не работаю в Яндекс.Здоровье, но как понять успешность или безуспешность эксперимента должно быть сформулировано на этапе его постановки.
Например, «Если подбросив любой объект(и не воздействовать на него другими силами) в воздух на Земле — объект упадёт, то на Земле действует сила притяжения, если не упадёт — не действует».
В такой формулировке — все ещё возможна ошибка, если бросок намагниченного предмета произойдёт над линиями электропередач, которые сработают как магнит и оттолкнут его, но это поведение явно будет не вписываться в постановку эксперимента, а значит будет все ещё полезно, т.к. приведёт к пересмотру гипотезы.
Если гипотеза не может быть опровергнута в рамках эксперимента(наблюдения) — она не научна.
Так называемый принцип фальсифицируемости.
Я не работаю в Яндекс.Здоровье, но как понять успешность или безуспешность эксперимента должно быть сформулировано на этапе его постановки.
Например, «Если подбросив любой объект(и не воздействовать на него другими силами) в воздух на Земле — объект упадёт, то на Земле действует сила притяжения, если не упадёт — не действует».
В такой формулировке — все ещё возможна ошибка, если бросок намагниченного предмета произойдёт над линиями электропередач, которые сработают как магнит и оттолкнут его, но это поведение явно будет не вписываться в постановку эксперимента, а значит будет все ещё полезно, т.к. приведёт к пересмотру гипотезы.
Все это хорошо, может даже отлично, но вопрос остается зачем?
Вам точно нужно из названия убрать слово «Яндекс».
Вам точно нужно из названия убрать слово «Яндекс».
это вроде как всё называется аджайлом, делать как можно больше и из того что приносит как можно больше прибыли, но как всегда это не может продолжаться вечно, если расти то в конце концов со всеми долгами придётся разбираться, для стартапов нормальная стратегия, а для развитого бизнеса означает что может настать жопа в неожиданый момент, тут не продумал там недоделал, дыр кучу оставили и опа утащили базу данных, а всё потому-что не выполнялись правила, они же не просто так придуманы, уже сколько лет все пишут, а понятие что всегда надо делать хорошо никак не доходит, надо чтоли регуляцию какую-то ввести и лицензию выдавать только тем кто знает правила и использует их :)
А как Вы вообще меняете стек? Если все нужно уложить в текущий? Или есть какие-то критерии для этого?
Очень нечасто такое случается. Обычно — при старте какого-то нового проекта. И стек должен быть очень понятно обоснован. Например, сейчас пилим новый проект в инфраструктуре большого Яндекса, поэтому технологии там немного другие. В основном касается внутренних решений и ограничения, которое они накладывают на компоненты.
Просто в случае продукта, который разрабатывают достаточно долго, рано или поздно технологии и средства разработки устаревают, разработчикам такие проекты становятся не интересны (например, писать код на Delphi 6)
Встречались некоторые предприятия, где стоят древние машины с соответствующим ПО. И чем дальше, тем хуже. Вроде бы очевидно, что что-то нужно менять, но к чему это привязать?
Встречались некоторые предприятия, где стоят древние машины с соответствующим ПО. И чем дальше, тем хуже. Вроде бы очевидно, что что-то нужно менять, но к чему это привязать?
Тяжёлый вопрос, да. Просто оставлю ссылку на Джоэля здесь: habr.com/post/219651 — она очень в тему.
От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.
От себя могу сказать, что переписывание на совсем новую технологию имеет смысл, только когда старая себя исчерпала как технически, так и экономически. Например, на поиск разработчика тратится полгода. Или добавление новой простой фичи занимает столько же ;). Но «исчерпала» — это очень растяжимое и неточное понятие, к сожалению.
Вопрос тяжелый, в самом деле. Проблема в том, что при полном «исчерпании» технолологии делать что-то уже поздно. Как раз «проблема Джоэля» и встанет — «Нужно все переписать» )
Разве модульная архитектура не могла бы тут помочь? Чтоб не все сразу, а частично? Те же микросервисы неплохо ложатся в эту парадигму.
Впрочем, это скорее тема для отдельной статьи ;)
Разве модульная архитектура не могла бы тут помочь? Чтоб не все сразу, а частично? Те же микросервисы неплохо ложатся в эту парадигму.
Впрочем, это скорее тема для отдельной статьи ;)
Как-то слишком много компромиссов между быстрыми решениями и правильными. На моей практике быстрые решения нужны только в крайних случаях, обусловленных сроками. Технические долги потом начинают становиться сильной обузой в условиях множества новых задач и отсутствия времени.
- Код можно абстрагировать для будущего повторного использования. Это может сильно увеличивать время на текущую творческую разработку, но на порядок уменьшает будущую в рамках компании, если в компании заведена и задокументирована библиотека внутренних наработок. Очень хорошо в этом плане подходят подмодули git, если их научиться правильно готовить. В качестве примера наработок, сильно сокращающих расходы компании, можно привести рождение хотя бы те же Golang или Protobuf у Google.
- Любое быстрое решение должно быть продумано так, чтобы в будущем его можно было легко подменить на правильное. Например, если все привыкли к XML и его выбрали в качестве формата для обмена между клиентом и сервером, где предвидится огромный объём траффика, фичу можно быстро и легко реализовать. Но когда-нибудь это может стать узким местом производительности и пойдут расходы по всевозможным оптимизациям legacy-кода, или вырастет в обслуживание дорогостоящего оборудования. В то время как можно было завязаться на те же Protobuf или Flat Buffers, или на крайний случай свою систему сериализации с самого начала. Всё потому, что принципы работы у технологий в корне отличаются, а быстрые решения обычно не предполагают лишние слои абстракций.
- Иногда имеет смысл отказаться от целой фичи, если её быстрое решение будет приводить в дорогостоящей будущей поддержке. Например, если кнопочка с небольшим удобством для клиента, которую он упорно просит, создаёт 24-й слой архитектуры, который потом не даст сделать для другого клиента более выгодный и масштабный 24-й слой архитектуры, то лучше не делать кнопочку (или подождать переработки архитектуры, когда не будет конфликтов).
Я с вами очень во многом согласен.
Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.
Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.
В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.
Во втором пункте главное, чтобы сериализация была абстрагирована от бизнес-логики. Я бы построил промежуточный слой абстракций, которые работают с API вне зависимости от сериализации, а потом реализовал её на быстром XML (кстати, в моём мире это не самый быстрый и лёгкий способ). В вероятном будущем, когда мы упираемся в производительность, меняется только слой сериализации на другую реализацию, оставляя всё остальное без изменений. Это как раз про два решения — быстрое, которое закладывает фундамент для правильного, и, собственно, правильное.
Библиотека внутренних наработок хорошее дело. Поэтому код стоит писать так, чтобы компоненты были максимально отчуждаемыми, и, при желании, их можно было вынести и реюзать. Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну а по поводу отказа от кнопочки, которая тащит глобальное усложнение архитектуры — тут вообще, думаю, спорить смысла нет. Просто садимся вместе с продуктологом и понимаем, так ли сильно она важна. И, если действительно критично важна (такое тоже бывает в реальности), то тут уж делать особо нечего — придумываем, как можно такую кнопочку делать по-другому.
В общем, я к тому, что быстрые решения могут быть правильными, а правильные — быстрыми ;). Опять же, очень важно понимать, что быстрые и неправильные тоже делать можно, но не забывать про них и как-то потом с ними разбираться.
Готов поспорить, что такой подход, нормально реализованный, тоже глобально не влияет на TTM фичи.
Ну раз готовы. :) Выскажу свои предположения. Как мне кажется, в крупных компаниях практически исключается любой серьёзный рефакторинг из-за большого количество разработчиков. Поэтому проекты пишутся наслаиваниями. Это как в deb-пакетах, система уже устоялась, а все доработки ведутся через всякие прослойки и дополнения, как то: dh_*, debuild, dpkg-buildpackage. Хотя по сути — просто архив со стандартизированным содержанием.
Наслаивание увеличивает время разработки. То есть всё то же самое можно было бы написать с нуля в несколько раз быстрее. Если выражать это в ресурсах компании, то это большие средства. Другое дело, что это уже потраченные средства, и они приносят прибыль, хотя и создают будущую поддержку кода.
То есть в перспективе может оказаться выгоднее переписать с нуля какую-либо систему, начать поэтапно внедрять новую, а старую объявить legacy и по возможности уходить с неё. И для крупных компаний это может быть вполне рентабельно.
Если рассматривать Вашу компанию, бэкенд базы лекарств Яндекс.Здоровья и бэкенд БД Яндекс.Маркета могли бы быть одной и той же программной системой. И там, и там требуется поиск (собственно движок поиска уже есть). Если есть какая-то разница в представлении, то эту разницу можно либо параметрами систем задавать, либо генерировать исходные тексты, если требуется очень сильная оптимизация производительности. А вот фронтенд уже разрабатывается разный. Но и тут по части скрпитов, элементов интерфейса, всё можно свести к единым кастомизируемым проектам. Остальное останется за дизайнерами.
Это моё видение. Я никогда не работал в крупных компаниях, поэтому мне любопытно узнать, насколько кардинально различается разработка в небольших и крупных компаниях. В мелких иногда бывает выгоднее написать сложную систему, чтобы сэкономить на найме нового сотрудника для поддержки разрастающегося проекта. Максимальное переиспользование кода позволяет конкурировать с крупными и держаться на плаву, хотя выглядит это как будто программисты долгое время ничего не делают, а результаты нельзя пощупать. :)
Для абстрагирования кода нужны хотя бы два-три клиента для потенциальной библиотеки — если же начать абстрагирование сразу, через год у библиотеки будут пять несовместимых версий.
UFO just landed and posted this here
Каждый сам следит за своими задачами
Ага… мечта управленца.
Включать голову нужно обязательно
Мыть руки перед едой, и слушаться маму.
UFO just landed and posted this here
Напишите в личку, пожалуйста — обязательно разберёмся.
UFO just landed and posted this here
Тоже смущает подобное
Вы по Анаферону по википедии судите? Если да, то должны понимать, что о нём судили только по этикетке, данные о концентрации на которой уже давно поменялись. Они могли просто неверно указать данные. Сейчас данные на этикетке больше похожи на правду. Лекарство может вполне оказаться эффективным.
данные о концентрации на которой уже давно поменялись
На wiki: в 1 грамме анаферона содержится не более 10-24 граммов антител к интерферону
На сайте производителя: не более 10-15нг/г активной формы действующего вещества
На сайте препарата: не более 10-15 нг/г активной формы действующего вещества
Приставка нано: 10-9
т.е. 10-24 граммов и 10-15 нг
Ничего не смущает?
п.с. На сайте препарата именно так и написано 10-15 нг/г, а не 10-15 нг/г
Человеческий фактор на лицо. Не могут никак правильно указать концентрацию. А о фактической концентрации мы не узнаем, увы.
Применяемые в лечебных целях препараты гамма-глобулинов состоят преимущественно из 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-ю кг раствора для нанесения на неё хотя бы одной молекулы активного вещества.
Там же: молекулярная масса 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-ю кг раствора для нанесения на неё хотя бы одной молекулы активного вещества.
В википедии не всегда актуальные данные. Если хотите, обновите их, сделаете полезное дело, уменьшив количество бессмысленных споров. А я был не прав, это не ошибка, а перерегистрация у них была. Писал же, что этикетка у них другая уже, да Вы и сами кидали ссылку на сайт препарата.
www.pravda.ru/news/health/13-07-2015/1263490-flu-0
Содержание — от 10 до 15 нг/г, а не 10-15 нг/г.
www.pravda.ru/news/health/13-07-2015/1263490-flu-0
Активное вещество: антитела к гамма-интерферону человека аффинно очищенные 0,003 г, наносятся на лактозы моногидрат в виде водно-спиртовой смеси с содержанием не более 10-15 нг/г активной формы действующего вещества, детская форма 10-16нг/г активной формы действующего вещества.
Вышел на рынок в 2002 г. в качестве гомеопатического средства. Начиная с 2009 г., Анаферон перерегистрирован как стандартное противовирусное и иммуномодулирующее лекарственное средство.
Содержание — от 10 до 15 нг/г, а не 10-15 нг/г.
Кто девушку ужинает…
Сервис не существует сам по себе, в пустоте.
Есть правовое поле в рамках которого существуют:
— изготовители бадов, гомеопатики и пр.
— продавцы этого
— врачи
— наверно кто-то еще.
Если начать отрицать реальность, и пытаться брать на себя несвойственные тебе функции, типа модерации бадов и гомеопатии, то твой сервис проиграет тем, кто занимается только развитием сервиса, и к которому уйдет аудитория.
Ни разу не сторонник бадов и гомеопатии, но проблемы в этой области должны решаться экспертами этой области.
Сервис не существует сам по себе, в пустоте.
Есть правовое поле в рамках которого существуют:
— изготовители бадов, гомеопатики и пр.
— продавцы этого
— врачи
— наверно кто-то еще.
Если начать отрицать реальность, и пытаться брать на себя несвойственные тебе функции, типа модерации бадов и гомеопатии, то твой сервис проиграет тем, кто занимается только развитием сервиса, и к которому уйдет аудитория.
Ни разу не сторонник бадов и гомеопатии, но проблемы в этой области должны решаться экспертами этой области.
проблемы в этой области должны решаться экспертами этой областиУже
В крайнем случае можно не модерировать, но информировать: плашку повесить типа «бад», «гомеопатия» и т.п. Всё корректно и опять таки по закону, каталогизация и сортировка ничему не противоречит.
Имхо, странно было бы от них ожидать какой-то особой фильтрации. Им же источник нужен. Откуда они возьмут, что Кагоцел не работает? Вот они и берут просто информацию, которую даёт производитель. Если у вас есть хороший систематизированный источник информации, поделитесь, пожалуйста.
Наши врачи и мы сами придерживаемся принципов доказательной медицины. Поэтому ваш вопрос мне понятен и закономерен. Задача, как правильно отделять препараты с клинически доказанной эффективностью от препаратов, для которых двойное слепое плацебо-контролируемое исследование не проводилось, актуальна и обязательно будет решаться.
Кстати, на станицах гомеопатических препаратов нет, на данный момент, ни одного упоминания того, что они таковыми являются. Как и отдельного раздела. Лично я бы не рассматривал сервис, который не предоставляет подобной информации, в качестве полезного. И, как мне кажется, многие люди тоже.
Ладно люди, если сервис раскрутится- им начнут пользоваться медики в качестве справочника. А это уже страшно…
Ладно люди, если сервис раскрутится- им начнут пользоваться медики в качестве справочника. А это уже страшно…
За гомеопатию давно пора расстреливать.
А статья хорошая.
И комментарии изящно подчеркивают проблему разных подходов разработчиков-перфекционистов и управленцев нацеленных на результат к вопросу.
А статья хорошая.
И комментарии изящно подчеркивают проблему разных подходов разработчиков-перфекционистов и управленцев нацеленных на результат к вопросу.
За распространение гомеопатии статьи пока нет ;)
К Яндексу вряд ли могут быть тут претензии, раз это в аптеках продается.
А вообще, идея «лечения онлайн» довольно спорная.
Я бы эту мысль сделал центральной — «никакой онлайн не заменит полностью личного общения с врачом».
Понимаю, что сейчас вообще проблема с доступностью медицины, но иллюзий что теперь поликлиники и больницы не нужны, быть не должно. Человек все же — это не айфон и не автомобиль.
К Яндексу вряд ли могут быть тут претензии, раз это в аптеках продается.
А вообще, идея «лечения онлайн» довольно спорная.
Я бы эту мысль сделал центральной — «никакой онлайн не заменит полностью личного общения с врачом».
Понимаю, что сейчас вообще проблема с доступностью медицины, но иллюзий что теперь поликлиники и больницы не нужны, быть не должно. Человек все же — это не айфон и не автомобиль.
Заметьте, про предметную область я ничего не писал. Ну, кроме расстрелов за гомеопатию, которые спасли бы какое-то количество жизней и сэкономили бы миллиарды честным, но неграмотным гражданам.
Просто статья затрагивает очень тонкие факторы. Например, вопросы этики в разработке. Должны ли разработчики вникать в предметную область и изучать такие вещи?
Мне кажется, что разработчики — нет, но параллельно должны привлекаться консультанты-профессионалы, которые все это учтут.
А так получается, что статья про организацию разработки вызывает вопросы по предметной области.
Мне кажется, что разработчики — нет, но параллельно должны привлекаться консультанты-профессионалы, которые все это учтут.
А так получается, что статья про организацию разработки вызывает вопросы по предметной области.
Гражданская позиция может и должна быть у каждого гражданина. Если бы химики в нацистской германии все дружно саботировали разработку хим оружия, то не было бы хим оружия у фашистов. Пример нарочито упрощенный, но суть ясна.
Я не к тому, что разрабы яндекса должны отказаться от проекта, а лишь отвечаю на ваш вопрос «должны ли смотреть, что делают».
Я не к тому, что разрабы яндекса должны отказаться от проекта, а лишь отвечаю на ваш вопрос «должны ли смотреть, что делают».
> я не воспринимаю критику болезненно (с условием, что вы не переходите на личности ;)
ну вот, вроде же всё так хорошо было, а начинаются какие-то пометки мелким шрифтом =))
Спасибо за пост. Простой, внятный, по делу. Вроде все истины прописные, но ещё один взгляд на важный вопрос оказывается с новыми деталями.
ну вот, вроде же всё так хорошо было, а начинаются какие-то пометки мелким шрифтом =))
Спасибо за пост. Простой, внятный, по делу. Вроде все истины прописные, но ещё один взгляд на важный вопрос оказывается с новыми деталями.
Две миллисекунды ничего не решат
Прям аж покоробило :(
Если у вас есть узкое место, которое можно ускорить на две секунды, оптимизация другого места на миллисекунды ничего не даст. Всегда нужно смотреть на алгоритм в целом.
У меня был случай, когда нужно было сделать выгрузку из учётной системы, которая могла работать порядка 30 секунд. Проблема заключалась в получении данных из самой системы, т.к. это можно было сделать только вызывая определённую функцию, которая была написана через одно место, как и вся система. Из-за этого получение данных могло занимать 5 секунд, а могло все 28. И переписать это место, подменяя своим кодом, нельзя было, т.к. система покупная и разработчики могут в коде что-то поменять без предупреждения.
У меня был случай, когда нужно было сделать выгрузку из учётной системы, которая могла работать порядка 30 секунд. Проблема заключалась в получении данных из самой системы, т.к. это можно было сделать только вызывая определённую функцию, которая была написана через одно место, как и вся система. Из-за этого получение данных могло занимать 5 секунд, а могло все 28. И переписать это место, подменяя своим кодом, нельзя было, т.к. система покупная и разработчики могут в коде что-то поменять без предупреждения.
В нашем сервисе две миллисекунды, действительно, ничего не решают. В системах, для которых 2ms критичны, очевидно, совсем другие подходы и правила.
Читал пост как человек, который управляет разработкой.
Михаил, респект!
Михаил, респект!
А сколько времени проект существует с таким подходом к разработке?
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Ошиблись. Два с половиной ;)
Контроль за архитектурой, периодические рефакторинги слабых мест — это очень важно, и мы их делаем. Если приводить аналогию — испачкаться не страшно. Плохо — не мыться и зарастать грязью. Мы периодически моемся :)
Для сравнения, есть у нас пара мест в проекте, где за этим следили плохо — и там, да, ад. Но это не зависит от времени жизни проекта. Ад там появился буквально за пару месяцев.
Ну, раз вы за эти два с половиной года еще не устали, значит либо не всегда такой подход был, либо действительно за архитектурой приглядывают. Потому что говнокод — здесь я под говнокодом подразумеваю не забагованный и/или криво писаный код, а код, который пишется не в какую-то хорошо продуманную структуру, а произвольно лепится — неизбежно приводит к тому, что в продукте начинаются суровые проблемы согласованности работы компонентов. Это как строить здание без плана, прифигачивая, что в голову пришло. Я поэтому не люблю «хакеров», которые могут — да — сделать финт в каком-то фрагменте, но этот финт на самом деле часто представляет собой сокрытие проблемы архитектуры, в виду чего и приходится изворачиваться; да и даже будучи к месту — зачастую наращивается сложность проекта без крайней на то необходимости — а это, как говорят знающие люди, самое «дорогое» в разработке — сложность.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
Вроде как яндекс.здоровье — это не проект, это продукт. Судя по всему — не совсем успешный, по сравнению с едой или такси или картами или чем то еще. Может быть, дело в том что сама по себе идея продать разговор с врачом по скайпу в России за 2,5 тысячи рублей, при цене посещения специалиста в регионе меньше тысячи рублей ну никак не пахнет большими посещениями сервиса. Может быть, дело в том, что когда у тебя болит зуб, ты какой то частью интуиции понимаешь, что сходить и запломбировать к самому плохому врачу, будет лучше, чем писать в скайп самому хорошему. Может быть, дело в том, что медицина конкретной страны вообще заслуживает мало доверия со своей гомеопатией, а может дело в обскурантизме большинства болеющих, все еще верящих в хиропрактиков и бабок.
В любом случае — ИМХО — с разработкой у вас все отлично, но вот именно продуктового и проектного менеджмента грамотного не хватает.
В любом случае — ИМХО — с разработкой у вас все отлично, но вот именно продуктового и проектного менеджмента грамотного не хватает.
Sign up to leave a comment.
Правила разработки в Яндекс.Здоровье