Простите, но тут проблема не в удалении и создании таблиц, а в неправильном использовании процедур Alpha и Beta. Редактор совершенно верно указал, где ошибка.
Имхо то, что выше описано - это больше задача менеджера по процессам, но не адвоката.
Вы же в том числе решаете околоюридические проблемы, возникающие у разработчиков? Например, защита от неправомерного увольнения, помощь в "выбивании" компенсации, борьба с токсичным поведением, разные виды несправедливости в офисе и т.д.?
То, что вы описываете - процесс, в принципе, абсолютно естественный, если посмотреть на него с точки зрения бизнеса.
команда полностью владеет кодом
Это возможно только в одном случае - когда код пишут лично директор и начальник отдела разработки, получающий прямой % от продаж. Только в этом случае они будут заинтересованы в качестве кодовой базы.
Но, как правило, высшее начальство интересует лишь показатель прибыли. Собственно, в этом и состоит суть бизнеса - приносить доход. Пока продукт продаётся - есть смысл развивать его "вширь", добавляя новые фичи. Всё остальное видится как "самодеятельность".
Выходит так, что в таких процессах никто особо не заинтересован в результате, процесс важнее.
Тут скорее наоборот - бизнес заинтересован только в результатах продаж. Сотрудники заинтересованы только в зарплате. Процесс разработки же интересует максимум непосредственного менеджера R&D - это единственный человек, который может и должен приложить усилия для оптимизации этого процесса, чтобы сделать его более эффективным. На более высоком уровне интересны только отчёты и KPI.
Как мне кажется, логику автопилота я описал достаточно однозначно.
Спасение водителя и пассажиров в приоритете ВСЕГДА. Независимо ни от чего. Автопилот не должен принимать этических решений "кого убивать, кого нет" - его задача простая и чёткая - сперва спасти пассажиров, параллельно минимизировав опасность для окружающих. Если это не возможно без нарушения ПДД - автопилот нарушит ПДД.
(что не будет нарушением и будет соответствовать ПДД - так как ПДД, как правило, разрешают нарушения в критических ситуациях).
Давайте посмотрим на проблему с другой стороны. Что сделает человек-водитель в данной ситуации? Инстинктивно будет спасать себя, поедет на обочину и возможно, задавит кучу народа - так как ему некогда будет просчитать оптимальный маршрут. Автопилот же тоже съедет на обочину - но при этом постарается сделать это с минимальными потерями. В итоге - в одной и той же ситуации количество пострадавших будет значительно меньше, чем без автопилота. Разве не в этом его смысл?
Первый приоритет однозначно за водителем и пассажирами. Тут идея очень простая - вы не купите машину, которая может принять решение пожертвовать вами. И я не куплю. И никто не купит. Поскольку автопилот не нарушает пдд - почему должны страдать пассажиры, которые на него надеются?
Второй приоритет за другими людьми. И тут автопилот может нарушить пдд, чтобы спасти максимум жизней. Ему не обязательно никого давить, чтоб спасти водителя - он может просчитать более безопасный маршрут, пусть даже и в разрез с пдд.
Пункты 1 и 2 как раз направлены на максимальную выживаемость водителя, пассажиров и пешеходов, как основную задачу автопилота в экстремальной ситуации. И они лучшим образом будут решать обозначенную проблему.
Поскольку при лобовом столкновении вариант "тормозить" не имеет особого смысла (убьются оба водителя с максимальной вероятностью - т.е. противоречие п.1 и п.2), то он не выполняется.
Поэтому автопилот выбирает альтернативный вариант - либо объезд вылетевшего на встречку (если возможно), либо съезд на обочину, с рассчётом траектории движения так, чтобы минимизировать последствия возможного столкновения с пешеходами (п.2 - они должны выжить по максимуму), максимально бибикая и мигая при этом, и в то же время поддерживать безопасность водителя (п.1). При этом по возможности не создавая проблем другим участникам движения (п.3).
В идеале, автопилот просчитает съезд с дороги так, что никого не убъет и не зацепит. И параллельно будет тормозить так, чтоб не занести и не перевернуться.
С учётом вышеизложенного, как по мне, наиболее разумным видится следующее:
Приоритет на максимальную безопасность водителя и пассажиров.
Приоритет на безопасность других участников.
Приоритет на соблюдение правил дорожного движения.
Если по простому - машину, которая будет думать, спасать ли велосипедиста за счёт водителя, никто не купит. Да машина и вообще не должна принимать подобные решения. ПДД говорят тормозить, значить тормозить.
Что касательно кейса "видимость 0, иду по приборам", когда вокруг все едут 80 и бибикают - опять же, пдд в приоритете. Ехать 50 и пофиг на идиотов.
"Технические задания" на собеседованиях - первый признак того, что в компании что-то не так с процессом найма сотрудников. Особенно многоэтапные. Просто потеря времени, причём для всех - и для кандитатов, и для собеседователей.
В чём проблема брать кандидата, который, по мнению собеседующих (по результатам общения! а не писания) готов и хочет работать на данной позиции, на испытательный срок? Во-первых, кандидат сразу ознакомится со спецификой проектов и решит, подходит ему эта работа или нет (а что он поймёт по задаче типа реверснуть массив на доске?) Во-вторых, компания быстро поймёт, подходит человечек или нет. Если по одному из вариантов "нет" - то быстро расстались и никаких проблем.
Давно применяем такой подход - пока работает.
PS. Тут некоторые писали, что к ним люди часто с фейковыми резюме приходят - но, честно говоря, мне трудно себе представить, как такое может сработать. Ну то есть может на какой-нибудь удалёнке в бодишоп ещё куда не шло, но в офис? Когда ты на виду у коллег и каждый твой коммит под микроскопом :) "не верю", в общем.
Думаю, все проблемы возникли из за того, что у вас в компании не налажены процессы разработки и обмена информацией с менеджментом. По сути, те задачи, которые вы на себя взяли, должен выполнять тимлид разработчиков, но ни в коем случае не продакт.
Общение с командой, постановка задач контроль исполнения, разговоры 1:1 - это типичная работа тимлида. Общение с клиентом вместе с руководителем проекта тоже. Меня, честно говоря, немного удивляет, чем у вас занимались тимлиды и начальник разработки в это время?
А токсичных удаков гнать надо в шею чем раньше, тем лучше. Будь они даже семи пядей во лбу. Как- то так.
В 2008 году купил недорогой ноутбук Acer Extenza. Живой до сих пор, только крышка треснула в одном месте. Правда, на нём даже скайп уже толком не работает, хотя винда 7-я как-то умудряется тарахтеть, с 4 гиг памяти то.
А в 2015 примерно купил себе HP, на тот момент очень неплохое железо. Помер примерно через год, месяца через два после окончания гарантии. Сначала стал процессор перегреваться (чистка не особо помогала), потом экран забарахлил, и в конце концов умер полностью.
Ремонтировать не стал, рабочие внутренности друзьям-коллегам раздал, которые "в теме", а останки на свалку отнёс. Такие дела..
- У меня стаж работы хирургом в больнице более 10 лет, также работал военным врачом в Ираке, где приходилось оперировать без подручных средств и без анестезии, и почти все пациенты выжили...
- Хорошо-хорошо, вот вам тестовое задание, удалите-ка аппендицит вот тому дяденьке. И пожалуйста комментируйте каждый ваш шаг.
Но почему-то хирургов так на работу не берут, не правда ли? Моё имхо - технические собеседования на уровень мидл+ не нужны от слова совсем.
В европах и прочих америках к "высокооплачиваемым" относятся врачи и топ-менеджмент. Всякая прочая IT-обслуга и кодерки в том числе получает не сильно больше, скажем, водителя грузовика. Максимум в 1.5-2 раза.
То, что в пост-СССР, сидя на удалёнке, можно получать "в долларах" меньше, чем в европах, но это всё же сильно больше, чем в местной валюте - просто временная ошибка выжившего и не более.
Конечно, неправильно. Как это обычно водится, "людьми до нас". Поэтому пришлось его выкорчёвывать и переделывать. В принципе, главная ошибка данных компонентов была в том, что авторы толком не владели С++ и решили применить классический Java подход к формированию классов и интерфейсов к ним.
Но С++ не Java, подобные вещи там не проходят бесследно. Как следствие, код, набитый С-макросами, кастами, методами-пустышками, плюс свой генератор кода и редактор компонентов (глючный, падающий). И всё это чудо работало раза в 3 медленнее безкомпонентного аналога, к тому же толком не умело в потоки.
Я к тому, что компоненты не панацея против сложности и при желании с ними можно сделать ещё хуже, чем без них. Модульный же подход решил в нашем случае все проблемы. Как по мне, модули - это следующий и более продуманный этап для борьбы со сложностью. Когда каждый модуль имеет лишь внешний интерфейс и протокол инициализации, а его внутренне представление скрыто от внешнего доступа, намного сложнее что либо сломать или "сделать не так".
Ну так хотя бы двое из шести выживут, а иначе вы всех в гроб предлагаете...
Простите, но тут проблема не в удалении и создании таблиц, а в неправильном использовании процедур Alpha и Beta. Редактор совершенно верно указал, где ошибка.
Есть такая профессия, как инфоцыгане...
Имхо то, что выше описано - это больше задача менеджера по процессам, но не адвоката.
Вы же в том числе решаете околоюридические проблемы, возникающие у разработчиков? Например, защита от неправомерного увольнения, помощь в "выбивании" компенсации, борьба с токсичным поведением, разные виды несправедливости в офисе и т.д.?
То, что вы описываете - процесс, в принципе, абсолютно естественный, если посмотреть на него с точки зрения бизнеса.
Это возможно только в одном случае - когда код пишут лично директор и начальник отдела разработки, получающий прямой % от продаж. Только в этом случае они будут заинтересованы в качестве кодовой базы.
Но, как правило, высшее начальство интересует лишь показатель прибыли. Собственно, в этом и состоит суть бизнеса - приносить доход. Пока продукт продаётся - есть смысл развивать его "вширь", добавляя новые фичи. Всё остальное видится как "самодеятельность".
Тут скорее наоборот - бизнес заинтересован только в результатах продаж. Сотрудники заинтересованы только в зарплате. Процесс разработки же интересует максимум непосредственного менеджера R&D - это единственный человек, который может и должен приложить усилия для оптимизации этого процесса, чтобы сделать его более эффективным. На более высоком уровне интересны только отчёты и KPI.
Любой проект должен стартовать с MVP. Основной функционал доделается в процессе.
Любая архитектура будет всё равно переделана. Поэтому проектируйте итеративно.
Для пользователя лучше надёжное и быстрое приложение, чем "красиво" написанное, но глючное.
KISS прежде всего.
В 2022 неожиданно случился 1984...
Как мне кажется, логику автопилота я описал достаточно однозначно.
Спасение водителя и пассажиров в приоритете ВСЕГДА. Независимо ни от чего. Автопилот не должен принимать этических решений "кого убивать, кого нет" - его задача простая и чёткая - сперва спасти пассажиров, параллельно минимизировав опасность для окружающих. Если это не возможно без нарушения ПДД - автопилот нарушит ПДД.
(что не будет нарушением и будет соответствовать ПДД - так как ПДД, как правило, разрешают нарушения в критических ситуациях).
Давайте посмотрим на проблему с другой стороны. Что сделает человек-водитель в данной ситуации? Инстинктивно будет спасать себя, поедет на обочину и возможно, задавит кучу народа - так как ему некогда будет просчитать оптимальный маршрут. Автопилот же тоже съедет на обочину - но при этом постарается сделать это с минимальными потерями. В итоге - в одной и той же ситуации количество пострадавших будет значительно меньше, чем без автопилота. Разве не в этом его смысл?
Близко, но не совсем так.
Первый приоритет однозначно за водителем и пассажирами. Тут идея очень простая - вы не купите машину, которая может принять решение пожертвовать вами. И я не куплю. И никто не купит. Поскольку автопилот не нарушает пдд - почему должны страдать пассажиры, которые на него надеются?
Второй приоритет за другими людьми. И тут автопилот может нарушить пдд, чтобы спасти максимум жизней. Ему не обязательно никого давить, чтоб спасти водителя - он может просчитать более безопасный маршрут, пусть даже и в разрез с пдд.
Пункты 1 и 2 как раз направлены на максимальную выживаемость водителя, пассажиров и пешеходов, как основную задачу автопилота в экстремальной ситуации. И они лучшим образом будут решать обозначенную проблему.
Поскольку при лобовом столкновении вариант "тормозить" не имеет особого смысла (убьются оба водителя с максимальной вероятностью - т.е. противоречие п.1 и п.2), то он не выполняется.
Поэтому автопилот выбирает альтернативный вариант - либо объезд вылетевшего на встречку (если возможно), либо съезд на обочину, с рассчётом траектории движения так, чтобы минимизировать последствия возможного столкновения с пешеходами (п.2 - они должны выжить по максимуму), максимально бибикая и мигая при этом, и в то же время поддерживать безопасность водителя (п.1). При этом по возможности не создавая проблем другим участникам движения (п.3).
В идеале, автопилот просчитает съезд с дороги так, что никого не убъет и не зацепит. И параллельно будет тормозить так, чтоб не занести и не перевернуться.
С учётом вышеизложенного, как по мне, наиболее разумным видится следующее:
Приоритет на максимальную безопасность водителя и пассажиров.
Приоритет на безопасность других участников.
Приоритет на соблюдение правил дорожного движения.
Если по простому - машину, которая будет думать, спасать ли велосипедиста за счёт водителя, никто не купит. Да машина и вообще не должна принимать подобные решения. ПДД говорят тормозить, значить тормозить.
Что касательно кейса "видимость 0, иду по приборам", когда вокруг все едут 80 и бибикают - опять же, пдд в приоритете. Ехать 50 и пофиг на идиотов.
"Где-то я это уже видел. Наверное, у Gof. А, не, показалось... А, не, не показалось."
"Люто плюсую".
"Технические задания" на собеседованиях - первый признак того, что в компании что-то не так с процессом найма сотрудников. Особенно многоэтапные. Просто потеря времени, причём для всех - и для кандитатов, и для собеседователей.
В чём проблема брать кандидата, который, по мнению собеседующих (по результатам общения! а не писания) готов и хочет работать на данной позиции, на испытательный срок? Во-первых, кандидат сразу ознакомится со спецификой проектов и решит, подходит ему эта работа или нет (а что он поймёт по задаче типа реверснуть массив на доске?) Во-вторых, компания быстро поймёт, подходит человечек или нет. Если по одному из вариантов "нет" - то быстро расстались и никаких проблем.
Давно применяем такой подход - пока работает.
PS. Тут некоторые писали, что к ним люди часто с фейковыми резюме приходят - но, честно говоря, мне трудно себе представить, как такое может сработать. Ну то есть может на какой-нибудь удалёнке в бодишоп ещё куда не шло, но в офис? Когда ты на виду у коллег и каждый твой коммит под микроскопом :) "не верю", в общем.
Думаю, все проблемы возникли из за того, что у вас в компании не налажены процессы разработки и обмена информацией с менеджментом. По сути, те задачи, которые вы на себя взяли, должен выполнять тимлид разработчиков, но ни в коем случае не продакт.
Общение с командой, постановка задач контроль исполнения, разговоры 1:1 - это типичная работа тимлида. Общение с клиентом вместе с руководителем проекта тоже. Меня, честно говоря, немного удивляет, чем у вас занимались тимлиды и начальник разработки в это время?
А токсичных удаков гнать надо в шею чем раньше, тем лучше. Будь они даже семи пядей во лбу. Как- то так.
В 2008 году купил недорогой ноутбук Acer Extenza. Живой до сих пор, только крышка треснула в одном месте. Правда, на нём даже скайп уже толком не работает, хотя винда 7-я как-то умудряется тарахтеть, с 4 гиг памяти то.
А в 2015 примерно купил себе HP, на тот момент очень неплохое железо. Помер примерно через год, месяца через два после окончания гарантии. Сначала стал процессор перегреваться (чистка не особо помогала), потом экран забарахлил, и в конце концов умер полностью.
Ремонтировать не стал, рабочие внутренности друзьям-коллегам раздал, которые "в теме", а останки на свалку отнёс. Такие дела..
Представляю собеседование на должность хирурга:
- У меня стаж работы хирургом в больнице более 10 лет, также работал военным врачом в Ираке, где приходилось оперировать без подручных средств и без анестезии, и почти все пациенты выжили...
- Хорошо-хорошо, вот вам тестовое задание, удалите-ка аппендицит вот тому дяденьке. И пожалуйста комментируйте каждый ваш шаг.
Но почему-то хирургов так на работу не берут, не правда ли? Моё имхо - технические собеседования на уровень мидл+ не нужны от слова совсем.
В европах и прочих америках к "высокооплачиваемым" относятся врачи и топ-менеджмент. Всякая прочая IT-обслуга и кодерки в том числе получает не сильно больше, скажем, водителя грузовика. Максимум в 1.5-2 раза.
То, что в пост-СССР, сидя на удалёнке, можно получать "в долларах" меньше, чем в европах, но это всё же сильно больше, чем в местной валюте - просто временная ошибка выжившего и не более.
У нас есть. Разговор с шефом R&D о предстоящих обязанностях и испытательный срок,прописанный в договоре. Пока что всегда срабатывало.
Конечно, неправильно. Как это обычно водится, "людьми до нас". Поэтому пришлось его выкорчёвывать и переделывать. В принципе, главная ошибка данных компонентов была в том, что авторы толком не владели С++ и решили применить классический Java подход к формированию классов и интерфейсов к ним.
Но С++ не Java, подобные вещи там не проходят бесследно. Как следствие, код, набитый С-макросами, кастами, методами-пустышками, плюс свой генератор кода и редактор компонентов (глючный, падающий). И всё это чудо работало раза в 3 медленнее безкомпонентного аналога, к тому же толком не умело в потоки.
Я к тому, что компоненты не панацея против сложности и при желании с ними можно сделать ещё хуже, чем без них. Модульный же подход решил в нашем случае все проблемы. Как по мне, модули - это следующий и более продуманный этап для борьбы со сложностью. Когда каждый модуль имеет лишь внешний интерфейс и протокол инициализации, а его внутренне представление скрыто от внешнего доступа, намного сложнее что либо сломать или "сделать не так".
Правильно, не надо так делать. Но компоненты этому способствуют. Поэтому лучше делать в модули.