999
Модераторы: Neoxygen, vsm, MadFlower
- Остап Бендер
- Продвинутый
- Сообщения: 942
- Зарегистрирован: Вт сен 30, 2003 12:03
999
что случилось с 999 мд? че не работает?
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация:
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация:
Редко когда встретишься с примером процесса разработки, где планирование архитектуры играет не менее важную роль, нежели сама реализация системы.
И вероятнее всего, девятки программировались по нарастающей, изначально в лучшем случае группой программистов одиночек. Это значит, что разные части системы имеют свою особенную структуру.
Кроме того, периодически нужно пересматривать места, где можно оптимизировать систему.
В том числе в структуре базы данных.
А это означает, что некоторые части кода будут неизбежно переписаны.
Но когда речь идёт о переписывании кода, - хочется сделать как можно лучше, с учётом последних знаний о паттернах проектирования с целью сделать систему более адаптивной, гибкой и расширяемой.
А значит, нужно переписать по крайней мере ядро, на котором будет строиться такая система. А это означает фактически переписать бОльшую часть кода. И адаптировать для него имеющиеся функции, методы, классы и так далее. Возможно, реструктурировать их. А затем пройтись по всем прочим местам и выяснить, где могут быть проблемы. Где появился мёртвый код. А где, возможно, даже, мёртвый код перестал быть таковым, отчего могут возникнуть фантомы.
Если процесс разработки хорошо поставлен, то при каждой итерации пишутся юнит-тесты. Если в коде использовались различного рода "магические" методы, то тестирование осложняется в разы.
Да и само тестирование составляет не менее 50% времени и усилий в процессе разработки.
А для такой большой системы как девятки это громадные производственные мощности. Которых, как мне кажется, им не хватает.
Кроме того, у симпласов есть несколько сервисов, одни из них написаны раньше, другие позже. Скорее всего есть большое количество общего кода в разных частях этих сервисов. Вот они и пытаются, скорее всего, подвести весь этот хаос к какому-то общему знаменателю.
Я принимал участие в разработке довольно крупных проектов, и мне известно как происходит миграция со старого кода на новый. Это особенно тяжело, если новая версия системы не переносилась слоями, а писалась почти с нуля.
И мне известно, как сложно адаптировать и оттестировать новую систему в сжатые сроки. И ещё сложнее поставить себе ограничение, до которого нужно дойти, чтобы получить целостную систему. Бывает, что одни программисты баги правят в старых каких-то делах, другие - новую систему дописывают. Третьи уже в новой системе баги начали исправлять. И в итоге получается, что вроде как можно выкладывать систему в продакшн, но всегда есть недоделанные вещи.
Короче, девятки помучаются ещё и потом всё устаканится.
И вероятнее всего, девятки программировались по нарастающей, изначально в лучшем случае группой программистов одиночек. Это значит, что разные части системы имеют свою особенную структуру.
Кроме того, периодически нужно пересматривать места, где можно оптимизировать систему.
В том числе в структуре базы данных.
А это означает, что некоторые части кода будут неизбежно переписаны.
Но когда речь идёт о переписывании кода, - хочется сделать как можно лучше, с учётом последних знаний о паттернах проектирования с целью сделать систему более адаптивной, гибкой и расширяемой.
А значит, нужно переписать по крайней мере ядро, на котором будет строиться такая система. А это означает фактически переписать бОльшую часть кода. И адаптировать для него имеющиеся функции, методы, классы и так далее. Возможно, реструктурировать их. А затем пройтись по всем прочим местам и выяснить, где могут быть проблемы. Где появился мёртвый код. А где, возможно, даже, мёртвый код перестал быть таковым, отчего могут возникнуть фантомы.
Если процесс разработки хорошо поставлен, то при каждой итерации пишутся юнит-тесты. Если в коде использовались различного рода "магические" методы, то тестирование осложняется в разы.
Да и само тестирование составляет не менее 50% времени и усилий в процессе разработки.
А для такой большой системы как девятки это громадные производственные мощности. Которых, как мне кажется, им не хватает.
Кроме того, у симпласов есть несколько сервисов, одни из них написаны раньше, другие позже. Скорее всего есть большое количество общего кода в разных частях этих сервисов. Вот они и пытаются, скорее всего, подвести весь этот хаос к какому-то общему знаменателю.
Я принимал участие в разработке довольно крупных проектов, и мне известно как происходит миграция со старого кода на новый. Это особенно тяжело, если новая версия системы не переносилась слоями, а писалась почти с нуля.
И мне известно, как сложно адаптировать и оттестировать новую систему в сжатые сроки. И ещё сложнее поставить себе ограничение, до которого нужно дойти, чтобы получить целостную систему. Бывает, что одни программисты баги правят в старых каких-то делах, другие - новую систему дописывают. Третьи уже в новой системе баги начали исправлять. И в итоге получается, что вроде как можно выкладывать систему в продакшн, но всегда есть недоделанные вещи.
Короче, девятки помучаются ещё и потом всё устаканится.
dmitry.meshin,
Спасибо за урок программирования/планирования/архитектуры, Дмитрий. Было очень полезно узнать о юнит-тестах, рефакторинге, патернах, тестировании. Не хотелось бы Вас ничем обидеть, но какое это все имеет отношение к понятию "business justification"? Вот есть веб-приложение, достаточно простое, если уж на то пошло, приложение (Вы его гордо именуете "системой"). Свою задачу оно выполняет - объявления размещаются, реклама крутится, денежка капает - все вроде бы довольны. Зачем вбухивать еще тонну бабла в то, чтобы его переписать на новую архитектуру/фрэймворк/платформу? Щас вот глянул на девятки - интерфейс похож на тот, что был 10 лет назад, концептуальных изменений не заметно. Зачем-то прикручен веб-магазин в дополнение к доске объявлений. По сути - это два разных бизнеса. Ну хочется их как-то связать - можно повесить банер на старый сайт, который вел бы на новый магазин. Это же гораздо дешевле (вспомним хотя бы о тестировании!).
Спасибо за урок программирования/планирования/архитектуры, Дмитрий. Было очень полезно узнать о юнит-тестах, рефакторинге, патернах, тестировании. Не хотелось бы Вас ничем обидеть, но какое это все имеет отношение к понятию "business justification"? Вот есть веб-приложение, достаточно простое, если уж на то пошло, приложение (Вы его гордо именуете "системой"). Свою задачу оно выполняет - объявления размещаются, реклама крутится, денежка капает - все вроде бы довольны. Зачем вбухивать еще тонну бабла в то, чтобы его переписать на новую архитектуру/фрэймворк/платформу? Щас вот глянул на девятки - интерфейс похож на тот, что был 10 лет назад, концептуальных изменений не заметно. Зачем-то прикручен веб-магазин в дополнение к доске объявлений. По сути - это два разных бизнеса. Ну хочется их как-то связать - можно повесить банер на старый сайт, который вел бы на новый магазин. Это же гораздо дешевле (вспомним хотя бы о тестировании!).
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация:
Да не в интерфейсе дело.Злобный писал(а):dmitry.meshin,
Спасибо за урок программирования/планирования/архитектуры, Дмитрий. Было очень полезно узнать о юнит-тестах, рефакторинге, патернах, тестировании. Не хотелось бы Вас ничем обидеть, но какое это все имеет отношение к понятию "business justification"? Вот есть веб-приложение, достаточно простое, если уж на то пошло, приложение (Вы его гордо именуете "системой"). Свою задачу оно выполняет - объявления размещаются, реклама крутится, денежка капает - все вроде бы довольны. Зачем вбухивать еще тонну бабла в то, чтобы его переписать на новую архитектуру/фрэймворк/платформу? Щас вот глянул на девятки - интерфейс похож на тот, что был 10 лет назад, концептуальных изменений не заметно. Зачем-то прикручен веб-магазин в дополнение к доске объявлений. По сути - это два разных бизнеса. Ну хочется их как-то связать - можно повесить банер на старый сайт, который вел бы на новый магазин. Это же гораздо дешевле (вспомним хотя бы о тестировании!).
Я понял, что вы видите мало внешних отличий.
Вопрос в том, зачем менять всё внутри. И мне кажется на этот вопрос я ответил
dmitry.meshin,
Вы не поняли меня )) Я осознаю, что поменяются и структура БД, и уровень бизнес-логики. Я не вижу, ЗАЧЕМ это делать. Чтобы что-то стало "лучше"? ))) Это лабораторную работу в институте можно полировать бесконечно, улучшая что-то то тут, то там. Время студента ничего не стоит. Переписывать работающее веб-приложение имеет смысл только тогда, когда это приведет как каким-то улучшениям в бизнесе - увеличит уровень продаж, к примеру. Просто так из эстетических соображений что-то не переписывают - это тупо дорого и не обосновано с финансовой точки зрения.
Вы не поняли меня )) Я осознаю, что поменяются и структура БД, и уровень бизнес-логики. Я не вижу, ЗАЧЕМ это делать. Чтобы что-то стало "лучше"? ))) Это лабораторную работу в институте можно полировать бесконечно, улучшая что-то то тут, то там. Время студента ничего не стоит. Переписывать работающее веб-приложение имеет смысл только тогда, когда это приведет как каким-то улучшениям в бизнесе - увеличит уровень продаж, к примеру. Просто так из эстетических соображений что-то не переписывают - это тупо дорого и не обосновано с финансовой точки зрения.
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация:
Ну так я и говорю, что поддержка кода, который строится на одинаковой "базе" будет намного эффективнее и быстрее.Злобный писал(а):dmitry.meshin,
Вы не поняли меня )) Я осознаю, что поменяются и структура БД, и уровень бизнес-логики. Я не вижу, ЗАЧЕМ это делать. Чтобы что-то стало "лучше"? ))) Это лабораторную работу в институте можно полировать бесконечно, улучшая что-то то тут, то там. Время студента ничего не стоит. Переписывать работающее веб-приложение имеет смысл только тогда, когда это приведет как каким-то улучшениям в бизнесе - увеличит уровень продаж, к примеру. Просто так из эстетических соображений что-то не переписывают - это тупо дорого и не обосновано с финансовой точки зрения.
Что в свою очередь позволит эффективнее вести поддержку, более быстро наращивать систему в будущем, уменьшить штат программистов, сузить количество знаний системы, которые необходимы для эффективной работы с ней, выбросить проблемные места и так далее. Эти все дела очень даже хорошо конвертируются в копеечку, если они не решены должным образом.
Поэтому, как я выше и написал, они скорее всего пытаются все свои сервисы подвести к этой "базе".
И перестроение кода, архитектуры и так далее - это неизбежное следствие.
Мне известен один яркий пример такого поведения в бизнесе.
Когда код 20-летней давности, написанный на перле, прекрасно работал. Но затраты на его поддержку ввиду его же "топорности", так скажем, - были довольно большими.
Компания переписала систему полностью на Zend Framework, сделав перед этим детальный анализ технологий, и выбрав ZF как самую поддерживаемую и стабильную платформу (по их мнению).
И траты на поддержку проекта существенно снизились, а заодно увеличилась скорость выпуска новых релизов с разными плюшками, которые в свою очередь также повысили прибыльность бизнеса.
Всё вроде бы понятно.
dmitry.meshin,
мне непонятны эти самые "плюшки". система простая, оттестированная, что там было развивать и поддерживать, мне не очень понятно. во времена своего нищебродского детства я клепал какие-то левые проектики за небольшие баксы - с базами данных, БЛ-слоем, веб-интерфейсом - прошло уже много лет, никаких требований по поддержке и расширению не приходило. Как было сделано, так и работает. Это ж сервис, заточенный под одну простую задачу, которая не меняется со временем. Если система живая, с меняющимися со временем требованиями, тогда дело другое. Но доска объявлений вряд ли является примером такой системы. И все же ее решено было переписать )) Что интересно, через лет 5-10 ее снова захотят переписать на очередной сверкающей технологии.
мне непонятны эти самые "плюшки". система простая, оттестированная, что там было развивать и поддерживать, мне не очень понятно. во времена своего нищебродского детства я клепал какие-то левые проектики за небольшие баксы - с базами данных, БЛ-слоем, веб-интерфейсом - прошло уже много лет, никаких требований по поддержке и расширению не приходило. Как было сделано, так и работает. Это ж сервис, заточенный под одну простую задачу, которая не меняется со временем. Если система живая, с меняющимися со временем требованиями, тогда дело другое. Но доска объявлений вряд ли является примером такой системы. И все же ее решено было переписать )) Что интересно, через лет 5-10 ее снова захотят переписать на очередной сверкающей технологии.
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация:
Возможно вы и правы.Злобный писал(а):dmitry.meshin,
мне непонятны эти самые "плюшки". система простая, оттестированная, что там было развивать и поддерживать, мне не очень понятно. во времена своего нищебродского детства я клепал какие-то левые проектики за небольшие баксы - с базами данных, БЛ-слоем, веб-интерфейсом - прошло уже много лет, никаких требований по поддержке и расширению не приходило. Как было сделано, так и работает. Это ж сервис, заточенный под одну простую задачу, которая не меняется со временем. Если система живая, с меняющимися со временем требованиями, тогда дело другое. Но доска объявлений вряд ли является примером такой системы. И все же ее решено было переписать )) Что интересно, через лет 5-10 ее снова захотят переписать на очередной сверкающей технологии.
Но мне показалось, а возможно и нет, - что они делают каталог в магазине и поиск по объявлениям более детальными.
Это также может быть причиной серьезных реконструкций.
Раньше я не помню чтобы видел некоторые опции при поиске и фильтрации.
А детальность в этих делах играет ключевую роль. Как-то общался с профессиональным брокером на эту тему.
- dmitry.meshin
- Новичок
- Сообщения: 25
- Зарегистрирован: Пн окт 08, 2012 06:53
- Контактная информация: