Size: a a a

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

2020 June 17

НХ

Николай Хитров... in Архитектура ИТ-решений
хотя по поводу скатывания в говно согласен
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
но ведь бизнес сам должен понимать, на какие риски он идет, разве нет?
Нет. Потому что человеческий мозг в критических ситуациях забывает о стратегии.

Человеческий мозг во время стресса выбирает - жрать торт, вместо спортзала.

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

Нам же не нужно каждое утро и вечер (как минимум) продавать себе "почистить зубы".
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Нет. Потому что человеческий мозг в критических ситуациях забывает о стратегии.

Человеческий мозг во время стресса выбирает - жрать торт, вместо спортзала.

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

Нам же не нужно каждое утро и вечер (как минимум) продавать себе "почистить зубы".
про торт жизненно)

но тем не менее, должен быть тот, кто решает, рефакторить или нет.

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

если мы говорим, что за выбор отвечает разработчик, то почему он не может просто поставить перед фактом, что все, тупик, надо рефакторить. иначе никак. бизнес все равно же не поймет, почему без этого никак. да, он может топнуть ножкой, надавить сроками, бюджетами, но не всё можно сделать в желаемые сроки. почти всегда бизнес говорит "надо вчера", но мало кто (никто?) попадает в такие сроки.
источник

НХ

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
про торт жизненно)

но тем не менее, должен быть тот, кто решает, рефакторить или нет.

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

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

НХ

Николай Хитров... in Архитектура ИТ-решений
тогда это получается выбор разраба, в моем понимании. ставим перед фактом и делаем
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Менеджер или бизнес (ребёнок в разработке) не может в этих вопросах ничего решать, потому что он некомпетентен и ему хочется сладкого прямо сейчас. И он не понимает, что кушать сладкое на ночь вместо чистки зубов - это плохо. Для него очевидно - сладкое, это вкусно, а чистить зубы - задротство взрослых.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
тогда это получается выбор разраба, в моем понимании. ставим перед фактом и делаем
Кто спрашивает разраба? Разраб херачит
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Кто спрашивает разраба? Разраб херачит
так никто не срашивает. ему говорят, хочу фичу. он понимает, что для этого нужно рефакторить. поэтому просто учитывает рефакторинг при оценке и молча делает его
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
так никто не срашивает. ему говорят, хочу фичу. он понимает, что для этого нужно рефакторить. поэтому просто учитывает рефакторинг при оценке и молча делает его
Хорошо, допустим. А как насчёт редизайна? Тут ведь думать надо и обсуждать. А документирование?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
И над разрабом есть лид, а лид видит чем занят разраб. А на лида давит менеджер.
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
Хорошо, допустим. А как насчёт редизайна? Тут ведь думать надо и обсуждать. А документирование?
по поводу документирования я согласен с вашим подходом, что на это отдельные задачи нужно заводить как техдолг. ну или нужно сразу прописывать обязательное наличие доки как definition of done. но, само собой, сроки давят и т.д., так что почти утопия)
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
с редизайном скорее всего также
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
по поводу документирования я согласен с вашим подходом, что на это отдельные задачи нужно заводить как техдолг. ну или нужно сразу прописывать обязательное наличие доки как definition of done. но, само собой, сроки давят и т.д., так что почти утопия)
А вот и не утопия. Можно этого добиться, когда проект почти утонул. Но добиться уже от нового руководства.
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
И над разрабом есть лид, а лид видит чем занят разраб. А на лида давит менеджер.
все всегда давят, тут ничего не поделать. на это и есть лид, чтобы загораживать команду от менеджеров
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
Gennadiy Kruglov
А вот и не утопия. Можно этого добиться, когда проект почти утонул. Но добиться уже от нового руководства.
утопия в том плане, что как часто разработчик приходит на проект с документацией? чтобы хотя бы процентов 50 было описано
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Иногда становится понятно, что от руководства ничего не добиться. Его нужно просто менять
источник

I

Ivan in Архитектура ИТ-решений
Gennadiy Kruglov
Нужное время - всегда. И наша задача - сделать так, чтобы продавать это стало не нужно, чтобы это стало неотъемлемой частью разработки.
Не совсем всегда. Во время программирования разработчик около 10% времени вводит символы с клавиатуры и около 90% он борется со сложностью и читает существующий код, и это еще оптимистичные цифры. Казалось бы, что чем чище код, тем лучше экономика. Но не всегда рефакторинг окупается. К нему также применим Принцип Парето. Есть код, который читается часто, и его рефакторинг быстро окупится и существенно улучшит экономику разработки. А есть такой код, который читается редко, и его рефакторинг не отразится на экономике разработки, но зато оттянет ресурсы от более приоритетных (и более монетизируемых) задач, что, кроме cost of repair, может повлечь за собой еще и ущерб упущенной выгоды ("cost of delay"). А есть такой код, который лучше вообще не трогать, и использовать Srangler Application или дублирование контекста. Ну и еще всегда будет образовываться prudent-inadvertent debt https://martinfowler.com/bliki/TechnicalDebtQuadrant.html , какой бы опытный разработчик не был, и как бы он не старался. Момент для устранения такого техдолга зависит от объема накопленных знаний, т.е. здесь время играет на руку.
В общем, по ссылкам все расписано.
А если мы говорим про reckless debt, то сколько времени на рефакторинг не выделяй, а качественных изменений это не принесет - у команды просто нет необходимых навыков.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Николай Хитров
утопия в том плане, что как часто разработчик приходит на проект с документацией? чтобы хотя бы процентов 50 было описано
Ну давайте эту тенденцию продолжать.
источник

НХ

Николай Хитров... in Архитектура ИТ-решений
так я не говорю ее продолжать)
источник