|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Modus ponens
|
Давайте на примере, так будет понятнее
Делали мы недавно рекламную кампанию нашему продукту. Програмка, по-сути сложный банер, должна была по ТЗ, в том числе, делать следующее: из введенной пользователем фразы искать слова соответствующие какому-то из ограниченого набора видео роликов, чтобы потом их проигрывать. Пока что оставим в стороне тот факт, что написать такую прогрмму по-чесному - это несколько доктроских диссертаций, по лингвистике, искуственному интеллекту и т.д. Но, собственно, никто и не ожидал, что программа будет действительно чего-то толковое находить, даже 1-10% совпадений было бы неплохо. Данные (назовем их "словарь") должна была подготовить девочка-переводчик. Fail #1: девочка не умеет пользоватся системой контроля версий, максимум, что она может - выложить свои труды в GoogleDocs. Научить ее пользоватся Git? - так я сам до сих пор толком не разбираюсь. В любом случае, это займет время, которого у нас нет (из финансовых соображений). Fail #2: Какой-то идиот, который разрабатывал API Google Spreadsheets сделал очень плохую работу. Это вылилось в то, что иногда не возможно с уверенностью сказать, что полученные данные были введены именно так а не иначе. Т.е данные завернуты в 100500 слоев SOAP-Atom2 XML, но сами по-себе сохранены в следующем формате: <содержание-ячеек>колонка: содержаниеячейки, колонка: содержаниеячейки</содержание-ячеек>. Т.о. пробелы и подчерки в содержании ячеек и названии колонок были просто удалены, а запятые в то же время остались. Т.о. автоматический парсер в 1% случаев давал сбой при разборе того, что пришло из GoogleDocs... - Переписать Google Spreadsheets API и попросить Google заменить? Написать парсер для Excel файлов (при этом иногда забывать обновить содержание словаря перед билдом)? Любое решение, которое бы обеспечило безбажную работу было бы в разы дороже самого проекта, для которого предназначалось. Поэтому парсер остался, а результат его работы иногда доправлялся вручную, если ошибки находились. Таким образом, программа была "сдана" с заведомо вероятными багами (и хорошо, если бы только этими багами все ограничивалось). Потому что сделать ее без багов было бы неимоверно долго и дорого. А вот если бы вы так программировали атомный реактор, то наверное оказались бы в тюрьме Да, раз уж тут первое апреля... Sapper makes only 1 mistake in her life. Let sapper get her first job when she was 20. Let sapper live until she was 75 Let her work every week every year since her first employment record. Let her disarm a mine each working hour. The probability a sapper would make mistake amounts to: 1 / 8 * 52 * 5 * 55 = 0.000008741 ------------------------------------------------- If Facebook were as careful as a sapper: http://www.facebook.com/press/info.php?statistics 500 000 000 active users ------------------------------------------------- 4370 mistreated (potentially dead) users!
__________________
Hell is the possibility of sanity Последний раз редактировалось wvxvw; 02.04.2011 в 02:07. |
|
|||||
Теперь хоть понял, о каком Вы качестве. Короче, хочешь качество - программируй атомные реакторы/системы запуска балистических ракет/системы управления воздушным движением. А если кодишь даже не игрушку, а серьезный коммерческий проект - принимай допуск "95% вроде рабочего кода / 5% известных критических багов" и не выпендривайся
Хотя не, хоть в том примере, который Вы описали, конечно по другому и не сделаешь - - но есть же такой подход "рост качества - уменьшение затрат на производство" (Если верить статьям - выпуск первой версии Microsoft World был просрочен чуть ли не на год именно благодаря наплевательскому отношению к качеству - новый функционал заставляли лепить на НЕпофикшенные баги http://www.gnuman.ru/joel/Test_Dzhoj...uchshemu_kodu/) Последний раз редактировалось expl; 02.04.2011 в 23:52. |
|
|||||
Modus ponens
|
Ну, проекты, которые нужно долго поддерживать будут, конечно, более качественными, но, опять же, пока качество кода не является конечной целью... Например, лозунг энтерпрайз - не важно, что работает медленнее, чем могло бы, и жрет тучу ресурсов - главное, чтобы поддерживать было удобно. Это, опять же, правильно с коммерческой стороны - поддержка стоит денег, больше багов выливаются в худшие продажи и т.п. Но конечная цель - не написать лучшую программу, а продать больше копий. Первое не обязательно связано со вторым.
Контора в которой я работаю делает видео чат. По сравнению со Скайпом, или любой другой похожей программой - то, что мы делаем - детский лепет, и смысла использовать нет. Но, коль скоро наша программа существует в виде Фейсбук-приложения, у нее есть что-то около миллиона пользователей. Т.е. по абсолютно не зависящим от качества кода причинам, программа успешно продолжает жить...
__________________
Hell is the possibility of sanity |
|
|||||
стервочка (я мужик)
|
так вот чего у меня гугланалитикс сума сходит ...
|
Часовой пояс GMT +4, время: 02:52. |
|
« Предыдущая тема | Следующая тема » |
|
|