тесты нужны для проверки логики, чтобы компоненты/система вели себя по-прежнему, как и раньше (если требования не сменились), а не для корректности кода. О нарушении последнего вам расскажет компилятор. Ну и плюс полностью согласен с комментом habrahabr.ru/post/206684/#comment_7125298, прям в точку
Согласен с положениями в статье, но не согласен с примером. Пример специально подведен к космическому построению архитектуры.
Например: требуется велосипед. К велосипеду есть определенный набор требований, и мы их реализуем. Именно по факту требований. Нужно что-то больше? Появляются новые требования. Из-за них могут появиться первые или новые уровни абстракции, опять же в угоду требованиям, но мы не пишем всё заново.
Далее, требуется всё-таки отличать бизнес-требования от технических. В статье приведен пример архитектуры технической, но условия её изменения уже бизнес, которые имеют свойство меняться действительно намного чаще. Поэтому порой чаще абстрагируются именно в них, ибо это естественная область не для программистов, а для пользователей системы из той или иной нетехнической сферы.
Ещё один момент: фреймворки. Они для того и нужны, что позволяют построить каркас. Но они ни разу не завязаны на требованиях к конкретной области, поэтому и стараются максимально декомпозироваться на модули. А вы уже выбираете: вам один позвонок или всё-таки позвоночник.
А что касается дженериков в их привычном понимании — это сугубо техническая фича, направленная на решение именно технических задач, но никак не бизнесовых. В бизнесовых собственно можно наплодить абстракций уйму.
Уважаемые наши Мартины (Роберт Мартин и Мика Мартин) не смотря на перечисления всех преимуществ Agile'а всё-таки ставят в главенство взаимоотношения людей в команде. Нет людей — нет взаимоотношений — не скрама — скрам плохой.
На счёт применения разных методологий — ещё один повод потом ругать, что, мол, методология не такая, а просто вязли и замиксовали всё в кучу. Есть даже понятие: scrum-but (на хабре была статейка весной этого года).
И раз уж Agile — это манифест, то лучшую практику выбирает уже команда, а они есть: scrum, crystal, kanban и т.д.
думаем, прорисована архитектура, концепция, но всё может сойти на нет снова из-за сроков с формулировкой: ну у вас же работает, чего там стоит дописать ещё и это
реальный случай: создана программа, с не слишком сложными требованиями. К проекту относились как к проходящему, но разработка нормальной архитектуры страдала именно из-за малых сроков, т.к. и руководство считало проект также проходящим. В итоге требования росли, росли, выкатывались новые, одна часть приложения после третьей итерации была переписана чуть ли не с нуля, а вторая часть страдала от нагроможденности, т.к. была рассчитана на первоначальные требования.
В итоге из-за сроков, из-за новых хотелок (достаточно серьезных) требуется время на переработку второй части, но в целом приложение рабочее, бизнес вроде доволен, его задачи выполняются, но код стал жутко не поддерживаемым, а с ним ещё работать, проходящий проект вырос в приоритетный. Так что приходится просто выбивать время, обосновывать, что так надо, но встречаем негодование, хрен объяснишь, пояснишь. Или ещё хуже — мы же профессионалы, должны были вообще всё предусмотреть.
за перевод средств со счёта на счёт взимается комиссия, увы. При обычном пополнении комиссия не взимается. Собственно ваша теория оправдана на 99%, т.к. и на самом чеке в сабже написано, что это взнос наличных. Спасибо кассирше просто за экономию средств
Также подписываюсь под просьбой посвятить вашему опыту ловкого манипулирования либами целую статью, особенно в контексте лучшей замены того или иного фреймворка
это подход, хорошо описанный ещё Макконнеллом про новаторские вещи, т.е. объясняющий скорость распространения той или иной новой технологии в IT. Другими словами: не стоит гнаться за чем-то сверхмодным, если текущие инструменты (актуальные) в купе с личным опытом позволяют решать свои задачи максимально эффективно. Поэтому я с вами полностью соглаен
часто приходится или приходилось мигрировать один клиент с одного бэка на другой? ))
вот честно, это какой-то вопиющий случай, даже при разработке приложения для широкой публики, когда неизвестно, какое там окружение будет у конечного потребителя.
я думаю фактор переключения сознания не настолько критичен в командах (архитекторы всея проекта не в счёт), т.к. обязанности всё равно распределяются на бэк и фронт (очень часто даже в вакансиях для корпоративных проектов указывается специализация по конкретному направлению: фронт или бэк).
да, на счёт повторяемости кода я косякнул. Хотел дать понять повторяемость логики работы с данными, чтобы одно и тоже (валидность, к примеру) не выполнялась по 2 раза.
Ладно, спасибо за ответы в разных тредах, очень содержательно получилось.
я имел ввиду не те фреймворки, а случай проработки архитектуры и построения стека применяемых технологий, не абстрагируясь от них, именно таким образом, чтобы использовать их совместно с разделением ответственности (нк и синхронизация данных между клиентами как раз через сервер-сайд). Т.е. простой случай: поменялось значение на клиенте, а через обертку (какой-нибудь observer, использующий штатные механизмы фреймворка) отпрвил запрос на серверную часть, где и пошла следующая обработка. Понимаю, возможно получилось слишком абстрактно.
чисто теоретически, для повторного использования кода на сервере и клиенте можно же написать обёртку для работы именно со своим бэком, заточенным под применение того или иного фреймворка на клиенте и правильно разнести ответственность? более того, возможно, такие обёртки уже существуют
Я быть может чего-то еще не понимаю, но использование Express подразумевает использование на бэке именно Node.js, что сразу ставит Angular в неконкуретное положение с оппонентами из топика, ибо нельзя же армию jee, asp.net, django и ror разработчиков взять так и сагитировать на node.js. Поэтому альтернатив на бэке полно, перечислял основные из них
Например: требуется велосипед. К велосипеду есть определенный набор требований, и мы их реализуем. Именно по факту требований. Нужно что-то больше? Появляются новые требования. Из-за них могут появиться первые или новые уровни абстракции, опять же в угоду требованиям, но мы не пишем всё заново.
Далее, требуется всё-таки отличать бизнес-требования от технических. В статье приведен пример архитектуры технической, но условия её изменения уже бизнес, которые имеют свойство меняться действительно намного чаще. Поэтому порой чаще абстрагируются именно в них, ибо это естественная область не для программистов, а для пользователей системы из той или иной нетехнической сферы.
Ещё один момент: фреймворки. Они для того и нужны, что позволяют построить каркас. Но они ни разу не завязаны на требованиях к конкретной области, поэтому и стараются максимально декомпозироваться на модули. А вы уже выбираете: вам один позвонок или всё-таки позвоночник.
А что касается дженериков в их привычном понимании — это сугубо техническая фича, направленная на решение именно технических задач, но никак не бизнесовых. В бизнесовых собственно можно наплодить абстракций уйму.
На счёт применения разных методологий — ещё один повод потом ругать, что, мол, методология не такая, а просто вязли и замиксовали всё в кучу. Есть даже понятие: scrum-but (на хабре была статейка весной этого года).
И раз уж Agile — это манифест, то лучшую практику выбирает уже команда, а они есть: scrum, crystal, kanban и т.д.
В итоге из-за сроков, из-за новых хотелок (достаточно серьезных) требуется время на переработку второй части, но в целом приложение рабочее, бизнес вроде доволен, его задачи выполняются, но код стал жутко не поддерживаемым, а с ним ещё работать, проходящий проект вырос в приоритетный. Так что приходится просто выбивать время, обосновывать, что так надо, но встречаем негодование, хрен объяснишь, пояснишь. Или ещё хуже — мы же профессионалы, должны были вообще всё предусмотреть.
вот честно, это какой-то вопиющий случай, даже при разработке приложения для широкой публики, когда неизвестно, какое там окружение будет у конечного потребителя.
Ладно, спасибо за ответы в разных тредах, очень содержательно получилось.