Проектирование, циклы разработки и тестирование

[vilgeforce]

Я тут на питоне тулзинку пишу для преобразования одного формата файла в другой. Не подскажете, куда мне там Docker прицепить и зачем?

Количество опечаток в написанном грусть наводит на меня :-(

[Padaboo]

Да вот именно, что я загнал в проверку орфографии перед тем, как написать.
А пишете вы в основном космический корабль на самописном коде и говорите, что те кто фреймворками пользуются программировать не умеют :)

[vilgeforce]

Те, кто такие статьи пишет, не представляют что программирование бывает за пределами ихнего(!) вэба. А там есть и драйвера, где низкоуровневые выкидоны как раз очень даже нужны, и много чего еще.

[sshikov]

Да они и ихнего веба похоже не представляют. Вы хоть на упоминание MVC поглядите, в контексте базы данных. А потом сравните с классическим определением MVC, где база данных вовсе не упоминается — а речь идет просто о данных (модели).

[ashumkin]

На какой версии питона тулзинка работает? И с использованием каких библиотек? И у вас это в ридми написано как это дело ставить (пусть даже и pip install).
Только, например, у меня нет нужной версии питона, и/или я не хочу ставить непонятно какие либы, чтобы тулзинка заработала. Так что я предпочитаю запустить docker run ..., и ваша тулзинка выполнит свою работу мне на радость без лишних моих телодвижений…
Вы можете возразить, что в pip install ничего сложного нет, но дело даже не в сложности, а в дополнительных телодвижениях для пользователя, которому не надо разбираться с инфраструктурой тулзинки, ему нужен результат её работы… Питон можно легко заменить на Java, Go, Rust, whatever

[werklop]

Ну оооочень спорная статья

[berez]

Вам не придется вносить дополнительные задачи, такие как: изменение дизайна, функционала или чего то еще во время хода работ.

К вам никогда не прибегал заказчик с горящими глазами и «небольшими уточнениями» к ТЗ? Еще прибежит. :)

[conopus]

Поясните, пожалуйста, на чем основана рекомендация: «Не используйте системы постановки и исправления задач для тестировщиков.»

[Padaboo]

Основано на том, что не обходимо покрывать все программными автоматическими тестами — тогда и тестировщики как таковые будут ненужны.

[conopus]

Т. е. писать тесты на собственные задачи будут сами разработчики? Тестировщики автоматизаторы не нужны?

[BALEHOK]

Я, конечно, извиняюсь, но описанный подход кажется довольно узким. Даже для веба так не всегда сработает.

Пара комментариев из моего личного опыта работы (примерно 10 лет в вебе):
1. При работе в команде continuous integration — это наше все! Когда задача выполняется за 1, максимум 2 дня, конфликтов возникает сильно меньше. Соответственно, каждый пулит код из гита ежедневно, а то и не раз (простите, я настолько привык к гиту, что не представляю проект, где работает больше одного человека, без него).

2. К continuous integration добавляется continuous delivery — выкатываем новый релиз, как только готова фича (ежедневно? раз в 2-3 дня?). Это тоже работает не всегда и не везде. Для веба подходит прекрасно, но оно требует определенных усилий на внедрение…

3. Подробное ТЗ — это прекрасно. Но опять же не всегда. Например, для какого-нибудь стартапа чаще дешевле и правильнее выкатить фичу, сделанную «на коленке» за пару дней (или часов), и посмотреть как оно работает. Планирование дизайна при этом никто не отменял — замечательно, если оно сделано так, чтобы через неделю эту «какашку» можно было выкинуть за 2 минуты или превратить в адекватно написанный код малой кровью.

[PchelaBeshena]

не сочтите за грубость, но статья — повествование «очевидного тривиала» ?! Спасибо, кэп ;)

[zsiteru]

Разделяйте работу разработчиков по разным функциональным модулям, для того, что бы когда ветки системы контроля версий будут сливаться в одну — не возникало конфликтов.

В такой ситуации нет защиты от фактора автобуса. Если разработчик который делал конкретный модуль заболел, уволился, в отпуске то работа по этому модулю встанет.

Тут скорее нужно решать через организацию модулей в коде, что бы слияние не выдавало конфликтов, а не через организацию работы разработчиков.

[sshikov]

>Вы сэкономите время.
>Вы сэкономите деньги.
>Выполненные задачи будут более качественными.

И все это одновременно? Простите, но автор либо троллит (причем плохо, не интересно), либо откровенно обманывает. Вероятнее всего — себя.

[Padaboo]

Покрывая все тестами:
вы сокращаете количество появляющихся ошибок.
сокращаете затраты на тестировщиков.
прорабатывая тех задание хорошо вы оскращаете количество фишек которые нужно внедрить и количество задач которые нужно выполнить.

увеличивая время на выполнение задачи — вы даете возможность ее качественно проработать.

Я бы не кидался такими обвинениями.

[sshikov]

>Я бы не кидался такими обвинениями.
А я вот себе позволю. Практически каждый в IT знает формулу: «Мы умеем делать быстро, качественно, и дешево — выберите любые два пункта из трех». А у вас эти пункты перечислены все вместе, так, как будто вы можете достичь их всех одновременно. Что, очевидно, неправда.

Но судя по вашему ответу, вы похоже будете настаивать, что можете достичь всех трех?

[Padaboo]

Для крупных проектов эта формула выгоднее чем любая другая — я в этом убежден.

Я разработчик и мне в этом плане важен стабильный код.

Если конечно как писалось одним из комментаторов выше вы не делаете: утилиту, драйвер или интернет магазин.