Автоматизация хаоса #85

Если автоматизировать хаос, получится автоматизированный хаос. К сожалению, информатизацию нередко пытаются подменить автоматизацией. При этом забывают, что компьютеры и программы — лишь инструменты. Если дом плохо спроектирован, даже лучшие доски и гвозди, пилы и рубанки не устранят ошибок проекта, все равно жизнь хозяевам будет не в радость. Если методика учета искажает информацию или не дает ее вовсе, никакие информационные технологии проблему не решат. Любая техника и программы не заставят предприятие работать по-новому, благодаря им лишь возникают дополнительные возможности. Большие перспективы открывает и Интернет. Но для грамотного использования новых технологий нужен хороший фундамент. Если предприятие еще не научилось оперативно управлять своими складскими запасами и производственными мощностями, оно будет плодить лишь недовольных клиентов, срывая сроки поставок, не укладываясь в заданную себестоимость, не обеспечивая обещанного качества и сервиса. Очень рекомендую прочитать всем исушникам. /

Ну не знаю, в Российской автоматизации, да, боюсь и в буржуйской, доски, гвозди, пилы - сплошное глючное убожество. Простая задача - биллинговая система. ТЗ можно уложить на 2-х страницах, а кода и глюков :) Разрабатывается годами и потом все равно покупается буржуйская. То есть и проектировать надо учиться, и гвоздики забивать :)

Я всегда считал, что до проектирования нужно хорошо проанализировать имеющиеся требования заказчика и БОЛЕЕ ТОГО его возможные будущие требования. Поэтому как бы хорошо не проводилось кодирование (реализация) глюки все равно возникнут! Парадокс! Но факт!

Это только ТЕОРЕТИЧЕСКИ правильно. Отсюда и возникли монстры типа RUP. А вот экстремальное программирование говорит обратное - нельзя в принципе учесть все настоящие требования, тем более будущие. И не надо. 20% усилий обеспечивают 80% результата. Давайте автоматизируем по быстренькому то, что горит, подстракуемся тестами, и будем готовы завтра все накрен переделать. Тут как-раз гвозди и рубанки выходят на первый план. Либо коллектив очень грамотный, либо среда разработки очень совершенная. А я не верю в анализ, если честно...

Волшебник, твой антимат глючит. Слово "подстракуесмя" - видишь, я даже не могу его правильно написать :)))))))

Я и не говорил, что их надо учитывать ЗАРАНЕЕ! Именно надо учитывать ВОЗМОЖНОСТЬ ИХ ПОЯВЛЕНИЯ! Поэтому я целиком за экстремальное программирование, но против "двух обезьян за одним компьютером". Компьютер - персональное устройство! По антимату я разберусь. Надо залить в него слова-исключения. Спасибо за замечание!

sorry Опять кавычки сломались.. Это все из-за ссылок. Вот так одно делаешь, другое ломается.. :(

Кстати очень верно про 2-х обезъян !!! У меня тоже такое отторжение, когда кто-то над душой стоит :) У себя в группе пытался модифицировать концепцию - работали по двое, но программист + тестер. С программиста код, тестер пишет методику тестирования, сами тесты и доку. Кроме того он должен быть способен читать код. Мне понравилось. Вроде работает.

Лучше, если сначала поработает тестер, составит тесты! Вот такой парадокс! Программиста лучше контролировать ДО того, как он наделает ошибок. Тогда программист даже не сможет сдать свою программу, потому что она не пройдет уже составленный тест. Кстати, это один из принципов XP (Экстремального Программирования) - тесты пишутся до программы.

Да знаю я, но на практике не получалось. На практике часто программер разрабатывал и интерфейсы, он тоже пробовал и переделывал, а как можно тест писать, когда интерфейсы не готовы ? И потом - тест написать - 10 минут, а прогу - поболее. К сожалению, у буржуев не работал и такой книжной организации труда не видел. А у наших - кто как умеет, так и руководит. Может это тоже правильно, выше головы все равно не прыгнешь, каких бы книжек не читал, так и живем :(

Да, согласен. Интерфейсы - это сама структура программы, т.е. связи между объектами. С другой стороны, это должна быть самая стабильная часть проекта, изменяться они должны в минимальной степени (на этом кстати основана идея COM). Поэтому проектирование интерфейсов должно идти как можно раньше и как можно качественнее. Это закладывает основу всего будущего проекта!

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

Наоборот, если с нуля - то можно сразу сделать как надо. А вот если уже что-то есть, то нужно сохранять совместимость. При этом наследуются старые ошибки. Так что лучше делать с нуля. Про масштабирование. Есть такое правило в XP: об оптимизации нужно думать тогда, когда возникли проблемы с производительностью. Я считаю, его в корне неверным. Тогда может быть уже будет поздно что-то делать, будут написаны сотни тысяч строк кода и переделать уже нереально. Так что в этом Александр прав.

Вот это была интересная дискуссия!