> Причастные граждане на хабре отметили, что одно 20 декабря для них, по выручке - примерно как неделя в июне.
Если это неделя июня 2017 года, когда с 1 июля почти все должны были перейти на онлайн-кассы, то да. Когда эти сраные ФНы ждали месяцами и приходилось тянуть до последнего, то ЦТОшники трудились не покладая рук, т.к. все ломились в последние недели.
> Много где работал, такого не встречал. Однако, когда столкнулся практика очень понравилась.
Я ж о том же - практика явно неплохая, но как факт - жрущая некоторое время как исполнителя, так и смежников. Тот факт, что данные человекочасы могут сэкономить оные же в дальнейшем не ебет до первого жареного петуха. А после оного - поздно да и ваще, "авось пронесет".
> Не встречал такого в реальности. Да, слышал, но по факту не знаю ни о ком, кто так делает. Все используют "технологию" Аджайл, в виде "херак-херак и в продакшн".
В критических приложениях, как например в ПО критических систем самолетов каждая строчка кода должна быть покрыта требованиями спецификации описывающими что конкретно она делает.
Для кассового ПО видимо нет таких требований, или никто их не проверяет.
> Для кассового ПО видимо нет таких требований, или никто их не проверяет.
я в 34м посте писал как работает именно эта контора. Ситуация когда контора пишущая ПО для 20% кассовых аппаратов в стране говорит "не шмогла" для задачи которую студент с нуля пишет за 2 недели, это на мой взгляд трындец.
>
> Я ж о том же - практика явно неплохая, но как факт - жрущая некоторое время как исполнителя, так и смежников. Тот факт, что данные человекочасы могут сэкономить оные же в дальнейшем не ебет до первого жареного петуха. А после оного - поздно да и ваще, "авось пронесет
Совсем не согласен. Время занимает немного, а культуру поддерживает - все в команде стремятся писать понятный код. Желание давать переменным дурацкие имена уходит после нескольких возвращений кода на доработку. Также отсекаются ошибки копипасты и опечатки, а иногда и вовсе кому-нибудь приходится полностью переделать свою работу, ибо на этапе ревью придумали и обосновали решение получше.
Если в команде 3 и более человек, то нет ни одной достойной причины, чтобы отказаться от этого этапа разработки ПО.
> я в 34м посте писал как работает именно эта контора. Ситуация когда контора пишущая ПО для 20% кассовых аппаратов в стране говорит "не шмогла" для задачи которую студент с нуля пишет за 2 недели, это на мой взгляд трындец.
Они Васю уже к этому времени уволили.
А больше никто не понимает как оно работает!
Но разработка полноценной программной документации, так чтобы можно было дядечке с улицы разобраться в коде (типа как по DO-178 в авиации), удорожает проект на порядок.
Если нет регулятора который заставляет это делать, никакая рука рынка не заставит разрабов этим заниматься.
Есть у меня дружок который работает начальником погромистов в Дойче Банке. Говорит у них тоже царит принцип хуяк-хуяк и в продакшен, хотя деньги там програмеры получают конские.
> Совсем не согласен. Время занимает немного, а культуру поддерживает - все в команде стремятся писать понятный код. Желание давать переменным дурацкие имена уходит после нескольких возвращений кода на доработку. Также отсекаются ошибки копипасты и опечатки, а иногда и вовсе кому-нибудь приходится полностью переделать свою работу, ибо на этапе ревью придумали и обосновали решение получше.
> Если в команде 3 и более человек, то нет ни одной достойной причины, чтобы отказаться от этого этапа разработки ПО.
ИМХО это легко обосновать когда есть куча дешевых погромистов на удаленке. Индусов или наших из провинции.
С московскими или упаси ТНБ европейскими ЗП програмеров код получается золотым, если его 3 человека ревьюят.
> ИМХО это легко обосновать когда есть куча дешевых погромистов на удаленке. Индусов или у наших из провинции.
> С московскими или упаси ТНБ европейскими ЗП програмеров код получается золотым, если его 3 человека ревьюят.
Дороже не делать ревью т.к. пинг понга между QA и разрабами существенно больше выходит, а результат работы - говнокод, который поддерживать сложно, а передать другим людям практически невозможно, т.к только автор понимает как "оно" работает.
> Это ж получается, продукт перед поставкой вообще не тестируется и не проверяется? Ну збс, чо.
Видимо тайм-бомба была, чтоб её рассмотреть нужно код ревью проводить, причём это должен делать другой сотрудник. Но скорее всего это был один охеренный программист, которого никто не проверял.
> Дороже не делать ревью т.к. пинг понга между QA и разрабами существенно больше выходит, а результат работы - говнокод, который поддерживать сложно, а передать другим людям практически невозможно, т.к только автор понимает как "оно" работает.
Ты говоришь про скрытые затраты которых заказчик не видит.
А вот то, что конкуренты не делающие ревью предлагают разработать ПО быстрее и дешевле, заказчик хорошо видит.
А ещё, тут все код-ревью обсуждают. Если вы вспомните, как работали первые прошивки для онлайн-касс, то вас сразу осенит, что там не только ревью, но и кода, в обычном понимании не было. Касса переставала работать после сотни чеков и требовала перезагрузки.
> Есть у меня дружок который работает начальником погромистов в Дойче Банке. Говорит у них тоже царит принцип хуяк-хуяк и в продакшен, хотя деньги там програмеры получают конские.
Принцип хуяк-хуяк и в продакшн устанвливается конкретным начальником погромистов. Т.е. если у него именно так - то в соседней команде может быть и код ревью, и QA и даже UAT.
> Принцип хуяк-хуяк и в продакшн устанвливается конкретным начальником погромистов. Т.е. если у него именно так - то в соседней команде может быть и код ревью, и QA и даже UAT.
Ну то что конкретный начальник погромистов может внедрить у себя всякое, это понятно.
Другое дело, что это может быть стандартом организации или даже отрасли.
Так вот я был удивлен, когда узнал, что для банковского ПО таких стандартов нет.
Думаю причина в том, что банкам важнее конфиденциальность чем отсутствие непреднамеренных ошибок.
Потому они предпочитают держать мало погромистов за конские деньги, а не много на удаленке.
Отсюда вытекает черезвычайная дороговизна всяких QA активностей.
> Так вот я был удивлен, когда узнал, что для банковского ПО таких стандартов нет.
Банковское ПО очень разное, особенно в группе типа дольчегабанка. Много некритичных для внутреннего использования, от падения которых не пострадает никто, но есть и критичные, падение которых чревато прямыми убытками в десятки, а то и сотни миллионов. Забавно, что при этом критичные приложения могут писать 2-3 погромиста, один из которых еще и тестировщик, а на всяком третьестепенном говне могут сидеть 10 говнокодеров с почти отрицательным результатом.
> Думаю причина в том, что банкам важнее конфиденциальность чем отсутствие непреднамеренных ошибок.
Несколько не так. Конфиденциальность, конечно, важна, но она тут не при чем. Внутрибанковский софт очень разный с очень разной критичностью для очень разных бизнесов. Он абсалютно не монолитен. В банках работают сотни, а то и тысячи разных систем ПО. Если коснуться торговли акциями или валютой, то есть, например, коннективити - это очень критичная часть как по стабильности, так и по скорости. Её тестируют и в хвост, и в гриву. Экзекьюшн - тоже критичен, и тоже тестируют. Аналитические системы - уже не так критичны, ну не увидит какой-нибудь трейдер красивого графика, ну и хрен с ним, и поэтому к таким системам меньше требования.
> Потому они предпочитают держать мало погромистов за конские деньги, а не много на удаленке.
700-800 айтишников (в основном - разработчиков) только в московском техцентре - это мало? На удаленке - сотни индусов, занимающиеся такой маловажной частью, как поддержка серверов.
> Отсюда вытекает черезвычайная дороговизна всяких QA активностей.
Нет. QA не дорог, особенно если учитывать потери от плохо протестированного софта.
Ну за что купил, за то продаю.
Товарищ вроде занимается софтом для машинной торговли на разнице котировок на разных площадках.
В авиации например есть 5 уровней критичности ПО и соответственно жестко прописанные стандарты разработки для каждого уровня.
Если не предоставишь всю отчетную документацию по процессу разработки то сертификат типа воздушного судна не получишь.
А вот кто занимается определением стандартов разработки для банковского ПО мне непонятно. Как я понял формализованных уровней критичности у них нет.
У меня знакомых в этой конторе работает с десяток, более или менее знаю, что там и как
> Товарищ вроде занимается софтом для машинной торговли на разнице котировок на разных площадках.
Реализация косяков, описанных . в "Мифический человеко-месяц или Как создаются программные системы" Брукса в масштабах страны.
После того, как один "очень хороший программист" одной строкой кода похерил консистентость документов в системе, да так, что пришлось 18 часов работы промгиганта выбросить и поднимать весь ландшафт из бэкапа - я читаю весь критичный код (обновления БД, интеграцию, проверки), который пишут программисты построчно.
И интегротестами стараюсь не пренебрегать.
Правильно говорил Мюллер - верить нельзя никому, даже себе.
Не только. Они там запилили мега скоростной выделенный кабель через окиян и торгуют на том что на какие-то миллисекунды опережают большинство остальных игроков в знании куда пошли котировки на американских площадках.
Как-то так в общих словах он объяснял.
> А что, есть программный продукт, который поставляется не as is, с отказом от всех претензий за любые последствия использования?
например ПО управляющее светофорами. Как раз кто то писал что пришлось подписать кучу бумажек связанных с отвественностью если двум направлениям на перекрестке будет зеленый, например.
> Количество факапов стало радикально меньше. Имхо - экономит время в итоге.
Я-то понимаю, что меньше, вот только оно неочевидно совсем. Плюс у заказчика как правило есть железный аргумент "пишите без багов", чеб не "переплачивать" за всякие там непонятные ревью.
Сейчас, сейчас
Если это неделя июня 2017 года, когда с 1 июля почти все должны были перейти на онлайн-кассы, то да. Когда эти сраные ФНы ждали месяцами и приходилось тянуть до последнего, то ЦТОшники трудились не покладая рук, т.к. все ломились в последние недели.