Comments 17
Я тут на питоне тулзинку пишу для преобразования одного формата файла в другой. Не подскажете, куда мне там Docker прицепить и зачем?
Количество опечаток в написанном грусть наводит на меня :-(
Количество опечаток в написанном грусть наводит на меня :-(
Да вот именно, что я загнал в проверку орфографии перед тем, как написать.
А пишете вы в основном космический корабль на самописном коде и говорите, что те кто фреймворками пользуются программировать не умеют :)
А пишете вы в основном космический корабль на самописном коде и говорите, что те кто фреймворками пользуются программировать не умеют :)
На какой версии питона тулзинка работает? И с использованием каких библиотек? И у вас это в ридми написано как это дело ставить (пусть даже и pip install).
Только, например, у меня нет нужной версии питона, и/или я не хочу ставить непонятно какие либы, чтобы тулзинка заработала. Так что я предпочитаю запустить docker run ..., и ваша тулзинка выполнит свою работу мне на радость без лишних моих телодвижений…
Вы можете возразить, что в pip install ничего сложного нет, но дело даже не в сложности, а в дополнительных телодвижениях для пользователя, которому не надо разбираться с инфраструктурой тулзинки, ему нужен результат её работы… Питон можно легко заменить на Java, Go, Rust, whatever
Ну оооочень спорная статья
Вам не придется вносить дополнительные задачи, такие как: изменение дизайна, функционала или чего то еще во время хода работ.
К вам никогда не прибегал заказчик с горящими глазами и «небольшими уточнениями» к ТЗ? Еще прибежит. :)
Поясните, пожалуйста, на чем основана рекомендация: «Не используйте системы постановки и исправления задач для тестировщиков.»
Я, конечно, извиняюсь, но описанный подход кажется довольно узким. Даже для веба так не всегда сработает.
Пара комментариев из моего личного опыта работы (примерно 10 лет в вебе):
1. При работе в команде continuous integration — это наше все! Когда задача выполняется за 1, максимум 2 дня, конфликтов возникает сильно меньше. Соответственно, каждый пулит код из гита ежедневно, а то и не раз (простите, я настолько привык к гиту, что не представляю проект, где работает больше одного человека, без него).
2. К continuous integration добавляется continuous delivery — выкатываем новый релиз, как только готова фича (ежедневно? раз в 2-3 дня?). Это тоже работает не всегда и не везде. Для веба подходит прекрасно, но оно требует определенных усилий на внедрение…
3. Подробное ТЗ — это прекрасно. Но опять же не всегда. Например, для какого-нибудь стартапа чаще дешевле и правильнее выкатить фичу, сделанную «на коленке» за пару дней (или часов), и посмотреть как оно работает. Планирование дизайна при этом никто не отменял — замечательно, если оно сделано так, чтобы через неделю эту «какашку» можно было выкинуть за 2 минуты или превратить в адекватно написанный код малой кровью.
Пара комментариев из моего личного опыта работы (примерно 10 лет в вебе):
1. При работе в команде continuous integration — это наше все! Когда задача выполняется за 1, максимум 2 дня, конфликтов возникает сильно меньше. Соответственно, каждый пулит код из гита ежедневно, а то и не раз (простите, я настолько привык к гиту, что не представляю проект, где работает больше одного человека, без него).
2. К continuous integration добавляется continuous delivery — выкатываем новый релиз, как только готова фича (ежедневно? раз в 2-3 дня?). Это тоже работает не всегда и не везде. Для веба подходит прекрасно, но оно требует определенных усилий на внедрение…
3. Подробное ТЗ — это прекрасно. Но опять же не всегда. Например, для какого-нибудь стартапа чаще дешевле и правильнее выкатить фичу, сделанную «на коленке» за пару дней (или часов), и посмотреть как оно работает. Планирование дизайна при этом никто не отменял — замечательно, если оно сделано так, чтобы через неделю эту «какашку» можно было выкинуть за 2 минуты или превратить в адекватно написанный код малой кровью.
не сочтите за грубость, но статья — повествование «очевидного тривиала» ?! Спасибо, кэп ;)
Разделяйте работу разработчиков по разным функциональным модулям, для того, что бы когда ветки системы контроля версий будут сливаться в одну — не возникало конфликтов.
В такой ситуации нет защиты от фактора автобуса. Если разработчик который делал конкретный модуль заболел, уволился, в отпуске то работа по этому модулю встанет.
Тут скорее нужно решать через организацию модулей в коде, что бы слияние не выдавало конфликтов, а не через организацию работы разработчиков.
>Вы сэкономите время.
>Вы сэкономите деньги.
>Выполненные задачи будут более качественными.
И все это одновременно? Простите, но автор либо троллит (причем плохо, не интересно), либо откровенно обманывает. Вероятнее всего — себя.
>Вы сэкономите деньги.
>Выполненные задачи будут более качественными.
И все это одновременно? Простите, но автор либо троллит (причем плохо, не интересно), либо откровенно обманывает. Вероятнее всего — себя.
Покрывая все тестами:
вы сокращаете количество появляющихся ошибок.
сокращаете затраты на тестировщиков.
прорабатывая тех задание хорошо вы оскращаете количество фишек которые нужно внедрить и количество задач которые нужно выполнить.
увеличивая время на выполнение задачи — вы даете возможность ее качественно проработать.
Я бы не кидался такими обвинениями.
вы сокращаете количество появляющихся ошибок.
сокращаете затраты на тестировщиков.
прорабатывая тех задание хорошо вы оскращаете количество фишек которые нужно внедрить и количество задач которые нужно выполнить.
увеличивая время на выполнение задачи — вы даете возможность ее качественно проработать.
Я бы не кидался такими обвинениями.
>Я бы не кидался такими обвинениями.
А я вот себе позволю. Практически каждый в IT знает формулу: «Мы умеем делать быстро, качественно, и дешево — выберите любые два пункта из трех». А у вас эти пункты перечислены все вместе, так, как будто вы можете достичь их всех одновременно. Что, очевидно, неправда.
Но судя по вашему ответу, вы похоже будете настаивать, что можете достичь всех трех?
А я вот себе позволю. Практически каждый в IT знает формулу: «Мы умеем делать быстро, качественно, и дешево — выберите любые два пункта из трех». А у вас эти пункты перечислены все вместе, так, как будто вы можете достичь их всех одновременно. Что, очевидно, неправда.
Но судя по вашему ответу, вы похоже будете настаивать, что можете достичь всех трех?
Sign up to leave a comment.
Проектирование, циклы разработки и тестирование