Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Здравствуйте, gandjustas, Вы писали:
ST>>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
G>Архитектор (в разработке ПО) это скорее звание, а не роль. Обычно это звание дается человеку за принятие ключевых технических решений и ответственности за эти решения. По сути архитектором может стать любой человек, который сможет аргументировать свое решение. Ему даже не надо уметь писать код, можно просто прочитать пару книг фаулера и популярных статей, а потом ссылаться на них.
Фаулер называет такого архитекта "Architectus Reloadus"
11.11.2013 18:52, SergeyT. пишет:
> Как-то так...
Я это прочитал. Куча благоглупостей ни о чем.
Имхо, программная система, как и любая другая должна иметь в своей
основе вполне четкий каркас (да-да, описываемый в том числе на UML и
человеческом языке). И да этот каркас должен позволять гибкость, но
исключительно в определенных рамках и не более. И да, должен быть такой
мужик или женщина (в роли архитектора) кто это разработает, четко
опишет, представит, согласует и будет контролировать разработку в рамках
сей архитектуры.
Например, когда я делал архитектуру, я обычно еще предоставлял пустышки
модулей, правила для написания и реализовывал основные связи между
модулями. Т.е. у меня был каркас, который не делал ничего
функционального, но показывал движение данных и связи между модулями.
Далее разработчики уже делали имплементации своих модулей.
Здравствуйте, SergeyT., Вы писали:
ST>Недавно наткнулся на замечательную статью Мартина Фаулера под названием "Who Needs an Architect?"
ST>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
С высоты птичьего полёта всё на много проще. Существует такая вещь как архитектура предприятия (enterprise architecture). Архитектор — это тот кто планирует любые изменения на этом предприятии. Никаких решений он не принимает, рекомендует, планы пишtт, что выберут то и будет. Ему в поддержку даются следующий ребята:
— business architect — опишет бизнес, зачем он, что делает и как
— data (иногда information) architect — объекты важные для бизнеса и как они друг с другом стыкуются, может словарик например написать, чтоб все на одном языке общались.
— application architect — приложения, сервисы, и пр. компоненты поддерживающие бизнес
— technology architect — технические компоненты на которых строятся приложения, сервисы и пр.
И это всё пока что планы глобальные и касаются всего предприятия целиком. Как бы и не важно IT ли это предприятие или нет. Архитекторы они везде планируют, оценивают, рисуют схемки. И, ещё раз, никаких решений не принимают, не их это работа.
Потом наступает момент когда план действия выбран и нужно его в жизнь претворить. Разбиваются задачки на программы и проекты. И вот тут может ещё один архитектор появится — solution architect. Это тот кто расписывает как же мы всё это на самом деле делать будем или может что купим и допилим.
Как бы всё. Нет других архитекторов. То что там напридумывали, обычно слезами заканчивается. Нет никаких technical architects, это просто тот самый старший программер обозванный чтоб его эго поддержать. Нет нужды в подобных "архитекторах", практика это доказывает раз за разом. И без них всё можно построить и быстрее и дешевле.
Здравствуйте, SergeyT., Вы писали:
ST>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор.
Ну, если убрать спор о терминологиях, то в двух словах, рефакторинг рулит (это к вопросу о reversibility).
ST>Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Не увидел связи.
А ещё мне показалось, но не то чтобы на 100%, что он НЕ считает выбор языка программирования частью архитектуры. И вот тут я бы поспорил.
Здравствуйте, SergeyT., Вы писали:
ST>Недавно наткнулся на замечательную статью Мартина Фаулера под названием "Who Needs an Architect?"
ST>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Сергей вы умеете шарить нужные и важные знания.
Я видел всего несколько проектов где были архитекторы и эти проекты были прежде всего понятные, и легко поддерживаемые. Про ключевые решения все понятно. Наличие архитектора(один человек или команда) дает проекту стройность, однообразие подходов,решений, сущностей. В добавок я бы сказал что архитектор ограничивает весь тот зоопарк, который способны залепить девелоперы, вместо того чтобы понять архитектуру и следовать в ее ключе.
Когда проект делается без архитектора (а ля скрам), то ни в чей голове нет истории эволюции развития проекта, на концептуальном уровне. Элегантные решения каких-то проблем могут прийти, только через некоторое время, после того как эта проблема будет намертво посажена в голову архитектора, на протяжении нескольких итераций.
06.11.2013 15:31, diez_p пишет:
> Я видел всего несколько проектов где были архитекторы и эти проекты были > прежде всего понятные, и легко поддерживаемые. Про ключевые решения все > понятно. Наличие архитектора(один человек или команда) дает проекту > стройность, однообразие подходов,решений, сущностей. В добавок я бы > сказал что архитектор ограничивает весь тот зоопарк, который способны > залепить девелоперы, вместо того чтобы понять архитектуру и следовать в > ее ключе.
Это все зависит только от одного — личности того архитектора и его
возможностей руководить разработкой.
Здравствуйте, dimgel, Вы писали:
D>А ещё мне показалось, но не то чтобы на 100%, что он НЕ считает выбор языка программирования частью архитектуры. И вот тут я бы поспорил.
Статью читал давно, перечивать лень. Поэтому только по поводу языка. Думаю, ситуация когда язык уже задан бывает достаточно часто. Например, у нас в конторе пишут на Java. И никто не будет на этапе разработки архитектуры рассматривать C# или Ruby. Просто потому, что мы пишем на Java.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, dimgel, Вы писали:
D>>А ещё мне показалось, но не то чтобы на 100%, что он НЕ считает выбор языка программирования частью архитектуры. И вот тут я бы поспорил. LV>Статью читал давно, перечивать лень. Поэтому только по поводу языка. Думаю, ситуация когда язык уже задан бывает достаточно часто. Например, у нас в конторе пишут на Java. И никто не будет на этапе разработки архитектуры рассматривать C# или Ruby. Просто потому, что мы пишем на Java.
А на Scala? А использовать XML конфигурацию или код? А писать серверный код или JS?
Вопрос на выборе языка не такой простой как кажется зачастую.
Здравствуйте, gandjustas, Вы писали:
D>>>А ещё мне показалось, но не то чтобы на 100%, что он НЕ считает выбор языка программирования частью архитектуры. И вот тут я бы поспорил. LV>>Статью читал давно, перечивать лень. Поэтому только по поводу языка. Думаю, ситуация когда язык уже задан бывает достаточно часто. Например, у нас в конторе пишут на Java. И никто не будет на этапе разработки архитектуры рассматривать C# или Ruby. Просто потому, что мы пишем на Java.
G>А на Scala? А использовать XML конфигурацию или код? А писать серверный код или JS?
У меня в голове крутился пример ближе твоему второму: использовать в веб-приложении для view-слоя встроенные в скалу XML-литералы или всякое динамически типизированное неотлаживаемое говно типа FreeMarker как у нас сейчас на java-проекте? Вполне себе важный выбор. Но LeonidV выразился как-то странно, что мол язык частенько уже спущен свыше. Ну спущен и спущен, мучайтесь. =)
Здравствуйте, SergeyT., Вы писали:
ST>Недавно наткнулся на замечательную статью Мартина Фаулера под названием "Who Needs an Architect?"
ST>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Архитектор (в разработке ПО) это скорее звание, а не роль. Обычно это звание дается человеку за принятие ключевых технических решений и ответственности за эти решения. По сути архитектором может стать любой человек, который сможет аргументировать свое решение. Ему даже не надо уметь писать код, можно просто прочитать пару книг фаулера и популярных статей, а потом ссылаться на них.
Это кстати не только в России\СНГ, в мире примерно такая же картина с архитекторами.
Здравствуйте, dimgel, Вы писали:
D>У меня в голове крутился пример ближе твоему второму: использовать в веб-приложении для view-слоя встроенные в скалу XML-литералы или всякое динамически типизированное неотлаживаемое говно типа FreeMarker
Здравствуйте, vsb, Вы писали:
D>>У меня в голове крутился пример ближе твоему второму: использовать в веб-приложении для view-слоя встроенные в скалу XML-литералы или всякое динамически типизированное неотлаживаемое говно типа FreeMarker
vsb>А какую типизацию дают XML-литералы?
Не забудешь закрыть тег. Не впишешь в embedded-код несуществующую переменную или синтасически неправильное выражение. А ещё по ним можно идти отладчиком. Есть ещё и другие соображения.
04.11.2013 17:20, gandjustas пишет:
> Архитектор (в разработке ПО) это скорее звание, а не роль.
Сарказм. Но тогда это не звание — это призвание.
> Это кстати не только в России\СНГ, в мире примерно такая же картина с > архитекторами.
То то последнее время софт все горбатее и горбатее.
Здравствуйте, gandjustas, Вы писали: G>А на Scala? А использовать XML конфигурацию или код? А писать серверный код или JS?
Не Scala, не Groovy. Java. Потому что все знают Java.
Вы сами пишете в рамках одного языка и обсуждаете обычные архитектурные вопросы. Чтобы ваш пример был более показательный, его надо сделать таким:
Использовать JavaScript? А может CoffeeScript или вообще Dart?
Использовать XML или JSON или, может быть, YAML?
Так что вы еще больше подвтердили мои слова — язык не так уж сильно выбирают.
Здравствуйте, gandjustas, Вы писали:
G>Архитектор (в разработке ПО) это скорее звание, а не роль. Обычно это звание дается человеку за принятие ключевых технических решений и ответственности за эти решения. По сути архитектором может стать любой человек, который сможет аргументировать свое решение. Ему даже не надо уметь писать код, можно просто прочитать пару книг фаулера и популярных статей, а потом ссылаться на них. G>Это кстати не только в России\СНГ, в мире примерно такая же картина с архитекторами.
Мне кажется это близко к CTO (Chief Technology Officer). Это как бы роль, всё таки, крайне близка или она же и есть местами с архитектором. Но в ней мне кажется крайне полезным если не уметь писать, то хотя-бы уметь писать прототипы (а мы знаем — что если это делатеся качественно, значит, — и писать умеешь). Но в принципе, на самом деле я согласен — важно то, что охватывать одним умом грубо говоря нужно многие аспекты системы (и в большей степени бизнес, сопровождение и даже экономические (а найдем ли мы разраба на haskell?)), и ставить задачу исполнителям (в том числе и самому себе).
Поправь.
Здравствуйте, LeonidV, Вы писали:
LV>Использовать JavaScript? А может CoffeeScript или вообще Dart? LV>Использовать XML или JSON или, может быть, YAML?
Выбирают. Я вот повёлся на TypeScript. Попробовал и только зря опять потерял время, на то, что второй раз с ним разбирался. Если чувакам неинтересен опыт банальной логики, то отрицать опыт dojo или google-closure — глупо. А у них (в TypeScript) — модульность — никакая. Они стремятся к модульности ES6 — только есть одно но! ES6 — всё таки будет средой выполнения, а TypeScript так и остаётся "компилируемым" во что-то недо-язычком.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, LeonidV, Вы писали:
LV>>Использовать JavaScript? А может CoffeeScript или вообще Dart? LV>>Использовать XML или JSON или, может быть, YAML? F> Выбирают. Я вот повёлся на TypeScript. Попробовал и только зря опять потерял время, на то, что второй раз с ним разбирался. Если чувакам неинтересен опыт банальной логики, то отрицать опыт dojo или google-closure — глупо. А у них (в TypeScript) — модульность — никакая. Они стремятся к модульности ES6 — только есть одно но! ES6 — всё таки будет средой выполнения, а TypeScript так и остаётся "компилируемым" во что-то недо-язычком.
TS вроде как не претендует на отдельный язык. Статически типизированное надмножество JS (со всеми вытекающими) + фичи из ES6. Там и разбираться то особо не надо: четыре ключевых слова — class\module\interface\enum, лямбды и пара фишек типизации. Остальное — "старый добрый javascript".
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>Архитектор (в разработке ПО) это скорее звание, а не роль. Обычно это звание дается человеку за принятие ключевых технических решений и ответственности за эти решения. По сути архитектором может стать любой человек, который сможет аргументировать свое решение. Ему даже не надо уметь писать код, можно просто прочитать пару книг фаулера и популярных статей, а потом ссылаться на них. G>>Это кстати не только в России\СНГ, в мире примерно такая же картина с архитекторами. F> Мне кажется это близко к CTO (Chief Technology Officer). Это как бы роль, всё таки, крайне близка или она же и есть местами с архитектором. Но в ней мне кажется крайне полезным если не уметь писать, то хотя-бы уметь писать прототипы (а мы знаем — что если это делатеся качественно, значит, — и писать умеешь). Но в принципе, на самом деле я согласен — важно то, что охватывать одним умом грубо говоря нужно многие аспекты системы (и в большей степени бизнес, сопровождение и даже экономические (а найдем ли мы разраба на haskell?)), и ставить задачу исполнителям (в том числе и самому себе). F> Поправь.
CTO\Архитектор и прочие слова — только бирка. Конкретные функции и ожидания могут сильно различаться. Я видел разны архитекторов — то рисователей схемы БД до фактически руководителей проектов.
Здравствуйте, gandjustas, Вы писали:
G>TS вроде как не претендует на отдельный язык. Статически типизированное надмножество JS (со всеми вытекающими) + фичи из ES6. Там и разбираться то особо не надо: четыре ключевых слова — class\module\interface\enum, лямбды и пара фишек типизации. Остальное — "старый добрый javascript".
Нет, он претендует на отдельный язык, он таким и является. Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается. А получается что если хочется чего-нибудь поразвесистее да поувесистее, да с возможностью выкидывать ненужное — оно всё не подходит... Ну а пиар то какой! Поддержки там в студиях-шмудиях. (Правда опять таки поддержка примитивная). Не, я не спорю, что наверное этого для многих вещей достаточно, но как по мне — легче на обычном JS в итоге с теми или иными стероидами (про модульность).
G>Я вот недавно делал доклад на эту тему: http://www.youtube.com/watch?v=Ly_hYZuUbYM
Спасибо, это я посмотрю.
Здравствуйте, gandjustas, Вы писали:
G>CTO\Архитектор и прочие слова — только бирка. Конкретные функции и ожидания могут сильно различаться. Я видел разны архитекторов — то рисователей схемы БД до фактически руководителей проектов.
Конечно бирка. Но имхо, речь ведь ты сам повел о тех, кто как раз разложит от и до. Не? Ты правильно, написал, что его роль принимать ключевые решения — при чём, наверное неплохой архитектор, руководствуется многими факторами при этом. И да, формально — наверное достаточно прочитать Фаулера. Хотя чем он поможет по факту — я не знаю (читал). От него — ещё больше вопросов возникает, чем готовая энциклопедия для референсов.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>TS вроде как не претендует на отдельный язык. Статически типизированное надмножество JS (со всеми вытекающими) + фичи из ES6. Там и разбираться то особо не надо: четыре ключевых слова — class\module\interface\enum, лямбды и пара фишек типизации. Остальное — "старый добрый javascript". F> Нет, он претендует на отдельный язык, он таким и является.
С боооольшой натяжкой.
F> Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается.
Да хоть из 100 классов. Это пока AMD не включишь. У AMD простое ограничение — один модуль должен быть в одном файле.
Все недостатки TS — это недостатки JS.
F>А получается что если хочется чего-нибудь поразвесистее да поувесистее, да с возможностью выкидывать ненужное — оно всё не подходит...
Оно и не должно подходить. TypeScript — "всего лишь" типизированный JS. Если ты не хочешь сталкиваться с JS, то и TS тебе не подойдет
F> но как по мне — легче на обычном JS в итоге с теми или иными стероидами (про модульность).
Легче что? Статическая типизация избавляет от кучи проблем, голый JS не поможет.
Модульность — совсем небольшая проблема на самом деле. До изобретения AMD люди умудрились написать gmail и outlook web access.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
G>>CTO\Архитектор и прочие слова — только бирка. Конкретные функции и ожидания могут сильно различаться. Я видел разны архитекторов — то рисователей схемы БД до фактически руководителей проектов. F> Конечно бирка. Но имхо, речь ведь ты сам повел о тех, кто как раз разложит от и до. Не?
Не распарсил...
F>Ты правильно, написал, что его роль принимать ключевые решения — при чём, наверное неплохой архитектор, руководствуется многими факторами при этом.
Само интересное слово — "ключевые". Ключевость решений обычно определяется самим принимающим решение (схема БД) в случае успеха или размером влияния на проект (выбор неверного Фреймворка для реализации) в случае фейла.
Об этом собственно в статье по ссылке топикстартера.
В этом и проблема — невозможно заранее описать какие действия должен делать абстрактный архитектор, поэтому и происходит шатание.
Здравствуйте, gandjustas, Вы писали:
F>> Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается. G>Да хоть из 100 классов. Это пока AMD не включишь. У AMD простое ограничение — один модуль должен быть в одном файле. G>Все недостатки TS — это недостатки JS.
AMD включил. В AMD я импортирую что хочу. Потом это могу обработать так как хочу. Почему этого не сделано в TS? Т.е. почему модуль обязан быть файлом, вдобавок иметь собственный алиас. Т.е. получаетяс смешно — один файл — один класс, который имеет собственный алиас через который можно добраться до класса. Вот в том же питоне — всё как раз по уму. Ну или в шарпе. Я понимаю, что многое навязано JS, но — всё таки, если есть нечто что процессит файлы да и магические комменты — то почему нельзя было уже решить и эту проблему, вместо манифеста "мы стараемся быть как ES6".
G>Оно и не должно подходить. TypeScript — "всего лишь" типизированный JS. Если ты не хочешь сталкиваться с JS, то и TS тебе не подойдет G>Легче что? Статическая типизация избавляет от кучи проблем, голый JS не поможет. G>Модульность — совсем небольшая проблема на самом деле. До изобретения AMD люди умудрились написать gmail и outlook web access.
Я сталкивался с JS очень плотно, и продуктивно. Года 3 назад. Жить без статики таки можно. Мне лично жутко неудобно, но множно. А вот жить без обвеса лишь со статической типизацией на плече — ну мне — как-то тяжковато. Я в общем-то сказал чего хотел — хочется модульности в стиле dojo / google-closure. При чём это ж не единственный подход. Другой подход, я уже выше озвучил — "как в питоне". А чистый AMD — он не нужен. Он реально годится именно уже для исполнения, я ж не против AMD именно как самого по себе. А проще — проще писать на голом AMD дописывая в зависимости ровно то что ты хочешь. А в релизе это "пересоединить" в функциональные блоки. Это всё можно конечно и с TS — но, наличие обязательных алиасов для модулей (которые как бы не хочется что бы были модулями) — это выше меня. Увы.
Т.е. более сжато и понятно мысль хочу сказать: как язык вроде в TS всё прикольно. А модульность — хромает. А без этого — мне лично он нафиг не нужен, и даже использование в ограниченном объеме — не позволяет чувствовать себя удобно. Вот и всё. Впрочем — может дальше будет получше, кто знает.
Здравствуйте, gandjustas, Вы писали:
F>> Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается. G>Да хоть из 100 классов. Это пока AMD не включишь. У AMD простое ограничение — один модуль должен быть в одном файле.
АМД здесь ни о чем. Собрать все файлы модуля в один js это ни разу не рокет-саенс.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>>> Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается. G>>Да хоть из 100 классов. Это пока AMD не включишь. У AMD простое ограничение — один модуль должен быть в одном файле. G>>Все недостатки TS — это недостатки JS. F> AMD включил. В AMD я импортирую что хочу. Потом это могу обработать так как хочу. Почему этого не сделано в TS? Т.е. почему модуль обязан быть файлом, вдобавок иметь собственный алиас. Т.е. получаетяс смешно — один файл — один класс, который имеет собственный алиас через который можно добраться до класса. Вот в том же питоне — всё как раз по уму. Ну или в шарпе. Я понимаю, что многое навязано JS, но — всё таки, если есть нечто что процессит файлы да и магические комменты — то почему нельзя было уже решить и эту проблему, вместо манифеста "мы стараемся быть как ES6".
А зачем? Глянь в трекер на codeplex. То что т описываешь вовсе не проблема для большинства. Усложнять компилятор ради почти бесполезной фичи никто не будет.
G>>Оно и не должно подходить. TypeScript — "всего лишь" типизированный JS. Если ты не хочешь сталкиваться с JS, то и TS тебе не подойдет G>>Легче что? Статическая типизация избавляет от кучи проблем, голый JS не поможет. G>>Модульность — совсем небольшая проблема на самом деле. До изобретения AMD люди умудрились написать gmail и outlook web access. F> Я сталкивался с JS очень плотно, и продуктивно. Года 3 назад. Жить без статики таки можно. Мне лично жутко неудобно, но множно.
Ага. Вот недаром историю рассказывают про TFS Web Access, в котором нашли 5 ошибок после конвертации в TS. Если что TFS Web Access тестируется чуть более чем полностью.
А ты много тестов для своего JS написал? Уверен что стоит его сконвертировать в JS и ошибки полезут тоннами.
F>А вот жить без обвеса лишь со статической типизацией на плече — ну мне — как-то тяжковато.
А как же ты с JS жил?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
F>>> Но вот именно меня бесит эта ограниченная модуляризация в нём. Я хочу иметь модуль из десяти классов (да-да, в разных файлах) и вменяемо референсится на них. Там же так не получается. G>>Да хоть из 100 классов. Это пока AMD не включишь. У AMD простое ограничение — один модуль должен быть в одном файле.
I>АМД здесь ни о чем. Собрать все файлы модуля в один js это ни разу не рокет-саенс.
Я так понял хочется обратного — чтобы один модуль был в нескольких файлах.
Здравствуйте, gandjustas, Вы писали:
G>А зачем? Глянь в трекер на codeplex. То что т описываешь вовсе не проблема для большинства. Усложнять компилятор ради почти бесполезной фичи никто не будет.
Мне это странно.
F>>А вот жить без обвеса лишь со статической типизацией на плече — ну мне — как-то тяжковато. G>А как же ты с JS жил?
Дык, я жил с "компилятором", который всё это дело собирал.
Здравствуйте, gandjustas, Вы писали:
I>>АМД здесь ни о чем. Собрать все файлы модуля в один js это ни разу не рокет-саенс.
G>Я так понял хочется обратного — чтобы один модуль был в нескольких файлах.
Хочется описывать модуль в разных файлах, а после компиляции хочется иметь один файл.
Без этого надо на каждый чих вводить модули или работать с простынями.
Здравствуйте, gandjustas, Вы писали:
G>А зачем? Глянь в трекер на codeplex. То что т описываешь вовсе не проблема для большинства. Усложнять компилятор ради почти бесполезной фичи никто не будет.
Потому что это большинство пока что юзает тайпскрипт для мелких приложений. В больших приложениях все очень непросто с модулями. Слишком много модулей это само по себе проблема, а требованием модуль на файл это уже катастрофа.
11.11.2013 13:53, SergeyT. пишет:
> Перевод — "Зачем нужен архитектор?"
Понятно. Мрак. Хорошо, что я не стал тратить время на читание оного на
ангельском.
Так что же он таки предлагает, я не понял?
Здравствуйте, Vzhyk, Вы писали:
V>11.11.2013 13:53, SergeyT. пишет:
>> Перевод — "Зачем нужен архитектор?" V>Понятно. Мрак. Хорошо, что я не стал тратить время на читание оного на V>ангельском. V>Так что же он таки предлагает, я не понял?
1. Архитектор — это не мужик, который знает и принимает все важные решения (это Архитектус Релоадус). Нормальный архитектор — это ментор и катализатор команды.
2. Архитектура — это хрень, важная для всех. При этом задача архитектора сделать так, чтобы важной хрени было как можно меньше. По своему определению, если важные решения нужно знать всем, то пяток архитектурных решений сделает из проекта кашу, ведь каждому придется держать в голове еще и эти вопросы, помимо тех проблем, над которыми работает человек.
3. Избавляемся от архитектуры (необратимость решений)
Задача архитектора — сделать так, чтобы важных решений было как можно меньше и их "импакт" был минимальным.
Дело в том, что мы можем ошибаться и должны сделать так, чтобы цена ошибки была разумной. Вот мы, например, используем WCF, можно сделать так, чтобы каждый участник проекта знал об этом и ноги WCF-а торчали из каждого модуля. А можно запихнуть его в пару модулей и сделать его (WCF) деталью реализации.
Наша же цель стараться не локализовывать любые решения минимально возможным количеством модулей.
4. У гибкости есть своя цена
Когда в предыдущем пункте шла речь о том, чтобы мы не вырубали решения в камне, совершенно не имелось ввиду то, что вся наша система должна быть гибкой. Гибкость не дается бесплатно, а приводит к увеличению сложности. Поэтому ее нужно закладывать там, где это действительно нужно, поскольку универсально гибкая система бесконечно сложнее простой системы.
12.11.2013 16:27, Mishka пишет:
> — business architect > — data (иногда information) architect > — application architect > — technology architect > — solution architect.
Скольковцы нервно курят в сторонке. И че на вашей конторе все эти есть???
Здравствуйте, Vzhyk, Вы писали:
V>12.11.2013 16:27, Mishka пишет:
>> — business architect >> — data (иногда information) architect >> — application architect >> — technology architect >> — solution architect. V>Скольковцы нервно курят в сторонке. И че на вашей конторе все эти есть???
В нашей конторке работает 300К народу, у нас всё есть Представь СТО, которому надо разрулить 1000+ проектов и все на его совести. Тут ещё и не такое придумаешь.
Здравствуйте, Vzhyk, Вы писали:
V>12.11.2013 16:27, Mishka пишет:
>> — business architect >> — data (иногда information) architect >> — application architect >> — technology architect >> — solution architect. V>Скольковцы нервно курят в сторонке. И че на вашей конторе все эти есть???
Так это ж роли, а не должности.
В реальном проекте на предприятии кто то эти роли все равно выполняет. только если человек не знает, что он в данном случае *** — архитектор, он не выполняет все обязательства этой роли (и часто не имеет знаний чтоб их выполнять). С соответствующими последствиями для предприятия.
Здравствуйте, Mishka, Вы писали:
M>Как бы всё. Нет других архитекторов. То что там напридумывали, обычно слезами заканчивается. Нет никаких technical architects, это просто тот самый старший программер обозванный чтоб его эго поддержать. Нет нужды в подобных "архитекторах", практика это доказывает раз за разом.
Перефразирую но все же. Сложно любить кошек, если не умеешь их готовить
Интересно посмотреть на ваш код, и на цену его ментанса.
Здравствуйте, Vzhyk, Вы писали:
V>13.11.2013 14:40, diez_p пишет:
>> Интересно посмотреть на ваш код, и на цену его ментанса. V>"работает 300К народу" — это уже говорит о многом.
Вот кстате еще. На моем девелоперском веку, сложные, большие продукты, создавались относительно небольшой командой девелоперов. Вокруг них может быть много тестоверов, вских там релиз инженеров, админов и т.д.
Сама по себе разработка требуешь больше профессионализма и времени, нежели количества рук. Пусть луше 5 девелоперов с тим лидом пишут год, чем 10 напишут за 7 месяцев. И через 5 лет велик шанс загнуться, если даже проект пользуется спросом со стороны бизнеса.
