Как стать автором
Обновить
100
1
Slava Vedenin @vedenin1980

Java developer

Отправить сообщение
Тот новый вид обфускатора называется «Обфускация Неразличимости» («Indistinguishability Obfuscation» — «iO»), формально: если имеются две разные программы, но с абсолютно идентичными функциональностями, то обфускации этих двух программ будут неотличимы друг от друга.

На пальцах, у меня есть программа с алгоритмом «x = y + z — t» она неотличима от по функциональности от программы «x = y — t + z», ни от программы «x = z — t + y». C точки зрения, определения «Обфускация Неразличимости» банальная перестановка суммы слагаемых дает нам эту самую идеальную обфускацию! Как вы прекрасно понимаете конкуренту достаточно получить лишь один из алгоритмов с абсолютно идентичными функциональностями (и желательно близко по размеру и сложности оригинальному), чему такая «Обфускация Неразличимости» никак не помешает. Ну, какая мне разница что алгоритм полученный после реверс инженеринга будет не совсем таким же как тот что был изначальный, если его функциональность идентична оригиналу?

Другими словами, весь этот великий алгоритм это проста игра с определениями: «дадим новое определение Искусственного интеллекта. ИИ это программа способная сложить два числа. Ура, теперь в моем калькуляторе живет ИИ!»
А если для каждого входа отдельный код? Узнав один вход, вы не узнаете что будет на другом. Если вход известен, деобфускация не нужна, можно просто запустить программу на этом входе и узнать выход (черный ящик). Но больше по программе вы ничего сказать не можете.

Не имеет значение кол-во шифрований, все равно вы будите должны процессору передать код который тот должен будет выполнить. Предположим, что у вас есть элементарный алгоритм z = x + y. Как вы его сможете зашифровать так чтобы процессор понял что нужно сделать, а человек нет? По сути, любая обфускация это просто создания огромного кол-ва лишних операций чтобы скрыть истинные, но истинные все равно нужно выполнять, а значит это попытка зашифровать сообщение в случае когда и алгоритм шифрования и все ключи всем известны, что невозможно по определению.
Это не обфусцированние программы — мы получаем несколько потоков зашифрованных данных, делаем какие-то операции над ними, расшифровываем их и получаем не шифрованные данные, при чем тут шифрование кода программы?

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

Тем не менее, вы же вполне можете объяснить: если будет сценарий 1 мы сэкономим столько-то времени, потратив сейчас столько-то, а если сценарий 2 то столько-то и столько-то. Вообще, ПМ'а как раз с вероятностями пи рисками должен работать по хорошему (вероятность, что разработчик поссорится с женой и его работоспособность резко упадет, вероятность что пол команды решит уволиться, вероятность что заказчик вообще не захочит платить за сделанную суперфичу.)
Вместо этого он находит промежуточное звено, ну или выделяет это промежуточное звено из имеющихся у него программистов, и делает из него крайнего за принятие и обоснование таких решений.

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

Заглянуть в будущее на столько далеко чтобы прозреть в точности будущую экономию

Почему в точности? ПМ должен хотя примерно представлять что ждет проект и прикидывать вероятность пользы и успеха. Из разряда:

— Давайте мы построим кран?
— А нафига? Мы же строим пятиэтажку.
— Ну, если а вдруг заказчик захочет построить небоскреб, это сильно нам потом время сэкономит.
— Не, ребят, небоскреб он точно не захочет, у него боязнь высоты.
Даже если сторонний продукт, я пишу на Java и один из самых главных плюсов — ты можешь открыть любую стороннею библиотеку/продукт, в которой случилась ошибка, и посмотреть что там произошло. Много раз таким образом находил причину ошибок, пару раз отправлял pull request в эти сторонние библиотеки, пару раз разобрался с недокументрованными возможностями, например, монги, иногда делал форки и создавал свои собственные реализации библиотек в которых исправлял ошибки.
Но плохой код все это осложняет в десяток раз.
а версия 7 вышла через 5 лет и была очень-очень слабым изменением по сравнение с MS IE 6

ну, хорошо в ряде случаев маркетинг может продвигать морально устаревший на годы продукт, как например Internet Explorer, но рано или поздно более качественный и современный продукт возьмет свое
На всякий случай добавлю Android построен на оперсорсном Линуксе, а Windows Phone на усеченной винде. Традиционно многими винда исторически считалась более прожорливой и менее качественной чем Линукс (честно говоря не знаю как на самом деле сейчас дела обстоят), так что о качестве кода (производительности, отлажености ядра) тут можно поспорить.
вместо решения конкретных задач появляются фабрики фабрик фабрик.

это кстати пример плохого кода
По многим признакам видно, что код там куда лучше, чем, скажем, в Android'е.

По каким признакам? Вы делали синтактический анализ качества Java кода Android и C# (вроде он там) Windows Phone? Да, я могу поверить что код Android'а менее протестирован, но это не значит что там писали говнокод.
Подозреваю что проблема совсем не в том что в гугле говнокодили, а в Microsoft'е вылизывали код, там на самом деле куча других причин почему Android обыграл Microsoft.
Скорее всего вы говорили не о качестве

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

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

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

Поверьте, качество кода напрямую влияет и на скорость разработки и на качество и на простоту поддержки.
Нормального опытного программиста легко. Если я могу решить задачу написав формулу в Excel'e за 15 секунд, я напишу формулу в Excel'e, а не буду пытаться написать класс. Нормального опытного программиста сложно переубедить, что хороший код и плохой код с точки зрения прибыли одинаковы, потому что у каждого программиста есть свое кладбище загубленных баз данных, глупых ошибок на много нулей в долларах, модулей на много тысяч человекодней, который проще выкинуть и переписать заново, чем пытаться понять.

Везде должна быть золотая середина: код не искусство, это лишь средство. Однако, глупо покупать набор отверток за десятки тысяч $, но и пользоваться китайской фигней за 10 центов/набор тоже не очень умно.
Не совсем так, продукт должен быть соответствующего качества. Скажем, за одну ошибку в ПО космической ракеты компания может просто разорится. Да, можно добиться нужного качества на самом ужасном коде, но намного легче выйти на нужное качество при определенном уровне качества кода.

Понятно сам по себе «красивый» код нафиг никому не важен, но если он ускорит разработку, облегчит поиск ошибок или сопровождение, то он вполне себе принесет прибыль. Грубо говоря если на стройки работают одни джамшуты в худшем смысле этого слова, то она легко может оказаться «золотой» при приемке дома. С другой стороны, на строке никому не нужны и великие гении-художники, которые десять лет будут шедевральный кафель класть в одной комнате.
На самом деле, плохой код вызывает и плохие ошибки. То что в хорошем коде просто выкинет понятный exception сразу как произойдет ошибка, в плохом может привести к незаметному игнорированию ошибок, блокировкам, зацикливаниям, утечки памяти, падению производительности, а то и повреждению данных.
Конечно, так как хорошо написанный код:
1) легче исправить,
2) проще отладить,
3) в конце концов, он просто не падает на глупых вещах (и падения не приводят к катастрофическим последствиям), запутанный плохо написанный код без всякого тестирования легко может содержать баги вроде полного удаления базы на продакшене, а вот в хорошо написанным коде такие вещи легко видно невооруженным глазом.
ПМ не должен понимать зачем в программе конкретные классы, он должен:
1) контролировать приоритеты и выполнения задач (для этого не нужно ничего понимать в программировании),
2) на ответ " Не успели, но мы написали вспомогательные классы для x,y и z. Это облегчит дальнейшую работу.", должен задать вопрос какие именно задачи и на сколько в будущих итерациях эти «вспомогательные классы» должны ускорить разработку. И отсюда уже делать вывод от «ребята молодцы, сократили мой план на итерацию 10 на две недели» или «какого фига вы потратили месяц на фраймворк сортировки бабочек, если мы никогда ими не будем заниматься»

То есть хороший ПМ, совершенно не разбирающийся программировании, может прекрасно рулить техническими задачами исключительно из КПД полезности (текущей и будущей).
Как можно назвать архитектуру прекрасной, если она не помогала продукту? Это равносильно «мы сделали замечательный дизайн-концепт автомобиля, одна проблема — он ездить не может».
тендер на разработку ПО по методологии Agile

А что есть тендер на разработку ПО по каскадной методологии? Методология это процесс взаимодействия с заказчиком и выдачи релизов, а не тендеров. На самом деле, процесс непрерывных уточнений у заказов и показов некоторых прототипов достаточно часто встречается (при том что ни исполнитель ни заказчик не подозревают что работают по Agile модели).

С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…

Заказчик в методологии Agile не обязательно покупатель, это может быть преальфа тестер, задачей которого определить «играбельность» каждой итерации.

P.S. На самом деле, методология проектирования не имеет отношения ни к тендерам, ни к продажам.
И теми и другими, если говорить о зарубежных компаниях. Ради интереса поищите вакансии java разработчик в Европе/США, в доброй половине вы увидите требования знания Agile или XP программирования, что как бы намекает на что сейчас мода.
А где же Agile проектирование, Экстрема́льное программи́рование и ему подобные? По сути надо было написать «Обзор водопадной модели процесса разработки программного обеспечения». Вообще-то водопадная (каскадная) модель по-моим наблюдениям уже даже не самая популярная и многими считается устаревшей.

Информация

В рейтинге
1 430-й
Откуда
Luxemburg, Luxembourg, Люксембург
Дата рождения
Зарегистрирован
Активность