[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Качество программного обеспечения для веб
Страницы: 1, 2, 3, 4, 5, 6
OleKh
По материалам Википедии
http://ru.wikipedia.org/wiki/Качество_прог...ого_обеспечения

Критерии
Цитата
-Читаемость кода
-Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости
-Низкая сложность кода
-Низкое использование ресурсов: памяти и процессорного времени
-Корректная обработка исключительных ситуаций
-Малое число предупреждений при компиляции и линковке


К примеру, попробую провести аналогию с качеством автомобиля и выберу первым критерием качества читаемость проектной документации. Спрашивается зачем, когда авто еле разгоняется до 100 км/с за 15с. Это так, в общем.

А если конкретно, просматривая код веб-приложения на ООП с очень красивой организацией структуры, обратил внимание на то, что кол-во комментариев в некоторых классах даже больше чем исполняемого кода. В рамках всего приложения - вероятно приличная цифра получится. Кроме этого вообще рекомендуется (где-то читал про стиль кода, неофициальная дока) красиво документировать. php интерпретатор пропустит комментарии, но в процессе выполнения, а во время загрузки - нет, в оперативную память загрузится в т.ч. и вагон комментариев.

А где низкое использование ресурсов: памяти и процессорного времени?

В интернетах написано 20мб memory_usage - нормально (хотя мне кажется 1-2 мб норма), т.е. если рассчитывать на посещаемость 1000 потребуется как минимум 20гб оперативной памяти.

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

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

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

Не, ООП - не для фриланса.
redreem
Тормоза создает не ООП, а кривые руки прогера.
OleKh
Именно ООП в веб создает "тормоза" и требует более мощного оборудования. Вопрос сложный, требует масштабного тестирования. Я сравниваю на e-commerce CMS.
redreem
бред. напиши свою CMS без ООП. через полгодика-годик у тебя начнется затяжная депрессия от мысли, что с утра надо вставать и садиться за свой велосипед, в котором ты уже нифига не помнишь: где какие файлы, что в них лежит, как называются процедуры, переменные, константы, какие параметры и куда надо передавать...
OleKh
т.е. ООП нужно чтобы не забыть где что лежит)
redreem
OleKh
для некоторых личностей - как минимум.
OleKh
ок, почему тогда покупатель софта должен оплачивать проблемы этих личностей? ему то что важно, чтобы сайт работал шустро и без проблем
redreem
покупатель софта платит за продукт.
продукт разрабатывает разработчик.
у разработчика есть выбор - не брать таких личностей на работу.
smile.gif
вот вы уже в 2-х понятиях запутались smile.gif какое еще нафик процедурное CMS, пожалейте себя! smile.gif
OleKh
redreem
кто-то кого-то с кем то путает, мы знакомы?
redreem
OleKh
нет, не знакомы.
Invis1ble
срач объявляю открытым! smile.gif

только вот я не понял, в чем вопрос у автора?

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

redreem
Invis1ble
да какой срач, я детей не обижаю smile.gif
YVSIK
Цитата (Invis1ble @ 1.11.2013 - 17:42)
срач объявляю открытым!

это хорошооооооооооо. даже отличненько,. Ща продолжим!!

И так мне понравились вот эти строки:
Цитата (redreem @ 1.11.2013 - 16:49)
Тормоза создает не ООП, а кривые руки прогера.

Цитата (OleKh @ 1.11.2013 - 17:10)
т.е. ООП нужно чтобы не забыть где что лежит)

и что то мне это стало напоминать) новершиной этой темы которую я не понял что он ТС хочет но это я уловил и мне оно так-же понравилось))
Цитата (OleKh @ 1.11.2013 - 16:45)
Печально, то что если раньше на форуме можно было найти темы где участники выкладывали свои решения и был какой-то дух соревнования у кого быстрее, меньше кода, то сейчас выкладывают ООП и смотрят у кого красивее оформлен код и как смотрится.

особенно вот этО! даже оформлю пожирнее . думаю автор не против будет ))
Цитата (OleKh @ 1.11.2013 - 16:45)
то сейчас выкладывают ООП и смотрят у кого красивее оформлен код и как смотрится.

а это наводит на определнные мысли в сторону ил не всторону ООП)) smile.gif

Ээээээээ) нет рОбЬяты это до добра не доведет, хоть и срач тут разрешили )) wink.gif

_____________
«Гнусное свойство карликовых умов приписывать
________________!свое духовное убожество другим!»
___
О) как-же он прав=>__________________ © Оноре де Бальзак.

отличный хост(рекомендую !! )
My MVC-CMV
Rand
Цитата (OleKh @ 1.11.2013 - 18:45)
А где низкое использование ресурсов: памяти и процессорного времени?

В коммерческом ПО очень важно, на сколько быстро продукт выйдет на рынок. Пока ты будешь оптимизировать код, конкурент уже начнет зарабатывать деньги на твоих клиентах. Разве Microsoft беспокоились по поводу глюков в своей ОС? Они спокойно зарабатывали деньги, постепенно выпускали патчи и переписывали ядро. А для слабых компов был линукс.
inpost
redreem
А тебе не кажется, что по той причине, что процедурное программирование отвергается рвотно обществом, разработчики публичных CMS вынуждены писать ООП-шный код, чтобы угодить привередливому обществу? Продукт делается для потребителей, а потребители знатно требуют ООП, приходится идти на уступки.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.