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

Entry tags:

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

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

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

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

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

Flat | Top-Level Comments Only | Expand All

"код 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).

> 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.

Edited 2018-03-11 01:07 (UTC)

Yes, I agree. But I am making a different point. The refactorings these guys attribute to "the bugs in the model" simply aren't the bugs in the model in some Twitter example.

Suppose, they built a model for the driver's behaviour, and then observed it isn't doing the right thing - they go fix the model. They have to deal with the model, because the actual controller doesn't exist yet. Also, they can't sell the earlier buggy version of the driver, because they sell the controller, not the driver. Then after it's sold packaged inside the camera, they have no way to patch or update it, so the requirements are such that the development should completely finish by the time the camera takes off Cape Canaveral - and that means "finish" in some very pure form; there literally shouldn't be anything else to fix or optimize.

Then this software perfection cycle appears to be only nested inside a bigger cycle, the version-to-version upgrade, which to them looks very differently.

If Twitter were to reach the same level of completeness, then after two years of development all it could do would amount to about the same thing as the digital camera can do. So my argument is that Twitter software is "crappier" compared to the embedded driver not because the approach to software development is wrong, but because they can afford to increase complexity before they reach the same level of perfection as some aerospace software. This reduces the distinction between the cycles of perfection vs version upgrade.

Curiously, even space probes get software updates and patches long after leaving Earth orbit.

Some fun bits here:
https://www.itworld.com/article/2823083/enterprise-software/88716-8-famous-software-bugs-in-space.html

Спасибо!

По-разному. В 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 сервис во всех виндах одновременно и приходилось ездить в датацентр, чтобы вручную через консоль поставить все апдейты заново и т.п. Вот как раз второй подход характерен для свежих модных ФП стартапов. :)

What I meant, it is very different from "fixing bugs in the model". Twitter "gets refactored" not because there were "bugs in the model", but because the requirements were in the future.

A twitter service for 9286 users has a totally different architecture from twitter for 10m users - if we freeze the requirements, and leave time to engineer the architecture optimal for exactly 9286 users, you'll end up with something completely fitting in memory of a single mobile phone, perhaps; instead of what really happened, and the engineers produced an architecture that could be extended to a solution supporting 1m users (ok, now, for example, you've got to replace shared-memory locks with distributed locks, and rearchitect parts where the incurred latency becomes prohibitive), which then could be extended to a solution supporting 10m users (ok, now we are talking cross-region), which then could be extended to a solution taking into account GDPR - it could not even be architected with GDPR in mind at the time twitter started, etc.

Why wouldn't they write it with (say) distributed locks to start with? Because that increases time to market, and because at the time there are just 9286 users in sight it is not clear when, or whether, it will even surpass the size requiring horizontal scalability.

No, it is not "different programming styles". It is different market pressures. Suppose, controller firmware is finished in two years (I don't know; just for the sake of an argument). Let's fix that as the standard of "high quality code". If Twitter in the same two years manages to deliver a service to their first 9286 customers, with much lower quality code, it means Twitter is that much more complex. Maybe after two decades it could reach the standard of the "high quality code". But after two decades the need for such a service is no longer there.

Besides, there is no market pressure for bug-free Twitter. So the time for fixing "bugs in the model" is traded for time delivering more functionality. (thus you end up with Twitter poorer in quality but higher in complexity than any beautiful embedded code)

"включая огромное количество сложной математики"

well....I am not denying, matrix multiplication needs doing right, once and for all; but if that's your measure of complex programming tasks....

"На меня так посмотрели и сказали - гм, это всё хорошо, но мы на таком решении не заработаем"

cool story, bro. And you want to tell me that's how things work everywhere, and only cool embedded dudes know the shit, right? I don't know what "стоит копейки" means. I don't know how that compares to hosted computing. I know how much running 10 VMs in AWS costs our company. And I know replacing them with decent two rack units in-house is not such a bright idea even money-wise.

"админ постоянно что-то чинил...вручную через консоль поставить все апдейты заново"

...and your super-duper "postfix/dovecot" solution wouldn't need that, because...?

Ну Твиттер и Фейсбук - это примеры того, как не надо проектировать код и делать интерфейсы (достаточно попытаться запустить их фронтэнд на слабом компе с не самым последним браузером и посмотреть на нечеловеческие тормоза и глюки). Одно то, что они в начале выбрали для codebase RoR, говорит о полном кризисе мозга с их инженерным мышлением. Дальнейший переход на Скалу это только подтвердил. Это всё тут уже обсуждалось не раз, я уже устал повторяться и объяснять, почему массовые сервисы в 2014+ году проектируются с кривым бэкэндом, а Безос зарабатывает безумные деньги на ленивых программистах, и да - это как раз потому, что нет "market pressure for bug-free" code, и это в равной степени касается практически всего нынешнего вебовского и корпоративного говнокода, no matter how big is the fish.

Вот, к приемру, древний эффект-процессор Sony для бродкастинга. Думаете его проще спроектировать (почти всё железо кастомное) и написать под него софт, чем забабахать какой-нибудь data parsing & processing для бизнес-аналитиков? :) Это абсолютно несравнимые по сложности задачи, подавляющее большинство нынешних программистских стартапов просто не имеют сотрудников достаточной квалификации, чтобы осилить устройства такого уровня, поэтому весь бродкаст до сих пор держится на японцах и старых игроках рынка типа Matrox, - достаточно зайти в любую телестудию и посмотреть. И можно говорить что угодно, питать любые иллюзии относительно применимости модных подходов к любым программистским задачам, но реальность, увы, не соответствует им ни на йоту.

Because it simply works and generally don't need updates at all. :)

Советы твитеру и фесбуку выглядят смешно, конечно.

У них деньги из тумбочки.

Почему смешно? Они зарабатывают деньги и если эти деньги слабо зависят от того, говнокод у них или экстаз программистского совершенства, зачем вообще заморачиваться качественным бэкэндом? Если он будет работать на Скале и не падать каждые несколько дней, имея при этом эффективность в 10% от сишного бэкэнда, который должны были бы ваять дольше более квалифицированные и трудоспособные программисты, то никто из управленцев не будет париться и менеджмент благополучно выберет непадающий неэффективный говнокод вместо непадающего эффективного хорошего кода. That's how contemporary IT-business works, мы как-то с Пропессором это ещё в ЖЖ обсуждали и пришли к консенсусу.

"Думаете его проще спроектировать..., чем забабахать какой-нибудь data parsing & processing"

to the same level of completeness? ("nothing else left to fix" level)

yes, obviously.

"нет "market pressure for bug-free" code"

Of course. There is market pressure for MTTF and MTTR.

Intel doesn't have a production line for i5. They only have i7. Then i5 are those i7 that didn't pass the test (and subsequently the connections to the second thread of each core is burned out before packaging). Do you blame them for not sufficiently perfecting their i7 production line? It is the same thing as knowing how to sell bugs in the code.

Edited 2018-03-11 18:01 (UTC)

То есть полагаете вот этот вот ящик проще спроектировать безглючным, чем код в каком-нибудь парсере? :) Я даже комментировать эту безграмотную оценку не буду, извините, особенно после упоминания ниже MTTF и MTTR.

Вы вообще представляете себе технологические проблемы чипмейкров и стоимость оборудования, к примеру, для фотолитографии (а также то, что их до сих пор выпускают всего три фирмы в мире, две из которых - японские, а третья - голландская)? Сравнить wafer production и программирование можно только при полном отсутствии хотя бы минимального инженерного кругозора.

"в каком-нибудь парсере?"

no, the parser some team spent the same amount of time making as that box you are talking about. Why would you suggest to compare 200*2 year project and 1*2 weeks project, and then laugh about how clever you are?

"MTTF и MTTR"

is the real metric people care about. A lay owner of a hard drive has no interest in knowing how they achieve that: through man-hours spent on perfecting the design, or through quaruply-redundant hardware.

"при полном отсутствии хотя бы минимального инженерного кругозора."

that's a projection.

You can't seem to even discern the example of a wafer production line is exactly that: the production line actually utilizes redundancy to account for errors in the process. By no means am I comparing the quality. I am only pointing out that you think one of them as a feat of engineering worthy of worship, and the other - it's just engineers being lazy.

PS I don't even see why you choose to argue. In the other thread above you admit the same thing - different business requirements is the cause of a different development process, and a different way of achieving the necessary reliability. (More error-prone RoR twitter can be mitigated through higher redundancy, once it scales horizontally by design - there is no business need to perfect the design; it is even against the business goals, as perfecting the design extends the time to market.)

Edited 2018-03-11 20:24 (UTC)

Talking about error-prone RoR twitter. RoR, being error-prone, was the reason for switching to Scala Lift. Which, I'm not sure, did it ever fail? Twitter was hacked once, but I don't believe it was because of Lift.

Именно потому, что Вам приходит в голову сравнивать по трудозатратам чисто программный проект длительностью разработки в две недели с аппаратно-програмным законченным автономным устройством на нестандартной элементной базе, которое должно работать в бродкаст-среде 24/7/365, я и не вижу смысла это далее обсуждать. Двумя постами выше я как раз и задал вопрос для того, чтобы выяснить, считаете ли Вы квалификацию инженера, который пишет двухнедельные чисто софтовые проекты, достаточной для участия в проектах проектирования устройств, подобных тому эффект-процессору, и Вы недвусмысленно ответили на него той ахинеей, которую я и ожидал. Давайте больше не будем об этом.

Нет, среднестатистических людей интересует то, сколько они скорости и надёжности получают за вложенный доллар. В мире финансового софта и компаний, получающих деньги от рекламы и социальной аналитики, ситуация иная, очень много лишних денег, поэтому в Гугле, Фейсбуке, Твиттере, Линктине и прочих аналогичных сервисах столько говнокода и плохих архитекторов системы, а нормальные программисты после нескольких лет работы там бегут оттуда, сломя голову, в другие конторы и персональные проекты.

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

Я спорю не с тем, что сущствуют разные потребности бизнеса, - это очевидно, - а с тем, что измерять удовлетворением локальных потребностей некомпетентного в кухне написания софта заказчика объективное качество создаваемого для него кода - это полное безумие; это всё равно как если бы на основе мнения человека, покупающего USB-флешку, которую он сломает или потеряет через месяц, делать вываоды о износостойкости используемой в ней MLC NAND.

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject