Просто навеяло.
Вчера был в гостях на работе у своего товарища. Пересекся с ребятами, которые по заказу компании друга (не IT-компания), делают им софт. Они в это время проверяли его на реальном железе (софт связан с радиосвязью).
По словам товарища, им часто приходится перепроверять и чинить то, что раньше работало.
Ребята-разработчики это с грустью подтвердили.
Спросил, есть ли у них автоматические тесты, хоть какие-нибудь. Порадовало то, что они про тесты знают, но дальше огорчение - они их не пишут. Про Continuous Integration тоже знают, но тоже не используют.
Знаете почему? Правильно - времени не хватает. А еще их начальник говорит, что тесты должны писать тестировщики. А тестировщиков у них тоже нет.
Занавес.
PS компания-разработчик, кстати, делает реально крутые ноу-хау вещи, но вот how это все делается, наводит на грустные мысли.
Вчера был в гостях на работе у своего товарища. Пересекся с ребятами, которые по заказу компании друга (не IT-компания), делают им софт. Они в это время проверяли его на реальном железе (софт связан с радиосвязью).
По словам товарища, им часто приходится перепроверять и чинить то, что раньше работало.
Ребята-разработчики это с грустью подтвердили.
Спросил, есть ли у них автоматические тесты, хоть какие-нибудь. Порадовало то, что они про тесты знают, но дальше огорчение - они их не пишут. Про Continuous Integration тоже знают, но тоже не используют.
Знаете почему? Правильно - времени не хватает. А еще их начальник говорит, что тесты должны писать тестировщики. А тестировщиков у них тоже нет.
Занавес.
PS компания-разработчик, кстати, делает реально крутые ноу-хау вещи, но вот how это все делается, наводит на грустные мысли.
 |
| тут (с) |
И что интресно им за это платят. Значит бизнес голосует рублем за тот подход что им нужен. Да и слушать их всех надо с некой долей скепсиса. В моей прошлой конторе начальство было далеко от разработки. Самих разработчиков стало напрягать собирать 40 минут С++ проект на своей машине, в инете было даже не полазать так все тормозило и мы собрали из старого хлама "сервер компиляции" , написали пару скриптов и запускали их удаленно. Прообраз CI сервера. Тоже самое было с тестами, писались консольные эмуляторы, программы выдававшие портянку сообщении о разных проверках или же просто гуевые апликухи с кучей кнопок проверяющие какую то фичку.
ОтветитьУдалитьПлатят, потому что ноу-хау (это факт).
ОтветитьУдалитьА насчет слушать их - не слушать. Да, понятно, что правильно писать - это не начальник должен за тебя делать. Это должно быть твое понимание профессии. Про это я им тоже сказал. Но согласись - проще и приятней работать, когда ты понимаешь, что начальник с тобой на одной волне :)
Отчасти соглашусь. Но я часто вижу как это саботируется. Люди говорят "мы пишем тесты" и это занимает какое-то неразумное время и на выходе что то ужасное. Так же уверею тебя, когда начальство говорит "Весь код должен быть с тестами" выходит еще хуже, особенно в старых\уставших командах с легаси продуктами. Людям тяжело менять то к чему они привыкли...
ОтветитьУдалитьты просто пессимист :) Но тоже отчасти соглашусь
ОтветитьУдалитьОпыт сын ошибок трудных... Сам же всё знаешь.
ОтветитьУдалитьСдается мне что у "радистов" это клиническое. Про тесты они знают, но когда пытаешься у них узнать
ОтветитьУдалить- а почему же их не пишете?
- Ну ты понимаешь, это же так сложно. Как же мы проверим вот это блок АЦП и вот этот приемник ?
Ты начинаешь им рассказывать , что тут ставишь стенд, тут пишется специальный ответный софт. а они возражают:
- Не, это дофига времени нужно, у нас такого времени нет.
- Хорошо, но вы же можете" проверить это до выхода в эфир? - спрашиваешь ты.
- Конечно можем - отвечают они.
- Так и в чем проблема? -
- Ну у нас программа под это не заточена, это дофига времени нужно.
И получается замкнутый круг, точнее сказка про белого бычка. Даже когда приносишь им готовое решение, как сделать полный цикл проверки, все равно найдут причину как не делать автотесты.
То есть на самом деле они не пишут тесты, просто потому что им лень, но в этом никто и никогда не сознается. Гораздо интереснее фигачить новые фичи, потому что заказчик все-равно придет к ним из-за отсутствия альтернатив и поэтому не о чем беспокоиться.
Как правило у них и баг трекинговой системы обычно нет, потому что тоже лень заполнять, ибо "и так все понятно что делать" и "А смысл планировать, если я не знаю когда я закончу".
Это я называю "Haсker-driven development" - у меня есть мысль и я ее буду фигачить.
Сдается мне что у "радистов" это клиническое. Про тесты они знают, но когда пытаешься у них узнать
ОтветитьУдалить- а почему же их не пишете?
- Ну ты понимаешь, это же так сложно. Как же мы проверим вот это блок АЦП и вот этот приемник ?
Ты начинаешь им рассказывать , что тут ставишь стенд, тут пишется специальный ответный софт. а они возражают:
- Не, это дофига времени нужно, у нас такого времени нет.
- Хорошо, но вы же можете" проверить это до выхода в эфир? - спрашиваешь ты.
- Конечно можем - отвечают они.
- Так и в чем проблема? -
- Ну у нас программа под это не заточена, это дофига времени нужно.
И получается замкнутый круг, точнее сказка про белого бычка. Даже когда приносишь им готовое решение, как сделать полный цикл проверки, все равно найдут причину как не делать автотесты.
То есть на самом деле они не пишут тесты, просто потому что им лень, но в этом никто и никогда не сознается. Гораздо интереснее фигачить новые фичи, потому что заказчик все-равно придет к ним из-за отсутствия альтернатив и поэтому не о чем беспокоиться.
Как правило у них и баг трекинговой системы обычно нет, потому что тоже лень заполнять, ибо "и так все понятно что делать" и "А смысл планировать, если я не знаю когда я закончу".
Это я называю "Haсker-driven development" - у меня есть мысль и я ее буду фигачить.
Да, может и так.
ОтветитьУдалить