> Не встречал такого в реальности. Да, слышал, но по факту не знаю ни о ком, кто так делает. Все используют "технологию" Аджайл, в виде "херак-херак и в продакшн".
В критических приложениях, как например в ПО критических систем самолетов каждая строчка кода должна быть покрыта требованиями спецификации описывающими что конкретно она делает.
Для кассового ПО видимо нет таких требований, или никто их не проверяет.
> я в 34м посте писал как работает именно эта контора. Ситуация когда контора пишущая ПО для 20% кассовых аппаратов в стране говорит "не шмогла" для задачи которую студент с нуля пишет за 2 недели, это на мой взгляд трындец.
Они Васю уже к этому времени уволили.
А больше никто не понимает как оно работает!
Но разработка полноценной программной документации, так чтобы можно было дядечке с улицы разобраться в коде (типа как по DO-178 в авиации), удорожает проект на порядок.
Если нет регулятора который заставляет это делать, никакая рука рынка не заставит разрабов этим заниматься.
Есть у меня дружок который работает начальником погромистов в Дойче Банке. Говорит у них тоже царит принцип хуяк-хуяк и в продакшен, хотя деньги там програмеры получают конские.
> Совсем не согласен. Время занимает немного, а культуру поддерживает - все в команде стремятся писать понятный код. Желание давать переменным дурацкие имена уходит после нескольких возвращений кода на доработку. Также отсекаются ошибки копипасты и опечатки, а иногда и вовсе кому-нибудь приходится полностью переделать свою работу, ибо на этапе ревью придумали и обосновали решение получше. > Если в команде 3 и более человек, то нет ни одной достойной причины, чтобы отказаться от этого этапа разработки ПО.
ИМХО это легко обосновать когда есть куча дешевых погромистов на удаленке. Индусов или наших из провинции.
С московскими или упаси ТНБ европейскими ЗП програмеров код получается золотым, если его 3 человека ревьюят.
> Дороже не делать ревью т.к. пинг понга между QA и разрабами существенно больше выходит, а результат работы - говнокод, который поддерживать сложно, а передать другим людям практически невозможно, т.к только автор понимает как "оно" работает.
Ты говоришь про скрытые затраты которых заказчик не видит.
А вот то, что конкуренты не делающие ревью предлагают разработать ПО быстрее и дешевле, заказчик хорошо видит.
> Принцип хуяк-хуяк и в продакшн устанвливается конкретным начальником погромистов. Т.е. если у него именно так - то в соседней команде может быть и код ревью, и QA и даже UAT.
Ну то что конкретный начальник погромистов может внедрить у себя всякое, это понятно.
Другое дело, что это может быть стандартом организации или даже отрасли.
Так вот я был удивлен, когда узнал, что для банковского ПО таких стандартов нет.
Думаю причина в том, что банкам важнее конфиденциальность чем отсутствие непреднамеренных ошибок.
Потому они предпочитают держать мало погромистов за конские деньги, а не много на удаленке.
Отсюда вытекает черезвычайная дороговизна всяких QA активностей.
Ну за что купил, за то продаю.
Товарищ вроде занимается софтом для машинной торговли на разнице котировок на разных площадках.
В авиации например есть 5 уровней критичности ПО и соответственно жестко прописанные стандарты разработки для каждого уровня.
Если не предоставишь всю отчетную документацию по процессу разработки то сертификат типа воздушного судна не получишь.
А вот кто занимается определением стандартов разработки для банковского ПО мне непонятно. Как я понял формализованных уровней критичности у них нет.
Не только. Они там запилили мега скоростной выделенный кабель через окиян и торгуют на том что на какие-то миллисекунды опережают большинство остальных игроков в знании куда пошли котировки на американских площадках.
Как-то так в общих словах он объяснял.
Сейчас, сейчас
не нацист »
В критических приложениях, как например в ПО критических систем самолетов каждая строчка кода должна быть покрыта требованиями спецификации описывающими что конкретно она делает.
Для кассового ПО видимо нет таких требований, или никто их не проверяет.