| Вопрос: Переменная | Добавлено: 12.05.09 12:51 |
Автор вопроса:  Sergey
|
| Ответы | Всего ответов: 220 |
|
Номер ответа: 181 Автор ответа:  LamerOnLine ICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #181 | Добавлено: 15.05.09 02:49 |
|
Да вообще то ЛОЛ еще здесь
Скорее этот мир перевернется Чем ЛОЛ до ахтунга допьется |
||
|
Номер ответа: 182 Автор ответа:  User UnknownВечный Юзер! ICQ: uu@jabber.cz Вопросов: 120 Ответов: 3302 |
Профиль | | #182 | Добавлено: 15.05.09 02:51 |
| От Ахтунга слышу! | ||
|
Номер ответа: 183 Автор ответа: User UnknownВечный Юзер! ICQ: uu@jabber.cz Вопросов: 120 Ответов: 3302 |
Профиль | | #183 | Добавлено: 15.05.09 02:55 |
| как говорится.. вяло, друзья мои, вяло... | ||
|
Номер ответа: 184 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #184 | Добавлено: 15.05.09 03:00 |
|
как говорится.. вяло, друзья мои, вяло...
Дык ипт, Узер, оно и будет вяло если тебе повсюду ахтунги выдяцо. Радуйся. Если бы стало твердо - пришлось бы учавствовать в "параде", слегка альтернативном Евровидению 
|
||
|
Номер ответа: 185 Автор ответа: User UnknownВечный Юзер! ICQ: uu@jabber.cz Вопросов: 120 Ответов: 3302 |
Профиль | | #185 | Добавлено: 15.05.09 03:01 |
| От Ахтунга слышу! | ||
|
Номер ответа: 186 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #186 | Добавлено: 15.05.09 03:07 |
|
Уважаю ботов.
Вспомнился баян про красивое вырубание антиматового бота * V1RUS меняет ник на сука
* сука был забанен @Guard (Следи за своим языком!) * @Guard был забанен @Guard (Следи за своим языком!)
|
||
|
Номер ответа: 187 Автор ответа: J. Smith ICQ: ненавижу Вопросов: 40 Ответов: 477 |
Web-сайт: Профиль | | #187 | Добавлено: 15.05.09 04:55 |
|
Ну совсем тупой бот оказался .
Отпишусь, чтоб не я был виноват в крахе этого супертопика
|
||
|
Номер ответа: 188 Автор ответа: Ra$calICQ: 8068014 Вопросов: 18 Ответов: 817 |
Web-сайт: Профиль | | #188 | Добавлено: 15.05.09 06:50 |
| по числу хитов топег пока уступает творению дефендера. Сергей, нада было название топику давать поинтереснее - например "Помогите" | ||
|
Номер ответа: 189 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #189 | Добавлено: 15.05.09 09:19 |
|
что в доме не меняйте - кроме лишнего гемора не получите ничего
А как на счет высокой скорости внутри дома? придется протолкнуть через своего тим лидера и прожект менеджера в топ менеджмент предельно убедительную аргументацию
Наш менеджмент отлично понимает роль рефакторинга и выделяет под него 25-30% времени. Потому что когда код начинает вонять, простейшие изменения начинают занимать слишком много времени. Если неграмотные менеджеры плюют на перспективу развития проекта, рано или поздно проект рушится под массой глюков, компания становится банкротом, а заказчики оказываются в калоотстойнике, потому что найти другую компанию на поддержку чужого легаси найти почти нереально. Ты описал типичный случай, когда люди make money вместо make work. просто ситуацию, которая существует в крупных компаниях.
Не в крупных, а в плохих. Если простой рефакторинг модуля занимает несколько месяцев, полностью останавливая разработку, значит, в проекте есть куски кода, которого не хотят касаться даже 18-метровой палкой. В нормальных компаниях любого размера процесс всегда поставлен так, чтобы этого не возникало. |
||
|
Номер ответа: 190 Автор ответа: MegaÐefenderВопросов: 19 Ответов: 313 |
Web-сайт: Профиль | | #190 | Добавлено: 15.05.09 10:23 |
| Люди, вы зачем впустую время тратите, вам не смешно, тема "переменная" на 13 страницах? ВОПРОС БЫЛ ОДИН, ОТВЕТОВ - 200! ОТВЕТ НА 1 СТРАНИЦЕ, ШАРПА. | ||
|
Номер ответа: 191 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #191 | Добавлено: 15.05.09 12:07 |
|
Sharp, тут люди давно уже о другом говорят. Ну да ладно...
А как на счет высокой скорости внутри дома?
Внутри дома она может быть какой угодно. Скорость системы в целом в лучшую сторону не изменится. Сложность и нерациональность - безусловно. Потому что когда код начинает вонять, простейшие изменения начинают занимать слишком много времени
Чушь. Во-первых, я уже писал что одно из преимущество VB - крайне высокая скорость разработки/багфиксинга. В серьезной системе изменения в 99% вызываюся не софтовыми причинами а модификацией бизнес логики. Которая никак не привязана к языку. рано или поздно проект рушится под массой глюков, компания становится банкротом, а заказчики оказываются в калоотстойнике
Увы, Sharp, но пока что это компания - один из мировых лидеров в области автоматизации бизнеса, и уже далеко не первый год. Повторяюсь - мы не ведем речь про контору, специализирующуюся на написании софта для кофейных аппаратов бескудниковского района. Речь идет о крупных бизнес-решениях. Если простой рефакторинг модуля занимает несколько месяцев, полностью останавливая разработку, значит, в проекте есть куски кода, которого не хотят касаться даже 18-метровой палкой
Повторяю снова и снова: обоснуйте резон для рефакторинга. Без загибания пальцев о том что на VB6 писать "не гламурно". Я имею ввиду действительную причину, по которой DRB совет и руководители проектов станут снимать людей с разработок и ставить их на деятельность, которая не принесет прибыли, не повысит качества кода, не продвинет функционал, при этом создаст проблемы со сборкой системы и наверняка посадит новые баги? Мне действительно это интересно. Чем бы ты при принятии такого решения руководствовался. ВОПРОС БЫЛ ОДИН, ОТВЕТОВ - 200!
lol Читаем снова про мопед
http://moto.kiev.ua/forum/?trid=perls/1162393539473&vp=361 Бессмертная классика. 361 страница флуда, 2,5 года оффтопа
Уважаю |
||
|
Номер ответа: 192 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #192 | Добавлено: 15.05.09 12:14 |
|
В целом согласен, надо сворачивать тупые обсуждения корпоративной деятельности отдельно взятыми и чрезмерно умными персонажами. Просто ситуация в стиле "Папа, ты зачем бензин покупаешь, вон моя бибика на двух батарейках ездит".
Давайте флудить о чем-нибудь другом
|
||
|
Номер ответа: 193 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #193 | Добавлено: 15.05.09 12:44 |
|
люди давно уже о другом говорят
Мне показалось, что флейм начал задыхаться. Скорость системы в целом в лучшую сторону не изменится.
Дом это плохая аналогия, т.к. даже одна улучшенная линия уже повышает радость некоторого подмножества пользователей. VB - крайне высокая скорость разработки/багфиксинга.
Багфиксинг? Скорость разработки? Несколько вопросов: какие используются средства юнит-, функционального тестирования и утилиты code coverage? какие используются средства для верификации и аудита кода? есть ли style guide? есть ли документация по системе? автоматическая локализация сбоя? версия с отладочными символами? чему равна метрика avg sLOC/bug issue? метрика sLOC, написанный ныне работающими программистами / всего sLOC? какие используются средства предотвращения дублирования кода? есть ли сервер компиляции/тестирования/сборок? как часто проводится нагрузочное тестирование и какие средства профайлинга при этом используются? Ну и как вообще обстоят дела с другими простыми вещами для обеспечения скорости и надежности разработки, без которых разработчик - не разработчик, а просто гнида? а модификацией бизнес логики
В серьезной системе модификация бизнес-логики приводит к записи этой модификации с помощью инструментария, прилагаемого к системе, а не правкой исходного кода самой системы. один из мировых лидеров
А какой-нибудь Materialize - мировой лидер в области rapid prototyping, однако 80% их продукта - злое легаси года эдак 1992-го. А какой-нибудь MUMPS - мировой лидер в области медицинского ПО, однако использует нечитабельный жестко вшитый язык M, две виртуальные машины и быструю ООСУБД Cache, чтобы это все не слишком тормозило. А в Microsoft (мировом лидере в области настольных ОС) никто не знает, что делает около 30% кода ядра. Долго это продлится? До первого серьезного конкурента. Речь идет о крупных решениях. Это кофейную программу можно написать на коленке за 20 минут, с хардкодом, спагетти и копипастом, и она будет работать, а если что - всегда можно с нуля переписать. В крупных системах качество кода выходит на первый план. Экономите время на рефакторинге - потеряете на зарплатах маркетологов. Если рефакторинг не приносит повышение качества кода, уменьшение числа багов и упрощение добавления новых фич, то это не рефакторинг. |
||
|
Номер ответа: 194 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #194 | Добавлено: 15.05.09 13:28 |
|
Sharp, сдается мне тебе просто очень хочется потроллить...
Мне показалось, что флейм начал задыхаться.
Это действительно показалось. т.к. даже одна улучшенная линия уже повышает радость некоторого подмножества пользователей.
Да как не улучшай линию - кокс все равно будет узким местом. Скорость цельносй системы не увеличится, а инструментов для поддержки понадобится значительно больше. Так яснее? Несколько вопросов:
К чему они? Вкратце и не по порядку могу сказать о процедурах следующее Документация присутствует в сочетании с отделениями консалтинга и академией. style guide присутствует. Code Review проводится при необходимости вручную, в помощь используется собственный продукт Syncro VSS в сочетании с Beyond Compare. Все необходимые пометки вносятся в онлайновую баг-трекинг систему. Количество строк не считается в пределах разумного. Сборка проводится централизовано. Зарепорченные через хотлайн (либо иначе) воспроизводятся тестерами, в далее либо передаются аналитикам, либо режектятся. Далее, скоп заявок рассматривается DRB советом, часть эскалируется, часть режектится. После чего, собственно, пишется design note и issue попадает в коррекшен. Перед внесением изменений кода в ветку VSS разработчик проверяет работоспособность кода в соответствующей версии продукта. Ежедневно в 16.00 начинается сборка тестового билда. В случае падения причастному лицу (и всему R&  департаменту) рассылаются результаты сборки с логами. После исправлений в 22.00 запускается основной билд. К 9.00 при успешной сборке он ставится на тестовые сервера. При условии что разработчик завершил коррекцию ошибки - issue в баг-трекинг системе переводится из статуса Correction в статус Test, со всеми необходимыми комментариями и стандартными данными.
При удачном тестировании исправления кода мержатся в согласно инструкциям в смежные версии продукта и в дефелоперскую ветку. По заданному графику скоп правок входит в билд очередного хотфикса. В случае необходимости выпускается фикскит. Нагрузочное тестирование проводится довольно редко по причине отсутствия требований к запредельному быстродействию. Узким местом может являться неоптимизированный SQL запрос, отслеживается профайлером. Бывают сложности с перфомансом по причине неоптимизированных таблиц, это скорее проблемы совместимости, CCR выпускаются регулярно. В общих чертах этого достаточно. Просто чтобы больше вопросов не возникало о том что и как делается. не разработчик, а просто гнида?
Следим за языком, уважаемый. Долго это продлится?
Это длится долго. Такова ситуация - одни являются лидерами на рынке, другие постоянно рефакторят код. Как говорится, кесареву - кесарево. Экономите время на рефакторинге - потеряете на зарплатах маркетологов.
Обоснуй. Я вроде задал простой вопрос по поводу мотивации рефакторинга. Получил снова что-то невразумительное. Если рефакторинг не приносит повышение качества кода, уменьшение числа багов и упрощение добавления новых фич, то это не рефакторинг.
Для уменьшения количества багов служит процесс мейнтенанса. Перенос того же кода на новую платформу уже подразумевает под собой возможность появления новых багов. Это очевидно. Добавление новых фич упрощает единая наработанная система. Когда разные модули системы написаны на разных платформах - унификации и упрощению добавления каких-либо универсальных фич это не способствует ни коим образом. Повышение качества кода в данном контексте подразумевает под собой в первую очередь бизнес-логику. Простым рефакторингом никаких улучшений в этом плане не добиться. Все остальное не интересует заказчика. Ему не интересно как вычисляются, к примеру, косты для сток айтема в ордере - в десятке процедур или через создание 15 производных классов. Его интересуют вещи, как правильно заметил UU - "кнопочка печати не там находится". Либо серьезные сбои в бизнес логике. Но никак не "беспонтовость" среды разработки. В общем, Sharp, спорить смысла не вижу. Результаты работы компании говорят сами за себя. И мне надоело читать как один мега-умник разводит демагогию. Когда подниметесь до уровня тех Materialize, MUMPS и Microsoft - тогда и будете критиковать их прагматичные подходы. На сем бестолковую дискуссию прекращаю. Тролльте в сингле. |
||
|
Номер ответа: 195 Автор ответа: AWPICQ: 345685652 Вопросов: 96 Ответов: 1212 |
Web-сайт: Профиль | | #195 | Добавлено: 15.05.09 16:23 |
флудерасты 
|
||
Страница: 1 | 2 | 3 | 4 | 5 ..... 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |