Вы не пропустили - именно так всё и устроено. В статье описано не событие, а состояние: когда человек формально присутствует в роли, но фактически не выполняет ни одной её функции. Тут не про 'сломалось'. Замысел про 'не работает, но считается, что работает'. Оттого и финала нет: его не случается в таких случаях. А проект, кстати, все еще не запущен.
Любопытно, как легко вы уловили формальное "нарушение" — и так же легко прошли мимо смысла, который при этом читается без всяких затруднений. Как правило это не вопрос языка, а вопрос внутренней настройки: если хочется уколоть, текст всегда покажется острым в нужном месте.
Но всё равно спасибо - напомнили, как тонко работает проекция.
Такое часто бывает. Сначала просто пишут, потому что нужно, потом оно неожиданно становится важным, а менять уже сложно. Архитектура как правило не приоритет, когда цель - по шустрому сдать и показать результат.
Если система уже работает, задача не в том, чтобы всё исправить. Тут задача в том, чтобы понять, что можно изолировать, а что пока лучше не трогать. Минимум риска, максимум стабильности. Всё остальное семимильными шагами по мере необходимости. О способах решения еще будет материал.
YAGNI работает, когда знаешь, что фича реально может не понадобиться. Но с архитектурой так не выйдет - она либо позволяет двигаться дальше, либо мешает. Если что-то не заложил, а потом без этого никак - придётся резать по живому. .NET 4.8.1 - как раз такой случай. Вроде без излишков писали, а теперь всё мешает. Не потому что наделали глупостей, а потому что система не готова меняться.
Так что да, ничего лишнего - это хорошо. Но если завтра менять будет нечего - толку от этого мало.
Справедливо подмечено про форму - и про то, что текст не уходит в морализаторство. Насчёт концовки - возможно, ощущение возникает от сдвига фокуса: от вскрытия к призыву. Да, обобщённо. Потому что инженерная конкретика в таких вопросах всегда контекст-зависима - шаблона нет. Щадил ли читателя? Нет. Просто выбрал точку, где боль уже озвучена, а дальше - либо работаешь с ней, либо закрываешь вкладку. Грязнее писать можно, но это уже будет не конструкция, а исповедь. Не уверен, что в этом был смысл.
Да, isaqb дал неплохую формализацию. Но системное мышление в статье не пересказ curriculum, а показать, как эти принципы проживаются на практике и рождаются не из теории, а из боли реальных решений. Доктрина - одно, рефлексия инженера под давлением - другое.
Спасибо. Однако считаю что вот как раз "мегабайт спагетти с God-классами" - это не отдельная тема, а следствие как раз отсутствия архитектурного мышления на старте. Мысли не про рефакторинг руками, а про то, как не создавать такие конструкции в принципе. Но если интерес к техникам расчистки хрупкого легаси устойчивый - можно будет отдельно разобрать подходы: от адаптеров до стратегий поэтапной миграции.
Документация фиксирует факты. Архитектурное мышление - это способность моделировать последствия до того, как они зафиксируются. Хранить знания в Confluence - правильно. Но полагаться только на это - наивно
if сам по себе не враг. Но когда их десятки, каждый с бизнес-исключением, и все в одном методе - это уже не контроль потока, это шифр на выживание. Ни имею ничего против if - против превращения кода в минное поле.
Если бросили на 2-й минуте, то неудивительно, что восприняли метафору буквально. "Умереть" в данном случае - не трагедия, а результат утраты локальности. Суть вы всё равно поймали: сильная связанность → каскад изменений. Так что по сути спорить, похоже, не с чем.
Соглашусь, полотно неимоверное получится. Но как вариант можно вывести отдельно подрубрики, в которых раскрывать эти самые нюансы. А на основной материал ссылаться. Как вариант:)
Классная статья, круто раскрывает, почему CGo тормозит, и как вы выжали из FastCGo в 16,5 раз больше скорости. Бенчмарки, разбор ассемблера и тонкости со стеком и ABI - всё чётко и по делу, для разработчиков на Go и C++ прям находка. Проблемы с выравниванием, упаковкой структур и памятью расписаны с примерами, что реально помогает въехать. ИМХО.
Некоторые вещи действительно забываются, хотя давно поддерживаются. Подборка полезная, хотя подача местами упрощённая. Я отмечу некоторые, автору на заметку наверное. Все приёмы поданы как отдельные лайфхаки, без систематизации. Было бы лучше сгруппировать по задачам: типографика, формы, UX и т.д. Местами не хватает анализа применимости. Например, user-select: all - где конкретно это оправдано в реальной интерфейсной задаче? Далее. Заключение по сути повтор оглавления. Нет общего вывода, по какой причине эти фичи выпадают из внимания разработчиков. В остальном - хороший повод освежить в памяти базовые, но забытые возможности.
Очень точное наблюдение. Сформулирую немного жёстче: отсутствие модерации - это не свобода, а отказ от архитектуры. Любая система без правил уходит в разнос. И токсичность в этом случае не баг, а естественное состояние. Аналогично и с кармой. Снаружи кажется: все взрослые, пусть голосуют. Но по факту - минусы анонимны, обратной связи нет, инженерную прямоту часто воспринимают как агрессию. Итог тот же: глубина вытесняется формой. Осторожные фразы выживают, острые мысли - минусуются. И система незаметно дрейфует в сторону "вежливого шума". И да, вы метко "подметили", это не вопрос вежливости или строгости - это инженерный вопрос. Устойчивость среды - такая же проектная задача, как отказоустойчивость у сервиса. Если её пустить на самотёк - всё развалится. Только заметим мы это уже постфактум.
Пост первый. Просто сразу с мыслью пришёл, а не с аватаркой и приветствием). А на больные и триггерные места мне коллеги указали. Есть один толковый спец у нас (их много, но этот особенно толковый). Так вот, наелся он досыта с ОСС и написал здесь свое мнение. Стиль и манера у него нетривиальные, на позиции своей стоит прочно и не отступает. А что, имеет право. Так его инквизиция из адептов "без сильных аргументов, но круговой порукою" просто минусанула. Меж строк читают такие что ли, или просто упорствуют из принципа - непонятно. Но дискуссию аргументированную поддержать не в состоянии. Как результат - в рекавери отправили. А у него столько сильных статей, вперемежку с легким чтивом лежат в заметках. Читал. Он теперь не постит, потому карма, как он выражается, особенная...
Абсолютно в точку. Если бы отображались все голоса - это бы сильно изменило восприятие. Видно было бы, что человек говорит по сути, а не за карму. 200 минусов от триггернутых - не то же самое, что один справедливый минус от коллеги. А так получается: вроде "+0", а реально за пост бились. И да, если человек продолжает говорить по делу, несмотря на "хлопки по рукам" - это не токсик, это как раз эксперт с позицией.
Если "последнее китайское предупреждение" висит неделями вне зависимости от активности, а потом внезапно исчезает - это не метрика, а ручной режим. И да, непрозрачность минусов отлично маскирует, кто именно «рулит» кармой.
История с Курчатовым - показательная и тут вы очень в тему упомянули про это. Он умел видеть потенциал даже в неудобных людях и находить им место в команде. Нынче же у нас - алгоритм, которому всё равно на суть. Он реагирует на тон, триггеры, настроение толпы. Резкий, но по делу? Будешь "токсичным". Чёткий, без лишней воды? "Высокомерный". А дальше - минус, без диалога и без шанса встроиться.
Сильное сообщество не боится сложных людей. Оно умеет с ними работать.Имхо.
Когда в тексте описывают тишину, важно не читать её как шум. Но это требует привычки вдумываться, а не выискивать, где “должно было случиться”.
Вы не пропустили - именно так всё и устроено. В статье описано не событие, а состояние: когда человек формально присутствует в роли, но фактически не выполняет ни одной её функции. Тут не про 'сломалось'. Замысел про 'не работает, но считается, что работает'. Оттого и финала нет: его не случается в таких случаях. А проект, кстати, все еще не запущен.
Уловить огрех в форме и тут же перестать видеть содержание - вполне типичная замена понимания на реакцию.
Любопытно, как легко вы уловили формальное "нарушение" — и так же легко прошли мимо смысла, который при этом читается без всяких затруднений.
Как правило это не вопрос языка, а вопрос внутренней настройки: если хочется уколоть, текст всегда покажется острым в нужном месте.
Но всё равно спасибо - напомнили, как тонко работает проекция.
Такое часто бывает. Сначала просто пишут, потому что нужно, потом оно неожиданно становится важным, а менять уже сложно. Архитектура как правило не приоритет, когда цель - по шустрому сдать и показать результат.
Если система уже работает, задача не в том, чтобы всё исправить. Тут задача в том, чтобы понять, что можно изолировать, а что пока лучше не трогать. Минимум риска, максимум стабильности. Всё остальное семимильными шагами по мере необходимости. О способах решения еще будет материал.
YAGNI работает, когда знаешь, что фича реально может не понадобиться. Но с архитектурой так не выйдет - она либо позволяет двигаться дальше, либо мешает. Если что-то не заложил, а потом без этого никак - придётся резать по живому.
.NET 4.8.1 - как раз такой случай. Вроде без излишков писали, а теперь всё мешает. Не потому что наделали глупостей, а потому что система не готова меняться.
Так что да, ничего лишнего - это хорошо. Но если завтра менять будет нечего - толку от этого мало.
Справедливо подмечено про форму - и про то, что текст не уходит в морализаторство. Насчёт концовки - возможно, ощущение возникает от сдвига фокуса: от вскрытия к призыву. Да, обобщённо. Потому что инженерная конкретика в таких вопросах всегда контекст-зависима - шаблона нет. Щадил ли читателя? Нет. Просто выбрал точку, где боль уже озвучена, а дальше - либо работаешь с ней, либо закрываешь вкладку. Грязнее писать можно, но это уже будет не конструкция, а исповедь. Не уверен, что в этом был смысл.
Да, isaqb дал неплохую формализацию. Но системное мышление в статье не пересказ curriculum, а показать, как эти принципы проживаются на практике и рождаются не из теории, а из боли реальных решений. Доктрина - одно, рефлексия инженера под давлением - другое.
Спасибо. Однако считаю что вот как раз "мегабайт спагетти с God-классами" - это не отдельная тема, а следствие как раз отсутствия архитектурного мышления на старте. Мысли не про рефакторинг руками, а про то, как не создавать такие конструкции в принципе. Но если интерес к техникам расчистки хрупкого легаси устойчивый - можно будет отдельно разобрать подходы: от адаптеров до стратегий поэтапной миграции.
Документация фиксирует факты. Архитектурное мышление - это способность моделировать последствия до того, как они зафиксируются. Хранить знания в Confluence - правильно. Но полагаться только на это - наивно
if сам по себе не враг. Но когда их десятки, каждый с бизнес-исключением, и все в одном методе - это уже не контроль потока, это шифр на выживание. Ни имею ничего против if - против превращения кода в минное поле.
Если бросили на 2-й минуте, то неудивительно, что восприняли метафору буквально. "Умереть" в данном случае - не трагедия, а результат утраты локальности. Суть вы всё равно поймали: сильная связанность → каскад изменений. Так что по сути спорить, похоже, не с чем.
Соглашусь, полотно неимоверное получится. Но как вариант можно вывести отдельно подрубрики, в которых раскрывать эти самые нюансы. А на основной материал ссылаться. Как вариант:)
Классная статья, круто раскрывает, почему CGo тормозит, и как вы выжали из FastCGo в 16,5 раз больше скорости. Бенчмарки, разбор ассемблера и тонкости со стеком и ABI - всё чётко и по делу, для разработчиков на Go и C++ прям находка. Проблемы с выравниванием, упаковкой структур и памятью расписаны с примерами, что реально помогает въехать. ИМХО.
Некоторые вещи действительно забываются, хотя давно поддерживаются. Подборка полезная, хотя подача местами упрощённая. Я отмечу некоторые, автору на заметку наверное. Все приёмы поданы как отдельные лайфхаки, без систематизации. Было бы лучше сгруппировать по задачам: типографика, формы, UX и т.д.
Местами не хватает анализа применимости. Например,
user-select: all- где конкретно это оправдано в реальной интерфейсной задаче? Далее. Заключение по сути повтор оглавления. Нет общего вывода, по какой причине эти фичи выпадают из внимания разработчиков.В остальном - хороший повод освежить в памяти базовые, но забытые возможности.
Очень точное наблюдение. Сформулирую немного жёстче: отсутствие модерации - это не свобода, а отказ от архитектуры. Любая система без правил уходит в разнос. И токсичность в этом случае не баг, а естественное состояние. Аналогично и с кармой. Снаружи кажется: все взрослые, пусть голосуют. Но по факту - минусы анонимны, обратной связи нет, инженерную прямоту часто воспринимают как агрессию. Итог тот же: глубина вытесняется формой. Осторожные фразы выживают, острые мысли - минусуются. И система незаметно дрейфует в сторону "вежливого шума". И да, вы метко "подметили", это не вопрос вежливости или строгости - это инженерный вопрос. Устойчивость среды - такая же проектная задача, как отказоустойчивость у сервиса. Если её пустить на самотёк - всё развалится. Только заметим мы это уже постфактум.
Пост первый. Просто сразу с мыслью пришёл, а не с аватаркой и приветствием). А на больные и триггерные места мне коллеги указали. Есть один толковый спец у нас (их много, но этот особенно толковый). Так вот, наелся он досыта с ОСС и написал здесь свое мнение. Стиль и манера у него нетривиальные, на позиции своей стоит прочно и не отступает. А что, имеет право. Так его инквизиция из адептов "без сильных аргументов, но круговой порукою" просто минусанула. Меж строк читают такие что ли, или просто упорствуют из принципа - непонятно. Но дискуссию аргументированную поддержать не в состоянии. Как результат - в рекавери отправили. А у него столько сильных статей, вперемежку с легким чтивом лежат в заметках. Читал. Он теперь не постит, потому карма, как он выражается, особенная...
Абсолютно в точку. Если бы отображались все голоса - это бы сильно изменило восприятие. Видно было бы, что человек говорит по сути, а не за карму. 200 минусов от триггернутых - не то же самое, что один справедливый минус от коллеги. А так получается: вроде "+0", а реально за пост бились. И да, если человек продолжает говорить по делу, несмотря на "хлопки по рукам" - это не токсик, это как раз эксперт с позицией.
Если "последнее китайское предупреждение" висит неделями вне зависимости от активности, а потом внезапно исчезает - это не метрика, а ручной режим. И да, непрозрачность минусов отлично маскирует, кто именно «рулит» кармой.
История с Курчатовым - показательная и тут вы очень в тему упомянули про это. Он умел видеть потенциал даже в неудобных людях и находить им место в команде. Нынче же у нас - алгоритм, которому всё равно на суть. Он реагирует на тон, триггеры, настроение толпы. Резкий, но по делу? Будешь "токсичным". Чёткий, без лишней воды? "Высокомерный".
А дальше - минус, без диалога и без шанса встроиться.
Сильное сообщество не боится сложных людей. Оно умеет с ними работать.Имхо.