Архитектура ПО

olijen | 17 марта 26 | 22 | 83

Что нужно знать бизнесу о современной ИИ-разработке и тестировании

Я видел много раз, как бизнес пытался вайбкодить сам или нанимал вчерашних студентов без опыта реального программировани и проектирования для написания приложений дёшево и быстро. Что может пойти нетак? Больше не надо знать программирование - говоришь на своёём языке, ИИ тебе всё пишет, можно даже попросить его покрыть текстами и сделать всё в лучших практиках архитектуры... Так ведь? Или нет? =) Те, кто писал что-то по сложнее мини-парсера или простенькие интеграции (которые вообще можно найти бесплатно и не пистаь) - понимают, что халява заканчивается быстро. Как только база кода вырастает, ИИ начинает галюцинировать, дублировать код, создавать бредовые бизнес-процессы, путаться, и чем больше ты пишешь ему "нет, сделай нормально, сделай хорошо", тем хуже он делает. Знакомо? Обсудим, как писать код быстрее и дешевле, но при этом минимизировать количество седых волос, мертвых нейронов и дофаминовых ям.

olijen | 16 июля 20 | 44 | 75

Грызём горло за операционные системы: Linux vs Windows vs MacOS

olijen | 16 июля 20 | 52 | 52

Люди изобретают, машины работают

olijen | 16 июля 20 | 37 | 53

Можно ли автоматизировать установку и масштабирование проекта?

olijen | 16 июля 20 | 59 | 47

Можно ли автоматизировать работу менеджера?

olijen | 16 июля 20 | 22 | 88

Что такое DDD и почему бизнес-ориентированное проектирование опасно?

olijen | 02 августа 20 | 12 | 17

Нефункциональные требования, о которых все забывают и проваливают проект

Конечно, описать интерфейс, создать дизайн, описать функции системы в ТЗ - это уже большой и важный шаг. Но к сожелению этого не достаточно для того, чтобы иметь уверенность, что система будет работать согласно ожиданиям. Более того, что если я Вам скажу, что как бы хорошо Вы не описывали функциональность системы, шанс того что проект будет провален достаточно высок? Для того, чтобы иметь уверенность в будущем проекта и даже получить документально-подтвержденные гарантии нужно определить НЕфункциональные требования к системе, требования, которые определят минимальное качество, которого будет достаточно, чтобы проект выполнил свою цель.

olijen | 16 июля 20 | 48 | 47

Гибкость против простоты. Почему нужно чем то жертвовать.

olijen | 16 июля 20 | 68 | 77

Что делает архитектор для повышения прибыли компании?

olijen | 16 июля 20 | 27 | 18

Логика, физика, статика, динамика и не только

olijen | 16 июля 20 | 75 | 89

Причинно-следственная связь в моделировании бизнес-продукта

olijen | 16 июля 20 | 25 | 54

Проектирование архитектуры - принятие ключевых решений

olijen | 11 августа 20 | 88 | 32

Почему детальный анализ конкурентов может угробить Вашу компанию

Нет, ну конечно же анализируйте, конечно же это очень важно. Но в данной статье речь пойдёт именно о навязчивом анализе. Будем приводить пример из реальной жизни про анализ конкурентов, но это так же касается чересчур усердного анализа клиентов или технологий, например. Суть в том, что к нам обратился клиент, который очень сильно интересовался конкурентами, хотел всё о них знать, хотел изучить их вдоль и поперек и искренне верил, что это важный вопрос, который приведет компанию к успеху. "А давайте проанализируем еще 10 конкурентов?", "А почему у всех разные технологии?" А почему у них Java?", "А может нам на Node разработать?", "А почему prom.ua на Python?", "Может на CMS сделаем? Или конструкторе?". И сотня различных других вопросов. И это нормально, любой директор или собственник имеет право переживать за то, что бы не быть хуже конкурентов. Однако на данный момент мы уже собрали множество информации о конкурентах, но совсем не продвинулись в другом критически-важном анализе...

olijen | 16 июля 20 | 55 | 57

Что нужно знать бизнесу о современной ИИ-разработке и тестировании

Грызём горло за операционные системы: Linux vs Windows vs MacOS

Люди изобретают, машины работают

Можно ли автоматизировать установку и масштабирование проекта?

Можно ли автоматизировать работу менеджера?

Что такое DDD и почему бизнес-ориентированное проектирование опасно?

Нефункциональные требования, о которых все забывают и проваливают проект

Гибкость против простоты. Почему нужно чем то жертвовать.

Что делает архитектор для повышения прибыли компании?

Логика, физика, статика, динамика и не только

Причинно-следственная связь в моделировании бизнес-продукта

Проектирование архитектуры - принятие ключевых решений

Почему детальный анализ конкурентов может угробить Вашу компанию

Сложность мира, Моделирование, Модульность

О сложности мира, о взаимосвязанности составляющих.

Можно ли автоматизировать тестирование проекта?

Можно ли автоматизировать работу программиста?

Требования к качеству системы. Перечень и описание.

Самописные проекты - это хорошо или плохо?

Что делает архитектор для продвижения стартапаи нужен ли он там вообще?

Нужно ли бизнесу документация и UML? Если нет - то почему.

Ограничения распределенной системы, CUP теорема

Про производные труда, платформы SAAS и будущее систем