С тех пор как я работаю на проекте QR (Queensland Rail) я чувствую какую-то привязанность ко всем местным поездам с аббревиатурой QR. Так что это фото весьма символично.
Чем я сейчас занимаюсь – сложно сказать. Но если описывать одним словом – программирование. Да, именно оно, мной всё время так ненавистное. И что самое интересное, я с удовольствием иду на работу, чтобы продолжать в том же духе (не ненавидеть, а программировать :). Это низкоуровневое и весьма специфическое и очень железнодорожное. Наконец-то разобралась, куда какие светофоры ставить, и в какой последовательности они включаются.
8 comments:
А можно по подробней про организацию? Я так понимаю это проект повышеной безопасности тойсть программа не должна содержать ошибок вобще. Мне интересно соотношение тестеров на программиста. Каким образом достигается повышеная отказо устойчивость, повышение качества и т.д. Заранее благодарен.
Удовольствия можно получать от работы в том случае когда творишь :)
Вадим Сотников
Программа пишется, компилируется - программер,
Проверяется - продвинутый программер,
Заверяется - кастомер.
Заноситься в хардваре - тестируется.
Если неправильно работает - начинаем с пункта 1.
ps Компилятор работает очень хорошо, а всякие логические ошибки продвинутый программер вылавливает.
Тестирование на хардваре - длинный отдельный разговор, но та логика, которая идёт в хардваре (которую пишу я), на хардваре в основном тестируется на совместимость с протоколами/портами. Вернее тестируется по полной программе, но проблемы в основном не в самой логике, а том, как она взаимодействует с остальными компонентами софта (Вовка занимается _операционной системой_ этого харда)и софтом другий станций.
всё это весьма путанно, но сложно перевести это с английского сохраняя специфику и неразглашая секреты чисто ансалдовского изобретения :-)
Спасибо. Ничего нового :( Все тоже самое только строже Придется читать NASA.
Спасибо
Вадим
Тут все процессы очень формальные, и их много. Благодаря этому несмотря на страшное раздолбайство в рядах получается создавать нормальные продукты :)
Например проект на котором я сейчас (просто крупный рефакторинг сузествующего продукта).
Только нашей же командой будет проводиться 3 вида тестинга. Плюс собственный аксептанс тестинг кастомера. Плюс интегрейшен на месте.
Программеры же в процессе производят тонну документации. Все строго через реквайрменты. Каждый реквайрмент - тестабельный.
И т.п.
Вадим, тут такие бизоны работают ! Пол-дня трындят, а потом за 2 часа делают то, на что у меня неделя ушла бы :) (правда у них опыта за плечами лет на 15 поболе)
Да уж ничего не скажешь такого я еще не встречал :) Просто как посмотрю по словам ничего сверхестественного. Но если там такие бизоны на лугах пасутся то ничего удивительного. Просто интересует вопрос как при начальном уровне опыта получить хороший продукт.
Получить хороший продукт ?
Смотря что имеется в виду под хорошим :)
Если оптимальным по скорости, масштабируемости и т.п. - то ИМХО тут только опыт (свой или чужой).
А если продукт с минимальным кол-вом ошибок, покрытием всей функциональности и более-менее в сроки - строгое следование формальным процедурам.
Неформальные, agile методологии хороши когда у тебя есть много опыта или же для продуктов где safety не есть критический фактор. Ну или в связке с другими технологиями.
Под хорошим ?
Успеть по сроком и выполнить все требования которые заявлены. При этом, что бы было как можно меньше ошибок.
Вобще меня интересуют проекты в которых вобще недолжно быть ошибок тойсть программы от которых будет зависить жизни людей.
Ну тогда процессы, процессы и еще раз процессы.
Post a Comment