Rust 1.7

Ну вот, вырвал фразу из контекста XD

вырвал фразу из контекста XD

Поставил фразу в контекст. Хорошие советы давать легко, а следовать им трудно и не всегда возможно. Поэтому нужно уметь разгребать последствия.

Хорошие советы

Не все советы одинаково хороши:

нужно быть богатым и здоровым.

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

Мотавация дающих эти советы гнилая изначально. Мотивация тех, кто их не соблюдает разная.

код нужно постоянно поддерживать во вменяемом сотоянии

Мотивация тех, кто дает такой совет разная. Мотивация тех, кто его не соблюдает всегда гнилая.

И да, сдается мне, что зависимость от рефакторинга есть последствия ООП гойловного моска. Вот цитата Степанова на эту тему:

Да ладно, я вот на F# генератор Rust кода для обертки FFI интерфейса писал. Никаких объектов, кроме .NET-овских конечно, и всё-равно пришлось рефакторить. Выбранная структура потока данных оказалась не слишком подходящей для задачи.

Выбранная структура потока данных оказалась не слишком подходящей для задачи.

А был ли рефакторинг?

А был ли рефакторинг?

Рефакторинг - изменение внутренней структуры кода, без изменения внешних интерфейсов.

Был.

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

Пфф... а советы «код нужно постоянно поддерживать во вменяемом сотоянии» дают менеджеры, когда давят на сознательность рядовых кодеров.

Мотивация тех, кто дает такой совет разная

Да пофиг на мотивацию. Обоим советам не всегда возможно следовать.

Это не большинство случаев.

Ну, некоторые не следуют советам «не стрелять себе в башку», но это не значит, что нельзя отговаривать их от их намерений.

Я хочу донести мысль о том, что код нужно постоянно поддерживать во вменяемом сотоянии, чтобы не приходилось его переписывать.

Ну и вот это «поддержание» как называется? Вот добавляю я фичу и вижу, что можно или сделать костыльно воткнуть или заодно поправить существующий код. Как по мне, это рефакторинг и есть.

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

Опять же, если в проекте появились костыли и «говнокод» (это может быть сознательным решением), то что ты предлагаешь? Бежать оттуда, потому что «рефакторинг делать уже поздно»?

И да, сдается мне, что зависимость от рефакторинга есть последствия ООП гойловного моска.

Ну-ну. Программы в процедурном, функциональном и прочих стилях магическим образом защищены от неправильных решений и неопытных программистов?

дают менеджеры, когда давят на сознательность
дают менеджеры
менеджеры

Блин! Опять палюсь!

Программы в процедурном, функциональном и прочих стилях магическим образом защищены от

Нет, но вероятность меньше, гораздо, ибо нет каргокульта о том, что «все есть объект»...

Вот добавляю я фичу и вижу, что можно или сделать костыльно воткнуть или заодно поправить существующий код. Как по мне, это рефакторинг и есть.
заодно поправить

А без фраз-детекторов можешь про рефакторинг сказать?

ибо нет каргокульта о том, что «все есть объект»...

По моему, этот культ есть, в основном, в голове у тех, кто всем рассказывает какое ООП плохое. Ну и у совсем уж контуженных типа анонимуса с Ио.

А без фраз-детекторов можешь про рефакторинг сказать?

Я тебя опять не понимаю.

Программы в процедурном, функциональном и прочих стилях магическим образом защищены от

Нет, но вероятность меньше, гораздо, ибо нет каргокульта о том, что «все есть объект»...

Слушай, а ты вероятности и подавляющие случаи извлекаешь из собственного опыта или есть какие-то исследования «ООП повышает вероятность рефакторинга»?

Нет, но вероятность меньше, гораздо, ибо нет каргокульта о том, что «все есть объект»

Действительно. Вот взять, например, типичный проект на php4. Никакого рефакторинга не нужно, просто берешь и переписываешь. KISS!

По моему, этот культ есть, в основном, в голове у тех, кто всем рассказывает какое ООП плохое.

https://habrahabr.ru/post/169601/

Си позволяет легко выстрелить себе в ногу; с C++ это сделать сложнее, но, когда вы это делаете, вы отстреливаете себе ногу целиком. (C)МёртвыйСтраус

Я тебя опять не понимаю.

рефакторинг
заодно поправить

Вот почему рядом со словом рефакторинг почти всегда возникают словосочетания, содержащие «исправить», «поправить», а ингода даже «сделать из говна конфетку»?

Это все фразы детекторы, как «умение разбираться в чужом коде», «фулл-стэк разработчик», и т.д.

https://habrahabr.ru/post/169601/

И? К чему это? Ты продолжаешь разговаривать сам с собой.

Это все фразы детекторы, как «умение разбираться в чужом коде», «фулл-стэк разработчик», и т.д.

Детекторы чего?

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

Давай ты нормально мысль сформулируешь

окей

чигур.жпг

Я считаю, что рефакторинг возникает там где:

а) есть каргокульт ООП;
б) есть плохой дизайн;
в) есть костыли/велосипеды с квадратными колесами/баги;
г) есть всё вместе и много!

ООП стимулирует к это всё, Степанов не зря сказал, что ООП-программисты обречены на постоянный рефакторинг, достаточно проанализировать «запахи кода» с сайта про него же:

Длинный метод

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

В результате получаем ситуацию, когда один алгоритм оказывается разбит по куче методов разных классов, но зато каждый метод < 10 строк, да. Об этом сказала Адель Голдберг:

https://habrahabr.ru/post/169601/

В SmallTalk все происходит где-то еще

А что начинается, когда надо реализовывать не алгоритмы, а протоколлы! УУххх!!!

Большой класс

Классы редко бывают большими изначально. Но со временем постепенно многие из них «раздуваются» в связи с развитием программы.

Тут и так все понятно.

Операторы switch

Ну не нравятся они ООП-шникам, потому что приводят к длинным методам...

Альтернативные классы с разными интерфейсами

Программист, который создал один из классов, скорей всего, не знал о том, что в программе уже существует аналогичный по функциям класс.

А почему? А потому, что наплодили ТЫСЯЧИ классов, зато все маленькие и методы у всех короткие, ЛОЛ!

Цепочка вызовов

Вы видите в коде цепочки вызовов вроде такой $a->b()->c()->d()

Причина та же.

То есть попытка ДЕКОМПОЗИРОВАТЬ задачу на кучу МАЛЕНЬКИХ классов с КОРОТКИМИ методами приводит к созданию БОЛЬШОГО КОЛИЧЕСТВА [лишних] сущностей, часть из которых дублирует друг-друга, и в которой упаришься разбираться...

Чтобы разобраться нужно что и убрать дубли нужно что? Правильно, рефакторинг!

А потом добавят еще сущностей и будет следующий рефакторинг.

А потом кто-то уйдет из проекта, и надо будет понять, как это все работает, и...

А потом...

Третий закон диалектики работает безотказно знаете ли!

окей

Вроде, есть и логичные мысли, но в целом похоже на бред. B общем, понятно, что для тебя «рефакторинг» является чем-то ужасным. Ну ок.

Я считаю, что рефакторинг возникает там где:
в) есть костыли/велосипеды с квадратными колесами/баги;

Баги есть везде.

Я считаю, что рефакторинг возникает там где:

Какой бред. Ты правда менеджер? Необходимость рефакторинга возникает там, где при выборе «сделать костыльно за N ресурсов» и «сделать качественно за M ресурсов» (N < M) выбирают первый вариант. ООП или нет - вообще неважно.

Читай вдумчиво: https://en.wikipedia.org/wiki/Technical_debt

Колобок, ну ты будто из секты сбежал. Смолтоком и Фаулером пытали? Сочувствую, но вся эта муть ни разу не догма, даже в кровавом тырпрайзе.

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

А что начинается, когда надо реализовывать не алгоритмы, а протоколлы! УУххх!!!

а что начинается, собственно? метаклассы ? аспекты? композиционное программирование в стиле Zonnon и «активностей» активных объектов?

расскажи — интересно же.

вон в объектном си, например, «протоколами» и категориями интерфейсы обозвали просто-напросто...

Чтобы разобраться нужно что и убрать дубли нужно что? Правильно, рефакторинг!

А потом добавят еще сущностей и будет следующий рефакторинг.

А потом кто-то уйдет из проекта, и надо будет понять, как это все работает, и...

А потом...

а потом можно на прологе написать, пусть он автоматически выводит все эти цепочки

Цепочка вызовов

Вы видите в коде цепочки вызовов вроде такой $a->b()->c()->d()

man linear logic

Читай вдумчиво

Читаю:

1.Берем контору, которая делает софт.
2.Идентифицируем риски, относящиеся к:технологии(Lack of building loosely coupled components, Lack of a test suite, Lack of documentation, Parallel development, Lack of alignment to standards), УЧР(Lack of knowledge, Poor technological leadership), Упр. коммуникациями(Lack of collaboration), Упр. временем(Business pressures), Упр. изменениями(Delayed refactoring, Last minute specification changes).
3.Придумываем страшилку для лохов ЦА (Lack of process or understanding).
4.Придумываем новый мем ньюфагов баззворд (Technical debt).
5.Добро пожаловать на тренинг личностного роста коучинг по Technical debt, сынок.
6.??????
7.ГЕШЕФТ!!!

Халявщики, хоть бы диаграмму Ишикавы построили...

ООП или нет - вообще неважно.

Ошибаешься. ООП — подход, который крайне затрудняет управление измемениями. В результате применения ООП получается архитектура, в которой алгоритмы и данные размазаны по большому количеству искусственно созданных сущностей (классов), поэтому нужно больше классов богу классов, и появляются

фреймворки, компоненты, аспекты, сервисы (которые, похоже, любопытным образом вернули нас к процедурному программированию!)

Уверен, что многие шаблоны проектирования и идеи (такие как посетитель и внедрение зависимости) — всего лишь костыли, которые исчезнут после реализации механизма контекстов в ООЯП.

(C)Oscar Nierstrasz

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

Эту проблему ООП пытаются решить за счет рефакторинга, но прикол в том, что изменения, вносимые в код при рефакторинге в ООП-стиле затрудняют дальнейшие изменения, что опять приводит к необходимости рефакторинга...

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

Таким образом сегодня в софто-индустрии сложился кризис (I закон диалектики): с одной стороны бизнес-среда требует управления рисками и изменениями (и появляются гибкие методологии УП), а с другой, там главенствуют ООП и ООЯП:С++/С#/Java/PHP/...

Дальше должны сработать II и III законы диалектики и будем ждать следующего кризиса...

З.Ы.: в моем прошлом посте должна была быть ссылка на II закон... опять я обкакунькался...

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

но надо ходить по иерархии или хуже, простыне функций, чтобы поменять один (абстракный) тип данных

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

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

«все критяне — лжецы» является парадоксом с «дурной бесконечностью» только в одном случае: говорящий это  — критянин.

в другом случае — эти противоречия не уходят на бесконечность тавтологий, в виде инвариантов «то есть то», «а тождественно а», а показывают нам аномалии, — альтернативные логики, способные преодолеть это противоречниие (кажущееся, с одной точки зрения и логики — но отсутствующее и мнимое с другой.

например, переходом от логики простой к интуиционистской, конструктивистской, линейной (в смысле linear logic) или каких-то многозначных модальных логики типа семантик Крипке, нечёткой логики, многозначной логики и т.п.

различай карту и территорию. карта нужна «картостроителям» (c) progStone только чтобы сверить наши карты, а не как догма или ритуал для «паковщиков» написано же — здесь могут водиться драконы, а нетути ни драконов, ни антиподов с песьими головами: скандалы, интриги, расследования!!!

то есть — метакарта это способ изменить логику, расширением в металогику, сохраняя основные инварианты, но упрощая точку зрения (и избыточную сложность, выбором подходящей точки зрения).

изменение логик металогиками, от программы к метасистеме через суперкомпиляцию.

а ты говоришь — рефакторинг, ога.

все эти тайпклассы или зависимые типы или там линейные типы или монады (тоже линейно же, с нулями и сложением, с единицами и умножением как моноид моноидов тоже моноид) — это всё ногами оттуда, в более другую логику, или там металогику или там теоркат жывотворящий с объектами, диаграммами и категориями (для облегчения трассировки, прослеживаемости, управления изменениями и т.п.).

не важно по какому пути, в какой логике пройдут вычисления — если диаграммы коммутативны же, результат не изменится (могут правда измениться ресурсы, более оптимально или менее).

Таким образом сегодня в софто-индустрии сложился кризис (I закон диалектики):

Дальше должны сработать II и III законы диалектики и будем ждать следующего кризиса...

почему, собственно, диалектики?

давай троичную или любую другую многозначную логику — тоже развитие же.

Халявщики, хоть бы диаграмму Ишикавы построили...

а показатели с оценками они откуда возьмут? тоже с потолка?

с другой, там главенствуют ООП и ООЯП:С++/С#/Java/PHP/...

но это всё не важно, пока титаник плывёт и есть теория «большего дурака» на бирже, которому это всё затем перепродадут. что там у него внутре, разбираться никто не будет — и так влом же.

главное, чтобы было чего перепродавать.

Завязывайте с многозначными логиками в этой теме.

Уверен, что многие шаблоны проектирования и идеи (такие как посетитель и внедрение зависимости) — всего лишь костыли, которые исчезнут после реализации механизма контекстов в ООЯП.

(C)Oscar Nierstrasz

вопрос: а чего этим «контекстам» не хватает от трейтов ржавичины, например?

с какими-нибудь более хитрыми, зависимыми типами?

Раст - это как раз одна из попыток разрешить противоречие...

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

Дальше появятся более «вылизанные» ЯП...

Раст - это как раз одна из попыток разрешить противоречие...

Забавно, что авторы компилятора на Rust говорят, что пора выплачивать technical debt.

пора выплачивать technical debt.

Это модно...

Но заметь, Классов там нет! Во всяком случае пока. И лучше, если не будет.

ЧТД: для ООП программирования классы не нужны. хватит и тайпклассов :)))

Но заметь, Классов там нет!

Классов нет, а долг есть. Фантастика.

Я в свое время после первого взгляда на java при выходе второй версии на нее смотреть лет на 10 перестал. Правда дальше они исправились.

Посмеялся. Пиши ещё.

Проще пойти от обратного:
рефакторинга не возникнет либо в навсегда заброшенном, либо в идеально написанном коде.
С первым случаем всё ясно.
Второй случай невозможен т.к. нельзя предугадать, что появится в будущем и как это повлияет на развитие технологий, в окружении которых будет работать твой код.
В таких условиях, чтобы «выживать» нужно постоянно идти в ногу со временем — добавлять, изменять что-то, фиксить…
Так со временем код превращается в мешанину; разнообразный функционал поверх устаревшего кода — рак убивающий проект.

От него спасает только рефакторинг.

В результате применения ООП получается архитектура, в которой алгоритмы и данные размазаны по большому количеству искусственно созданных сущностей (классов), поэтому нужно больше классов богу классов, и появляются

Такая архитектура появляется потому что никто не делает рефакторинг.
Пришлось мне однажды работать над проектом в котором класс обёртка над обёрткой над сервисом … никакой абстракции, никакой документации, разные отступы и окончания линий и т.д.
Ну нереально в этом всём разобраться.
Я грамотно рассчитал что будет гораздо быстрее это всё отрефакторить, но не там то было, меня остановили со словами «БОЖИ НИ В КОЕМ СЛУЧАЕ НИ ДЕЛАЙ ЭТОГО НАМ ЖИ ПОТОМ ПРИВЫКАТЬ ПРИДЁТСЯ НАЛЕПИ ЕЩЁ СВЕРХУ КЛАСОВ И ТАК САЙДЁТ».
В итоге все потратили время, а сделали почти ничего.
Вся суть штабильности

Так со временем код превращается в мешанину; разнообразный функционал поверх устаревшего кода — рак убивающий проект.

Согласен, сам недавно код планировщика в BuguRTOS приводил в порядок.

От него спасает только рефакторинг.

Это не был чистый рефакторинг, там еще и оптимизация под размер была...

Второй случай невозможен

Идеального ничего не бывает, согласен.

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

Ну там компонентный подход, внедрение зависимостей всякое, не? Зачем сразу рефакторинг?

Такая архитектура появляется потому что никто не делает рефакторинг.

А что было бы если бы его делали другие люди?

класс обёртка над обёрткой над сервисом … никакой абстракции, никакой документации, разные отступы и окончания линий и т.д.
Ну нереально в этом всём разобраться.

меня остановили со словами «БОЖИ НИ В КОЕМ СЛУЧАЕ НИ ДЕЛАЙ ЭТОГО НАМ ЖИ ПОТОМ ПРИВЫКАТЬ ПРИДЁТСЯ НАЛЕПИ ЕЩЁ СВЕРХУ КЛАСОВ И ТАК САЙДЁТ».

Нe что тут сказать, видимо боялись, что при вырывании очередной карты домик схлопнется...

В итоге все потратили время, а сделали почти ничего.

Логично.

Ну там компонентный подход, внедрение зависимостей всякое, не? Зачем сразу рефакторинг?

Затем, что всё сразу предусмотреть сложно. И как показывает (моя) практика - не (всегда) стоит городить всякий оверинжиниринг с надеждой, что он поможет «расширяемости». Зачастую наоборот - расширять придётся не в ту сторону, в какую ожидалось, и это всё будет только мешать. И уж точно будет увеличивать (не факт что полезный) объём кода, затрудняя чтение и понимание. Во многих случаях (ну да, тут сильно зависит от ситуации), лучше написать без оглядки на потенциальные изменения - это будет быстрее и ведь даже не факт, что придётся что-то менять.

И ты говоришь «зачем сразу рефакторинг» как будто хуже этого сложно что-то придумать. Но рефакторинг - это «сделать код лучше». Чем это плохо? Плохим может быть то, что к нему приходится часто прибегать, но это ведь уже другой вопрос.

Затем, что всё сразу предусмотреть сложно.

Согласен.

И как показывает (моя) практика - не (всегда) стоит городить всякий оверинжиниринг с надеждой, что он поможет «расширяемости». Зачастую наоборот - расширять придётся не в ту сторону, в какую ожидалось, и это всё будет только мешать.

Ну, создателям UNIX, например, хватило мозгов не выпиливать, возможность объединения большого количества простых программ в конвейеры пайпами (а потом сокетами и dbus-ом, наконец) c помощью простого шелл-скрипта/конфиг-файла.

Хотя это те самые люди, которые придумали КИСС и «тебе это не понадобится».

И они сделали такую фичу задолго до того, как это стало мейнстримом.

Плохим может быть то, что к нему приходится часто прибегать, но это ведь уже другой вопрос.

Абсолютно согласен. Если код приходится постоянно переписывать без добавления новых возможностей отстрелить себе ногу, то что-то внутри черепной коробки его создателя явно не так.

Ну там компонентный подход, внедрение зависимостей всякое, не? Зачем сразу рефакторинг?

В каком смысле «внедрение зависимостей»? Я не понимаю.

Нe что тут сказать, видимо боялись, что при вырывании очередной карты домик схлопнется...

Даже если схлопнется — построю новый, всёравно лучше чем пытаться сверху наложить подпирая костылями.

Ну там компонентный подход, внедрение зависимостей всякое, не? Зачем сразу рефакторинг?

Интересно. По-твоему, «компонентный подход» и «внедрение зависимостей» не могут быть рефакторингом?

В каком смысле «внедрение зависимостей»?

Dependency injection.

Даже если схлопнется — построю новый, всёравно лучше чем пытаться сверху наложить подпирая костылями.

Может и лучше, но процесс строительства может затянуться.

Dependency injection.

Дык оно ж для облегчения Unit тестирования вроде, для чтения кода человеком наоборот создаёт дополнительные трудности.
Или я неправ?

процесс строительства может затянуться.

Согласен, есть такой риск.
Но в моём случае времени было дофига + оптимизация не помешала бы (это было приложения под Android и оно занимало много места + тупило).
Никто не хотел разбираться в том, что я там перепишу — так и сказали

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

Так ведь довод был за расширяемость. И довод не мой, спорить не буду. (:

Никто не хотел разбираться в том, что я там перепишу — так и сказали

Дык, я их не защищаю, просто ради объективности упомянул, что причины городить костыли вполне себе бывают. Другое дело, что в идеале с техническим долгом стоит бороться.

Так ведь довод был за расширяемость.

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

Говорю же - спорить не буду. Можешь ещё в недавнюю тему заглянуть:

IoC в С++