Прикладной дизайн на 5 лет

Мой вопрос не является техническим. Это скорее философское и, по сути, индивидуальное предпочтение. Я разрабатываю и разрабатываю приложение (web + desktop), и это только что произошло со мной, и мне было интересно, если вы, ребята (программисты и дизайнеры), когда-либо сталкивались с этим раньше:Прикладной дизайн на 5 лет

Некоторые дизайнеры верят в создание приложений, 5 лет вниз, и любые изменения, которые приходят к ним, будут отражаться на них, без необходимости прибегать к изменениям в системе. Как программист, я знаю, что это никогда не случай. Небольшие косметические изменения происходят, но обычно они угасают через год или два, по прошествии времени будут изменения, которые потребуют изменений ядра, и в конечном итоге вы сделаете новое приложение.

Учитывая стремительные изменения технологий, разработка приложения на 5 лет вниз по линии довольно абсурдна, ИМХО. Ну, я имею в виду не конструирование, а мысль о том, что это приложение будет работать в течение 5 лет, и убеждение, что нам не нужно будет создавать новую, я думаю, живет в дурацком раю. Я имею в виду, действительно, коллеги-программисты, большинство критически важных или базовых небольших приложений, которые имеют бегущий поток, как правило, повторно создаются/реструктурируются/реорганизованы/перекодированы за несколько лет вниз по линии в любом случае.

Итак, мой вопрос в том, почему придерживайтесь такого подхода к тому, чтобы иметь это идеальное приложение, которое будет работать в течение десятилетия. Это действительно глупо, потому что вы знаете, что технология будет меняться каждый год; новые рамки, новые методы, появятся новые технологии и ваш клиент захочет их. Итак, если вы прощаете мое использование этой фразы, WTF - это точка?

Я продолжаю рассказывать своему дизайнеру, что приложение будет переработано через несколько лет в любом случае, нет смысла пытаться заставить его снимать освещение с его @ss, потому что это просто не будет. Нет такого понятия, как идеальное приложение.

Надеюсь, вы, ребята, получите мой дрейф. Вы тоже так поступили так же. BTW Я занимаюсь бизнесом в области программного обеспечения уже около 7 лет. Если вы действительно думаете об этом, вы действительно думаете, что Facebook останется тем же самым 5 лет подряд, наверняка, дизайн будет меняться каждый год или около того, чтобы оставаться «фанки», но ядро будет меняться каждые пару лет. Я уверен в этом. Я параноик или что? Скажите, что есть другие программисты на той же дороге, что и я. Кто угодно?

источник

2010-08-09 xeshu

Внутренняя часть вашего приложения будет меняться часто. Будут обнаружены ошибки, которые могут потребовать нетривиальных изменений. Код будет реорганизован, чтобы быть более эффективным. Новые функции могут быть добавлены, API может быть добавлен и т. Д. Используя ваш пример Facebook ... Я смотрю на этот сайт, когда я впервые зарегистрировался в 2006 году, и теперь я смотрю на него, и он радикально отличается. Они добавили функции вызова (функции чата, как/неприязнь, fanpages, поиск друзей, рынок и т. Д. И т. Д.), API-интерфейс разработчика и внутренне я уверен, что много изменилось в соответствии с новыми функциями. – RavB

Это точно моя точка! большинство приложений, если не все, радикально меняются со временем. В основном это связано с тем, что клиентские требования развиваются в сочетании с быстрыми технологическими изменениями. Теперь его вопрос о погоде не будет работать, или нет, его больше похоже на «если он соответствует текущей технологической модели». – xeshu

«Самый большой блокпост к прекрасному плану - мечта идеального плана».

Я согласен - проектирование идеальной системы, которая может быть элегантно эластичной для всех возможных будущих изменений, бесплодна. Каждый успешный проект - это компромисс: гибкость здания, где вы уверены, что это будет необходимо (или там, где это легко сделать); и создавая несколько быстро-n-грязный код, где вы считаете, что гибкость/изменение маловероятны. Если вы хорошо разбираетесь в системе, и у клиента есть хорошее представление о своих потребностях/требованиях (не всегда дано), вы получите этот баланс, по крайней мере, большую часть времени.

Однако идея о том, что вся система будет заменена каждые 3-5 лет новой технологией, также является ошибкой. Для каждого клиента, который хочет новейшую, самую новую, самую сексуальную систему, есть 5 клиентов, которые боятся расстаться с (или не могут позволить себе заменять) свою устаревшую систему COM/VB/MS-Access/любую систему, которая является болотом логики спагетти независимо от ремонтопригодности, гибкости или расширяемости. Вы не хотите быть одним зданием этой системы; если вы, то вы делаете ваш клиент/работодатель плохим сервисом.

источник

2010-08-09 17:38:20 mikemanne

Я полностью согласен с вами на 100%. Однако мой опыт работы с такими устаревшими системами, в которых работает клиент, который не учитывает ремонтопригодность и т. Д., Заключается в том, что в конце дня им нужна новая система. Хотя истиной одной из главных причин является то, что код был в значительной степени кошмаром для поддержания, но это НЕ ТОЛЬКО ПРИЧИНЫ: С тех пор, как он так долгое время, технологии изменились и бла-бла, хотя они, возможно, не смогут позволить себе последние сексуальное приложение, они будут готовы согласиться на продукт среднего класса. – xeshu

Дело в том, что я разрабатываю и разрабатываю приложения как можно более гибкие, расширяемые и поддерживаемые, и если позволит время. Тем не менее, я знаю того же самого системного клиента, что теперь я разрабатываю новую систему, независимо от того, будет ли ее беспорядочный код или наиболее гибкое приложение, когда-либо построенное, захочет изменения. Зачем? Потому что он теперь входит в XXI век. Как я уже сказал в своих других комментариях, унаследованные системы в то время продолжались десятилетиями, потому что мир был медленным. Теперь новые рамки развертываются каждые 6 месяцев. Новая ОС выходит каждые 2 года. – xeshu

Желаю, чтобы у клиентов было отношение «если это не сломалось, зачем это исправлять!». Но, к сожалению, клиенты 21 века не такие. Те, у кого $$$, захотят изменить СЕЙЧАС. Те, у кого умеренный $$, будет хорошо подождать немного. Тем, кто сломался, все равно, будет ли приложение гибким или полно беспорядочного полуфабриката. Пункт: ум, установленный для запуска приложений, когда-либо должен измениться. Лучше всего от двух до четырех лет. – xeshu

Мой подход заключается в разработке изменений. Это означает, что я пишу наиболее удобный код, который я могу, поддерживая слабосвязанность и модульность, пытаясь сделать что-то стандартным способом, чтобы другие разработчики могли быстро найти код и т. Д.

Обычно я немного больше усилий для будущего проектирования базы данных, поскольку изменения во многих случаях могут быть намного сложнее, чем изменения кода.

источник

2010-08-09 15:00:58 RedFilter

+1 для того, чтобы быть более осторожным с базой данных. Внесение изменений в дизайн db отстойно даже с помощью таких инструментов, как миграция. – jvenema

О да, конечно, это помогает разработчикам действительно, если дизайн (косметическая и бизнес-логика) гибкий, чтобы справляться с изменениями, но на самом деле это может только пойти так много. У этого есть предел, и по моему опыту (хотя только 7 нечетных лет) приложения получают перепроектированные или обновленные (почти завершенные дела) каждые 3, 4 года. Я не думаю, что ЛЮБОЕ приложение использует более 60% своего исходного кода с момента его создания. – xeshu

Точно. Я ненавижу изменения БД, но опять-таки я могу сделать его немного гибким, всегда будут какие-то грязные неприятные изменения, которые произойдут по линии, в которой вы должны решить, должны ли я делать это, взломать и нарушить все правила или начать сделать больше. Ответ основывается на требовании, что он сам в основном – xeshu

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

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

Так это зависит от того, что вы определили как ядро. Для меня ядро означает дизайн системы, который, если все сделано правильно, вероятно, вообще не изменится в будущем.

источник

2010-08-09 15:03:23

Стандартизация БД, модуляция кода проста, стандарты для бедного человека. Как только приложение становится немного сложным, BAM! первое, что вы выбрасываете из окна, это стандарты, потому что они стоят как стена перед вами и конечным продуктом. – xeshu

Теперь вы можете опровергнуть это, сказав, что, нарушив стандарты, я в основном пригласил себя в кошмар по обслуживанию кода. Правда! Очень верно. Но если бы я приложил огромные усилия, чтобы попытаться получить вещи в соответствии со стандартами, я бы прибегнул к действительному измельчению некоторых основных требований клиента и значительно увеличил время доставки продукта. Но в какую пользу? Через два года мой клиент захочет внести некоторые изменения в хромальные радикалы, которые потребуются, если не полная версия, но более 50% изменений в приложении. – xeshu

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

Хорошо, я думаю, что дизайн идеален полностью ортогонален, но вам просто нужно признать, что он редко работает так, как вы предполагаете. Если вы никогда не читали «Прагматического программиста», он много говорит о будущей проверке вашего кода.

источник

2010-08-09 15:04:05 Nobody

Ровно мои чувства. Нет идеальной конструкции для идеального применения. И стандарты дизайна и кода только заходят так далеко: они вращаются вокруг клиента в основном. Если он станет кошмаром, в мире нет системы, которая будет работать на него. Если он просто хочет быстрого решения, не нужно разрабатывать для него ракетный корабль, потому что он не оценит его, и он попросит радикальные изменения. Для тех немногих счастливчиков, которые сталкиваются с этими почти идеальными клиентами, я завидую им. :) – xeshu

Лично я бы никогда не планировал какое-либо приложение, предполагая, что он будет заменен в течение нескольких лет. Это все, что часто «обновления» и «переписывания» отталкиваются для быстрого исправления, желаемого клиентами, которые не хотят ждать целого нового приложения. Уверены, что требования меняются, нужны функции, но часто они желательны в текущей итерации.

Я имею в виду, что есть много приложений, языков и шаблонов дизайна, которые думали одно и то же, и до сих пор используются. Тот, который появляется в моей голове, является ошибкой y2k. Программисты в 70-е годы никогда не думали, что их код продлится 30 лет, и, несомненно, кто-то расширит эти значения года до 4 цифр до начала века. Мы все помним, как это мышление получилось ...

источник

2010-08-09 15:05:06 Kevin

Ваш аргумент верен и звучит, и я уважаю это. Это зависит от типа проекта, который вы разрабатываете, и кем является клиент. Конечно, я бы подумал о том, что проект будет развернут на 2-4 года, но это мой максимальный предел. Я думаю, что с клиентами, над которыми я работал, я полностью потерял веру в них. – xeshu

Я работал в двух разных компаниях, у которых были программные продукты, которые приближались к 10+ годам. Хотя они были расширены множеством новых функциональных возможностей и получили много подтяжек, ядро приложения было практически нетронутым с момента первого стабильного выпуска. Это может быть не типичным, но если архитектор достаточно квалифицирован, система может быть построена так, чтобы быть модульной и достаточно расширяемой, чтобы обеспечить удивительный рост.

источник

2010-08-09 15:09:22 acanaday

Очень верно! Его навыки архитектора. Однако то, что вы описываете, является очень чистой средой, где клиент немного более образован, чем средний клиент. Так как теперь они верят в приложение, и они знают, что он выполняет эту работу, зачем тогда менять ядро. Я желаю, чтобы больше клиентов были такими, но, к сожалению, с моим опытом встречи с разными клиентами, это не так. – xeshu

Ну, нет. Это были две очень разные среды, одна из которых была инженерно-производственной средой, которая была настолько далека от «чистой», как вы можете получить. Я полагаю, что это зависит от обстоятельств, но обычно я не думаю, что клиент должен ЗНАТЬ, когда вы меняете ядро. То, что они делают, указывает на сломанный дизайн, ИМХО. Они должны просто предоставлять требования и получать новые функции взамен. Другой продукт использовался клиентами, постоянно развивающимися и чрезвычайно требовательными! Хорошо спроектированная система упрощает управление сложными клиентами! – acanaday

Худший клиент - это клиент, который не знает, чего хочет. Компании-разработчики программного обеспечения, использующие свой опыт, стараются предоставить клиенту, исходя из его первоначальных требований (как вы так правильно положили) и доставить конечный продукт (с обратной связью с клиентом и всеми остальными). Что бы вы сделали в ситуации, когда клиент после 2 лет развертывания говорит, что ему не нравится, как это делается и что делается (хотя он и не знает, но все еще является ядром)? Не могли бы вы сказать, что это плохой дизайн программы? или злого клиента? – xeshu

Это действительно зависит от окружающей среды. Я обнаружил, что наши внутренние корпоративные приложения полностью переработаны (часто удаляются) в течение 18 месяцев после запуска. Это не чья-либо ошибка - смена бизнес-приоритетов, изменение требований, появление новых систем. В то же время другая система работает очень долго.

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

источник

2010-08-09 15:11:23

Данные и структуры данных (часто) должны быть законно рассчитаны на десятилетия. Ожидается, что алгоритмы, UI и все остальное будут быстро развиваться.

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

Это тоже может быть доведено до крайности. Есть подмножества данных, которые, вероятно, никто не будет заботиться в течение 50 лет, например, счетчики производительности памяти, которые могли быть сохранены в базе данных.

источник

2010-08-09 15:21:04 MatthewMartin

Финансовые приложения, я согласен, последний самый длинный среди пула приложений. Однако, тем не менее, я очень сомневаюсь, что они продолжаются более 6-8 лет. Несомненно, данные сохранены. Но приходят другие приложения или радикальные обновления из оригинального приложения, которое в основном является обновлением. Поэтому я хочу сказать, что это не будет оставаться неизменным, изменение неизбежно. И причина, по которой приложения так долго продолжались, для некоторых из вас, ребята, - это то, что в начале 90-х - начале 2000-х годов платформы, рамки, технологии кодирования не менялись так часто, как сейчас. – xeshu

Его быстрый темп сейчас, с нынешним средним набором клиента XXI века, я очень сомневаюсь, что приложения будут длиться даже 5 лет. – xeshu

Я работал над кодом, который использовал структуру данных где-то между 50 и 80 годами - макет записи был оптимизирован для бумажных карточек. Я знаю людей, которые использовали код финансового анализа около 2005 года, который был написан в начале 1980-х годов. В академических кругах все еще используется код Fortran, потому что никто не достаточно умен, чтобы переписать его. Даже если приложение переписывается, часто устаревший код встраивается в новый с просто синтаксическими изменениями. Во всяком случае, крупные организации могут только так быстро меняться, независимо от темпов инноваций в остальном мире. Зависит от того, где вы находитесь. – MatthewMartin

Я помню цитату из Джеймса Ковача я считаю, в одном из подкастов скалах .NET, где он описал нашу промышленность, как:

один, где единственная константа является изменить

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

* Я знаю, что во многих банках люди по-прежнему используют древние приложения, потому что слишком рискованно их менять, и у них просто нет опыта в их изменении.

источник

2010-08-09 15:25:21 theburningmonk

Прикладной дизайн на 5 лет

ответ

Смежные вопросы