Код метода в 342 строки — это очевидное нарушение одного из базовых принципов проектирования ПО, single responsibility principle. И это не «техническая деталь», с которой «знакомиться там и место», а то, что превратит код проекта в «большой ком грязи», ну или «спагетти-код», кому как нравится.
Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
Красота кода — это не главный критерий, код не картина и не женщина, главный критерий — эффективность. Красота это производная эффективности скорее…
Базовые цели у заказчика и исполнителя на самом деле совпадают — решить задачи с минимальными потерями времени, денег и нервных клеток.
Есть набор практик, которые были созданны отнюдь не глупыми людьми, и совсем не теоретиками. Эти практики как раз и направлены на обход всевозможных граблей и, в конечном итоге, на экономию времени, денег и нервных клеток.
Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.
Итог — скупой платит дважды, или как говорят автомобилисты «кроилово ведет к попадалову». Поэтому я и говорю про образование — человек владеющий этими методологиями, понимающий их важность, решать бизнес-задачи будет гораздо эффективней.
Уважаемый krasko, в последних двух абзацах я не написал ничего, что относится к этой замечательной цитате.
Музыкант не должен играть без нот, а инженер работать
«with little or no idea of the mathematical underpinnings of what they are doing»
Но! Математика для инженерии и инженерия для математики — это две большие разницы. Я видел senior'ов с «solid mathematical background», но не знающих, что код метода не должен быть длиной 342 строки.
Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
Плюс — дело не только в грамотно нормализованной модели, знании SOLID и О-нотации, дело вообще в таком замечательном понятии как «обеспечение качества ПО». Вот с пониманием что это такое, у бизнеса реально большие проблемы. Что наплевательское отношение к такой на первый взгляд хрени, как проектирование классов и интерфейсов, как рефакторинг и код ревью, в общем к тому, на чем бабки не отбить, в дальнейшем выливается в бесконечные багфиксы и кастомер инциденты.
Качество кода — это не абстракция, качество кода реально оценивается с помощью кучи метрик, существует четкая зависимость времени, затраченного на поддержку кода от его качества. Но не понимают же, что условный день, потраченный на нормальную архитектуру, даже три дня, потраченных на рефакторинг говнокода, потом сэкономят условные две недели/месяц на багфиксинге. И хорошо, если дело еще обойдется просто багфиксингом, многие проекты, «написанные просто», реанимации уже не подлежат, такие полуживые трупы на искусственном дыхании.
Причина? Опять-таки, среднестатистический уровень компетенции людей, принимающих административные решения и распределяющих ресурсы проекта. Вроде бы на хабре слышал хорошую фразу — «вчера он порошком торговал, а сегодня менеджер проекта».
Изучение поведенческих алгоритмов, психологический портрет… На приеме у психолога чтоли? Было бы разумно отдать на откуп решение таких вещей тем, кого яндекс собирается защищать — хочет человек, юзает вариант, описанный в статье, хочет — «простая» аутентификация без наворотов.
Еще как клеили… Почитайте «Записки авиаконструтора» Яковлева, как начинался совдеповский автопром — брали чемодан денег и галопам по европам, скупать все лучшее, привозили, разбирали, снимали размеры и копировали. И кто-то даже на полном серьезе даже верит, что АК-47 сделал сержантик с 8 классами образования, и Хьюго Шмайссер тут не при чем:) Так что «заимствование лучших западных образцов» не вчера и не позавчера началось.
Разумеется на десятилетия, но вполне возможно тут дело просто в уровне развития людей принимающих решения. «Старшие пацаны» привыкли другими делами заниматься, уж точно не реальным производством, этого по факту в РФ нет. А тут «грядка» совершенно незнакомая, но рефлексы то все те же — дадим бабок и все разрулят, и невдомек же что база, как кадровая, так и технологическая, тут даже не годами — десятилетиями нарабатывается.
На банальный попил это уже не похоже — прилетел санкционный петушок к «старшим пацанам» и больно клюнул в зад.
В первом случае я имел ввиду поведение, контролируемое тем, что в нашем доморощенном переводе называется операционный уровень приложения, а в оригинале application layer. Сюда же с огромной натяжкой можно отнести контроллер из того же MVC-паттерна, к примеру. Это самый «высокоуровневый» код, который контролирует всякого рода мэнэджеры, хэлперы, контроллеры, и ту бизнесс-логику которую они отрабатывают, если речь идет про anemic domain model, или data driven design, если смотреть с точки зрения методологии проектирования, и контролирует фабрики, репозитории и агрегаты, если речь идет про domain driven design. То есть ближе всего use case соотносятся с методами именно application layer-а, и соответственно ответственность за некорректную отработку прецендентов было бы логично возложить именно на методы application layer-а. Это я имел ввиду, говоря про «код, наиболее близкий к клиенту» и «знающий больше всего про ожидаемое поведение».
Далее по второму случаю, и тому, что будет делать обработчик — здесь банальное поддержание согласованности данных, когда это представляется возможным. Когда нет — падение с фиксацией описания ошибки для скорейшей локализации и расследования причин, ничего нового тут не сказал. habrahabr.ru/post/126374/ исходя из этой градации, думаю то, что я имею ввиду, относиться к строгой гарантии.
Базовые знания о проектировании ПО должны разумеется закладываться в ВУЗе, на профильных дисциплинах — ООП, технологии разработки ПО, контруирование ПО и тд
Базовые цели у заказчика и исполнителя на самом деле совпадают — решить задачи с минимальными потерями времени, денег и нервных клеток.
Есть набор практик, которые были созданны отнюдь не глупыми людьми, и совсем не теоретиками. Эти практики как раз и направлены на обход всевозможных граблей и, в конечном итоге, на экономию времени, денег и нервных клеток.
Только заказчик/менеджмент проекта зачастую воспринимает эти практики, как какие-то глупые, ненужные и совершенно излишние вещи.
Итог — скупой платит дважды, или как говорят автомобилисты «кроилово ведет к попадалову». Поэтому я и говорю про образование — человек владеющий этими методологиями, понимающий их важность, решать бизнес-задачи будет гораздо эффективней.
Музыкант не должен играть без нот, а инженер работать Но! Математика для инженерии и инженерия для математики — это две большие разницы. Я видел senior'ов с «solid mathematical background», но не знающих, что код метода не должен быть длиной 342 строки.
Если есть знакомые/друзья которые учились например в немецких технических ВУЗах, поитересуйтесь как, когда и в какой форме там дается математика.
Плюс — дело не только в грамотно нормализованной модели, знании SOLID и О-нотации, дело вообще в таком замечательном понятии как «обеспечение качества ПО». Вот с пониманием что это такое, у бизнеса реально большие проблемы. Что наплевательское отношение к такой на первый взгляд хрени, как проектирование классов и интерфейсов, как рефакторинг и код ревью, в общем к тому, на чем бабки не отбить, в дальнейшем выливается в бесконечные багфиксы и кастомер инциденты.
Качество кода — это не абстракция, качество кода реально оценивается с помощью кучи метрик, существует четкая зависимость времени, затраченного на поддержку кода от его качества. Но не понимают же, что условный день, потраченный на нормальную архитектуру, даже три дня, потраченных на рефакторинг говнокода, потом сэкономят условные две недели/месяц на багфиксинге. И хорошо, если дело еще обойдется просто багфиксингом, многие проекты, «написанные просто», реанимации уже не подлежат, такие полуживые трупы на искусственном дыхании.
Причина? Опять-таки, среднестатистический уровень компетенции людей, принимающих административные решения и распределяющих ресурсы проекта. Вроде бы на хабре слышал хорошую фразу — «вчера он порошком торговал, а сегодня менеджер проекта».
МушкетерыПаттерны 20 лет спустя. Нет планов привлечь хабросообщество к написанию сего труда?Если по сути — думаю не лучшая практика гонять автотесты на каждый чекин, там хватит и обычных юнит-тестов.
На банальный попил это уже не похоже — прилетел санкционный петушок к «старшим пацанам» и больно клюнул в зад.
Далее по второму случаю, и тому, что будет делать обработчик — здесь банальное поддержание согласованности данных, когда это представляется возможным. Когда нет — падение с фиксацией описания ошибки для скорейшей локализации и расследования причин, ничего нового тут не сказал.
habrahabr.ru/post/126374/ исходя из этой градации, думаю то, что я имею ввиду, относиться к строгой гарантии.