Из каждого утюга сейчас можно услышать про аджаил и как надо быстро-быстро (х.як х.як) в продакшен. Для этого и облака подтянули, и девопс.
То есть натуральный конвейер для скручивания одних фрейморков с другими, с соответствующим оверхедом из-за лишних фич в каждом фрейморке и излишним гемороем по спариванию интерфейсов
Все это прекрасно вписывается в мир индустриальных цепочек производства и впаривания МВП шустрыми маркетологами лоховатым бузинесменам и бузинесвуменам
При этом старое поколение айтишников, которое знает, как еще можно по-другому, постепенно уходит, а новое поколение "яблочников", "амазонщиков" и "гугловцев" и прочих "индиго" чаще, чем нет, мыслят строго в категориях хайпа и сектанского копирования "образцов"
Вот перед тем, как сомкнуться веки последнего из могикан, хочется оставить миру напоминание о том, что есть хорошо и что есть плохо и что вообще есть
Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, sharpman, Вы писали:
S>Из каждого утюга сейчас можно услышать про аджаил и как надо быстро-быстро (х.як х.як) в продакшен. Для этого и облака подтянули, и девопс. S>То есть натуральный конвейер для скручивания одних фрейморков с другими, с соответствующим оверхедом из-за лишних фич в каждом фрейморке и излишним гемороем по спариванию интерфейсов
S>Все это прекрасно вписывается в мир индустриальных цепочек производства и впаривания МВП шустрыми маркетологами лоховатым бузинесменам и бузинесвуменам
S>При этом старое поколение айтишников, которое знает, как еще можно по-другому, постепенно уходит, а новое поколение "яблочников", "амазонщиков" и "гугловцев" и прочих "индиго" чаще, чем нет, мыслят строго в категориях хайпа и сектанского копирования "образцов"
S>Вот перед тем, как сомкнуться веки последнего из могикан, хочется оставить миру напоминание о том, что есть хорошо и что есть плохо и что вообще есть
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Срочно напишите книгу как надо в противовес "современным" подходам. И обязательно с примерами. Возможно через поколение или два она пригодиться.
Здравствуйте, kov_serg, Вы писали:
_>Срочно напишите книгу как надо в противовес "современным" подходам. И обязательно с примерами. Возможно через поколение или два она пригодиться.
Здравствуйте, sharpman, Вы писали:
S>Из каждого утюга сейчас можно услышать про аджаил и как надо быстро-быстро (х.як х.як) в продакшен. Для этого и облака подтянули, и девопс.
Читал книги про различные гибкие методологии, там авторы рассказывали как они к этому пришли. Сначала они делали всё "по учебнику", а потом у них в голове щёлкнуло, что они могут делать всё быстрее, так как знают все процессы разработки от начала и до конца. Вот на этих моментах мне всегда было интересно, а что делать тем, кто ещё не умеет создавать программы так сказать классическим способом.
Для примера TDD, во время разработки мешает делать изменения в программе. Методологи очень любят всякие метафоры, вроде вонючий код. Ну так я тоже могу придумать не мало подобного трешака — использовать TDD это всё равно, что залить программу в бетон. То есть тесты нужны, но умение создавать их до программы доступно лишь профессионалам у которых низкий коэффицент выбора неправильных решений, которые придётся изменить переписав код.
Но если TDD обязывает писать тесты, то многие гибкие методологии завязаны на отказ от "лишних" процессов. Вот, к примеру, зачем документировать код, это же лишнее время, а значит можно обойтись без этого. Вроде как код лучше всего объясняет, что имелось в виду и только он критерий истины. Но по мне так код не объясняет все задумки. Напротив происходит множество упущений в угоду используемых языков и парадигм программирования, библиотек алгоритмов, устройства процессора и так далее.
Можно долго обсуждать каждый пункт, но мой вывод из всех прочитанных книг в том, что многие из гибких методологий могут использовать только профессионалы достигшие определённого уровня развития, работающие в одиночку и понимающие, что они делают. Эффективность будет достигаться не за счёт гибких методологий как таковых, а за счёт профессионализма.
В целом же "проблема утопающих дело рук самих утопающих", "каждый дрочит как он хочет".
Здравствуйте, kov_serg, Вы писали:
_>Срочно напишите книгу как надо в противовес "современным" подходам. И обязательно с примерами. Возможно через поколение или два она пригодиться.
Здравствуйте, velkin, Вы писали:
V>Можно долго обсуждать каждый пункт, но мой вывод из всех прочитанных книг в том, что многие из гибких методологий могут использовать только профессионалы достигшие определённого уровня развития, работающие в одиночку и понимающие, что они делают. Эффективность будет достигаться не за счёт гибких методологий как таковых, а за счёт профессионализма.
Именно. Чтобы делать ТДД, нужно _уже_ знать проблематику. А предлагают ТДД использовать на зеленых проектах и еще зеленым соплякам...
V>"каждый дрочит как он хочет".
Это теперь берут под контроль с соответствующим эксгибиционизмом на код ревью и ретроспективе
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
Думать.
Это — ВСЕМ. Независимо от должности и "веса в команде".
Анализировать: требования, задачу, предметную область.
Остальное и так нормально.
Мы в 80-е тоже делали агиле (или, прости господи, скрам? ), только без менеджеров, а сами.
И не каждую неделю, а так примерно раз в месяц.
И код ревью — но только по желанию ревьюироемого.
Подходит и говорит: чего-то я запутался.
Садишься и начинается парное экстремальное программирование.
Через полчаса-час-полтора код структурирован и работает.
Чего не было — так это тдд.
Но его и сейчас далеко не каждая контора применяет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, sharpman, Вы писали:
S>Из каждого утюга сейчас можно услышать про аджаил и как надо быстро-быстро (х.як х.як) в продакшен. Для этого и облака подтянули, и девопс. S>То есть натуральный конвейер для скручивания одних фрейморков с другими, с соответствующим оверхедом из-за лишних фич в каждом фрейморке и излишним гемороем по спариванию интерфейсов
S>Все это прекрасно вписывается в мир индустриальных цепочек производства и впаривания МВП шустрыми маркетологами лоховатым бузинесменам и бузинесвуменам
S>При этом старое поколение айтишников, которое знает, как еще можно по-другому, постепенно уходит, а новое поколение "яблочников", "амазонщиков" и "гугловцев" и прочих "индиго" чаще, чем нет, мыслят строго в категориях хайпа и сектанского копирования "образцов"
S>Вот перед тем, как сомкнуться веки последнего из могикан, хочется оставить миру напоминание о том, что есть хорошо и что есть плохо и что вообще есть
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Не моя мысль, кто-то вроде уже это высказывал, что процесс разработки стихийно или намеренно подстраивается под взаимоотношения с клиентом,а при долгом сотрудничестве даже определенный тип людей подбирается. По моей практике так и есть. Так что аджаил он не только внутри, но и снаружи и не каждому клиенту он подойдет.
Самый лучший способ довести что-то до абсурда, это применять это без обдумывания.
Лучше на основе бюрократических процедур.
Как и вышло с аджайлом. Сейчас уже не обьяснить, что аджаил родился совсем не таким, и
только благодаря припадочным рукойводителям он стал истеричным и шизофреничным
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, Qulac, Вы писали:
Q>По моей практике так и есть. Так что аджаил он не только внутри, но и снаружи и не каждому клиенту он подойдет.
И хвост виляет собакой. "Клиент хочет" как погоняло сраммастера. В конечном итоге, обычно, вместо хоть немного продуманной архитектуры — полный JIRAдец
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
Так ведь изменилась цель написания программ: раньше добавлялись новые возможности, теперь же выпускаются навязываются [job] security updates. Смысл "современных" подходов как раз в переливании из пустого в порожнее, в доении клиента. Когда вымрут могикане, появится "новая" каскадная методология, но без техзадания, типа "сделайте мне клон ..." или "переведите то, что есть, на ...".
Здравствуйте, velkin, Вы писали:
V>Для примера TDD, во время разработки мешает делать изменения в программе. Методологи очень любят всякие метафоры, вроде вонючий код. Ну так я тоже могу придумать не мало подобного трешака — использовать TDD это всё равно, что залить программу в бетон. То есть тесты нужны, но умение создавать их до программы доступно лишь профессионалам у которых низкий коэффицент выбора неправильных решений, которые придётся изменить переписав код.
...
Бетон по любому долбить придется. Поэтому купите себе, в хозяйство, нормальный отбойный молоток.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам? S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Да-да-да, помню помню эту зелёную траву.
На моей первой работе не было таск-трекера и системы контроля версий.
Зачем все эти костыли для настоящих ковбоев?
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
Думается, самый важный принцип — это KISS (Keep it simple, ...).
Но сам по себе он не очень ясен (слишком много кардинально РАЗНЫХ представлений о том, что есть "simple" и как его нужно "keep").
Ученым известен принцип "бритвы Оккама": "не создавать лишних сущностей без необходимости". Но программисты и системные архитекторы только этим и занимаются — создают сущности по необходимости.
Можно сформулировать такой важный принцип: при необходимости лучше создать сущность более низкого порядка, чем сущность более высокого порядка.
Описать все возможные "порядки" и их относительные "высоты" вряд ли возможно, но для практики достаточно интуитивного понимания.
Для наглядности несколько очевидных примеров:
* (новое) поле в (существующей) таблице БД — ниже порядком, чем (новая) таблица в БД
* (новая) папка для файлов исходников в (существующем) проекте — ниже порядком, чем (новый) проект
* (новая) сущность на любом уровне иерархии ниже порядком, чем (новый) уровень иерархии сущностей
Кажется, что современные программисты создают сущности самых высоких порядков (и сами эти порядки) абсолютно без напряга.
Компьютеры быстрые, справятся со всем.
К тому же, сущность более высокого порядка можно или продать дороже, или себя как её автора показать чуть получше (или хотя бы себе самому вообразить).
То, что и себестоимость этой сущности будет выше, оказывается неважным. Получается эффект, похожий на надувание пузыря.
А, может быть, всё проще: современные программисты недостаточно ленивы? (Или больше любят абстрактно-красивый и "правильный" код писать, чем задачи быстро решать?)
Я, конечно, пока сам молодой, но всё же напишу, может самому через 15 лет интересно будет прочитать.
У меня сейчас сформировался некий набор инструментов, которыми мне комфортно пользоваться и которыми я забиваю все гвозди. Я периодически пытаюсь что-то из них заменить, но пока что не получается, очень уж они хороши. В основном мои гвозди это серверные приложения с простым браузерным интерфейсом.
В качестве ЯП Java. Долго пробовал Kotlin, он хорош, но я немного разочаровался в векторе его развития, они начали, как better Java, что меня и подкупило, а сейчас они уже пошли в какую-то свою степь, Kotlin Native, corutines и прочее, мне всё это не нужно от слова совсем, в общем фокус у них ушёл с моих нужд, поэтому я вернулся назад к Java. Но он всё равно хорош и я его держу в загашнике.
В качестве платформы Tomcat. Раньше часто писал консольные приложения, в последнее время вообщё всё тупо веб-приложением делаю. Не скажу, что доволен томкатом, подозреваю, что коммерческие апп-серверы круче или может даже что-то вроде жбосса, в первую очередь хотелось бы мощного дэшборда, зачастую проблемы с мониторингом приложения. Но в целом жить можно. Зато жрёт мало и запускается относительно быстро.
В качестве библиотек: либо голые сервлеты, если совсем мало нужно, либо Spring MVC. Если к фронтэнду требований больших нет, то делаю серверный рендеринг с помощью Thymeleaf, а так Angular планирую использовать, но пока ещё таких проектов не было. Из интересного пробовал Wicket, два приложения на нём написал, но не очень доволен. Хотя тут сложный вопрос, для некоторых видов приложений он будет очень хорош, там, где куча состояния на сервере в сессии удобно хранится и где очень нужна компонентная модель. Это его две сильнейшие стороны.
В качестве доступа к базе MyBatis, как универсальное решение. Для простых случаев голый JDBC, для некоторых можно Hibernate, но в целом это для совсем уж дубового CRUD. Но Hibernate надо относительно хорошо знать, так просто подключить, пролистать туториал и пойти использовать не выйдет, скорей всего получится плохо. MyBatis мне не очень нравится, но ничего лучше я не нашёл. Хотелось бы более низкоуровневое решение.
Не нашёл подходящую библиотеку для генерации бинов, когда-нибудь я её таки напишу. Что-то вроде Google AutoValue но чуть по-другому. В целом мне нужна одна простая фича: чтобы поля могли быть неинициализированными и кидать исключение при вызове геттера. Ну и, естественно, чтобы оно всё работало со скоростью вручную написанного кода.
Что я пробовал и не понравилось:
Google Guava — иммутабельные коллекции. В теории штука хорошая, на практике вот это слово Immutable всё портит. ImmutableList l = ImmutableList.of(1, 2, 3). Очень длинно. Им бы сделать ImList и всё. Да, вот только из-за именования и не пользуюсь. Ну и ещё у них очень странная идея того, что null хранить в коллекции нельзя и они это не разрешают. А я порой храню и мне удобно.
@Nullable/@NotNull аннотации. Кстати и в котлине система типов с этими non-null типами мне не нравится. У меня никогда не было проблем с NullPointerException-ами, поэтому мне далека проблема, которую они пытаются решать, а вот неудобства от того, что надо ублажать компилятор, присутствуют повсеместно. Ну и, конечно, неразмеченные этими аннотациями примерно все Java-библиотеки. Почему не делают инструмент, который анализируя байткод сам сгенерирует все эти аннотации, я до сих пор не понимаю, задача-то тривиальная. Вон ребята с TypeScript натянули систему типов на JavaScript и не постремались сгенерить кучу аннотаций для существующих JavaScript-библиотек. Ситуация очень похожая.
Здравствуйте, L_G, Вы писали:
L_G>А, может быть, всё проще: современные программисты недостаточно ленивы? (Или больше любят абстрактно-красивый и "правильный" код писать, чем задачи быстро решать?)
Скорее склонны к сектанскому мышлению и карго-культу — если Фейсбук так делает, значит это хорошо
Раньше не было интернета, каждый думал сам. А теперь, наоборот, слишком лень думать — лучше на стаковерфлоу спросить и пока ждешь ответа на рсдн потрепаться
.
Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!
Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам? S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Напоминает страдания о здоровой натуральное еде пещерных людей, в противовес современной "искусственной"
Здравствуйте, sharpman, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>Напоминает страдания о здоровой натуральное еде пещерных людей, в противовес современной "искусственной"
S>Ты в макдаке питаешься? Может и детей там кормишь каждый день?
Выбирая между червяками из под камней и макдаком, я, разумеется, выберу макдак.
Точно, "карго-культ" тоже в голове крутился, но как-то упустил возможность присобачить его к своему высказыванию.
И еще одно объяснение: повлияло прогрессирующее разделение труда.
Если раньше один человек мог делать довольно крупные куски инфосистем, то нынче появились специальные должности, у которых в качестве основной должностной обязанности может быть прописано это самое "созидание сущностей". Не будут же попавшие на такую должность лица своей основной обязанностью пренебрегать!
Здравствуйте, velkin, Вы писали:
V>Читал книги про различные гибкие методологии, там авторы рассказывали как они к этому пришли. Сначала они делали всё "по учебнику", а потом у них в голове щёлкнуло, что они могут делать всё быстрее, так как знают все процессы разработки от начала и до конца.
И потом начинается — а как эта фича работает? А почему при изменениях X рухнул Y? А что у нас на проде?
Здравствуйте, sharpman, Вы писали:
S>И хвост виляет собакой. "Клиент хочет" как погоняло сраммастера. В конечном итоге, обычно, вместо хоть немного продуманной архитектуры — полный JIRAдец
Вообще-то хотелки заказчика и роль скраммастера никак не пересекаются.
Здравствуйте, L_G, Вы писали:
L_G>Можно сформулировать такой важный принцип: при необходимости лучше создать сущность более низкого порядка, чем сущность более высокого порядка.
Хороший принцип! А где ты его взял и где можно про него почитать?
Или может есть аналогии какие нибудь например из математики?
Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Современные подходы лучше, т.к. не отменяют "старые", а расширяют и дополняют, растягивая треугольник "быстро, дешево, качественно". Т.е. быстро и некачественно можно делать дешевле, ибо фреймворки. Для "дешево и качественно" появился опнсорс, ускоряющий тестирование. "быстро и качественно" тоже эволюционирует серьезными темпами.
Хайпожорство и поиск авторитетов вместо использования собственной головы — это возрастное и лечится только с опытом.
DP>Хороший принцип! А где ты его взял и где можно про него почитать?
Боюсь, что сам придумал, непосредственно в процессе написания того поста.
Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него).
Если создание любой сущности — зло, то (при необходимости совершить это действие, но возможности выбора в неких рамках) лучше совершить меньшее зло, нежели большее.
К мысли подтолкнула, среди прочего, работа с легаси-кодом с признаками массивного оверинжиниринга.
Здравствуйте, L_G, Вы писали:
DP>>Хороший принцип! А где ты его взял и где можно про него почитать?
L_G>Боюсь, что сам придумал, непосредственно в процессе написания того поста. L_G>Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него). L_G>Если создание любой сущности — зло, то (при необходимости совершить это действие, но возможности выбора в неких рамках) лучше совершить меньшее зло, нежели большее. L_G>К мысли подтолкнула, среди прочего, работа с легаси-кодом с признаками массивного оверинжиниринга.
Не создавать лишнюю функцию, фигачить все одну, чтобы не плодить сущности...
Здравствуйте, L_G, Вы писали:
DP>>Хороший принцип! А где ты его взял и где можно про него почитать?
L_G>Боюсь, что сам придумал, непосредственно в процессе написания того поста. L_G>Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него).
+1 да, наверно это Оккама
еще напоминает Дэвид Уилер "We can solve any problem by introducing an extra level of indirection." "... except for the problem of too many levels of indirection"
Или как его часто переиначивают "любую архитектурную проблему можно решить добавлением дополнительного слоя абстракции, кроме проблемы большого количества абстракций"
PJ>Не создавать лишнюю функцию, фигачить все одну, чтобы не плодить сущности...
Ты сам написал слово "лишнюю", и оно здесь ключевое.
Необходимость отдельной функции, в том числе, может определять принцип DRY. Also SRP, etc.
Еще, например, соблюдение принципа самодокументирующегося кода может привести к замене комментария в середине большой функции на выделение в отдельную функцию кода, к которому относился комментарий, и назначении этой функции такого имени, что комментарий становится излишним. Лично я —
за такой подход.
Здравствуйте, sharpman, Вы писали:
S>Самый лучший способ довести что-то до абсурда, это применять это без обдумывания. S>Лучше на основе бюрократических процедур.
S>Как и вышло с аджайлом. Сейчас уже не обьяснить, что аджаил родился совсем не таким, и S>только благодаря припадочным рукойводителям он стал истеричным и шизофреничным
Это да. Вот, например, в предыдущей конторе, где я работал был у нас проект с одним из клиентов.
Сначала взялось за этот проект прогрессивное поколение со своими аджайлами, скрамами, хермесами и прочими модными словечками.
Сначала одна команда помыкалась — все в говне оказалось, потом другая команда пришла и сказала, что предыдущие забыла использовать TOGAF, поэтому все так плохо выглядит.
Ладно, взялись они и тоже все в итоге сдохло.
Потом пришла команда со "старичками", которые все эти модные процессы и словечки не знали. Сделали все как надо и все заработало как надо.
Вот к сожалению это и получается так, что понапридумывали умные дядьки хорошие процесса, а всякие эффективные менеджеры их переложили под себя совершенно не понимая, что они делают и как.
В итоге полный хаос и заваленные проекты. А если проекты не завалили, то зачастую, потому что люди, которые "внизу" работали не по процессами, которые им были предписаны, а просто нормально работали.
Потом менеджерам премии за успешный проект, а тем кто ниже — "нихера".
Здравствуйте, sharpman, Вы писали:
L>>Странно. TDD, который мне доводилось использовать, серьезно помогает делать изменения в программе. S>Ты, наверное, путаешь с юнит-тестами
), только без менеджеров, а сами. 
