Чудо-Программеры млин :)

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

Уважаемые, а чего удивляться? Ведь не мало заказчиков на сайте, которые хотят сделать проект, скажем доску объявлений, с кучей наворотов и платят за это 20-50 у.е. На такие деньги можно работать разве что так, для веселья. Либо откликаются еще не сбывшиеся программисты, которые краем уха слышали о БД, нормализации, реляциях.

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

Цитата:

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

не факт =)

А я согласен.
А если сделать качественно за 30, то заказчики думают что это нормально и у них
возникают иллюзии о ценах.

Цитата ("SmartDesign"):

не факт =)

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

Цитата ("-IIIyT-"):

SolNikolay, естественно первого, смысла выступать со стороны второго я не вижу, а вы видите? Тестеры работают с человеком написавшим программу, а не пытающимся её переписать.

Интересно говорите
При проведении тестирования методом "белого ящика" тестер просматривает именно код. И если он написан криво - то тестер тоже будет говорить, что программописатель редиска.
Это при функциональном и прочем "черном" тестировании тестеру все равно, что там в коде - главное чтобы все работало. А если программа через неделю упала, то тестеру БОЛЬШОЙ косяк (при условии, что тестер и программер два разных человека).

SolNikolay, а вдруг и тестер и программист одно и того же мировоззрения?

Цитата ("-IIIyT-"):

SolNikolay, а вдруг и тестер и программист одно и того же мировоззрения?

Какого - пофигистского?
Ну тогда видим то, что приведено в первом посте:
программер - "А, сойдет!";
тестер - "Да и фиг с ним. Работает."

Цитата ("SolNikolay"):

Какого - пофигистского?
Ну тогда видим то, что приведено в первом посте:
программер - "А, сойдет!";
тестер - "Да и фиг с ним. Работает."

Ну, тестер обычно не залазит в код, обычно, в большинстве случаев, он тестирует программу как черный ящик, все работает как было затребовано по спецификации - и ладно. Максимум, если тестер продвинутый, - может тесты написать (рассматривая систему как белый ящик), но обычно тесты пишутся к программным интерфейсам, код не исследуется. Также могут быть тесты для нагрузочного тестирования, функциональные, интеграционные, и т.д. Иными словами, плохой код тестер может не посчитать дефектом, если система в целом работает. Это не дело QA (Quality Assurance), вне их компетенции. Да и не нужно - у QA другие задачи, инструменты, возможности, процессы.

Также тестеры обычно не являются специалистами в кодинге. Оно и понятно - сегодня они тестируют сайт на PHP, завтра - на Perl, послезавтра - на Java и т.д. Чаще всего, из практики, QA существенно больше работают с документацией, чем с разработанной тестируемой системой, и это правильно...

Кот ревьюить должен программист, это эффективнее... Причем желательно чтобы это делал не тот программист, который код писал, а другой. Такой процесс называется QC (Quality Control), когда программисты в команде перекрестно занимаются плановым ревьюингом/пересмотром кода друг друга, выявляют откровенное ламерство, некорректности, уязвимости, и т.д., и так же как и QA постят дефекты (но обычно в отдельном репозитории команды разработчиков).

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

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

<gram|work> Какой самый извращенный способ проверить в условии if () булевскую переменную ?
<gram|work> bool b;
<gram|work> b = false;
<gram|work> if (b == true){...}
<gram|work> Это децкий лепет
<gram|work> ИТАК, ПЕРВОЕ МЕСТО
<gram|work> Знакомый говорит что нашел только что в коде:
<gram|work> if (b.ToString().length < 5){...}

SmartDesign, это уже базар-вокзал пошел.

tvv, вы смешали понятия тестирования методом "черного ящика" и методом "белого ящика" + неправильная организация работы отдела тестирования.

Цитата:

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

Какой уровень тестирования вы выберете - так тестировать и будете.

Цитата:

Максимум, если тестер продвинутый, - может тесты написать (рассматривая систему как белый ящик), но обычно тесты пишутся к программным интерфейсам, код не исследуется.

Тесты пишутся и при "черном ящике" и при "белом".

Насчет того должен-недолжен:
"Модульное тестирование" - типы дефектов: Локальные дефекты, такие как опечатки в реализации алгоритма, неверные операции, логические и математические выражения, циклы, ошибки в использовании локальных ресурсов, рекурсия и т.п.

"Интеграционное тестирование" - типы дефектов: Интерфейсные дефекты, такие как неверная трактовка параметров и их формат, неверное использование системных ресурсов и средств коммуникации, и т.п.

"Системное тестирование" - типы дефектов: Отсутствующая или некорректная функциональность, неудобство использования, непредусмотренные данные и их комбинации, непредусмотренные или не поддержанные сценарии работы, ошибки совместимости, ошибки пользовательской документации, ошибки переносимости продукта на различные платформы, проблемы производительности, инсталляции и т.п.

SolNikolay, сколько нового я про тестирование узнал:shok::blink: спасибо

axiom, это так, по-мелочи.Там много больше и сложнее.

SolNikolay, брр.не буду даже думать, про то, что бы, лезть в эти дебри (:

Цитата ("SolNikolay"):

tvv, вы смешали понятия тестирования методом "черного ящика" и методом "белого ящика" + неправильная организация работы отдела тестирования.

Ничуть, где это я смешивал?

Цитата ("SolNikolay"):

Цитата:

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

Какой уровень тестирования вы выберете - так тестировать и будете.

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

Цитата ("SolNikolay"):

Цитата:

Максимум, если тестер продвинутый, - может тесты написать (рассматривая систему как белый ящик), но обычно тесты пишутся к программным интерфейсам, код не исследуется.

Тесты пишутся и при "черном ящике" и при "белом".

Вы наверное имеете ввиду тесты для автоматического тестирования? Так никто же не спорит. Только тесты-то совсем разного уровня, так как при тестировании черного ящика QA не знает что у него внутри. Для черного ящика автотесты пишутся намного реже, например, для мануального тестирования черного ящика типичные тесты вообще часто выглядят в виде набора тест кейсов в текстовом виде, к примеру в виде "1. Зайти на форму xxx1, ввести то-то, нажать то-то, проверить получилось ли это. 2. Зайти на форму xxx2....". Автоматизирующие скрипты используются существенно реже, да они и не всегда возможны, особенно если QA идет параллельно с интенсивной разработкой.

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

Цитата:

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

Я знаком с работой QA (проще писать тестера). И черный ящик используется в основном из-за экономии денег, а не для повышения качества.
Неправильная организация работы отдела тестирования. Вы сейчас говорите о первом уровне (из 5) модели тестирования.
"Уровень 1 ТММ. Начальный. Тестирование носит хаотический характер; оно плохо определено и не отличается от отладки. Тесты разрабатываются специальным образом после завершения кодирования. Тестирование и отладка сочетаются с целью устранения ошибок программного обеспечения. Целью тестирования является демонстрация того, что программное обеспечение работает. Прорграммные продукты внедряются без обеспечения качества. Ресурсы, средства и надлежащим образом подготовленный персонал отсутствуют. На этом уровне не существует целей достижения зрелости."

Цитата:

Вы наверное имеете ввиду тесты для автоматического тестирования?

Я имею ввиду тест-case'ы как таковые.

Цитата:

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

Нет. Тестер, способный написать какой-нибудь тест на вес золота не ценится. При выборе тестера вы можете пользоваться теми же критериями, как и при составлении команды программистов.

Аааа.....!!!!!!! БРРРРР!!!! Ну право хватит тут балаболить. давайте лучше работать

-IIIyT-, поддерживаю.

Цитата ("keymaster"):

Меня всегда веселят такие сообщения...
Как буд-то сами как из пеленок вылезли, так сразу стали писать код на хорошем уровне, минуя стадию "начинающего"...
Удивительно, но зачастую, подобные кодеры не видят брёвен в своем собственном коде...

Поддерживаю. Хотя не стоит все же делать серъезные сайты или сайты на заказ с таким уровнем, но думаю любой программер, правя чужой код, найдет такие ляпы, исправит, и сам тут же наворотит. Надо быть просто гением чтобы делать все правильно. Иначе почему появляются новые версии софта? Не только для предоставление новых возможностей, но и для того чтобы исправить ошибки, допущенные в предыдущей версии ИМХО