Comments 31
Очень позновательно, сохранил линк, прочитаю внимательно чуть позже :)
В избранное, так же позже переварю головой…
Но уже есть вопрос, Списки в правой колонки выставлены по важности или в разброс, мне кажеться в разброс…
Но уже есть вопрос, Списки в правой колонки выставлены по важности или в разброс, мне кажеться в разброс…
Насколько я понял, автор считает все эти пункты обязательными, так что порядок не играет роли.
А вообще, т.к. я не избалован кучей теории и практики в проектировании приложений (я могу спроектировать, но исходя из опыта и потребностей, а не как аналитик), было бы неплохо если бы автор мог бы каждый пункт в левой колонке описать отдельно что это такое, привести примеры, задать те же вопросы и на них ответить в виде пары примеров. Теоретик с меня к сожалению плохой, зато отличный практик и часто правильные решения я вывожу сам, делаю, а потом где-то читаю что это хорошая практика. Так что правка мозгов в нужное русло мне бы очень не помешала :)
А вообще, т.к. я не избалован кучей теории и практики в проектировании приложений (я могу спроектировать, но исходя из опыта и потребностей, а не как аналитик), было бы неплохо если бы автор мог бы каждый пункт в левой колонке описать отдельно что это такое, привести примеры, задать те же вопросы и на них ответить в виде пары примеров. Теоретик с меня к сожалению плохой, зато отличный практик и часто правильные решения я вывожу сам, делаю, а потом где-то читаю что это хорошая практика. Так что правка мозгов в нужное русло мне бы очень не помешала :)
я недавно обнаружил, что у меня статей на «переварю позже» собралось больше 40 за месяц)
надо как-то решать проблему…
надо как-то решать проблему…
UFO just landed and posted this here
UFO just landed and posted this here
Напоминает лекции в университете. Все на столько хорошо структурированно, насколько оно же бесполезно.
Практической пользы может быть и немного, но я лично всегда с уважением относился к структурированию информации. Хорошо, когда в голове все инструменты аккуратно помечены и лежат на полочках. С этой точки зрения пробежаться по пунктам полезно.
почему бесполезно? такие наброски позволяют заранее обозначить множество проблем, которые непосредственно влияют на проектирование. если не учитывать их сразу, потом вполне может возникнуть ситуация с необходимостью переделать какую-нибудь логику, и это может привести даже к глобальным изменениям в архитектуре.
часто мы не можем заранее учесть все потребности системы, но следует сразу продумать как можно больше потенциальных проблем, особенно это актуально для распределяемых приложений
часто мы не можем заранее учесть все потребности системы, но следует сразу продумать как можно больше потенциальных проблем, особенно это актуально для распределяемых приложений
Да я как бэ не спорю. Но скажите честно, как вам поможет в этом пункт, например, «Промахи кэша» в категории «Кэширование и состояние». Какую информацию он вам принес?
Для новичка это действительно мало что скажет. Разве что фразу для Гугла. А знающий человек поднимет в памяти знакомые рецепты.
Информация — промахи кэша существуют, вероятно для оптимизации нужно с ними бороться :-)
Часто достаточно показать существование пути.
Методы решения меняются, вопросы остаются.
Часто достаточно показать существование пути.
Методы решения меняются, вопросы остаются.
В проектировании привык называть Workflow потоком операций, как-то ближе оно мне, учитывая, что актором и инициатором потока может выступать не только бизнес-пользователь.
>>Ключевые решения
>>Эта таблица перечисляет ключевые решения для каждой горячей точки:
Может я не верно понимаю, но как то странно звучит слово «решения» в этом контексте… по моему правильнее было бы слово «задачи»… все-таки в таблице задаются вопросы плана «как это сделать», а не ответы на них… возможно я и ошибаюсь.
>>Эта таблица перечисляет ключевые решения для каждой горячей точки:
Может я не верно понимаю, но как то странно звучит слово «решения» в этом контексте… по моему правильнее было бы слово «задачи»… все-таки в таблице задаются вопросы плана «как это сделать», а не ответы на них… возможно я и ошибаюсь.
Информация изложена ужасно!
Майкрософт во всей своей красе, с табличками, буллет-пойнтами и ответами на все случаи жизни.
So you wanna be a great programmer, do ya? All you have to do is follow these seven easy bullet points:
1. Stop reading bullet points!
2. You heard me, stop reading these stupid bullet points!
3. They're not helping, you know.
4. They are often just fluffy platitudes.
5. Still reading? I thought you'd get wise by now?
6. It just shows how useless bullet points actually are…
theprogrammersparadox.blogspot.com/2008/09/7-fabulous-ways-to-great-programming.html — интересный пост по поводу такого рода информационного фастфуда, рекомендуется к прочтению
So you wanna be a great programmer, do ya? All you have to do is follow these seven easy bullet points:
1. Stop reading bullet points!
2. You heard me, stop reading these stupid bullet points!
3. They're not helping, you know.
4. They are often just fluffy platitudes.
5. Still reading? I thought you'd get wise by now?
6. It just shows how useless bullet points actually are…
theprogrammersparadox.blogspot.com/2008/09/7-fabulous-ways-to-great-programming.html — интересный пост по поводу такого рода информационного фастфуда, рекомендуется к прочтению
Почему-то представилось грустное выражение лица начинающего программиста «Я всего лишь хотел сделать сайт :)». А так очень позновательно, браво.
Очень интересный текст. Никогда мне не удавалось всё это учесть, к сожалению — что и приводит к проблемам через несколько лет эксплуатации системы.
Честно говоря у нас в системе, если не учитывать это, то к проблемам начинает приводить почти сразу. Но в большей степени данные «точки» относятся к крупным распределенным системам, чем к обычным Web сайтам и любительским приложениям. Так что их можно взять на заметку, если пишешь такую большую систему, но в тоже время следовать всему что тут написано я бы не стал. Если прочитать все существующие стандарты и рекомендации, то время больше убьешь на их запоминание и понимание, чем на разработку такой системы, и не знай еще что у тебя после всех этих «знаний» получится. Я лично предпочитаю делать в таком русле: если есть технология, которая решает мою проблему (или задачу, не важно) самым оптимальным для меня образом и без проблем применяется в «мире» — я ее и применяю, нету такой технологии, приходится изобретать самому :)
Стандарты говорят о том, что если их использовать, то изменение требований к проекту в будущем не потребует серьёзных перестроек, и проект сможет взаимодействовать с другими проектами, поддерживающими стандарты.
Если же пользоваться своими изобретениями, то полечается в конце концов вещь в себе, которую проще переделать чем развивать.
Если же пользоваться своими изобретениями, то полечается в конце концов вещь в себе, которую проще переделать чем развивать.
Блин, это бред, но трудно объяснить почему. Попробую с помощью притчи:
Приносят Вам колеса от грузовика, мотор от запорожца, кузов от X5 и подвеску от Субару Легаси. И говорят — вот смотри каждая из этих фигней крайне эффективна. Смотри — мотор от запорожца экономичный до жути! Кузов X5 эффективнейшим образом создан в плане жесткости и безопасности. Колеса от грузовика ваще супер эффективны — их можно не накачивать.
Сделай теперь мне из этих суперэффективных деталей небольшой семейный автомобиль, работающий на водороде.
И?
Намек понятен?
Приносят Вам колеса от грузовика, мотор от запорожца, кузов от X5 и подвеску от Субару Легаси. И говорят — вот смотри каждая из этих фигней крайне эффективна. Смотри — мотор от запорожца экономичный до жути! Кузов X5 эффективнейшим образом создан в плане жесткости и безопасности. Колеса от грузовика ваще супер эффективны — их можно не накачивать.
Сделай теперь мне из этих суперэффективных деталей небольшой семейный автомобиль, работающий на водороде.
И?
Намек понятен?
Понятно что Вы не поняли о чём писал автор. А писал он о пунктах контроля качества разрабатываемого проекта. И не требовал применять их все к разработке сайта-визитки. А вот для разработки сайта, который должен 10-20 лет работать и развиваться, при этом не падая под мегабайтами старого неподдерживаемого кода — это совершенно незаменимые пункты.
Еще раз повторяю — не существует универсальных советов. Эффективность не существует в вакууме, она служит определенным целям. Поэтому общие положения являются ерундой. На каждый пункт списка этого якобы качества я за секунду могу придумать контрпример. Вот беру по одному из каждого:
«Используйте политики блокировки аккаунтов конечных пользователей (например при множественных ошибках в пароле).»
… что позволит хакерам без особых сложностей блокировать нужные им аккаунты.
«Кэшируйте данные, которые меняются не очень часто или полностью статичны.»
Торговая система, данные из шлюза обновляются редко, пользователь грузит конфигурацию и видит пустой экран вместо текущего состояния рынка.
«Минимизируйте объём данных, передаваемых по сети.»
Например для Вашего проекта цифрового телевидения вместо картинки передавайте текстовое описание того, что происходит на экране?
«Будьте осторожны с зависимостями между компонентами. Используйте паттерны абстракции при первой возможности для уменьшения потенциальных проблем с поддержкой системы в будущем.»
Между связностью системы и стоимостью ее поддержания не существует прямой связи. Наоборот может оказаться, что сильно связанная система (использующая прямое обращение к MS SQL) окажется намного проще слабо связанной (использующей распределенные компоненты, слои доступа, DCOM, CORBA и прочее) и поддерживать ее будет легче.
«Избегайте выполняющихся долго атомарных транзакций»
Неатомарных транзакций вроде как и не бывает. Транзакция она по определению атомарна.
«С самого начала проектируйте систему со слабой связанностью.
Проектируйте систему с сильным сцеплением.»
Гы гы гы. У меня стоит задача написать Тетрис и я вот думаю — как бы мне его слабо связать и сильно сцепить. :)))
«Если вы поддерживаете несколько видов БД, то вам необходим специальный уровень абстракции, который можно легко настроить под конкретное окружение.»
Угу я вот использую timestamp из MS SQL, а в ORACLE его и нет. В какую бы мне это абстракцию засунуть?..
«Не перехватывайте исключения, которые вы не можете обработать.»
Позвольте им обрушить Ваше приложение!!! Это ведь прикольно и понравится пользователям!!!
Это ваще супер-совет! Совет дня! Надо на стенку его прибить!..
Все, надоело… Пускай теперь воинствующее невежство минусует меня…
«Используйте политики блокировки аккаунтов конечных пользователей (например при множественных ошибках в пароле).»
… что позволит хакерам без особых сложностей блокировать нужные им аккаунты.
«Кэшируйте данные, которые меняются не очень часто или полностью статичны.»
Торговая система, данные из шлюза обновляются редко, пользователь грузит конфигурацию и видит пустой экран вместо текущего состояния рынка.
«Минимизируйте объём данных, передаваемых по сети.»
Например для Вашего проекта цифрового телевидения вместо картинки передавайте текстовое описание того, что происходит на экране?
«Будьте осторожны с зависимостями между компонентами. Используйте паттерны абстракции при первой возможности для уменьшения потенциальных проблем с поддержкой системы в будущем.»
Между связностью системы и стоимостью ее поддержания не существует прямой связи. Наоборот может оказаться, что сильно связанная система (использующая прямое обращение к MS SQL) окажется намного проще слабо связанной (использующей распределенные компоненты, слои доступа, DCOM, CORBA и прочее) и поддерживать ее будет легче.
«Избегайте выполняющихся долго атомарных транзакций»
Неатомарных транзакций вроде как и не бывает. Транзакция она по определению атомарна.
«С самого начала проектируйте систему со слабой связанностью.
Проектируйте систему с сильным сцеплением.»
Гы гы гы. У меня стоит задача написать Тетрис и я вот думаю — как бы мне его слабо связать и сильно сцепить. :)))
«Если вы поддерживаете несколько видов БД, то вам необходим специальный уровень абстракции, который можно легко настроить под конкретное окружение.»
Угу я вот использую timestamp из MS SQL, а в ORACLE его и нет. В какую бы мне это абстракцию засунуть?..
«Не перехватывайте исключения, которые вы не можете обработать.»
Позвольте им обрушить Ваше приложение!!! Это ведь прикольно и понравится пользователям!!!
Это ваще супер-совет! Совет дня! Надо на стенку его прибить!..
Все, надоело… Пускай теперь воинствующее невежство минусует меня…
«самый плохой из которых — это анти-паттерн «переделать заново» («do over»)» — к сожалению с этим вынужден не согласиться. Все еще существуют системы, которые выполнены не в соответствии с принципами, приведенными в топике, и их проще переделать, чем рефакторить. Да и тов. Брукс писал, что первая система всегда разрабатывается на выброс, так что даже следование данным правилам, не факт, что приведет к желаемому результату, но Очень сильно поможет направить проект в нужное русло, если развитие пошло криво. Вообщем контент в заклады. Каждый архитект должен иметь подобный чеклист под рукой.
Не подскажите какую-нибудь дитературу, которая может помочь понять все вышеперечисленные проблемы?
Пишу потихоньку cms, улучшаю, удаляю, исправляю, хотелось бы почитать что-нибудь на эту тему.
Пишу потихоньку cms, улучшаю, удаляю, исправляю, хотелось бы почитать что-нибудь на эту тему.
Такие статьи очень сложно воспринимать — терминология может использоваться по разному.
Например:
— кэширование js, css, cookies на стороне клиента
— или кэширование jsp-сервлетов на j2ee-сервере
— или кэширование хранимых процедур в БД
-и т.д.
… как понять?
Так что в зависимости от архитектуры, данные термины могут иметь абсолютно разные значения.
Например:
— кэширование js, css, cookies на стороне клиента
— или кэширование jsp-сервлетов на j2ee-сервере
— или кэширование хранимых процедур в БД
-и т.д.
… как понять?
Так что в зависимости от архитектуры, данные термины могут иметь абсолютно разные значения.
Sign up to leave a comment.
Архитектура приложений — горячие точки