продолжая беседу

[juan_gandhi]

Т.к. есть такое европейское мнение, что рефакторинг - это метросексуальный аджальный метод продажи навоза юзерам, то я вдруг задумался - а что в Европе делают, когда их хакают и информацию воруют? Ну понятно, против воровства в Европе есть законы, например, GDPR; а в Швейцарии так даже масс шутинги запрещены (это мне швейцарцы когда-то сказали); но вот если случилось, так что тогда? Компьютеры сжигают на свалке, покупают новые, и пишут для них новые программы?

Ведь, я слышал, в Европе сначала на Z-notations и на Rational Rose весь дизайн правильно напишут, так что европейская программа не может быть неправильной, так что и рефакторить там нечего. Она совершенна.

И вот если она сломалась, то чо. Неужели с нуля переписывают?

Тесты-то понятное дело что не нужны; программист выполняет приказ менеджера, а менеджер не может ошибаться; и только плохой программист пишет код с ошибками. Немецкий код работает везде и без ошибок. Ой, тут сразу вспоминается Энигма, и три ушлых поляка, которые ее кракнули как раз перед Второй Мировой. 

Comments

[1master]

Ну вот у них чего-нибудь случается и они пишут очередной GDPR, главным солюшеном к которому являются всплывающие на всех сайтах плашки "мы используем куки, соглашайтесь"

[perdakot]

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

[sassa_nf]

(I do get your jest, but can't help to expand on it)

No, not of correctness, but only that the corresponding theorem is proven.

Example:

Function a: List -> b: List sorts list a, if b_i <= b_(i+1) for all i.

Then functions

duh _ = []

duh2 xs = [head xs | _ <- xs]

clearly satisfy that theorem.

So one needs to start with the correct theorem involving a proposition that the output list is necessarily a permutation of the input list. How does one prove the "correctness" of the theorem?

[bamalip]

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

[sassa_nf]

:) звичайно!

і проміжок між "треба відсортувати" (постановкою ТЗ) та записом у вигляді теореми.

[caztd]

Не знаю как в других европах, а у нас дизайн рисуют на whiteboard'е, а потом на мобильник фотографируют и картинку в репо кидают. Ха-ха.

А недавно вот я сам наблюдал как чел на конфе дизайн в пэйнте лайф рисовал. Да, прям вот так, прямоугольничками и текстом. Architect lead, кстати.

Кстати да, EA у нас тоже юзают.. те же люди, которые весь код в виме пишут. Это наверное правильные программисты.

[vit_r]

Я знаю только несколько групп в Германии, которые генерируют из моделей. (Кстати, не на Розе, потому что это дерьмо ужасное) Причём, в основном это структурное программирование. С объектно ориентированным стопроцентной генерации ни у кого нет, а xtUML в Германии вообще не известен.

В случае изменений это называется не рефакторингом, а "исправлением ошибок модели" или "внесением новых требований".

И вот если она сломалась, то чо.

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

[juan_gandhi]

Структурное! Рехнуться можно.

Насчет педали газа - у Тойоты пластмассовая штучка блокировала эту педаль.

[vit_r]

Легенду о коврике мы все слышали. Только этот ужал люди изнутри видели. Там, даже, watchdog отсутствует.

А какой подход лучше, зависит от задач. Многое прекрасно решается структурным подходом. Особенно, если в код люди практически не заглядывают, всё делают на уровне моделей.

[juan_gandhi]

Вы точно программист?

[ded_maxim]

Не-не, в Тойоте использовали рекурсию в embedded safety-critical коде.

Рекурсию, Карл!

В общем, переполнение стека, вот это вот все.

https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf

[snowps]

Нормально написанный код действительно редко нуждается в рефакторинге. Самый лучший пример - эмбеддед софт в технике японских производителей и тех же немцев. Нельзя его сравнивать с тем, как пишут в bay area на Скале или Джаве - это совершенно разные категории программирования и если использовать методы модных программистстких тенденций в эмбеддед софте, то домашняя техника и автомобили просто не будут нормально работать. Например версии всех прошивок в аудиовидеотехнике Sony или фото-видеотехнике Canon почти никогда не переваливают за номер версии 1.00, и не потому, что производители бросают свои товарные линейки, а потому, что в этом нет необходимости - код is rock stable. Этого невозможно добиться тогда, когда программирование в эдаком прихиппованном стиле считается фаном (хренак-хренак и в продакшн), а не трудной и кропотливой работой (каковой оно на самом деле и должно быть), но просто во многих направлениях подход фана just works somehow и людям начинает казаться, что это откровение. Увы - это не так.

[juan_gandhi]

Вы ведь не программист (с программистской точки зрения)? По мне так вы в этом деле совершенно не разбираетесь.

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

Мои телевизоры апгрейдится регулярно, например. И мои японские машины тоже, каждый раз, как в сервис приволоку.

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

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

Это ничего, что вы не в курсе; плохо, что вы, будучи не в курсе, несете всякую чушь, чисто как зритель с трибун. Bay Area не угодила, надо же. Плохо мы тут программируем. Твитер с фейсбуком, хром с андроидом, гугл и эпл, нетфликс и линктин недостаточно хороши, надо же. Давайте их заменим японскими или немецкими.

[snowps]

Нет, я просто программист в другой области, нежели Вы, и в своей области разбираюсь существенно лучше Вас. :) Cофт в современных смарт-телевизорах - это достаточно низкокачественный софт, я поэтому и не привёл их в пример в перечислении, к тому же обновления в них связано в основном с изменением набора модулей подключаемых сервисов, а не самой операционной системы, кроме того - не смарт телевизоры отличаются намного более высоким уровнем стабильности и качества прошивок (я сравнивал неоднократно). В атомобилях иногда обновляется прошивка ECU (а чаще - просто калибровочные константы в ней), если в работе оной на уровне завода находятся проблемы, и изредка - прошивки отдельных периферийных контроллеров (каковых в машине как минимум 40-50 штук и которые в подавляющем числе случаев никогда не обновляются), ну и довольно регулярно может обновляться система навигации/интеллектуального управления, но это не полноценный эмбеддед, а примерно уровень магнитолы или навигатора на андроиде, в которых очевидно полно говнокода ("Toyota Motor Co. only issues software updates (Calibration or CAL files) for engine management and other electronic control units (ECU) only when there are specific issues or problems to be resolved. All updates are vehicle, model and model code specific." и примерно так же у всех остальных). Многие автомобильные периферийные контроллеры (в частности подушек безопасности, тормозной системы и т.п.) вообще не имеют возможности перепрошивки, в том числе и из соображений безопасности.

Твиттер с Мордокнигой и Гугль с Хромом - это безобразный код, и в плане ресурсоёмкости, и в плане совместимости. Нормальный код - повторюсь, - это код в вайфай-карточке, бейзбанде сотового телефона, в контроллере SSD или жёсткого диска, в авионике и том же автопроме, когда устройство может работать непрерывно десятилетиями без единого сбоя. И да - такой код пишется в подавляющем числе случаев на ANSI C, поскольку модные ныне языки просто не дают нужного уровня контроля над кодом, а "компилятор лучше знает" и "если что - выделим ещё мощностей в AWS" в машинах и самолётах не прокатывает. Вот когда эмбеддеры на джаваскрипте и скале начнут писать авионику - тогда я готов буду признать, что это именно я чего-то недопонимаю, but till they don't, I doesn't too, for sure. :)

P.S.: по поводу рефакторинга - когда изначально спроектированная система в процессе написания конечного кода требует именно рефакторинга (т.е. переделки изначальной модели) - это всегда означает проблемы проектирования и аналитики модели. Это примерно как если бы в линуксе бы с каждым изменением в какой-нибудь внешней библиотеке приходилось бы переписывать куски ядра. Рефакторинг - это необходимая вещь, но не в процессе разработки, а в процессе изменения/расширения первоначального проекта, а-ля смена мейджорной версии и расширения функциональности, а если это процесс оказывается постоянным, то о качестве работы архитекторов системы очень сложно говорить в ползитивном ключе.

[anonim_legion]

>Твитер с фейсбуком
Говно.
>хром с андроидом
Дважды говно.

1.
Все мы знаем сайты с бесконечной прокруткой. Началось это безобразие с твиттера, потом дошло до Tumblr и далее везде. Пользователь докручивает страницу до низа, она снизу подгружается, и так без конца. Обычно это сопровождается отсутствием поиска по дате и вообще какого бы то ни было поиска.

Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.

2.
Проблема: в некоторых случаях браузер жрёт немерянно много памяти. С недавних пор Firefox стал 64битным и не ограниченным адресным пространством в 2гб. Вдобавок, он еще и многопроцессный. Иногда, видимо из вредительских целей, вкладки с google translate на некоторых сайтах отжирают по 6 ГБ, а все процессы браузера - больше 12ГБ, и через некоторое время вся система уходит в жесткий своппинг.

В браузере такой настройки "не жрать, сука!" почему-то нет. Job objects, которые виндовые ограничения, не могут быть вложенными (начиная с Win 8 могут, но у меня Win 7), а Firefox уже использует оные job'ы для своих дочерних процессов, и еще одно ограничение наложить не получается.

Какая же дрянь это современное айти.

[sassa_nf]

"код is rock stable"

how much of that code is there?


"а не трудной и кропотливой работой"

трудная и кропотливая работа doesn't scale. Don't work hard.


"Самый лучший пример - ..."

Proof by example? Ok, here's another example.

The OVA we sold also rarely needs refactoring (after we sold it). And we rarely refactor it, as long as we can sell it, and do not spend cycles to make it do new things.

See? We don't refactor things, because we can sell them. And if we can keep selling it without making changes, why would we make any changes to it? The absence of refactorings is not a measure of anything; it only indicates the absence of a business need.


The example with Toyota and their software is not the proof (by example!) of the evils of recursion and the drawbacks of being too clever a programmer. It is the invalidation of the theory that just having the famed development procedures and best practices is what makes the embedded code exceptional.


"хренак-хренак и в продакшн"

is a meaningless analogy. The "продакшн" part for AWS services and embedded mean different things. We can start selling AWS service at the beginning of its lifecycle. You can start selling embedded software only at the end of its lifecycle. All these musings about embedded software development is being somehow superior, is nonsense. You simply can't sell embedded software until all the refactorings (others prefer to proudly call it "fixing bugs in the model") happened.

The difference in when things are sold is hardly anything to do with software engineering (or computer science for that matter).

[juan_gandhi]

> You simply can't sell embedded software until all the refactorings (others prefer to proudly call it "fixing bugs in the model") happened.

That's if they are going to close the engineering dept after release. If not, if they plan to build the next version the next year, they either refactor, or write from the scratch.

[snowps]

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

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

"We can sell" к качеству кода имеет весьма опосредованное отношение, поскольку среднестатистический потребитель оценивает всё, что угодно, но не этот параметр, - у него элементарно нет для этого должной квалификации (а если есть, то это кошмар аутсорсера). Например Canon долго использовал в своих продуктах VxWorks, но потом задолбался получать дебильный саппорт от Уиндривера, который трабл-тикеты патчил месяцами, если не годами, и с 2006-2007 года перешёл на свою собственную самописную Dry OS. Речь выше была несколько про другое: рефакторинг в процессе перевода модели в код законченного продукта говорит о проблемах архитектуры системы, т.е. о недостаточной проработке, - в том числе это касается и математического подхода, который Влад декларирует единственно верным: при работе с железом соблюдение концептуальных правил программирования из сферы ФП никак не поможет, это разные миры с разными требованиями.

Разумеется, - я примерно о том же регулярно говорю здесь: different programming styles and rules are not better or worse, only usable or useless in different use cases. Просто в случае, если производитель выпустит SSD или винт с плохим кодом в фирмвари, то он может легко прогореть, а если стартап, ваяющий на джаве или скале, напишет клиенту тормозной, но в целом рабочий говнокод, то маркетинг может навешать лапшу про то, что-де код офигеть какой сложный, так что надо купить ещё два шкафа серверов и всё будет зашибись. Я уже тут как-то приводил пример с одним моим клиентом - повторюсь: как-то меня позвали на обсуждение, как заказчику собрать почтовый сервис. Как, говорю, - postfix/dovecot, отдельный сервер с базой данных и файловым хранилищем почты, система бэкапов, - всё реализуется на двух рэковах одноюнитовых серверах (с резервированием - на трёх), стоит копейки. На меня так посмотрели и сказали - гм, это всё хорошо, но мы на таком решении не заработаем. В результате сделали какой-то немыслимый огород на десяти (!) серверах, причём с AD, Forefront, HyperV, резервированием, выносом виртуалок на фиберченнеловскую полку, везде понаставили Windows Server 2012, общей ценой всего примерно в лям, при этом за год, пока я это всё наблюдал, майкрософтовский админ постоянно что-то чинил, два раза с приходом апдейтов умирал RDP сервис во всех виндах одновременно и приходилось ездить в датацентр, чтобы вручную через консоль поставить все апдейты заново и т.п. Вот как раз второй подход характерен для свежих модных ФП стартапов. :)

[anonim_legion]

>doesn't scale.

Doesn't web scale?

>We can start selling AWS service at the beginning of its lifecycle.
И это явление нужно засунуть обратно, туда, откуда оно вылезло. И еще добавить к софту гарантийные требования, вместо "AS IS".

[bamalip]

Skype can't fix a nasty security bug without a massive code rewrite
http://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/

[juan_gandhi]

Ну они уже свое получили, так что ж теперь. Понятно, что сейчас там все деморализовано.

[bamalip]

Вот если бы это был немецкий код настоящего немецкого качества...))

[rampitec]

Могут и с нуля переписывать, наверное ;) Вот факап случился, всю команду, которая нафакапила, отстранить, а новые приходят, смотрят в код и нифига не понимают. Тогда новые говорят, что им проще с нуля написать. Да и денег так больше, и времени спокойной разработки, пока за качество кода еще никто не спрашивает.

[errorrishe]

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

[juan_gandhi]

У меня уже давно подозрение, что такое явление объясняется страхом перед собственно программированием.