Здравствуйте, agogotz, Вы писали:

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

Это не ко мне. Просто интересно на каком уровне все разжевывать.

A>Ни разу не встречал ни одного человека, который за деньги работает хорошо, а без денег плохо.

Я встречал.

A>Программирование тут не исключение. Скорее даже, для души еще больше стараются. Не верю я, что посади тебя атомный реактор программировать тут же начнешь писать высококачественный код.

Блин, ну ты янус хоть видел? А его код? О чем тогда речь? Я тоже могу выдернуть твой неотлаженный код и сказать что ты писать программы совсем не умеешь.

A>Это не "стараюсь", это скорее наоборот. Интересно, что ты подразумеваешь под полномаштабным тестированием.

Это значит параллельная работа со старыми системами хотя бы месяц, с постоянной сверкой результата.

A>Программирование это такая же технология, как и, например, производство машины. И соотвественно нельзя сэкономить на технологическом цикле, ну просто нельзя.

Можно.

A>Не получишь ты нормальную продукцию. На эту тему есть масса литературы, так что не проси меня все здесь доказывать.

Самый лучший аргумент. Есть масса литературы где расписан процесс производства софта и как его планируют и оптимизируют. Вот и почитай.

A>А теперь аксиомы.
A>1. Бухгалтер не может, не должен, да и не не будет тестировать твои программы.

И может, и должен, и будет.

A>По определению, у него другие заботы, функции, да и мозги работают по другому.

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

A>2. Программист должен тестировать свою программу, но он все равно не может ее протестировать правильно. Но тестировать должен.

Должен. Я вроде бы этого и не отрицаю.

A>3. Тестирование программы, должен заниматься только один человек, тестер.

Фигню говоришь. Тестировать софт должна вся цепочка от кодера до рядового бухгалтера. Тебе IT написал типовые этапы внедрения.

AVK>>Я стрелки не перевожу, я просто привел пример еще более безответственного отношения к результатам своего труда.

A>Вот этого не надо. Тебя не должно беспокоить, что есть хуже, тебя должно беспокоить, что есть лучше.

Что меня должно беспокоить это мое личное дело.

AVK>>Это не мерянье гениталиями. Это, говоря современной технологией, предложение ответить за базар. Кидаться фразами я тоже могу.

A>Да? А чего это ты присвоил себе право говорить за весь мир?

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

AVK>>А у тебя есть способ безошибочного достижения идеального оптимума?

A>Да. Не нарушайте технологию производства и улучшайте культуру производства.

Ну ну, советую тебе снять розовые очки.

AVK>>Не видел ни одного решения где для введения налога с продаж обошлись только обновлением базы.

A>Назови мне причины, по которым бизнес-логика не должна быть отдельно?

Она отдельно и есть. Ее мы и обсуждаем. И именно ошибки в бизнес-логике приводят к неверным цифрам, и именно ее нужно тестировать.

A>А изменени последней есть фактически изменени базы. Сложнее, но смысла не меняет.

То есть бизнес-логику тестировать не нужно? Это твоя культура производства?

AVK>>Менеджер, который программерами и не только рулит. Программлю я как правило исключительно для своего

A>Тогда за программиста в данном контексте покатишь, тем более должен отвечать за их работу.

Не покачу. Я бухгалтерией тоже занимаюсь.

AVK>>Ну так и нечего тогда такие цитаты приводить.

A>Как это нечего? Извини, но зачастую именилось только потребление бумаги.

Говори за себя.

AVK>>Кто возмущается? Возмущаются тем что пытаются переложить чисто бухгалтерские задачи на программеров.

A>Бухгалтерская задача, поставить тебе задачу и пользоваться результатом, а не выискивать глюки.

Советую открыть любой договор с внедренцем и внимательно его почитать. Если у вас бухи не отвечают за правильность цифр и приемку нового софта то могу вам только посочувствовать.

AVK>>Ну и к чему все это? К тому что и с бухгалтером так же можно? В текущем состоянии вряд ли, Дума не дремлет.
A>Ой не смеши, у бухгалтера задач и так хватит. Не связаных с выискиванием неверных цифр.

Ну например. Как тут предлагали использовать их вместо юристов и финансового менеджмента? Это не задачи бухгалтеров.

Здравствуйте, IT, Вы писали:

IT>- Семёновна, ну выпиши ты мне наконец ведро краски
IT>- Я тебе уже сказала, нема у меня для тебя краски, иди отсудава.

IT>Это видимо национальная черта, маленький человечек, обличённый хоть какой-то властью или правом подписи каких-то документов, становиться очень важным и мнит себя пупом земли. Такое мне приходилось наблюдать не раз, начиная от вахтёров и заканчивая ментами. Бухгалтера занимают почётное место в этом ряду.

Программисты кстати тоже не последние в этом ряду. Притом обрати внимание что надпись у сисадмина на двери "Обращение с глупым вопростом 100$" это то же самое впечатление "пупа земли". Только в отличие от бухгалтеров мы считаем это нормальным, и даже смеемся в humor-е.

ОЖ>>Вот такие фразы:
IT>

"это обслуга, которая часто мнит себя важнее самого производства"
IT>"неправильные цифры выискиваются, корректируются, пересчитываются и т.п. Физически такая программа ничем не управляет, соответственно ничего не может разрушить"

ОЖ>>Значит, что для "обслуги" можно делать программы с ошибками.

IT>Возможно насчёт обслуги я и погорячился. Скажем так, это вспомогательное подразделение, которое предназначено для обслуживания основного вида деятельности предприятия. Так же, кстати, как и отделы автоматизации

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

IT>Почитай мой предыдущий пост. В нём я пытался сказать о том, что помимо нерадивых программистов существует не меньше, если не больше, нерадивых бухгалтеров. Если осуществляется нормальный процесс приёмки, то бухгалтеру за неверные цифры можно винить только себя. Но ведь очень удобно не проводить тестирования, а потом всё свалить на программиста.

Да бухгалтер физически не может организовать тестирование он может в нем только участвовать. И глупо с него спрашивать за недопроведенное тестирование.

IT>Вот скажи мне честно, у тебя в конторе есть люди, которые профессионально занимаются тестированием твоих программ? Или ты сделав изменения и потестировав как-нибудь на своей машине и на стареньких данных сразу ставишь свои программы бухгалтерам? Если так, то тогда конечно у тебя должно быть повышенное чувство ответственности и набор отработанных способов как прикрыть свою задницу.

Обрати внимание что эти люди занимаются тестированием не вместо программиста, а в дополнение.

Здравствуйте, AndrewVK, Вы писали:

AVK>А чаще всего думать, прежде чем лепить. А то воткнут отрицательные остатки на складе, а потом вопят что программа глючит. Спрашиваешь — расскажите мне, что такое -10 коробок, молчат.

Спрашивается: КАКОГО ХРЕНА твоя программа позволяет завести отрицательный остаток. И чей это тогда баг.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, AndrewVK, Вы писали:

AVK>>А чаще всего думать, прежде чем лепить. А то воткнут отрицательные остатки на складе, а потом вопят что программа глючит. Спрашиваешь — расскажите мне, что такое -10 коробок, молчат.

A>Спрашивается: КАКОГО ХРЕНА твоя программа позволяет завести отрицательный остаток. И чей это тогда баг.

A>

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

IT>А вот случаи, когда бухгалтер явно напортачил, но валит всё на программиста, сплошь и рядом. Вполне >возможно, что алгоритм действительно неправильно считает, возможно даже из-за ошибки программиста в

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

>Главный программер излагает начальству необходимость найма работника. Дальше схема простая — На чем написан >проект? — На С. Пишем заявку, включаем туда все модные темы и пошло поехало ... Кнут то, что Дональд в

ну все правильно же.. на чем проект написан то и требуют. очень редко программеров нанимают на
разработку "нового софта с нуля". чаще это поддержка, расширение и переписывание (новое модное слово —
рефакторинг ) программ, жизненный цикл которых уже составляет несколько лет. и человек нужен сразу,
чтобы посадить его мочить код а не читать книжки про MFC и RSDN

A>Спрашивается: КАКОГО ХРЕНА твоя программа позволяет завести отрицательный остаток. И чей это тогда баг.

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

A>По ходу пьесы все программисты к этому относятся. За исключением возможно произодителей игр, т.к. в игры >играют ради самих игр, а все остальное делается ради чего-то. И вообще помоему делить отрасли на

кроме тех фирм где основная коммерческая деятельность — производство софта

Здравствуйте, AndrewVK, Вы писали:

AVK>Это не ко мне. Просто интересно на каком уровне все разжевывать.

Это как бы форум, пиши так, что бы все поняли.

A>>Ни разу не встречал ни одного человека, который за деньги работает хорошо, а без денег плохо.

AVK>Я встречал.

Ну а я вот нет. Обчно в любом случае плохо работают, но типа отмазка, мне платят мало, вот начнут хорошо платить, я как развернусь... Другое дело, что это лечится.

A>>Программирование тут не исключение. Скорее даже, для души еще больше стараются. Не верю я, что посади тебя атомный реактор программировать тут же начнешь писать высококачественный код.

AVK>Блин, ну ты янус хоть видел? А его код? О чем тогда речь? Я тоже могу выдернуть твой неотлаженный код и сказать что ты писать программы совсем не умеешь.

Видел, иначе бы не говорил. Я не говорил, что ты писать не умеешт, я говорил, что янус криво написан. Когда б3 работает хуже чем б1, мне не надо на код глядеть, что бы выводы сделать. К тому же б3 это почти RC, куда там янусу до RC шутишь наверно. Да и вообще привел я его только, как пример что база была без бэкапа изменена, см топик. Я вообще удивлюсь как можно на этапе б3 менять форматы?

AVK>Это значит параллельная работа со старыми системами хотя бы месяц, с постоянной сверкой результата.

Это, мягко говоря, не всегда возможно.

A>>Программирование это такая же технология, как и, например, производство машины. И соотвественно нельзя сэкономить на технологическом цикле, ну просто нельзя.

AVK>Можно.

В ущерб качеству. Причем ниже слова нормально.

A>>Не получишь ты нормальную продукцию. На эту тему есть масса литературы, так что не проси меня все здесь доказывать.

AVK>Самый лучший аргумент. Есть масса литературы где расписан процесс производства софта и как его планируют и оптимизируют. Вот и почитай.

Читал. Нигде не читал, что на тестировании стоит экономить. Можно ссылочку?

A>>А теперь аксиомы.
A>>1. Бухгалтер не может, не должен, да и не не будет тестировать твои программы.

AVK>И может, и должен, и будет.

Ну и что он тебе натестирует?
— У вас ту не правильно работает.
— Что неправильно?
— Ну не правильно, вы же программисты вы и разбирайтесь.

Мне такое тестирование не нужно. Кстати на joelonsoftware неплохо про тестирование написано.

A>>По определению, у него другие заботы, функции, да и мозги работают по другому.

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

Да какой, к черту, этап внедрения. Мы о тестировании говорим.
Ты же мне наверно не хочешь сказать, что вы начинаете тестировать систему на этапе внедрения? Это ведь даже не смешно.

A>>2. Программист должен тестировать свою программу, но он все равно не может ее протестировать правильно. Но тестировать должен.

AVK>Должен. Я вроде бы этого и не отрицаю.

Но протестирует он ее плохо. Так как подсознательно будет подстраиваться под свой алгорит. И половину глюков пропустит. Факт, проверено.

A>>3. Тестирование программы, должен заниматься только один человек, тестер.

AVK>Фигню говоришь. Тестировать софт должна вся цепочка от кодера до рядового бухгалтера. Тебе IT написал типовые этапы внедрения.

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

A>>Вот этого не надо. Тебя не должно беспокоить, что есть хуже, тебя должно беспокоить, что есть лучше.

AVK>Что меня должно беспокоить это мое личное дело.

Да ради бога, но другие тогда могут соотвествующим образом оценивать твой профессионализм.
Ладно замнем, для ясности, а то сейчас скатимся до уровня дурак, сам дурак.

AVK>>>Это не мерянье гениталиями. Это, говоря современной технологией, предложение ответить за базар. Кидаться фразами я тоже могу.

A>>Да? А чего это ты присвоил себе право говорить за весь мир?

AVK>Я и не говорю за весь мир, всех бухгалтеров и т.д. Я говорю исключительно за себя.

Да ну? А что означает фраза весь мир не может?

AVK>>>А у тебя есть способ безошибочного достижения идеального оптимума?

A>>Да. Не нарушайте технологию производства и улучшайте культуру производства.

AVK>Ну ну, советую тебе снять розовые очки.

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

AVK>>>Не видел ни одного решения где для введения налога с продаж обошлись только обновлением базы.

A>>Назови мне причины, по которым бизнес-логика не должна быть отдельно?

AVK>Она отдельно и есть. Ее мы и обсуждаем. И именно ошибки в бизнес-логике приводят к неверным цифрам, и именно ее нужно тестировать.

Её? Откуда это следует? Да нее еще и не добрались. Проблем хватает и без нее, пока.
Ошибок и в самой программе обычно хватает.
Я как то наблюдал, как в бэсте без всякой бизнес логики начали размножаться товары.
Раз так и на складе больше на 5 винтов. Это конечно не атомная станция, но их хотели повесить на обычных продавцов. Для тебя это может и не трагедия, для них да.

A>>А изменени последней есть фактически изменени базы. Сложнее, но смысла не меняет.

AVK>То есть бизнес-логику тестировать не нужно? Это твоя культура производства?

Нужно, причем так же как и отдельную программу. Ты еще предложи у тут сэкономить.

A>>Как это нечего? Извини, но зачастую именилось только потребление бумаги.

AVK>Говори за себя.

Гордость это конечно хорошо, но все же надо реально глядеть на вещь. Самомнение тут плохой помощник.

AVK>>>Кто возмущается? Возмущаются тем что пытаются переложить чисто бухгалтерские задачи на программеров.

A>>Бухгалтерская задача, поставить тебе задачу и пользоваться результатом, а не выискивать глюки.

AVK>Советую открыть любой договор с внедренцем и внимательно его почитать. Если у вас бухи не отвечают за правильность цифр и приемку нового софта то могу вам только посочувствовать.

Приемка это приемка, тестирование это тестирование. Давайте мух отдельно, котлеты отдельно.
У некоторых тестирование при приемке должно проводится сурезными организациями, за свои деньги.
Ты им еще предложи фсбшникам платить, пока они твои глюки ищут.

AVK>>>Ну и к чему все это? К тому что и с бухгалтером так же можно? В текущем состоянии вряд ли, Дума не дремлет.
A>>Ой не смеши, у бухгалтера задач и так хватит. Не связаных с выискиванием неверных цифр.

AVK>Ну например. Как тут предлагали использовать их вместо юристов и финансового менеджмента? Это не задачи бухгалтеров.

Возможно это токлько у вашего бухгалтера есть время искать ошибки в отчетах.
Нормальные еще ищут способы повысить доходы предприятия и снизить затраты. Это "слегка" другой вид деятельности.

Здравствуйте, Олег Жихарев, Вы писали:

[]

Я плакалЪ.
Судя по всему ето в Вашем понимание сравнимо с подвигом Александра Матросова (Мересьева, Гастелло и т.д., нужное подчеркнуть\вставить).

ЗЫ Мдя, пока у нас бухгалтеры будут _так_ гордиться за выплаченную вовремя зарплату, мы коммунизьма не построем.

Привет!
Удивительно что вы досихпор спорите.
Качество софта определяется не только способностями (или даже усилиями программеров), но количеством учасников проэкта и временем на него затраченым. Как следствие и средствами которые заказчик готов заплатить за разработку. Понятно что если это гнушный проэкт, и программеров (высокого уровня) много + врямя на разработку никто не ограничивает — то и результаты обычно хорошые. Другое дело в программах для конкретной фирмы (бухучёт в частности...). Ты можешь прийти на фирму и поинтересоваться какие сроки для разработки тебе выделят. И уж поверь это не год и не два... и средства которые он готов потратить тоже ограничены. И дело даже не в желании скачать как можно больше денег (хотя порой и не без этого) и в том, что есть минимум, который нужно платить програмисту (ему ведь нужно что-то кушать) и количество человеко-часов которое нужно затратить для качественого результата (которое определяется сложностью проэкта). И если эти человеко часы можно потратить по разному: 1) нанять больше лудей — требует средст. 2) увеличить время на разработку — также тредует средст (зарплата обычто по месячная), да и просто не подходит. все нужно зделать еще вчера 3) упростить проэкт — решаем не все задачи 4) понизить требования к проэкту — уменьшаем надежность и т.д.
В первых 3-х случаях заказчик (у малых проэктов) сам оказывается ПРОТИВ. как следствие выбор падает на 4-й пункт. Если ты скажеж заказчику что создашь надёжный проэкт через два года и этот проэкт будет стоить ему больших денег — то он будет первым протестующим. А тестирование проэкта, как ты сам понимаешь, вещь далеко не бесплатная и не быстрая — люди должны получать зарплату и тратить время. Клиенту может на это и наплевать, но сложный проэкт по определению содержит ошибки (читай Гради Буч). Чем больше система тем выше сложность (в геометрической прогрессии), а сложность неизбежно вёжет к ошибкам (человеческий фактор). Говорить о том, что следует писать качественно не надо, это и так понятно (но от человеческого фактора не уйти, для этого программы и тестируют).
Вот на упомянутых атомных станция совсем другое дело, там не ставая надёжность под угрозу из-за желания сыкономить средства... там программы, доказываются... а это совсем другой подход, требует и сил и средств и высокоуровневых специалистов (такие программы для складского учёта не пишут... ) Все очень зависит от заказчика. Если ты найдеш клиента ГОТОВОГО ОПЛАТИТЬ усилия высоко-уровневых программистов по созданию безотказный программ для бухучёта — то прграммы будут заглядение, можещь мне поверить. В противном случае это выбор клиента (он конечно хочет всё что б надёжно, сразу и главное бесплатно — но это не возможно... труд программистов не бесплатный, заметь я о суммах не говорю, в любом случае он не бесплатный...)

Здравствуйте, agogotz, Вы писали:

A>>>Ни разу не встречал ни одного человека, который за деньги работает хорошо, а без денег плохо.

AVK>>Я встречал.

A>Ну а я вот нет. Обчно в любом случае плохо работают, но типа отмазка, мне платят мало, вот начнут хорошо платить, я как развернусь... Другое дело, что это лечится.

Ага, повышением зарплаты. Иначе если попробуешь с них драть больше чем платишь то они просто уйдут.

AVK>>Блин, ну ты янус хоть видел? А его код? О чем тогда речь? Я тоже могу выдернуть твой неотлаженный код и сказать что ты писать программы совсем не умеешь.

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

Он еще не написан.

A>Когда б3 работает хуже чем б1, мне не надо на код глядеть, что бы выводы сделать.

Кто тебе сказал что хуже? Лучше он работает.

A>К тому же б3 это почти RC,

Сам придумал?

A>куда там янусу до RC

Так о том и речь.

A> Да и вообще привел я его только, как пример что база была без бэкапа изменена,

Не было такого, база всегда перед бекапом сохраняется.

A>см топик. Я вообще удивлюсь как можно на этапе б3 менять форматы?

А что их теперь не менять до скончания века?

A>Это, мягко говоря, не всегда возможно.

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

AVK>>Можно.

A>В ущерб качеству.

Да, в ущерб качеству. Тебе ведь другое говорят — не всегда это качество экономически выгодно.


AVK>>Самый лучший аргумент. Есть масса литературы где расписан процесс производства софта и как его планируют и оптимизируют. Вот и почитай.

A>Читал. Нигде не читал, что на тестировании стоит экономить.

Плохо читал. Экономить монжно на всем.

AVK>>И может, и должен, и будет.

A>Ну и что он тебе натестирует?
A>- У вас ту не правильно работает.
A>- Что неправильно?
A>- Ну не правильно, вы же программисты вы и разбирайтесь.

Этого достаточно. Главное чтобы он показал что вот посчитано ручками, а вот программой и эти два числа не сходятся. А уж что конкретно не работает должен разбираться программер.

A>Мне такое тестирование не нужно.

Тебе? А ты бухгалтер?

A>Кстати на joelonsoftware неплохо про тестирование написано.

Мы про Россию говорим и про бухгалтерию.

A>Да какой, к черту, этап внедрения. Мы о тестировании говорим.

Тестирование проводится на этапе внедрения.

A>Ты же мне наверно не хочешь сказать, что вы начинаете тестировать систему на этапе внедрения? Это ведь даже не смешно.

Не начинаем а продолжаем. И это действительно не смешно.

AVK>>Должен. Я вроде бы этого и не отрицаю.

A>Но протестирует он ее плохо. Так как подсознательно будет подстраиваться под свой алгорит. И половину глюков пропустит. Факт, проверено.

Не знаю чем ты там проверял, но нормальный бухгалтер тестирует бизнес-логику лучше программера. Факт, проверено.

AVK>>Фигню говоришь. Тестировать софт должна вся цепочка от кодера до рядового бухгалтера. Тебе IT написал типовые этапы внедрения.

A>Я говорю то что прошел на практике.

А мы тебе тоже говорим что прошли на практике.

A>Тестировать должны разработчики, бухгалтер должен пользоваться.

Тестировать должны все.

AVK>>Что меня должно беспокоить это мое личное дело.

A>Да ради бога, но другие тогда могут соотвествующим образом оценивать твой профессионализм.

Не надо оценивать мой профессионализм, а то я твой начну оценивать.

A>Ладно замнем, для ясности, а то сейчас скатимся до уровня дурак, сам дурак.

AVK>>Я и не говорю за весь мир, всех бухгалтеров и т.д. Я говорю исключительно за себя.

A>Да ну? А что означает фраза весь мир не может?

Констатацию факта.

A>>>Да. Не нарушайте технологию производства и улучшайте культуру производства.

AVK>>Ну ну, советую тебе снять розовые очки.

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

Какие еще тебе аргументы нужны? Приезжай, я тебе покажу как у нас все работает.

AVK>>Она отдельно и есть. Ее мы и обсуждаем. И именно ошибки в бизнес-логике приводят к неверным цифрам, и именно ее нужно тестировать.

A>Её? Откуда это следует? Да нее еще и не добрались. Проблем хватает и без нее, пока.

То есть бизнес-логику тестировать в программе не нужно. Ну что ж, дальше вобщем то говорить не о чем.

A>Раз так и на складе больше на 5 винтов. Это конечно не атомная станция, но их хотели повесить на обычных продавцов. Для тебя это может и не трагедия, для них да.

У меня такого не было ни разу.

AVK>>То есть бизнес-логику тестировать не нужно? Это твоя культура производства?

A>Нужно, причем так же как и отдельную программу. Ты еще предложи у тут сэкономить.

А что еще тестировать? Движок? Так его лучше купить, а не изобретать велосипед.

Это все к тому что ты утверждал что при введении налога с продаж ничего тестировать не нужно.

AVK>>Говори за себя.

A>Гордость это конечно хорошо, но все же надо реально глядеть на вещь. Самомнение тут плохой помощник.

То есть ты лучше меня знаешь как у меня все плохо?

AVK>>Советую открыть любой договор с внедренцем и внимательно его почитать. Если у вас бухи не отвечают за правильность цифр и приемку нового софта то могу вам только посочувствовать.

A>Приемка это приемка, тестирование это тестирование. Давайте мух отдельно, котлеты отдельно.

Ну уж нет — приемка это всегда тестирование, иначе какая это нафик приемка.

A>У некоторых тестирование при приемке должно проводится сурезными организациями, за свои деньги.

Вот именно что за свои деньги.

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

ЭТО НЕ ЕСТЬ ЗАДАЧА БУХГАЛТЕРОВ. Искать способы повысить доходы предприятия и снизить затраты должны совсем другие люди. Задача бухгалтерии — вести учет.

Здравствуйте, Anatolix, Вы писали:

A>Спрашивается: КАКОГО ХРЕНА твоя программа позволяет завести отрицательный остаток. И чей это тогда баг.

Она позволяет это сделать специальным набором действий для определенных проводок. Чтобы сделать отрицательный остаток надо делать это преднамеренно и целенаправленно, в обход ограничений. Просто бухи, вместо того чтобы провести как положено решили все попростому сделать.

Здравствуйте, Awaken, Вы писали:

A>>По ходу пьесы все программисты к этому относятся. За исключением возможно произодителей игр, т.к. в игры >играют ради самих игр, а все остальное делается ради чего-то. И вообще помоему делить отрасли на

A>кроме тех фирм где основная коммерческая деятельность — производство софта

Хрен то там. Они делают этот софт для того чтобы его потом использовали в той же бухгалтерии, видеомонтаже или производстве другого софта. А не ради самого софта.

Здравствуйте, Anatolix, Вы писали:

A>Хрен то там. Они делают этот софт для того чтобы его потом использовали в той же бухгалтерии, видеомонтаже или производстве другого софта. А не ради самого софта.

Разработка компиляторов и пр. утилит.

Здравствуйте, shalts, Вы писали:

S>Вот на упомянутых атомных станция совсем другое дело, там не ставая надёжность под угрозу из-за желания сыкономить средства... там программы, доказываются... а это совсем другой подход, требует и сил и средств и высокоуровневых специалистов (такие программы для складского учёта не пишут... ) Все очень зависит от заказчика. Если ты найдеш клиента ГОТОВОГО ОПЛАТИТЬ усилия высоко-уровневых программистов по созданию безотказный программ для бухучёта — то

Ээ вряд ли атомные станции стоят только потому, что у них работают некие свехспеци пишущие код без ошибок.
Там другие технологии, но они другие в том смысле что там повышают надежность от "нормальной". И в первую очередь дублированием, резервированием, используя специально оборудование. Что бы даже вслучае ошибки система не не вышла из строя. Но тут то уже скатились до того, что прикрываясь атомными станциями вообще отказываются тестировать, типа им надо пусть сами и тестируют, а я сэкономлю. Но такой подход качество опускает ниже приемлемого.

Здравствуйте, Mishka, Вы писали:

M>Здравствуйте, Anatolix,

A>>Согласен. Кроме того даже если ты где-нибудь видишь баг это не всегда значит что его надо фиксить. Классический пример вот отсюда:
A>>http://www.joelonsoftware.com/articles/fog0000000014.html

M>На самом деле ещё проще. Пока баг не мешает работать, его не надо фиксить. Потому, если пользователь доволен, что имеет, то зачем причёсывать код?
M>"Good enough software", и ничего более.

Нет как раз наоборот! Код надо причесывать всегда, даже если багов нет. Это называется Refactoring.

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

У того же Joel-а есть пример как из-за нехватки времени один из программистов работающий над Excel в функции которая возвращает размер шрифта просто написал return 12; и стал ждать bug report-а.

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

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, LOK, Вы писали:

А>Мимо, не тот случай. Опытный летчик пересев на новый самолет, легко разберется с управлением нового прочитав "талмуд", как ты говоришь.

Вот вот ... опытный летчик это тот который с Истребителя переседает на легкий спортивный самолет ))) Вот по этому сначала С++ а потом все остальное ..

А>Плохо спроектированая программа имет больше ошибок и следовательно падает чаще. Докажи обратное.
Проектирование не имеет ничего общего с реализацией.

возмем пример .

class A
{
protected:
    char szBuff[10];
public:
    A(){};
    void init(char* szBuffIn){strcpy(szBuff,szBuffIn)};

}

//Вот что будет в этом случае )) ?
A a;
a.init("1234567890123456789");

как бы спроектировано нормально ..)) но вот падать будет очень интересно )).. только в релизе.. и ошибок не будет выдавать никаких ))

А>Читается. В серьезных проектах. Каждый день перед глазами вижу Разработке уже 25+ лет, кто ее начинал наверно давно на пенсии, без проблем изменяется расширяется итп.

Не верю ))) Ну не может много разных команд розработчиков в течении 25+ лет мыслить одинаково ))

Здравствуйте, IT, Вы писали:


IT>У меня другие примеры. В частности, некоторым ребятам, которых я уважал как толковых математиков, нужно было руки отбивать железной линейкой за тот код который они производили. Причём, чем толковее как матиматик, тем сильнее нужно бить


Не помню кто писал...и дословно не процетирую ..
Но хорошие программеры получаются не с математиков ,как не странно,а с людей занимающихся гуманитарными науками. ))

Здравствуйте, Atilla, Вы писали:

A>Здравствуйте, Anatolix, Вы писали:

A>>Хрен то там. Они делают этот софт для того чтобы его потом использовали в той же бухгалтерии, видеомонтаже или производстве другого софта. А не ради самого софта.

A>Разработка компиляторов и пр. утилит.

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