Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Здравствуйте, SergeyT., Вы писали:
ST>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор.
Ну, если убрать спор о терминологиях, то в двух словах, рефакторинг рулит (это к вопросу о reversibility).
ST>Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
Не увидел связи.
А ещё мне показалось, но не то чтобы на 100%, что он НЕ считает выбор языка программирования частью архитектуры. И вот тут я бы поспорил.
Здравствуйте, 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, Вы писали:
ST>>Очень любопытная точка зрения, которая объясняет, почему существует столько разных и иногда противоречивых представлений о том, что такое архитектура и что должен делать архитектор. Она же дает ответ на вопрос, почему в отечественном аутсорсе с этой ролью еще долго будут проблемы.
G>Архитектор (в разработке ПО) это скорее звание, а не роль. Обычно это звание дается человеку за принятие ключевых технических решений и ответственности за эти решения. По сути архитектором может стать любой человек, который сможет аргументировать свое решение. Ему даже не надо уметь писать код, можно просто прочитать пару книг фаулера и популярных статей, а потом ссылаться на них.
Фаулер называет такого архитекта "Architectus Reloadus"
