Size: a a a

2020 September 05

SS

Slava Savitskiy in ctodailychat
Slava Savitskiy
в каждом случае ответ разный. общая картина такая, что мы строим невероятно сложные системы, понимать которые и разбираться как она работает с другими системами - сложно и затратно. проще захреначить в прод и посмотреть, что получилось
я же не говорю, чот мы хреначим без тестов. на каждое изменение архитектуры есть свое обсуждение и опытные инженеры, которые укажут на то, что может пойти не так. но все варианты то ты не просчитаешь. поэтому подход, когда инженер устроил инцидент из-за ошибки - и его за это увольняют неправильный. это напрочь убьет креативность, все будут сидеть и бояться что-то поменять, опасаясь санкций. ship fast fail fast, или как-то так
источник

NK

Nikita Kulikov in ctodailychat
Slava Savitskiy
я же не говорю, чот мы хреначим без тестов. на каждое изменение архитектуры есть свое обсуждение и опытные инженеры, которые укажут на то, что может пойти не так. но все варианты то ты не просчитаешь. поэтому подход, когда инженер устроил инцидент из-за ошибки - и его за это увольняют неправильный. это напрочь убьет креативность, все будут сидеть и бояться что-то поменять, опасаясь санкций. ship fast fail fast, или как-то так
Да, я говорю то же самое, круть
источник

NK

Nikita Kulikov in ctodailychat
Видимо не так выразил
источник

SS

Slava Savitskiy in ctodailychat
я просто на другой пост отвечал =) про "почему вылезает в другом месте"
источник

NK

Nikita Kulikov in ctodailychat
Если понадобится, будем писать качественно. Но медленно
источник

A

Alex in ctodailychat
KN
Я не обвиняю вас и вашу команду. Нельзя настроить систему так, чтобы при обновлении ПО какие-то важные части никак не затрагивались? Пусть будут баги, ок. Но почему когда обновляется поиск какой-то программы, баг вылезает совсем в другом месте?
С одной стороны, [вставить мем с боромиром про "нельза просто взять и ..."]. В сложных системах не так просто все предусмотреть, тестирование и дебаггинг экспоненциально геморнее.

С другой стороны - я тебе отлично понимаю. Я хоть и сам программер, но ппц бесит ответы типа "не бывает команд которые не делают ошибок" как сказал @slavasav Просто надо сформулировать по-другому - цена от этой ошибки не настолько высока, чтобы инвестировать в rock-solid архитектуру. Спотифай ничего не потерял, если поиск заикнулся на полчаса. Это всего-лишь стриминг музыки, камон. Не система мониторинга за охлаждением атомного реактора
источник

MS

Max Syabro in ctodailychat
Емнип в букенге тестов нет и они ошибки на проде отслеживают по метрикам
источник

MS

Max Syabro in ctodailychat
Где-то несколько раз слышал такое
источник

A

Alex in ctodailychat
ну и нормально...
источник

A

Alex in ctodailychat
там выше написали, иногда экономически выгоднее написать криво но быстро, чем надежно и долго
источник

MS

Max Syabro in ctodailychat
вообще круто
источник

A

Andrey in ctodailychat
источник

A

Andrey in ctodailychat
Счётчик уменьшается на неделю
источник

K

KN in ctodailychat
Alex
С одной стороны, [вставить мем с боромиром про "нельза просто взять и ..."]. В сложных системах не так просто все предусмотреть, тестирование и дебаггинг экспоненциально геморнее.

С другой стороны - я тебе отлично понимаю. Я хоть и сам программер, но ппц бесит ответы типа "не бывает команд которые не делают ошибок" как сказал @slavasav Просто надо сформулировать по-другому - цена от этой ошибки не настолько высока, чтобы инвестировать в rock-solid архитектуру. Спотифай ничего не потерял, если поиск заикнулся на полчаса. Это всего-лишь стриминг музыки, камон. Не система мониторинга за охлаждением атомного реактора
Я не программист. Но с моей колокольни кажется что есть одно решение. Если система сложная, то значит и людей должно быть достаточное количество, чтобы минимизировать ошибки как мелкие, так и серьезные.

Элементарно даже на репорты, бывает, не отвечают.
источник

A

Alex in ctodailychat
KN
Я не программист. Но с моей колокольни кажется что есть одно решение. Если система сложная, то значит и людей должно быть достаточное количество, чтобы минимизировать ошибки как мелкие, так и серьезные.

Элементарно даже на репорты, бывает, не отвечают.
nothing personal, just business (tm)

Вопрос приоритизации. Fortnite и Pubg с точки зрения качества кода - глюкавое говно. Но зарабатывают ярды же.... мир несправедлив
источник

RK

Roman Kononov in ctodailychat
Alex
там выше написали, иногда экономически выгоднее написать криво но быстро, чем надежно и долго
А есть ещё бюджет на даунтаймы
источник

K

KN in ctodailychat
Alex
nothing personal, just business (tm)

Вопрос приоритизации. Fortnite и Pubg с точки зрения качества кода - глюкавое говно. Но зарабатывают ярды же.... мир несправедлив
К сожалению да. Но рынок рано или поздно прогнется под качество, потому что иначе уже никак
источник

A

Alex in ctodailychat
хорошо бы если так. Пока он, к сожалению, прогибается в обратную сторону. Стартапы оверинжинирят простые вещи и пишут глюкавый отстой... Потому что связка "качество кода <=> фин.результат" становится все призрачнее. Можно вообще быть убыточным и зарабатывать на valuation.
источник

SS

Slava Savitskiy in ctodailychat
KN
Я не программист. Но с моей колокольни кажется что есть одно решение. Если система сложная, то значит и людей должно быть достаточное количество, чтобы минимизировать ошибки как мелкие, так и серьезные.

Элементарно даже на репорты, бывает, не отвечают.
звучит хорошо. есть по крайней мере одно но, чем больше людей, тем сложнее им договариваться и делиться информацией. смотришь, и оп, мы опять вернулись к разговору про 3 сениора напишут за 3 месяца, а 20 человек 2 года будут делать.
источник

AR

Anton Revyako in ctodailychat
KN
Из-за этого не хочется обновлять программы. У меня стоит Photoshop 2020 года и 2018. Потому что в 2020 висит баг, который никак не исправят
просто адоби - гадские гады. что они творили с флешом, пока он был жив - стыдно вслух произносить. в наше время за такую скорость доставки фич закапывают
источник