Size: a a a

Архитектура ИТ-решений

2020 February 27

PD

Phil Delgyado in Архитектура ИТ-решений
Daria Kaftan
А почем нынче дешевые кодеры?) и средние, мидлы?
Не знаю, я таких не набираю )
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
Проблема в том что “грамотных” разработчиков очень мало. крупным компаниям приходится работать с тем что есть.
Так что СА это и вправду немного костыль, решающий ограничение квалификации разработчиков.
++. Но в таком ключе можно и БА рассмотреть, точнее, часть их работы - они берут на себя разгребание предметки. В которую почему-то не может разраб.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Phil Delgyado
Не знаю, я таких не набираю )
а мидлов?
источник

AK

Anton Korotkikh in Архитектура ИТ-решений
Phil Delgyado
Ну да. А если из кода не понятно, что он делает - то это повод рефакторинга.
Исключения бывают - но это исключения.
По хорошему, надо обосновывать наличие комментариев, а не их отсутствие
Ну вообще-то совсем нет. Код может быть очень огромным или иметь те или иные неочевидные хаки по разным причинам, например борьба за производительность. Коменты ускоряют навигацию по коду и его понимание, на крупном проекте придётся слишком много прочитать и деражать в голове, чтобы понять, что же тут происходит в итоге.
Скорее наоборот - код без комментариев обычно плох и куда хуже кода у которого они есть.
Например
https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/src/Dispatchers.kt

Ну красота же, а теперь представь без этих коментов
источник

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
При таком подходе возникает и другая проблема: команда не фиксирует принятые решения, описание предметной области. То есть “в скраме” отсутствует документооборот, все на словах.
В сложных, длительных проектах критически важно фиксировать знание в документах. Иначе команда будет замедляться, ввиду растущей сложности решения и непонимания предметки.
Нужны выделенная роль для ведения документооборота? Специальный аналитик, который фиксирует все решения команды?
Ну, предположим, мы зафиксируем «знание» в документе на 500 страниц. Чем оно будет отличаться от ТЗ на 500 страниц на входе, которое не читают?

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

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergey V
Ну, предположим, мы зафиксируем «знание» в документе на 500 страниц. Чем оно будет отличаться от ТЗ на 500 страниц на входе, которое не читают?

Нужны документы с логическое схемой для «введения», со всеми связями. Нужны описания моделей данных, нужны описания спецификаций API и процессов. Последние три группы должны либо быть кодом, либо из него генерироваться, чтобы не дублировать источники знаний.
Через год-два-три, у меня будет возмодность этот документ найти, найти в нем объяснение почему приняты такие-то решения.
источник

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
Через год-два-три, у меня будет возмодность этот документ найти, найти в нем объяснение почему приняты такие-то решения.
Через 2 года это уже не нужно, если мы активно развиваемся
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
боевой опыт говорит что нет: регулярно ищем концы в водах трех-пяти летней давности
источник

SV

Sergey V in Архитектура ИТ-решений
А все «почему» они не в документации обычно, и не в спеках, а в презентациях-сравнениях решений. Иногда — в meeting notes встреч.
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Roman Tsirulnikov
На слуху сейчас тема про “коммодитизацию разработчика”, так что погадаю на то что зарплаты СА будут только расти. Мозги очень нужны индустрии. Скрам в крупных компаниях низводит инженера до уровня дворника.
Моя коллега по ремеслу с 15 годами в разработке ещё 3 года говорила следующее: "Сейчас рынок разработчиков делится на два категории: на тех, кто будет говорить как (инженеров) и тех, кто будет делать (кодеры)".
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Именно по-этому она работала в СА, а не в разработке, а сейчас стремится к Solution Architect
источник

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
На слуху сейчас тема про “коммодитизацию разработчика”, так что погадаю на то что зарплаты СА будут только расти. Мозги очень нужны индустрии. Скрам в крупных компаниях низводит инженера до уровня дворника.
Когда скрам внедряется сверху, обычно ничего хорошего и не получается. Опыт десятка команд (сбоку). Это, опять же, не скрам. Когда строим снизу, у меня только положительный опыт в трёх командах.

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

DK

Daria Kaftan in Архитектура ИТ-решений
Кодеры - естественная часть всей кучки программистов. Они были, есть и будут. Нельзя всем конторам брать только "сливки". Даже если рынок будет наводнен хорошими прогерами - поменяются критерии качества и из них тоже выделятся слабые. И появятся более сильные СА/Солюшены/проч которые будут говорить им, что деллать
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Ну, на войне можно быть хреновым бойцом, но хорошим тактиком. Но лучший вариант тогда, когда ты имеешь хорошую подготовку и там и там. Но в таких случаях могут быть свои перекосы. =\
источник

ОИ

Олег Игонин in Архитектура ИТ-решений
Я бы сказал, что получается так, как получается. Где-то предпочитают решать тимлидами, где-то системными аналитиками. Где-то просто разработчиками. Сложно сказать что лучше. а что хуже. Разные типы проеков, разные типы управления, разные достоинства и недостатки.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Sergey V
Когда скрам внедряется сверху, обычно ничего хорошего и не получается. Опыт десятка команд (сбоку). Это, опять же, не скрам. Когда строим снизу, у меня только положительный опыт в трёх командах.

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

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
Это плохо масштабируется на крупные организации. Каждая команда захочет работать как ей удобно. Но нужно как-то унифицировать прцоессы, соблюдать отчетность, координировать работу команд между собой на сложных продуктах.
Ватерфолл это уже фейл, скрам - однозначно фейл в корпорации, я лично ожидаю чего-то нового из комбинации классики и аджайла.
Рабочего варианта на 100+ пока не видел, к сожалению.

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

DK

Daria Kaftan in Архитектура ИТ-решений
а зачем синхронизировать команды на разных продуктах?
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Мы сейчас пробуем предварителюную фазу up-front design (кусочек ватерфолла), а затем реализацию по agile с возможностью обратной связи и корректировки up-front design. Как-то так.
источник

SV

Sergey V in Архитектура ИТ-решений
Roman Tsirulnikov
Мы сейчас пробуем предварителюную фазу up-front design (кусочек ватерфолла), а затем реализацию по agile с возможностью обратной связи и корректировки up-front design. Как-то так.
А синхронизация между командами как?
источник