Офтоп
Младший кубок
0
327 комментариев
Популярные
По порядку
Написать комментарий...

Ну и в чем он не прав?

342

@ Приходит заказчик

@ Говорит сделайте мне программку чтобы стабильно работала и мало весила.

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

@ Заказчик смотрит на смету.

@ Говорит хуй с ним с весом, давайте на готовых библиотеках.

@ Анонимы пишут в интернетах, что программисты не умеют программировать.

245

А как это объясняет наличие чуши в родных приложениях от вк и тд и тп? 

23

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

83

Но если ребята прошли по граблям, почему букет из их библиотек лагает?

4

Потому что идеальных программ на такой сложности не существует. Как обычно происходит дело с такими приложениями: сперва есть некоторый план и допустим хочется всё сделать хорошо. Потому мы продумываем архитектуру согласно плану и стараемся учесть максимум вероятностей. Важно отметить что "знания" здесь почти не канают, а играет только опыт. То есть чем больше шишек набил специалист, тем больше возможных вариантов можно учесть заранее. Итак у нас есть архитектура и она прекрасна. Функционал пилится и наконец мы получаем некую начальную итерацию. Потом прибегают те кому надо, смотрят на это дело и составляют список чего бы ещё нужно туда добавить. Каким бы прозорливым и опытным ты ни был, обязательно в этом списке будет страшно необходимая функция которая ну вообще не пришей пизде рукав согласно той красивой архитектуре что уже есть. А потом начинается лавирование, компромисы, костыли. Нельзя просто выкинуть 3 месяца работы потому что одна фича не ложится в архитектуру. И вот это вот сопровождает проект на всём пути существования. Иногда кто-нибудь врывается и обновляет какую-то устаревшую часть кода. Если он достаточно хорош и хорошо налажены процессы - это не вызывает негативных эффектов. Если он очень хорош - это вызывает положительные эффекты, которые даже может заметить пользователь. И всё это одна нескончаемая война с ветряными мельницами, не воевать с которыми нельзя. Так и живём.

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

49

Как программист с образованием инженера могу сказать, что с самолётами всё таки ситуация получше) В инженерном деле ты хотя бы накидываешь 20-30% запаса прочности, в авиастоении как правило запас больше, и это будет работать всегда. А вот при разработке какого-то проекта можно так накинуть "запас прочности" что продукт будет работать ещё хуже чем планировалось)

12

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

3

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

3

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

7

Да, забыл самое главное. Надо умело ссать в уши помимо умелого гугления. Вот вас бы взяли на работу. Чувствую, вы мощный специалист. ред.

4

Как бы ни было печально, возможно для вас, это называется софт-скиллы, и да, за это доплачивают и дают повышения)

5

И парадигама "зачем мне знать, мне надо оперативно уметь искать в гугле" ставится во главу угла

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

0

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

0

то есть, всего лишь лагает? Но при этом работает плюс-минус везде, поддерживает фичи и не крэшит приложение каждые 10 минут? Это успех, хорошая библиотека.

0

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

0

Ммм, дартаньян вылез. Таких обычно выставляют на мороз, поскольку они проебали все сроки пытаясь написать свой АБСОЛЮТНО ИДЕАЛЬНЫЙ И НЕПОВТОРИМЫЙ фреймворк, когда перед ними стояла абсолютно типовая задача. 

8

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

0

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

4

И как раз по ссылке не отрицается то, что некоторые куски кода необходимо переписывать с нуля. Важно соотношение факторов. Насколько критичен код, насколько хорошо работает, сколько времени занимают правки. А то прямо какая то презумпция невиновности местами прогрлядывает - юзаем старые библиотеки и не ругаемся.

0

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

0

Не стоит бросаться из крайности в крайность. Большую функцию можно распилить на несколько мелких более атомарных, большую вложенность часто можно сократить ранним выходом. Всегда же есть git если что-то пошло не так, всегда есть автотесты если сомневаетесь что можете что-то поломать. Если пишите проект который постоянно меняется, то нормально иногда рефачить какие-то куски. 

0

Это как раз то случай что я упоминал. Ну и плюс саму реализацию поменяли. В результате и кода меньше в два раза и понятно что вообще а каких случаях происходит. Есть ещё одна такая же функция, менять которую ужасная боль с багами, но ошибки в ней это реальные деньги, а сейчас она на 100% рабочая и поэтому трогать её никто не будет. При этом понятно, почему написано так криво - потому что зависит от законодательства, а оно за 15 лет таких виражей дало, что любой архитектор удавится.

0

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

1

Ещё пример. Решение на платформе 1с. Не от самой 1с, но в своей категории висит в топе. Очень медленное. Настолько, что конкуренты упоминают в рекламе, правда обезличено. Один из процессов настолько всех задолжал, что 50летний дядька программист не знавший 1с, взялся за книжки и частично оптимизировал его. Через месяц оно уже было без багов, с одной новой полезной фичей и намного быстрее. Потому что в оригинале разработчики на каждом шаге цикла по нескольку раз лазили в 300гб базу. При том, что реально нужных данных там мегабайта на 2. И это продаётся за деньги и тендеры выигрывает, потому что про некоторые "мелкий" особенности софта никто не рассказывает, а то что расчёты могут занимать сутки вместо минут, будущие пользователи могут и не представлять.

1

1С. Ты б ещё brainfuck какой-нибудь вспомнил. Это один большой крайний случай. Его используют просто потому что лицензия на SAP стоит раза в 4 больше.

0

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

0

Началось юление - оказывается речь о типовых задачах. 

Я совершенно точно не имел ввиду написание своего собственного фреймворка для решения задачи. Что ж ты не предположил, что я ещё и собственные языки придумываю?

0

Ладно, не фреймворк так не фреймворк, тогда свой движок, надо же свой рендер писать, не так ли? Или что ты имеешь в виду под "чужими режениями"? Библиотеки по работе с временем? О каких задачах ты оказывается говоришь (и ни капельки не изворачиваешься сам, пытаясь при этом сказать что изворачивается собеседник)? Тут в главном посте речь идёт о приложении банкинга под мобилку. Это типовая задача с поправкой на безопасность. Никакой рокет саенс. Что ты желаешь с нуля для него написать?

0

Мой комментарий касался твоего конкретного комментария. И конкретных пунктов нем.

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

0

Если он касался конкретного комментария - то и доводы должны быть в рамках конкретного комментария.

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

0

Да ты мастер по навешиванию ярлыков! Что ещё ты можешь рассказать обо мне по одному моему посту? 

Мне кажется, что такой уровень самомнения как у тебя - это как раз уровень зелёного новичка, который уже решил, что все знает.

0

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

0

 а) говнокодеры пишут долго, поэтому для скорости используют готовые решения

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

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

Потому что языки создают когда пытаются закрыть какую-то нишу в которой другие языки не так удобны/быстры/просты

2

Ну вы мастера все возводить в абсолют, я же не предлагал вернуться к ассемблеру. Здесь странная привычка делить все только на чёрное и белое.

0

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

1
Парадный каякер

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

0

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

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

Товарищ привел совершенно дикие аргументы, я над ними поиронизировал. 

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

0

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

1

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

0

Вот это правильная интерпретация поста от "Ghar Undefeated"! Полностью согласен. Поэтому мы и имеем ситуацию, когда надо покупать новый смартфон, потому что на старый не помещаются приложения. 

0

понял. спасибо за разъяснение 

4

А ты видел сколько там функционала? Лайвстримы, эффекты для фотографий, платежи, сторис и это только то что я могу вспомнить из головы, я их сервисами не пользуюсь лет 5 уже.

11

Так там функционал постоянно растет. Появляется новая социальная сеть - копия её функционала появляется ВК. Из последнего - тикток.

8

На самом деле там много места занимают даже тупо картинки. Потому что у всех ретина, двойное разрешение, тройное разрешение, на телефонах разрешение экрана больше чем на компах 10 лет назад. Для всего нужны картинки, картинки большие и много весят. (Хотя на самом деле двойного разрешения часто за глаза, но не все это знают, и даже это уже немало.)
Это раньше Дум шёл в разрешении 320×200. Сейчас такой размер только у одной иконки.

1

Родное приложение не означает, что оно не использует разные SDK под платформу, под которую делается

0

Потому что ВК также пишется на готовых библиотеках.

0

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

3
Парадный каякер

А кто за это платить будет?
Это не так работает, что ты сел, написал один раз и всё заебись. Это потом надо поддерживать годами, покрывать тестами, закрывать миллионы багов от индусов которые создают ишью в духе "AUTHOR FUKEN RETARDO WHY WONT WORK FIX ASAP", потому как на каждую функцию и метод могут быть сотни эджкейсов. 

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

За ваши деньги — любой каприз. Пик тотали рилейтед

3

Но ведь кто-то же когда-то уже создал "готовые библиотеки" и до сих пор их поддерживает и кто-то это оплачивает. В чём проблема сделать ещё? 

2
Парадный каякер

Я картинку зачем запостил?
На какой библиотеке остановимся, на сотой, тысячной или миллионной? 

0

Вот примерно так молодой стажер, но отличный программист получался, а потом дошёл до реализации  задачи где есть ГОСТ и такой "ооо, как же круто". Документация есть, вся в одном месте, никаких изменений и костылей - красота)

0

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

0

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

За счёт роста мощностей оказывается выгоднее написать кое-как, а все недостатки ПО переложить на железо. Тот же Electron стал символом времени - все запускается в браузере, поэтому программисты умеют писать только на ява скрипте. Подогнали им среду, чтобы они тоже могли для десктопа пилить. А то, что оно медленное и жрет уйму ресурсов - так надо просто всем компы обновить.

0

Хочешь сказать, у банка нет денег? 

2

Времени. 20 программистов не делают проект в 4 раза быстрее чем 5, так что деньгами тут не помочь. Банку нужно приложение, которое будет готово максимально быстро, чтобы начать приносить деньги. Они болт клали на ресурсы, их приоритет скорость и стабильность.

3

"20 программистов не делают проект в 4 раза быстрее чем 5"

А вы точно ПМ?

1

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

0

Так что ресурсы банки считать умеют прекрасно.

Можно открыть новости за прошлые годы, почитать сколько из российских банков закрылось.

0

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

0

Вчера в НГ прочитал, что в России сотни долларовых миллиардеров, но в отличии от зарубежных богачей, они почему-то не пишут книжки о том, как они разбогатели.

0

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

0

Конечно, потому что тебе мидла который курс на гикбрейнсе прошел за 15к в день выставляют (это еще дешево). Вот вам и 1000000 часов на разработку собственного решения. А то что они криворукие это ничего?

0

Не нравится аутсорс - нанимай своих разработчиков или делай сам.

1

А потом из-за долбоебов-программистов падает Boeing 737 MAX и забирает с собой 300 человек.

–4

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

0

Я сам с морскими системами работал, в частности с оборудованием Rolls Royce, BAE, Ulstein. И с действующими газовыми и нефтяными терминалами имел дело. Там во-первых все максимально просто, во-вторых дублировано. Если что-то и надо проапгрейдить, то это целое событие. Потому что просто и надежно. И неверные движения сто раз предусмотрены. И до сих пор все на NT4.0 и ниже. 
И все эти сертифицированные высокооплачиваеимые умники с кучей фреймворков, знаниями нах никому не нужны.

0
Парадный каякер

В том, что за оптимизацию никто и не платит, чтобы она была.
Главное, чтобы работало, да побыстрее. ред.

94

Вот тут не поспоришь.

1

Согласен, если бы изначально стоял вопрос про размер, уверен, что можно было бы сделать и компактнее, вопрос только чем пришлось бы жертвовать - временем, функциональностью или стоимостью.

0

Простой пример. В приложении нужна функция. Можно взять сторонний компонент и потратить неделю на его внедрение, но компонент реализует еще много ненужных функций, которые вместе с нужной формируют избыточный объем. А можно не брать сторонний компонент и потратить год, чтобы самостоятельно с нуля разработать нужную функцию и оптимизировать ее под твое приложение, и она будет весить копейки. Каким путем пойдут разработчики очевидно, так как за год работы платить никто не будет. Есть еще вариант, что избыточный объем формируют ресурсы внешние, картинки, музыка и т.д. Но там тоже нужна адекватная задаче оптимизация, будут ли на это потрачены ресурсы разработки - это отдельный вопрос. ред.

66

А разве сложно просто вырезать ненужные функции? Не наезд, спрашиваю 

4

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

45

отлаживать упаритесь. особенно в будущем. проще написать самому.

0

Да, довольно часто это не совсем тривиально, ибо функции могут быть зависимыми от других функций и так далее.

23

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

34

Сторонний компонент это как закрытый ящик черный чужой, ты берешь его как есть и соглашаешься с его особенностями, либо нет. Но дальше хуже. Функции не всегда бывают независимыми. Мир устроен по модульному принципу. Одна функция зависит от множества других, другие от множества третьих, формирую цепочку зависимостей. Заимствуя функцию, ты тащишь к себе всю цепочку зависимостей, что тоже объем.

13
Парадный каякер

Сложно. Заебешься разбираться в чужом коде

2

Я думал, программисты пишут в коде комментарии, типа вот здесь то, а вот здесь это

1
Парадный каякер

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

9

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

3

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

Поэтому иногда сами библиотеки делаются в несколиких вариантах - например, Laravel (полноценный фреймворк) и Lumen (мини-фреймворк на той же основе).

Но в реальной жизни никто не заморачивается. Берут то, что знают, наворачивают библиотек, надо / не надо это все тянет завыисимости, на которые никто вообще не смотрит - работают и отлично,....

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

1

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

2

о, не знал, что есть термин такой.

0

Проще с нуля написать будет )

0

из готовой библитиотеки - конечно сложно. невозможно я бы сказал.

Хотя есть пакеты, которые собираются из частей - чтобы можно было собрать нужную сборку, но это уже никто не делает, да и просто дерево зависимостей огромно. Помню, как мы делали лэндинг (одностраничный, мать его¸ сайт) и по итогу сборки фронта в папке node_modules (используемые библиотеки, которые автоматом подтягиваются по зависимостям) было 40 000 файлов!

На оптимизацию очень часто забивают. Место, трафик, ресурсы начинают считать только для хайлоада, а в обычной жизни "стреляют из пушки по воробьям"

0

Да это в целом нереалистичный  кейс
Если нужна какая-то одна функция то проще свою написать, либо - это какая-то маленькая библиотека, которая вряд ли повлияет на размер
Если это какая-то большая библиотека то как правило она активно используется, то что ненужно сегодня станет нужно завтра и от такого урезания один вред
А потом еще гипотетически возникла причина обновить библиотеку и все по новой
Такие манипуляции -  очень дорого в разработке и тестировании

0
Парадный каякер

Щас бы хранить картинки и прочую статику внутри приложения

0

А где их надо хранить, лол? На внешнем сервере?

0

Берешь условный "hello world". Добавляешь библиотеку для работы, скажем, с дропбоксом. Хуяк — и приложение "подросло" метров эдак на 10. Вот просто так, на ровном месте.
Добавил библиотеку для работы с AR: условно +50 мегабайт. Если банковская шняга, то там будет еще дофига всякой всячины для входа с биометрией, для BankID, для всяких ApplePay/GooglePay... Не забудем про кэш.

Вот так с миру по нитке — голому веревка.

29

а зачем голому веревка?

0

Вздернуться т.к. на смартфоне нет места под новую приложуху

22

Комментарий удален по просьбе пользователя

0
Парадный каякер

В том, что приходят эффективные менеджеры и требуют React Native везде :) А как говорится, есть спрос - есть предложение :) И их можно понять - их задача - потратить меньше денег на разработку. Потом приходят артисты и у тебя появляется куча ресурсов, которые должны быть доступны вот прям всегда. Потому что тебе вот эту картинку надо показать при первом запуске (и только при нем), даже если нет интернета. Иначе ууу, никто не узнает про модную фичу.

Бонусом - если речь про Android - то все, что NDK - будет лежать собранным под несколько архитектур со всеми сраными зависимостями :) Потому что Google очень красиво решил проблему ABI стабильности С++ - он просто забил на нее хер.

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

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

14

Сбербанк то нативный же, вряд ли там кроссплатформа. 

0
Парадный каякер

Поглядел в APK - тоже кордова :) Банковские сейчас по другому не модно писать :)

1

Они дебажные либы с символами чтоль кладут туда, 1.5Мб на библиотеку сканирования баркодов это как-то дохрена

0

За оптимизацию не платят. Все хотят "выкатите нам продукт побыстрее" и чтобы он "хоть как-то работал". И часто это оказывается оправданно, потому что важно не упустить окно и занять нишу. Если вылизывать приложуху, оптимизировать и тп - рискуешь опоздать к раздаче и выкатить ее когда рынок уже  поделен и никому ты нахрен не упал.
Более адекватный вариант сначала выйти с говнокодом, а потом когда ты уже стоишь на ногах - заниматься оптимизацией, если есть пользовательский запрос на это. И вот тут другие затыки... если изначально архитектура - говно, то много ты не наоптимизируешь... 
На самом деле никто не любит работать с говнокодом и с неоптимизированным говном. Но убедить заказчика выделить время(и соответственно бабки) на оптимизацию можно лишь в том случае, когда он теряет бабки от отсутствия оптимизации. 
С учетом того что затолкать 32 гб оперативы сейчас в комп вообще просто - мало кто парится. 

12

в том, что размер приложения - это картинки. код в таком приложении весит с 10-30 мб

–12

Хуйня это все, не надо мне лапши на уши. 

21

лапша тоже тяжелая, снимай

2

Хочешь я тебе сделаю три картинки где ты не заметишь разницы в качестве но заметишь разницу в весе?

3

Хочешь я тебе сделаю три картинки

Одна в ПНГ вторая в жипег и третья в тифф?

8

Нет, зачем, одну и ту же работу, в одном и том же разрешение и формате можно сделать по размеру.

2

Как? Без подколов, правда интересно 

1

Будет дописывать метаданные. Видимо прошёл курс по стеганографии, 3 курс Универа)))

1

кручу барабан: названия разной длины в символах сделать?

0

а, т.е. ты серьезно это все лол. 
ну делай, я посмотрю, могу даже с телефона. только учти, что у меня retina 2778×1284.
я, конечно, не знаю кем надо быть, чтобы в 2021 считать мегабайты в приложении

–22

То есть ты сейчас намекаешь, что все это время нес хуйню?

6

я намекаю, что ты несешь хуйню

–7
Парадный каякер

Нет, ты.

6

2.3МБ против 2.6, и это твоя "разница", серьезно? Не, фактически ты не соврал, но как-то маловато 15% разницы.

0

ты не соврал

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

0

15% это ничто в данном контексте, изображения можно жать с минимальными потерями в несколько раз, что я и ожидал увидеть. А мою ЗП могут резать хоть на 200%, все равно она ни на копейку не уменьшится.

1
Парадный каякер

Нет зарплаты, ночуешь под мостом?

1

А вот теперь представь, что игру разрабатываешь, а мощности у пользовательских компьютеров не резиновые. В игре сотни таких текстур. Что будешь делать?

0

И к чему это? Я говорю что 15% разницы не хватит чтоб существенно изменить вес приложения, но это не значит что сжатие не нужно использовать.

1

вот это оптимизация 200-300 кб. отдаю должное, сударь, уделал просто

0
Парадный каякер

Тебе любой seo откусит яйца за 300 кб, если их можно урезать.й

4

а при чем тут seo вообще? 

0
Парадный каякер

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

0

Ору

0

Любой seo идет нахер когда речь идёт о картинке в приложении которую не нужно качать каждый раз из сети. 

0
Парадный каякер

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

0

"не современного формата и кодировки" АХАХАХАХА
вот именно что разработчику, потому что никто кроме него не знает какого формата картинка на самом деле в приложении, любая картинка которую пришлёт сошник в приступе оптимизации будет прогнана через что нибудь вроде Tinypng чтобы уменьшить размер для веба и страница грузилась быстрее а получив векторную картинку сразу же переделает её в пнг пусть и больше размером раз в 10 но с ней приложение/сайт не будет тормозить, ну а дизайнер создающий картинку услышав от сеошника что нибудь про современность форматов забудет об этом ровно через секунду.
Ну и последнее самые современные форматы часто ещё и не поддерживаются всеми платформами и версиями платформ что всё ещё используются.

0
Парадный каякер

Раз ты так говоришь, то так и есть

0

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

0
Парадный каякер

Тебе должно быть не похуй какую картинку хуйнуть? Мне, например, похуй. Мне не за это деньги платят.

0

Важно чтобы она отображалась как по дизайну и её отображение не крашило приложение, вес/современность дело десятое. 

0
Парадный каякер

Как картинка может крашить приложение? Разве что хуенуть svg на 20к точек.

0

У нас как то рисовали иллюстрацию в веб предлагая её в свг использовать.) Ну и 100 иконок по 200 точек не сильно от этого отличается так что иногда и их приходится пнг-шить.
Вообще tinypng универсальное решение, прогоняешь всю графику в приложении через него -20% веса сразу. 

0
Парадный каякер

Мне больше compressor нравится. Tyny png очень шакалит

0

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

1

Ну т.е. если тебе положат в прилогу банковского приложения картинку не в нативном разрешении, а в 2 раза меньше то это всё, совершенно неюзабельно?

0

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

3

Рисуют то это всё в векторе, а в приложении оно лежит уже растром.

8

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

0

Тормоза ж на сложных картинках.

6

Потому что вместо того чтобы отобразить простой растр телефону придётся отрендерить миллиард точек векторного изображения, векторные иллюстрации сложные не используются почти НИГДЕ потому что одна их прогрузка на слабомощных системах займёт вечность. 

2

Вектор тоже вектору разница. Там, где деталей много, как правило, растром уже лучше как по размеру, так и по времени декодирования (вектор тоже небесплатный в этом плане).

0

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

0