Pull to refresh
17

User

0,2
Rating
3
Subscribers
Send message

Что такое правильный ?

И цель то не создать новое, а тупо зафиксировать текущее положение вещей, чтобы любое изменение было зафиксировано.

Положим у нас есть

def sum(a,b): return a-b

Пишем тест, который проверяет там sum(1,1)==0

Зафиксировали текущее положение.

Далее, скажем, поняли мы, что надо исправить. Изменяем “-“ на “+” и получаем падающие тесты.

Без тестов мы бы не знали вообще как изменение влияет !

Ну и в конце обновляем тесты: sum(1,1)==2.

Я не утверждаю, что модельки сделают всё идеально за нас

Зато помогают здорово экономить время на некоторых вещах.

Это смотря какую работу.

Например простую работу как покрыть код тестами моделька делает на ура.

Берём старый код за пару минут получаем тесты. Гарантировано находятся баги.

На и дальше можно развивать код гораздо спокойнее.

Увы мир C++ настолько разнообразен , что в 2026 лучше с нуля учить Rust или что угодно не C++.

У нас есть проекты где до сих пор C++17, есть где запрет исключений, есть где запрет RTTI, есть где запрет ranges, лямбда и т.д.

Вопрос в том стоит ли тратить своё время на это сегодня когда модельки худо бедно сделают работу лучше чем кто-то с небольшим опытом плюсов.

У VSCode есть приятная возможность внедрить в веб сайты.

А Zed может таким похвастаться ?

Проблема и преимущество goto это возможность прыгнуть куда угодно, а не только выйти из цикла.

А здесь мы ограничиваем себя и упрощаем понимание кода.

Это в мире где все обновились.

А на деле только вот сейчас работают над переходом на 17 с 11.

Так что Kotlin вари таком раскладе здоров облегчает жизнь.

Энтерпрайзы именно так и работают по этой схеме и ничего ведь.

Корпорации только богатеют хотя изнутри мало кто действительно делает что-то существенное наперекор системе.

Или пойми ещё кто правильно ведёт работу.

А какие долгосрочные последствия будут?

Возьмём к примеру сотрудник нашёл проблему и донёс до начальства.

Начальство говорит не нужно ничего делать это лишние риски.

Далее проблема появляется у клиента и начальство просит разобраться.

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

Далее сотрудник поднимает тему, что надо бы таки починить и снова получает негативный отказ и требование начальства «заниматься своим делом».

Итого более сотрудник ничего не будет извещать заранее ведь это влияет на его отношения с начальством и бонусы.

Другие коллеги видя как обстоят дела так же перестают проявлять инициативу.

Зато начальник доволен всеми и все довольны им.

Замечательно выходит :)

А проблема ли это на самом деле ?

Зачем нужны конфликтные работники если можно иметь без конфликтных и спокойно работать.

Можно и желательно добавить линтеры с ограничением any.

https://typescript-eslint.io/blog/avoiding-anys/

Говорите как-будто РФ эта единственная страна с таким мышлением .

https://habr.com/ru/amp/publications/1022444/

Э.. как бы на этом построен весь C++.
Порядок имеет значение.
Добавляем перегрузку и получаем другие инварианты.

#include <string>
#include <type_traits>

// First overload
int f(int a) { return a; }

template<typename T>
concept can_call_f = requires {
    f(T{});
};

void before() {
    static_assert( can_call_f<int>);
    static_assert(!can_call_f<std::string>);

    f(1);
}

// New overload
std::string f(std::string c) { return c; }

template<typename T>
concept can_call_f_2 = requires {
    f(T{});
};

void after() {
    static_assert(can_call_f_2<int>);
    static_assert(can_call_f_2<std::string>);

    f("a");
}

int main()
{
}

Ну то есть подход как в Rust только без удобств.

И даже там в итоге не все так просто и многие приходят к решению упростить через https://docs.rs/anyhow

Сегодня можно вместо Result вернуть std::expected.

Это удобно когда вы хотите раскидать задачу по множеству агентов.

Где каждый живет в своем окружении.

В этом случае курсор становится заметным накладным расходом и хочется сэкономить.

Вот и получаем CLI подход.

Промахнулся кнопкой +1 :(

Так и есть. Не любая ошибка это катастрофа.

Скажем пришел неправильный запрос от клиента это ведь не катастрофа.

А кто сказал, что не ревьюют?

Одна модель пишет код другая модель проводит ревью.

Ну да, в какой-то степени нет такого, что сидел долго, чтобы найти как починить и получил озарение.

С другой стороны получаем возможность решать задачи сложнее и быстрее.

У управляющего, если пришёл из разработки, тоже руки чешутся писать код и некоторые уходят обратно в разработку и тех-лидов.

В ленту вам обратный опыт.

Как раз я вижу, что развиваюсь и при чём существенно.

Раньше я даже не думал лезть в девопс со своими советами.

А сейчас с помощью моделей делаю работу которую сами девопсы иногда не в силах сделать сами.

Параллельно к этому и учусь новым инструментам. Ведь прелесть моделей это не только формы клепать, а возможность спросить почему так сделано и что это делает.

Также я начал большой проект по перестройке инфраструктуры которая сделана через пень-колоду.

Лучшие умы сдались давно, а с моеделчми дал задание и оно пол дня работает на результат.

Проверил, не достаточно хорошо и понятно ещё пол дня поработало и выдало идею.

Смотришь на изменения если подходят хорошо, правишь где надо. Не подходит дальше пусть думает.

Действительно чем это лучше того же Zig?

Также мы тут получаем все недостатки Go с interface{}. А точно ли оно надо ?;)

1
23 ...

Information

Rating
3,058-th
Registered
Activity