Зачем нужен архитектору компьютер: как технологии меняют строительство — Офлайн на vc.ru

Софт для архитектора | Блог Софт Культуры

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

Чтобы самостоятельно делать красивые картинки, молодому архитектору нужно погружаться в ремесло визуализации — но не очень глубоко, чтобы не стать молодым визуализатором. Для такого погружения пригодятся связки Corona + 3ds Max или V-Ray + SketchUp / Rhinoceros. Выбор зависит от программы для моделирования: например, если ты работаешь в Revit, логичнее всего визуализировать проект с помощью Corona, потому что модель можно без лишних усилий импортировать в 3ds Max и быстро настроить материалы и свет — эта связка разработана хорошо. А если ты работаешь в SketchUp или в Rhino, то лучше визуализировать проекты в V-Ray, потому что связка V-Ray + SketchUp / Rhino тоже позволяет делать все быстро и качественно.

Можно освоить и более редкие инструменты визуализации — например, Octane Render: он есть и на Rhino, и на SketchUp, то есть для работы с ним не нужен 3ds Max, зато нужна видеокарта от NVIDIA, которая есть не у всех, а значит, Octane Render нельзя рекомендовать как общее решение.

Если архитектор хочет углубиться в BIM, строительные технологии и в менеджмент проектирования и строительства, BIM-инструменты — бездонный ресурс: можно глубоко копать и осваивать Dynamo — плагин на Revit, — чтобы делать квартирографию и автоматизировать некоторые процессы проектирования.

Для аналитических задач или экспериментов с формой необходимо иметь в арсенале какой-то алгоритмический инструмент. Например, Grasshopper вместе с Rhino. Rhino без Grasshopper — это просто точный инструмент для моделирования. Связка Rhino и ArchiCAD хорошо налажена. С Revit будет больше проблем, если заниматься алгоритмическими экспериментами, потому что швов в рабочем процессе будет больше — но и это возможно.

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

В любом случае «золотого ключика» — одной или двух программ, которые ты можешь выучить и которые тебя во всех случаях жизни спасут, — просто нет. Специфика архитектурной профессии в том, что нужно потратить значительное количество времени и выучить много всего, чтобы потом в этом плавать как рыба в воде и не чувствовать напряжения и каких-то ограничений, связанных с инструментами.

Как работают IT-архитекторы – наши примеры и задачи / Блог компании SimbirSoft / Хабр

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

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

Мы в SimbirSoft развиваем собственный архитектурный комитет – в нем уже 54 опытных разработчика. Делимся опытом, чем у нас занимаются архитекторы и на каких проектах они нужны.

Задачи IT-архитектора

Архитектура – это технологическая база IT-продукта. IT-архитектор, или системный архитектор – это, прежде всего, опытный разработчик. Он знает, когда полезно использовать определенную технологию, а самое главное – когда этого не нужно делать и какие есть риски.

Его задачи:

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

Говоря о хорошей архитектуре, обычно имеют в виду:

Гибкость

Возможность адаптации продукта к новым требованиям бизнеса, даже если в начале процесса проектирования они не были известны в полном объеме.

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

Соответствие

Адаптация к ограничениям системы и соответствие техническим и операционным требованиям: по технологическому стеку, работе с персональными данными, Big Data, большим количеством интеграций.

Качество

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

Рассмотрим несколько ситуаций, в которых необходима проработка IT-архитектуры.

Когда нужен IT-архитектор

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

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

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

Как правило, бизнес заказывает разработку архитектуры в IT-компании в следующих случаях:

1. Нужно разработать ПО с учетом требований законодательства.
2. Нужно с нуля разработать ПО, при этом снизить риски ошибок, срыва сроков, увеличения стоимости реализации.
3. Требуется повысить гибкость системы.
4. Система не отвечает требованиям масштабирования, нагрузки, безопасности.
5. Нет ресурсов для разработки IT-архитектуры.

Как выбрать архитектуру

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

Коробочное или кастомное решение?

Кастомная разработка с нуля требует времени и тщательного планирования. «Коробки» – например, такие как «1С: Бухгалтерия» – подходят для компаний с простыми и стандартными бизнес-процессами, но их возможности развития ограничены. При необходимости дальнейшей кастомизации коробка может обойтись даже дороже, чем разработка с нуля, сразу заточенная под нужды компании.

Монолитная или микросервисная архитектура?

Оптимальное решение для прототипов и простых веб-приложений (например, CRM, интранет-порталы, сайты-визитки), позволяет быстрее выпустить новый продукт на рынок и при необходимости постепенно переписывать отдельные его фрагменты. Подробнее об этом можно прочитать в нашей прошлой статье.

Риски: при увеличении функциональности приложения и количества активных пользователей монолит может перестать справляться с нагрузкой, и срок доставки новых фич будет долгим.

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

Риски: сложность разработки влечет за собой дополнительные требования к квалификации сотрудников. Для микросервисов наличие CI/CD – обязательное условие. Время на разработку будет выше, чем при работе с монолитом (при условии, что архитектурная структура монолита позволяет быстро вносить изменения).

Пример реализации

Один из наших клиентов-банков использовал коробочную систему дистанционного банковского обслуживания (ДБО). Добавить новые функции (и даже передвинуть кнопки) можно было только с помощью вендора. А значит, во-первых, релизы выходили редко (один раз в квартал), во-вторых, вся экспертиза была сосредоточена у вендора, а не в банке. Кроме того, из-за сложной балансировки клиентов монолитной архитектуры приложение работало со сбоями. Из-за этого банк обратился к нам для проработки нового решения.

Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.

Как работает архитектурный комитет

У разных IT-компаний свои способы работы с архитектурой. В небольших монопродуктовых командах у специалистов есть возможность напрямую посоветоваться с коллегами, опытными в тех или иных технологиях. А когда проектов много, появляется необходимость накапливать экспертизу, поскольку при переключении сотрудников с проекта на проект теряется ценный технический контекст. Выстраивая этот процесс, мы снижаем риск ошибок и неоптимальных решений.

У нас в разработке параллельно десятки проектов, и мы стремимся поддерживать внутреннее комьюнити экспертов и обмен опытом. Для этого мы создали архитектурный комитет – отдельную группу со своим руководителем.

Архитектурный комитет – это команда, в которую входят наиболее опытные разработчики Backend, Frontend, Mobile. Сейчас у нас 54 таких специалиста, их число постепенно растет.

Мы уже писали на Хабре, как мы разбираем входящие запросы и оцениваем сроки разработки. Расскажем, как в этом участвуют архитекторы.

Этапы работы

• Анализ требований

На старте проекта мы собираем функциональные, нефункциональные, системные и бизнес-требования.

• Проектирование архитектуры

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

• Внутренний контроль

Дополнительная проверка выбранного решения 3-5 участниками архитектурного комитета. При необходимости – доработка решения с учетом рекомендаций.

• Презентация заказчику

Архитектор, ответственный за проект, формирует документ с архитектурными схемами, описанием взаимодействий и другими необходимыми материалами, обосновывает выбранное решение.

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

• Архитектурный надзор при разработке

На начальном этапе разработки каждого проекта архитектор помогает заложить каркас системы и курирует архитектуру.

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

Несколько участников архитектурного комитета SimbirSoft

Вывод

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

• Сокращение срока выпуска продукта на рынок MVP (Minimum Viable Product)
• Сокращение времени на выпуск новых фич (time-to-market).
• Независимость заказчика: возможность выбирать любого подрядчика или вести разработку самостоятельно.
• Минимизация количества сбоев в продукте.
• Возможность найти оптимальное решение для каждой проблемы и гибкость при внедрении новой функциональности.

Спасибо за внимание! Надеемся, что статья была вам полезна.

Какие компьютерные программы нужны архитектору? — Технологии

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

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

BIM-программы

Архитектору следует освоить Revit или ArchiCAD, а лучше и Revit, и ArchiCAD – ведь в BIM-среде можно организовать совместную работу со смежными специалистами. Общая трехмерная модель будущего здания разбивается на рабочие плоскости, каждый элемент которых рассматривается отдельно. База данных таких программ содержит информацию обо всех этапах проекта – от разработки концепции до строительства.

AutoCAD

AutoCAD уже не так актуален, как раньше. Несмотря на довольно широкие возможности, он по-прежнему считается электронным кульманом (особенно на фоне BIM-программ). Инструмент теряет свою популярность и сейчас применяется только для решения промежуточных задач.

SketchUp

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

Grasshopper

Параметрическая архитектура больше не в тренде, а вместе с тем уходят в небытие такие инструменты, как Grasshopper 3D. С его помощью можно проектировать замысловатые модели в среде Rhino 3D – в любом случае вам не помешает знать эту программу хотя бы на базовом уровне. Генеративное моделирование в Grasshopper – это создание алгоритма. То есть достаточно будет внести новые данные, и программа сама изменит весь объект.

Photoshop

С Photoshop знакомы даже ленивые и неискушенные в технологиях люди. В чем польза Photoshop для архитектора? Ему всегда была важна визуальная составляющая проекта. А магические техники Photoshop позволяют подрисовать то, что нужно.

«Хочешь быть системным архитектором? Там только свет и чистота…»

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

— Рома, я задолбался быть инженером. Всё, ухожу!

Он ласково улыбнулся и сказал:

— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.

Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.

Но! Если понимаете — это будет очень увлекательное приключение.

Как это выглядит?

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

Разрыв с реальностью в том, что то, что у них в головах, не всегда соотносится с тем, что у них в инфраструктуре.

И сначала ты работаешь психологом, потом доносишь правду, потом на тебя обижаются (иногда), потом ты опять работаешь психологом, потом задаёшь сто вопросов, потом проверяешь факты (и не все они такие, как представлены) — и только после этого складывается мнение, как проектировать систему. Потом ты объясняешь это всем людям, которые в ней заинтересованы: почему так, зачем, сколько будет стоить, как правильно для такой-то ситуации и для такой-то, почему может оказаться, что «чтобы быстрее заработало» и «надо на 10 лет вперёд» может быть на одной и той же технологией, а может и не быть. И как выбрать. А потом, когда твоя печень вырастает большая-пребольшая, остаётся только нарисовать сову — собственно, спроектировать систему в деталях.

Самое большое удовольствие в профессии — это сначала закончить проектирование и понять, что всё именно так, как нужно по задаче. А потом, спустя пару лет, увидеть, как это воплощается командой (или многими командами, до сотен людей), и порадоваться, что ты это увидел и показал, как делать.

В общем, архитектор — это тот, кто принимает главные решения на проекте. Наверное, это больше всего и «подсаживает» на профессию.

Что вообще делает архитектор?

Сейчас я занимаюсь клиентскими проектами и нашим облаком Техносерв Cloud. Развлечение выглядит так: прилетает какой-нибудь крупный проект. Например, спроектировать дата-центр.

Кто-то ЦОД рисует. Кто-то хорошо разбирается в базах данных. Кто-то в сети. И во всём этом нужен такой человек, который понимает верхнеуровневые требования заказчика к проекту в целом. У заказчика нет желания построить ЦОД или внедрить какую-то систему. У него задача — «хочу переместить всю свою нагрузку из одного места в другое» или «организовать отказоустойчивую площадку, которая позволила бы всем моим системам пережить дизастер». Нужен тот, кто поймёт все эти требования. Причём они ещё даже не требования, они просто хотелки. «Мы хотим увеличить продажи в 2 раза и при этом число инцидентов сократить в 3 раза» — надо прийти поговорить с нужными людьми, понять, откуда у них столько инцидентов, что с этим можно сделать.

То есть сначала собираются хотелки. Потом составляется и согласуется ТЗ, потом по нему делается решение, которое включает и физику, и прикладную часть, — для всех этих задач нужен архитектор.

Не обязательно архитектор делает весь проект по всем подсистемам — на крупных вещах система совета или зон ответственности под руководством главного специалиста. Например, сетевой архитектор привлекается тогда, когда необходимо спроектировать и построить ВКС (СКС) для проекта. Архитектор-прикладник же привлекается, когда нужно разработать какие-то информационные системы. И так далее.

Проще всего объяснить на примере облака. Я делаю начальное проектирование всего того, что компания продаёт из облака. Я планирую и проектирую (и ещё потом контролирую) построение собственной инфраструктуры, потом сдаю её команде эксплуатации. Со мной работают три человека на подзадачах: отвечают за OpenStack, за VMware, за сеть хранения.

Где тогда геморрой?

Где-то в 85% случаев бизнес считает, что половина того, что он хочет, и мы ему рассказываем, у него уже есть — и проблем никаких нет. Но штука в том, что когда спускаешься на уровень департамента, отдела и т. д., оказывается, что всё не так прикольно: процессы прорисованы у бизнеса («Мы полностью исполняем ITIL в процессах, заявки проходят согласование чисто только в системах, всё проскакивает моментально»), а у админов СУБД выясняется, что безопасники всё равно просят принести бумажную копию, подписанную у всех руководителей компании. Анализируют эту бумажку много месяцев и только потом дают добро на развёртывание какой-то тестовой среды.

Подстава в том, что если прийти на проекте к бизнесу с формулировкой, что у вас всё работает не так, то молись, чтобы тебя не взяли в этот проект.

Потому что те, кого ты этим «спалил», тебе работать не дадут.

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

И да, мне нравится придумывать, как всё это можно изменить.

Оценить проект можно только вместе с бизнесом, и то через пару лет. Но на самом представлении бывает субъективная составляющая: ну, самолёт должен летать и быть красивым. А ещё такой результат должен стать шаблоном в идеале, чтобы можно было внедрять во всех похожих случаях.

Как выгорают

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

Говорит: «Как вас земля носит, идиотов таких!» И доказывает, разбирая код. Но его любят за профессионализм. Он никогда не хотел быть архитектором, говорит: «Я не хочу переводить оттенки смыслов и эманации, что они там чувствуют». И остаётся инженером и по сей день. «Есть ТЗ. Я взял, пошёл и сделал. Я не хочу даже знать, нужно ли ему это было или нет».

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

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

«А если я буду делать неправильно»?

ИТ-директор телекома как-то спросил: «Если я буду делать неправильно, вы меня поправите?»

«Да, — говорю, — мы будем разговаривать».

Он: «А как вы будете меня убеждать?»

Я говорю: «Никак. Пистолет у вас. Я могу только сказать, что если вы будете себе стрелять в ногу, вероятно, вам будет больно».

Но я всегда предупрежу, что пистолет направлен в ногу.

Или вот пример. Есть виртуализованные приложения, нагрузка скачет от случая к случаю. Клиент из розницы, и у него перед 8 марта начинается шквал. Бэкэнд успевает, а сайты ложатся на 404. Тут всё просто: надо просто приложение разнести на параллельные процессы, продумать, чтобы узких мест не было. А писалось оно в 90-х и с тех пор обрастало ракушками — надо много чего переворошить. Потом сменились люди в бизнесе, говорят: «Давайте закупим лишних серверов и будем жить от концепции, чтобы мощностей хватало под пик». Докупили пару стоек, вхолостую гоняют их 320 из 365 дней в году. Через два года эти дядьки ушли, пришли новые. Смотрят на стойки, говорят: «Чего воздух греют, давайте продадим». Продают. Весна наступает неожиданно, пик. Снова начинается первая итерация. В итоге они идут в облако, и мои коллеги начинают помогать им правильно делать инсталляцию. Не все даже понимают, что такое балансировщик, но тут лучше в деталях эксплуатация расскажет, у них накипело.

Часто надо быстро запустить проект любой ценой за 2 месяца, а на деле, когда зоопарк разбираешь, понимаешь, что строить должны на 10 лет. Иногда удаётся донести. Иногда нет — заказчик мыслит годовым планом, и это его деньги и его бизнес. Он прав, он знает, что делать стратегически в бизнесе. Моя задача — показать ему варианты и, условно говоря, плюсы-минусы каждого в максимально понятных ему числах или определениях.

А ещё нас иногда дразнят стартапщиками — всё чаще запускаем прототипы, а потом их начинаем переделывать в постоянные штуки.

Кто может «потянуть»?

Не знаю, как становятся архитекторами. Могу сказать, что я 4 года работал инженером, потом в другой компании (уже с опытом) — как проектировщик, а потом как архитектор. В «Техносерве» два с половиной года. Но «на той стороне» я всё равно работал с инженерами «Техносерва», как с людьми подрядчика — делали один большой проект.

Большинство архитекторов, конечно, вырастают из продвинутых разработчиков и инженеров. Но есть единичные исключения, всё зависит от навыков системного мышления, которые в целом приобретаются не обязательно в ИТ-специальностях.

Многие в архитектуру идут за новыми технологиями. Общие подходы к проектированию и построению систем остаются неизменными. Что внедрять и что планировать — вопрос подготовки. За достаточно ограниченное время можно в своё портфолио включить решения какого-нибудь вендора. Например, есть мониторинг БД, приложений, сети, пользовательских транзакций, ЦОДов — в принципе подходы одни и те же. Решает опыт (много опыта) и системное мышление.

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

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

Как понять, что стоит идти в архитекторы?

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

В общем, приходите. У нас тут, говорят, только свет и чистота.

Это материал нашего архитектора Александра Шубина.

Кому нужен архитектор? / Хабр

Disclaimer: Статья Мартина Фаулера была опубликована в 2003 году в журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).

Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.

Причиной его «титульного психоза» являлся тот факт, что по меркам даже нашей индустрии, смысл слов «архитектор» и «архитектура» чрезвычайно переоценен. Многим кажется, что к термину «архитектор программного обеспечения» отлично подходит тот самодовольный и все контролирующий образ из финальных сцен «Матрица: Перезагрузка». Но даже в компаниях относящихся с большим презрением к такому отображению, все равно, существует жизненно важная роль технического лидера, в сущности – архитектора, такого, как сам Дейв.

Что такое архитектура?

Когда я изводил себя по поводу названия книги «Архитектура корпоративных программных приложений» (Patterns of Enterprise Application Architectureб Addison-Wesley, 2002), каждый наш рецензент соглашался, что «архитектура» попала в заголовок по праву. Однако у всех нас возникли сложности с попытками дать определение этому слову. Так как это была моя книга, я чувствовал, что был обязан разделаться с этим понятием.

Первым порывом уйти от неясности было – удариться в цинизм. В известном смысле я определял архитектуру как слово, которые мы используем, когда хотим обсудить дизайн, пытаясь, при этом, придать ему побольше важности. (Да, это же можно применить и к архитекторам). Как это часто случается, однако, в любом разливе цинизма обнаруживается капля истины. Понимание пришло ко мне после прочтения сообщения Ральфа Джонсона (Ralph Johnson) из списка рассылки «Экстремальное программирование». Переписка была настолько хороша, что я приведу ее тут полностью.

В предыдущем сообщении говорилось:

RUP, опираясь на определение IEEE, описывает архитектуру как «самое высокоуровневое понятие о системе в рамках ее среды. Архитектура программной системы (в заданный момент времени) – это ее организация или структура важных компонент, взаимодействующих через интерфейсы, где каждая из компонент собрана, в свою очередь, из еще более мелких составных частей и интерфейсов».

Джонсон ответил:

Я был рецензентом упомянутого стандарта IEEE и доказывал, безрезультатно, что это было целиком и полностью фальшивое определение. Нет никакого высокоуровневого понятия о системе. У пользователей свое видение системы, отличающееся от того, чем оперируют разработчики. Пользователям вообще нет никакого дела до структуры важных составных частей. Да, возможно архитектура и является самым высокоуровневым представлением разработчиков о системе в рамках среды. Но давайте забудем о тех разработчиках, которым доступно понимание лишь своего небольшого участка. Архитектура – это самое высокоуровневое представление системы разработчиками-экспертами. Что делает определенный компонент важным? Он важен, потому что так сказал эксперт.

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

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

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

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

Является ли что-либо частью архитектуры – полностью зависит от того, расценивается ли это как важное разработчиками. Люди, которые создают «корпоративные» приложения считают критически важной персистентность. Когда они начинают обрисовывать архитектуру, сразу получают три уровня. Упомянут что-то вроде «мы используем Oracle в качестве нашей базы данных и создадим свой слой хранения для отображения в нем объектов». А вот приложение для медицинских снимков может включать технологии Oracle без рассмотрения их с архитектурной точки зрения. Так происходит потому, что самые большие трудности для них заключаются в обработке изображений, а не в хранении. Получение и сохранение изображений обеспечивается лишь маленькой частью приложения и большинство разработчиков ее попросту игнорируют.

Именно это делает сложным делом объяснение людям того, как им описывать архитектуру. «Скажите нам, что здесь важно». Архитектура о важных вещах. Чтобы под ними не подразумевалось.

Роль архитектора

Итак, если архитектура — это о важных вещах, тогда архитектор — это персона (или группа людей), который заботится о важных вещах. И тут мы подходим к сути отличия вида архитектора из «Матрица: Перезагрузка» с тем стилем, который представлен в лице Дэйва Райса.

Аркитектус Рилаудус (Architectus Reloadus) – это персонаж, который принимает все важные решения. Архитектор занимается этим, потому что для обеспечения концептуально целостной системы необходим единый взгляд и, возможно, потому что архитектор не считает членов команды достаточно квалифицированными, чтобы принимать такие решения. Часто такие решения нужно принимать на самых ранних стадиях, чтобы у всех остальных имелся план, которому они могли бы следовать.

Аркитектус Оризус (Architectus Oryzus) это другой зверь (если не получается угадать, попробуйте archives.nd.edu/latgramm.htm). Такой тип архитектора должен быть очень внимателен к тому, что происходит в проекте, выискивая важные вопросы и решая их до того, как они превратились в серьезные проблемы. Когда я наблюдаю за архитектором такого рода – я вижу, что самая заметная часть его работы – это интенсивное сотрудничество. По утрам такой архитектор программирует вместе с разработчиками, выискивая наиболее общий «стопорящий» код. Днем этот архитектор участвует в собраниях по определению требований, помогая объяснять разработчикам требований технические последствия некоторых из их идей через нетехнические понятия, такие как стоимость разработки, например.

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

На недавнем выездном собрании ThoughtWorks я обсуждал с некоторыми из коллег тему архитекторов. Мне показалось интересным, что мы быстро пришли к единому мнению о природе должности, имея в виду Аркитектуса Оризуса, но вот подобрать ему название было уже непросто. Аркитектус Рилаудус же, слишком знаком нам, чтобы причислять его к «архитекторам», и, кроме того, основан на некорректной метафоре (см. тут). Майк Ту (Mike Two) предложил лучшее название из тех, что мне довелось услышать: проводник, в альпинистском смысле. Проводник – это более опытный и умелый член команды, который учит остальных участников группы лучше справляться с опасностями самостоятельно, и, в тоже время, всегда оказывается рядом в особо сложных случаях.

Избавляясь от архитектуры ПО

Люблю писать провоцирующие заголовки, лучшие из которых, как и в данном случае, содержат важный, но не всегда очевидный изначально, смысл. Вспомните второе определение от Джонсона: «Архитектура — это решения, которые вы хотели бы принять без ошибок еще на ранних стадиях проекта». Почему людям кажется, что некоторые моменты надо решить правильно уже в самом начале проекта? Суть в том, что они, очевидно, считают данные элементы слишком сложными для изменения в будущем. Т.е. в итоге мы можем перефразировать определение архитектуры как «элементы, которые люди считают сложными для изменения в будущем».

Общепринятым в построении корпоративного приложения, например, считается необходимость определиться со схемой базы данных с самого начала. Потому что изменить схему базы действительно сложно, особенно если приложение уже используется. В одном из наших проектов, администратор БД Прамод Садалаж (Pramod Sadalage) придумал систему, позволявшую нам менять схему (и переносить данные) без проблем (см. тут, а тут перевод). Сделав это, он исключил схему БД их разряда архитектурных элементов. Я считаю это решение замечательным, так как оно позволило нам лучше справляться с изменениями.

Экономист Энрико Занинотто (Enrico Zaninotto), в восхитительном выступлении на конференции XP2002, представил основные идеи, стоящие за идеей agile на производстве и в разработке программного обеспечения. Один момент, который показался мне особенно интересным, заключался в его комментарии о том, что необратимость была одним из первичных факторов, приводившим к сложности. Он рассматривал agile методы в промышленности и в индустрии разработки ПО как сдвиг парадигмы в поисках способа борьбы с необратимостью, в противовес попыткам избавиться от других предпосылок, приводящих к запутанности. Я считаю, что одна из главных задач архитектора – избавляться от архитектуры, находя способы предотвращения необратимости в дизайне ПО.

И снова вернемся к Джонсону, в этот раз привожу ответ на мое письмо:

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

Никаких теоретически обоснованных причин считать что-либо трудно изменяемым в программном обеспечении нет. Если Вы выберите любой отдельный аспект ПО – его легко изменить, но сложность в том, что мы не знаем, как сделать легко исправляемым сразу все вместе. Попытки сделать что-либо легко изменяемым немного усложняют всю систему, попытки сделать все изменяемым приводят к тому, что вся система становится очень сложной. Запутанность – вот, что усложняет изменение программного обеспечения. Это и дупликация.

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

Программное обеспечение не ограничено физическими законами мира как те же здания. Оно ограничено фантазией, дизайном, организацией. Если коротко – оно ограничено человеческими свойствами, не характеристиками мира. «Мы встретили врага, и он оказался нами».

Мартин Фаулер, ведущий научный сотрудник в ThoughtWorks

Что нужно знать, чтобы стать системным архитектором

Роли в проекте выглядят так:

1. Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
2. Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
3. Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
4. Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.

Потом в обратном порядке проект принимается.

Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.

Дальше — имхо про то, что нужно от первых трёх ролей.

Архитектор, как это ни странно — человек, который соприкасается с реальным миром. Если рассматривать модель развития разработчик или инженер → проектировщик → архитектор (части проекта) → ведущий архитектор, то сначала реальный мир за стеклом и кажется безопасным. У проектировщика на входе сухие требования старшего коллеги-архитектора. По мере роста по этой цепочке (она не единственно возможная, не обязательно развитие идёт так), нужно всё больше и больше общаться с другими людьми из своей команды и у заказчика.

Появляется необходимость в дополнительных навыках. Сначала идут технические навыки — например, мы, когда отбираем проектировщиков из разработчиков и инженеров, хотим, чтобы они умели внятно смотреть мониторинг больших сетей, групп приложений, умели управлять конфигурацией сети, делать инвентаризацию сети, знали теорию про сетевые модели и протоколы управления. Для молодых архитекторов нужны уже не только навыки сбора данных, но и их отображения, нужно уметь работать с массивами собранного визуально, строить понятные всем в команде схемы.

Опять же, вряд ли проектировщику понадобятся навыки управления сервисдеском или навыки миграций-изменений. А архитектору — очень даже, потому что у процесса есть три стадии: где мы сейчас, как будем жить ближайший год, и где мы будем в конце проекта. И этот год хорошо бы не потерять под девизом «under construction».

По мере роста искушённости архитектора растут требования к знаниям стандартов. Можно начать с ласкового и нежного ГОСТ 34, а потом почитать про принципы размещения ГИС для медицины с персональными и платёжными данными сразу. Там же — методологии проектирования. Проектировщику не нужно знать теорию управления проектами, а архитектор должен понимать, как люди работают (хотя бы на уровне понимания, что такое ошибка планирования). Ведущий архитектор должен уметь быть ПМ’ом при необходимости, но никогда не делать такую работу.

А дальше начинается нестандартное и часто недооцениваемое. Вот, например, зачем нормальному ИТ-специалисту навыки выступлений и проведения презентаций? А они нужны, хотя бы базовые. Для начала — чтобы не начинать объяснение новой системы словами:

— Вы здесь все блаженные идиоты. Смотрите, что мы будем делать.

Реальный случай, кстати. Самое главное — человек ответил за слова и доказал, почему именно они такие люди. Но исполнители после такого начала не горели желанием работать. На самом деле, навыки презентаций нужны не для этого, а для того, чтобы объяснять свои задумки остальным в команде. Там есть несколько базовых вещей, которые очень берегут всем время.

Проектировщику и обычному архитектору, по идее, не надо знать много про продажи. Ведущему — надо, он должен был хоть раз продать ИТ-решение. Потому что тогда он будет знать, на каком языке говорит бизнес. И это будет не «некоторые риски повышения FRR навигационной системы», а «если не поменяем вот это — у вас будет полный самолёт трупов на полосе». Есть небольшая разница в убедительности и точности донесения данных. Очень близко лежит навык выбора перспективных продуктов, когда ничего непонятно про технологию (если смог выбрать сам, то знаешь, что заказчик оказывается в похожей ситуации, когда архитектор показывает пару вариантов).

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

Очень важный навык в выборе проектного решения — умеет человек обосновывать выбор или нет. Если оценка делается по цене, надёжности, масштабируемости и другим факторам в совокупности — это уже рациональный проектировщик. А если оценка делается с учётом всех возможных сценариев, собранных аналитиком, — это ведущий архитектор. Почему? Потому что ещё надо уметь выявлять зависимости проекта, его риски и точные требования. Выявлять — это не когда ты внедрил и узнал, что чего-то не хватает, а когда заранее знал, что будет, и заранее же подготовился. За пару лет. Здесь ведущий архитектор отличается от своего более прикладного коллеги тем, что думает об этом всегда и во всём.

Вообще, вот это — подготовиться заранее и продумать все варианты — наверное, самое главное отличие профессионала от человека, способного спроектировать систему. Архитектору надо учесть всё: и возможные нетрадиционные использования, и защиту от дурака, и продумать точки отказов, переходный процесс. Упрощённая аналогия такая: если вы играли в градостроительные стратегии, то знаете, что иногда лучшая архитектура на «через 10 лет» бывает крайне контринтуитивной. Нужно сначала построить город, а потом его отрефакторить, чтобы понять, как надо правильно. У архитектора такой роскоши нет — строительство и рефакторинг идут в голове, а в работу берётся уже оптимизированная модель. Архитектор — он думает про концепцию и влияние на смежные системы, о назначении, применимости и выгодах.

Важны навыки формулировки техтребований и техзаданий. А ещё — оценки рисков и изменений. Если человек работал только с проектами до, скажем, 50 дней — навыки оценки, скорее всего, недостаточные. На реально больших проектах есть свои особенности, связанные со спецификой заказчика и тем, что при большом накоплении обычных погрешностей уже не получается «за полчаса вечером доделать». Точнее, время — это очень ограниченный ресурс, и лишнее рабочее время из ниоткуда не появляется.

Подготовка разных планов — мало иметь план по своему подразделению, ещё готовятся ресурсные планы (независимо от принадлежности к подразделениям). Это снимает необходимость контроля плана целого чужого подразделения, — понимать компетенции и возможности команды надо.

Разработка документации — просто полезный навык, нужен в любой стадии. Ещё он здорово дисциплинирует в плане системного мышления.

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

Навыки делового общения — если ведущий архитектор этого не умеет, то он очень быстро перестаёт быть ведущим, поскольку с ним серьёзные люди не разговаривают. Потому что одно дело высказать мнение о системе со словом «жопа» в середине в курилке, а другое — то же самое вице-президенту европейской компании. Плюс нужен беглый английский для общения с вендорами. Печень и мозг сохраняются в первозданном виде. Хотя, например, я часто в процессе встречаюсь с тем, что «сейлзы» как раз знают, на какие встречи нужен архитектор, чтобы рисовать в воздухе правильные узоры пальцами — и берут с собой к заказчику.

Из «общечеловеческих» навыков обычно при назначении роли оцениваются отзывы предыдущих руководителей человека по трудовой биографии. Нужна нацеленность на результат: не сдать систему, а решить задачу. «Всё сделано по ТЗ, но не работает» — это не решение задачи.

Очень важный критерий — любознательность: как правило, если человек сам ищет новые знания и сам учится, это повод задуматься, зачем же он живёт. Значит, ему не всё равно (ну или он готовиться сменить компанию, гы-гы). Архитектору должно быть не всё равно больше всех.

Важно управление временем: для проектировщика — определение приоритетов в духе коротких спринтов (получил задачу — сделал — сдал — получил новую), а вот для архитектора — уже самому определить сроки своих задач, их приоритеты — и самому всё сделать правильно. И ещё умение принимать решения в условиях недостатка времени, дефицита ресурсов и когда всё вокруг горит: и велосипед горит, и костыли горят, и ты горишь. «Вытянутый» проект, когда что-то пошло не так, — это не только километр нервов и недосыпы, но и шанс стать круче, поняв что-то для себя о том, как действительно решаются задачи в реальном мире.

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

Поэтому, как я уже говорил, быть архитектором и напряжно, и интересно. Особенно интересно стало в последние годы, когда появились инфраструктуры, которые можно изменять относительно быстро — в частности, на базе облаков. Например, в нашем облаке Техносерв архитекторы нужны почти на каждый переезд — для многих это возможность не только перенести инфраструктуру в облако, но и сразу отрубить «хвост» из всякого легаси и тянущихся костылей, спроектировав систему правильно — раз уж всё равно она меняется.

Если вдруг вы хотите стать архитектором, а у вас в компании есть не очень-то нужные вам курсы — задумайтесь. Очень многие компетенции связаны с такими базовыми вещами, как управление проектами и переговоры. Хоть это больше история ПМ’а или «сейлза», вам она тоже может неожиданно пригодиться.

Это материал архитектора нашего облака Техносерв Cloud Александра Шубина. Вот его прошлый пост про архитектора: как выглядит его работа.

Как выбрать персональный компьютер для учебы, геймера, архитектора

Прежде чем приступить к выбору персонального компьютера, стоит определиться с его функциональной принадлежностью.

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

Офисные компьютеры

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

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

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

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

Читайте здесь «Какой монитор выбрать для компьютера»

Самые высокие требования предъявляются к ПК бухгалтеров, в которых обязательно должна быть установлена программа «1С». Оперативная память в таких устройствах составляет порядка 2 Гб, а то и больше.

ПК для дизайнеров и архитекторов

Такой компьютер должен поддерживать самые современные типы графических редакторов, что обусловливает его необходимость в мощном процессоре, объеме оперативной памяти не менее 4 Гб, современной видеокарте.

Не последним в списке требований, предъявляемых к ПК дизайнера, стоит цветопередача монитора.

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

Диагональ монитора также играет не последнюю роль. Минимальный его размер должен быть равен 20 дюймам.

Компьютер геймера

И самым требовательным типом ПК по праву можно считать компьютер геймера., который должен быть на высоте практически по всем параметрам.

Тут и процессор нужен, как минимум, четырех ядерный, и мощная видео и звуковая карта. Немаловажные параметры — объемный звук и высокое разрешение цветов.

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

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

УРОК 3

КОМПЬЮТЕРНАЯ МАШИНА [1]

Задание 1. Прочтите и переведите текст:

1.:

Все мы думаем о компьютере. Вот почему мы спрашиваем: «Что такое компьютер?» Компьютер — одна из современных технологий, используемых повсеместно. Это сложный инструмент, состоящий из сотен электронных устройств, миль электронных проводов. Его сложный электронный мозг производит информацию. Эта информация хранится на магнитных лентах или перфокартах.Кто скармливает компьютерной информации? Оператор может вводить цифры и символы в машину. Когда оператор хочет получить ответы, он просит машину на специальном языке обработать информацию, взятую из хранилища. Электронная машина может дать любой ответ или комбинацию возможных ответов. На пульте управления, подключенном к прибору, машина может отображать свои ответы на экране, печатать их на бумаге и хранить на магнитных лентах или карточках.

Конечно, более 100.На одной машине можно хранить 000 единиц информации. Компьютер может выполнять множество операций. Например, компьютер может умножать большие числа. Сколько времени нужно компьютеру, чтобы умножить большие числа? За одну треть секунды компьютер может перемножить два 127-значных числа. За одну целую секунду он может сложить 4.000 пятизначных чисел. За две секунды он может выполнить 320 задач с длинными делениями. Одна и та же машина выполняет работу тысяч подготовленных математиков в любой заданный период времени и без ошибок.Но … люди действительно думают, передают информацию машинам. Компьютер только помогает нам быстрее и точнее находить ответы и предоставлять факты. Машины работают на нас, но они не думают за нас.

Задание 2. Ответьте на следующие вопросы:

2.:

1. Что такое компьютер?

2. Какие функции есть у компьютера?

3. Зачем людям сегодня остро нужен компьютер?

4. Какая связь между компьютерным мозгом и человеческим разумом?

5.Электронная система компьютера очень сложна или проста?

6. Производят ли информацию электронный мозг компьютера?

7. Сколько единиц информации можно хранить на одной машине?

8. Чем прошивается компьютер?

Задание 3. Сопоставьте приведенные ниже слова с определениями:

3.:

Компьютер.

Факс (аппарат) ..

Электронная почта …

Телефон.

Интернет ..

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

Международная сеть компьютеров. Имеет электронную почту и

предоставляет большой объем информации.

Электронная машина, которая может хранить и вызывать информацию, выполняет на ней множество процессов.

Электронная система, которая объединяет группу компьютеров. Люди могут отправлять сообщения друг другу на своих компьютерах.

Система для отправки или приема речи на большие расстояния.

Задание 4. Найдите в тексте слова и комбинации слов , приведенные ниже:

4.,:

электронная система компьютера

снять со склада

для подачи информации в машину

перфокарта

для решения задач на длинное деление

для отображения ответов на экране

для хранения на магнитных лентах

Задание 5. Заполните следующие предложения, соответствующие содержанию текста:

5.:

1. Электронный… очень сложно.

2. Более 100.000 штук ……

и когда оператор хочет ответов, он спрашивает … и для решения проблемы.

3. В одной трети … двух 127 — цифр …

4. Одна и та же машина делает … в любой заданный период времени и …

5. Аппарат умеет прошивать …

6. … может дать любой ответ или …

7. Но это … кто думает, кто … находит ответ и …..

8.Машины … для нас, но не … для нас.

9. … электронных устройств, миль электронных проводов.

10. … оператор вводит в машину факты, цифры и символы, чтобы быть …

Задание 6. Скажите, верны ли приведенные ниже утверждения:

. 6:

1. Электронная система компьютера очень проста.

2. На одной машине можно хранить более 50 единиц информации.

3. За секунду компьютер может перемножить два 970-значных числа.

4. Машины думают за нас, но не работают за нас.

5. Компьютер не может выполнять много операций.

.

Упражнение: Покупка компьютера (диалог)

ПОКУПКА КОМПЬЮТЕРА

Прослушивание

Помощник: Вам нужна помощь ?

Пол: Гм, да, мы ищем компьютер Mac. Есть ли у вас базовых ?

Ассистент: Да, конечно. Если хочешь пойти сюда.

Пол: Какие существуют модели ?

Assistant: На данный момент у нас есть две модели : iMac, который представляет собой настольный компьютер с процессором Intel Core 2 Duo , работающий с на 2.33 гигагерца, и портативный MacBook с процессором , работающим на на частоте 2,0 гигагерца. Технология Core Duo на самом деле означает два ядра или процессоры, построил в одном чипе, предлагая до вдвое скорость традиционного чипа.

Сью: Значит, они оба очень быстрые. А у какой больше памяти ? Я имею ввиду, у кого больше ОЗУ?

Assistant: Ну, у iMac есть два гигабайта оперативной памяти, которые можно расширить с до трех гигабайт, а у MacBook один гигабайт с возможностью расширения до двух гигабайт.Все зависит от ваших потребностей. В iMac подойдет для домашних пользователей и небольших офисов . MacBook более практичный , если вы много путешествуете.

Исправление ошибок и языковые функции

1 Ulysses — это мощный расширяемый компьютер ful , предлагающий высококачественную графику по низкой цене.

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

3 Какова емкость жесткого диска?

4 Я ищу настольный компьютер с хорошей графикой для игр.

5 Вам нужна помощь any / some ?

6 Сколько стоит КПК?

7 Эта рабочая станция имеет процессор Pentium с двухъядерным процессором, 1,024 мегабайта оперативной памяти и 1 терабайт дискового пространства.

Me gusta esto:

Me gusta Cargando…

Relacionado

.