"Программисты не умеют программировать"19
Яркий пример: у Яндекса есть на андроиде браузер как с Алисой, так и лайт "без всего". С Алисой лагает даже на мощном телефоне. А на лайт не все сайты открываются, зато быстро. Я полную версию открываю только для поиска по картинке, остальное исключительно на лайт версии.
раскрыть ветку (3)
Здравствуйте! Хотим помочь вам разобраться с этой ситуацией.
Отправьте, пожалуйста, письмо из формы обратной связи в браузере. Для этого:
1. Откройте браузер → в поисковой строке нажмите значок ≡ → выберите пункт «Настройки».
2. Прокрутите экран до самого низа и нажмите на строчку «Написать отзыв».
3. Появится всплывающее окно с предложением выбрать почтовое приложение для отправки письма. Если у вас нет такого, установите его, пожалуйста. Можно использовать, например, приложение Яндекс Почта.
4. Откроется форма с уже заполненной технической информацией. Не удаляйте из неё ничего. В любом месте письма напишите номер обращения 24040102530424699 .
Повторно описывать вашу ситуацию не нужно.
У меня кстати установлен браузер с Алисой. Не ое основной, но работает вроде нормально.
Я только не понял вы его, как пример чего хотели привести. Херовой реализации фичи в приложении? Ну да бывает такое, куда же без этого.
раскрыть ветку (1)
Голосовые помощники и учет финансов уже давно можно делать отдельными модулями, которые можно подгружать только по необходимости.
Но даже вместе с ними программа может весить меньше ста мегабайт.
У меня учетная система под .Net весит десяток мег, на Дельфах она весила мегабайт отсилы.
А тут - мессенджер, блин, триста мегабайт жрет! Куда, зачем?
Я, на самом деле, ответ знаю. Потому что сам программист. И понимаю, что в том же .Net можно легко сделать массив на десять гигабайт - и он будет работать. В отличие от Паскаля или Дельф, где массив не может быть больше определенного размера, и надо уметь работать со списками, с подгрузкой страниц, и т.д. и т.п.
И опытный программист будет писать нормально, а вчерашний школьник Вася возьмет и заебенит массив на полтора гига - потому что других решений ему пока в голову не приходило - зато быстро!
А потом переделывать Васину поделку, чтоб работала нормально - то денег нет, то времени, то уже некому, потому что в конторе одни Васи остались.
раскрыть ветку (12)
Их можно и отдельными приложениями сделать. Вопрос зачем? Чтобы потом пара десятков человек оценила размеры приложения)) Ну смешно же.
раскрыть ветку (5)
Вы немного неправильно понимаете вопрос.
Вопрос не в том, сколько человек вам скажут, что приложение большое или там наоборот, маленькое. Вопрос в том, что оно крайне неэффективное и неэкономное.
Оно работает плохо. Оно места много жрет.
Мне 16 гиг хватает для запуска кучи сложных приложений и отладки еще парочки.
А вам - столько же надо для общения и картинок.
Когда-то даже ста мегабайт было достаточно.
Вот меня не устраивает эта гонка мощностей, когда приходится покупать более новую и дорогую технику только потому, что программист Вася не умеет программировать.
раскрыть ветку (4)
Вопрос не в том, сколько человек вам скажут, что приложение большое или там наоборот, маленькое.
Вот именно в этом и вопрос. Потому что когда к вам придет менеджер с очередной задачей, то он эту задачу где-то защитил и попросил у кого-то на нее денег. А в замен он пообещал вырастить какую-то метрику. И если он не справится, то не будет никакого приложения. Я упрощаю немного, но суть передаю.
Вот меня не устраивает эта гонка мощностей, когда приходится покупать более новую и дорогую технику только потому, что программист Вася не умеет программировать.
Ну так не покупайте. Есть сайты, есть pwa. Опять же, сколько вас таких, которых не устраивают размеры приложений. Да еще и на столько, чтобы отказаться от использования сразу всего сервиса.
раскрыть ветку (3)
раскрыть ветку (2)
Я тот человек, который говорит, что надо делать, чтобы у компании были деньги, а у пользователя то, что ему нужно.
А программирую я так, для души))
раскрыть ветку (1)
Т.е. вы хотите сказать, что вы как раз принимаете решения в стиле "сделать быстро, пусть не так эффективно", так?
Тогда у вас есть какие-то резоны так действовать?
Вот это действительно интересно.
Я-то сперва подумал, что вы со стороны пользователя оправдываете менеджеров и разработчиков. А если вы действительно "в теме" - можно поподробнее?
Какие резоны заставляют вас делать такие приложения?
Например, где мелкий функционал использует сотни мегабайт памяти?
Одно соображение я услышал - что памяти хватит, и большинство пользователей ничего не скажет. А еще есть?
В iOS нельзя подгружать:) это одна из проблем, почему блокировка в AppStore так трудно и долго происходит.
И по моему опыту больше всего места занимают, какраз, ассеты - картинки и иконки всякие, ну и некоторые тяжеловесные либы.
раскрыть ветку (5)
Вот насчет IOS не скажу, не знаю его. Там что, приложение представляет собой один неделимый файл? Динамических библиотек нет?
раскрыть ветку (4)
Либы есть, но они подключаются обычно сразу. Нет, бесспорно можно сделать подгрузку либы, но если на ревью или позже это заметят - прилу могут зареджектить, а если такое повторится - то и заблочить аккаунт разрабов за нарушение правил.
раскрыть ветку (3)
Ну, это, как я понял, в вашей команде такие правила? Это ж ваш архитектор решает.
А технически-то, получается, возможно сделать и так, как я предположил - подгружать только тот функционал, который фактически используется?
раскрыть ветку (2)
Ревью от Apple, при выкладке в AppStore все прилы проходят ревью. Не кода, а работы и внутреннего устройства приложения: подключенные либы, работа приложения, персональные данные, которые прила собирает и тд и тп.
Как сейчас банки обходят блокировку?
Выпускают прилу, например, как тинек - выпустили прилу якобы календарь инвестора с инфой и новостями по инвестициям, но если там залогиниться по номеру - будет совсем другое приложение - тинькоф инвестиции.
Так вот - apple их блочит не из-за того, что это тинькоф, а из-за того, что приложение модифицирует свое содержание и функционал в «полете».
В 97 году жесткие были по 800 мб и на них ставилась винда, ворд и для игрушек место оставалось...
раскрыть ветку (5)
ага) у меня хард на котором стояла ХРюша на 120 гигов был вроде, и все свое время жизни был забит процентов на 15-20 наверное
раскрыть ветку (4)
У всех моих корешей в начале нулевых харды были по 40 гигов.
А у меня был на 80, считалось уже чуть ли не мажорством.
Ещё круче было только два харда, чтоб один снимать и по друзьям ходить файлами обмениваться.
У меня так знакомый аниме распространял, покуда эти ваши локалки массово не появились.
раскрыть ветку (3)
а у меня не было локалки, у меня инет то нормальный(ну как нормальный 512 кбсек) появился в году 2006м наверное
раскрыть ветку (2)
Ха, у меня в конце 2008 на 128кбит только появился, ADSL2+
Волчехуйск же, да еще и окраина города.
А 512кбит для 2006 это прям круто. В Питере в начале 2008 1мбит обычная скорость подключения была, по витой паре от Corbina Telecom.
Волчехуйск же, да еще и окраина города.
А 512кбит для 2006 это прям круто. В Питере в начале 2008 1мбит обычная скорость подключения была, по витой паре от Corbina Telecom.
раскрыть ветку (1)
Да может и позже, я точно время не помню, но 2007-8 точно. Адсл, все дела, но скорость на тот момент была космическая. Как минимум по сравнению с мобильным инетом(друг игрушку помню неделю качал)
Помнит 40 мбайт? Помню игры на спектруме в килобайтах исчислялись, а играть в них неделями можно было. Да дуум2 на пк 15мегабайт весил.
раскрыть ветку (1)
Так и щас весит. Ланчер современный метров 15 вроде, главный файл игры вроде 20. Ну и коллекция модов на 20 гб часов на 500 геймплея)
Я чот ленюсь со старого жесткого переенести(
В том, что слегка далек от мира. Еще бы написал, что «врачи не умеют лечить, так как стране умерло Х людей от излечимых заболеваний за последний год».
У человека есть некая производительность. Быстрее этой скорости работать не получится. А потому, можно делать вылизанное хорошее ПО, а можно сваять рабочее дерьмо в 2-3 раза быстрее.
раскрыть ветку (9)
Я разработчик. Не забывайте, что не мы сами себе задачи ставим. Вот есть у меня выбор, использовать библиотеку на 10мб или написать свое решение на 1мб (ну это край прям, уже дохера). Как вы думаете, что мне одобрят по времени?
Библиотеку, потому что быстрее. Бизнес хочет новые фичи. И хочет прям щас. На одном проекте я делал функционал внесения данных ГОРОСКОПА для сотрудников. Вы думаете я хотел это делать и увеличивать этим объем кода?) Нет, конечно. Но ничего не попишешь, ч за это деньги получаю
Библиотеку, потому что быстрее. Бизнес хочет новые фичи. И хочет прям щас. На одном проекте я делал функционал внесения данных ГОРОСКОПА для сотрудников. Вы думаете я хотел это делать и увеличивать этим объем кода?) Нет, конечно. Но ничего не попишешь, ч за это деньги получаю
раскрыть ветку (3)
И я разработчик. Но только аргументация у тебя хуевая.
Ты прав, что, у тебя есть выбор. Ты, правда забыл, что разные люди обладают разной квалификацией, так что там, где один потратит много времени на говно, другой сможет потрать меньше времени на рабочее решение.
А вот далее начинается то, что ты говорил - бизнес экономит деньги (сложно их винить в этом), бизнес не умеет оценивать риски (а подсказать некому), а пользователи выбирают не только приложение, но и услугу этого бизнеса.
Отсюда и получаем большие программы: разная квалификация и разные приоритеты.
раскрыть ветку (2)
Не, ну конечно я не учитывал квалификацию, здесь была задача объяснить что не все так просто, это не разрабы вконец обленились (такое тоже есть), есть и другие факторы
раскрыть ветку (1)
так он и говорит про "рабочее дерьмо". Оно дерьмо, и оно работает. Всех интересует только то что оно работает, никому не интересно что оно дерьмо)
раскрыть ветку (4)
И далеко не всегда это дерьмо.
В общем-то обычно техлиды и тимлиды очень настороженно относятся к затаскиванию новых зависимостей на проект.
Но вот взять например авторизацию по OAuth2.0
Есть фреймворки которые мало того, что реализуют OAuth mиз коробки, так они ещё постоянно обновляются. Из них постоянно выпиливаются уязвимости.
Т.е. чтобы написать условную приложуху для пиццерии с современной авторизацией через OAuth2.0 (а также по кнопке Гугл ID/ЯндексID/VK ID)
Нужно внезапно стать гуру по секьюрити, всё учесть и не делать ошибок. Правда только на авторизацию потратишь многие сотни часов.
А потом ещё много часов, если условный Гугл изменит протокол обмена данными при авторизации через свою кнопку.
А можно просто подключить готовый фреймворк и за неделю всё настроить в идеал.
Разница будет и в качестве и в скорости. Но да, придётся заплатить объёмом.
Благо что этот объём сейчас почти ничего не стоит.
И для условной пиццерии вопрос не стоит. Она либо делает своё приложение на фреймворках за полгода и за 5млн. р., либо не делает вообще потому что написать всё с нуля будет стоить кратно больше и по времени и по деньгам.
раскрыть ветку (2)
А разве её готовят по-другому? Разве кто-то там изобретает с нуля молекулярную кухню?
Как раз так и делают - поливаем дерьмом поля, получаем корм скоту, далее кормим скот (ну и заливаем антибиотиков, но так, чтобы проверяющие не заметили), потом продаем мясо так, чтобы не были заметны проблемы, а далее жарим на сковороде, но не моем её идеально каждый раз.
раскрыть ветку (1)
но можно и хуже. взять готовое, недоеденное кем то из тарелок. надкусанное отрезать. грязное помыть, и на новую тарелку.быстрее же )
Изменилась концепция. Я помню, как учили в 2005 году ещё - заморачивались на памяти и ее использовании, тк ее стоимость была дорогой и являлась реальным ресурсом + пропускная скорость интернета оставляла желать лучшего. Это были одни из важнейших ограничений. Сейчас же память стоит копейки (что оперативная, что жесткие диски). Скорости интернета в тч мобильного выросли кратно.
И всё. Ограничение стало условностью. Нет смысла упарываться в память. Те же 400 мб сейчас скачиваются и хранятся в стоимости ниже чем прошлые 40. Теперь многие расчеты и генерации можно вынести на устройство пользователя, а не сервера. Сейчас мощность телефона больше чем ПК в 2000.
+ спрос на свистоперделки вырос. Причем вырос и со стороны пользователя. Хотят красиво и быстро.
Так что это обычное развитие с логичными причинами.
раскрыть ветку (1)
Ну вы же хотели быстро, дёшево, со свистоперделками. Вот и кушайте. Рыночек и бизнес именно так и работает. Работа программиста стоит дорого. Да и дефицит их хронический. Итог вот. Какие задачи ставят перед программистами так они и решаются. Поставили бы что надо хорошее, оптимизированное и есть на это время, было бы по другому.
раскрыть ветку (4)
раскрыть ветку (3)
ага, наверное поэтому у них одни из самых больших зп. Ведь работодатели из чистого альтруизма её платят, хотя за забором очередь стоит программистов. Это ведь не рыночек порешал. Это работодатели добрые....
раскрыть ветку (2)
Большие зп потому конкуренция по всему миру, а не по Урюпинску, где 3 завода и сговор генералов не переманивать и не повышать
раскрыть ветку (1)
да и в Урюпинске нет программистов просто. Потому пофигу сколько там заводов и какой там сговор...
Да не особо то он и прав. В приложении содержаться файлы под разные конфигурации телефонов(архитектура проца, разрешение экрана и т.п.). Т.е. в приложении может быть 10к изображений под HD, 10к под full HD, 10к под 2к и т.д. Гугл, вроде, хотели сделать установку только нужных частей приложения чисто под железо.
В том, что приложение включает в себя целую экосистему а не просто банковское приложение. Это уже суперприложение как и Яндекс GO и 300 мб херня. Большое количество ресурсов уже внутри и подтягивать их каждый раз в кэш не нужно.
раскрыть ветку (32)
Ну так расскажи, объясни непосвящённому народу почему у меня приложение озон весит 360 мб? Что там может весить 360, блять, мегабайт? Или ты просто ляпнул не подумав?
раскрыть ветку (31)
Бизнес приходит к программисту и говорит нужно сделать приложение. Ему отвечают 1 вариант 1₽ и 1 день, берем кучу фреймворков и все по-быстрому пишем. 2 вариант 2₽ и 2 дня, пишем на чистой джаве с нуля, будет весить в два раза меньше и в 2 раза быстрее. 3 вариант 3₽ и 3 дня, пишем на языке ассемблера, будет в 4 раза меньше весить и в 10 раз быстрее. Бизнес выбирает первый вариант.
раскрыть ветку (6)
Скорее с фреймворками 1р. и 1 день.
На голой джаве 5р. и 5 дней (без Спринга, Секьюрити и JPA, и кстати отсюда скорее всего с упрощённой безопасностью)
На ассемблере 20р. и 200 дней (но только под одну платформу)
раскрыть ветку (2)
раскрыть ветку (1)
когда начинают доводить все хотелки, которые не укладываются в стандартные схемы фреймворка, тогда всё и вылазит, но потом, после MVP
Скоро будет вариант номер 0. Код будет писать нейросеть под управлением уборщицы. Приложение будет весить десятки гигов и работать соответственно.
раскрыть ветку (1)
Ну так раньше, например, сайты писали "под заказ" от $2500 на php (давно это было). Сейчас для себя можно за это 20 минут бесплатно на Вордпрессе сделать.
ещё комментарии
Потому что уменьшение размера приложения не принесет денег бизнесу, но потребует больших затрат.
раскрыть ветку (1)
Ради интереса глянул, там половина размера это библиотека Яндекс карт под разные архитектуры.
Судя по всему это универсальное приложение, если делать отдельное под каждую архитектуру, то оно бы весило где-то 180МБ, если убрать Яндекс карты, то 100 Мб ))
Само приложение весит вполне приемлемо для своей функциональности.
ещё комментарии
Т.е. скачивая ozon, я по сути ещё и Яндекс карты скачиваю? @Ozon, а ну ка иди сюда, блять, и попробуй это объяснить
раскрыть ветку (2)
Это только библиотека для работы с картами, а не всё приложение. Ты же хочешь пункты выдачи сразу на карте видеть, а не копировать адрес каждого и вбивать в другое приложение?
раскрыть ветку (1)
блин, а мне б вполне хватило чтобоно мне адрес написало, я как я найду, картами, яндексом, гуглом или по памяти своей. мое дело. а они вот так. я читаю всю тему, вникаю. пихают что нужно не всем, что не нужно многим, и еще на всякий случай. я себе вобще не ставлю ни озон, ни спортмастер, ни банковские, и прочие магазинно-услуги. во изза этого.
ещё комментарии
Библиотеки и модули, которые прикручиваются как коляски для мопеда, во многих функционал дублируется, но так быстрее разработчикам, а значит и дешевле бизнесу.
К примеру, чтобы написать с нуля раздел отзывов на озоне надо 6 месяцев и 3 программиста (пример из головы, я брежу), в итоге получится компактная подпрограмма весом в 1,5 МБ. Т.е. добавление простого функционала займет полгода работы, готовы столько ждать? А если дорабатывать потом, то еще месяц-полтора вручную лопатить голый код. Вместо этого 2 программиста средней руки, имея удобный конструктор могут собрать тот же модуль за 1,5-2 недели, но весить он будет 20 МБ. Это быстрее, удобнее и позволяет развивать сервисы. Первая фирма, которая сейчас начнет отступать от этих стандартов очень скоро отстанет от конкурентов
К примеру, чтобы написать с нуля раздел отзывов на озоне надо 6 месяцев и 3 программиста (пример из головы, я брежу), в итоге получится компактная подпрограмма весом в 1,5 МБ. Т.е. добавление простого функционала займет полгода работы, готовы столько ждать? А если дорабатывать потом, то еще месяц-полтора вручную лопатить голый код. Вместо этого 2 программиста средней руки, имея удобный конструктор могут собрать тот же модуль за 1,5-2 недели, но весить он будет 20 МБ. Это быстрее, удобнее и позволяет развивать сервисы. Первая фирма, которая сейчас начнет отступать от этих стандартов очень скоро отстанет от конкурентов
раскрыть ветку (3)
типа все компании гоняться за фичами обновлениями с фичами и скоростью внедрения. и пох на то как это жрет железо пользователя. он пойдет и купит новое под все это. чтоб летало. так? разве нет тех, кто за простоту, или они не выживают? может, не умеют себя подать-продать? может ли кто то выускать, к примеру, приложение для пользования озоном. но чтоб оно простое, пусть и ограниченое, только самое важное?
раскрыть ветку (2)
раскрыть ветку (1)
да я и так делаю. Просто на сайты. Что банки что озон. Почему то стараюсь не пользоваться приложениями, кроме узко рабочих, развлекательных, где понимаю что и для чего без массы лишнего. Была у меня чуйка что чем дальше тем больше в приложениях фич красота и не нужные массивы для меня . Пикабу подтвердил
или какой-нибудь ебаный телеграм на компе жрет опертивы раза в три больше, чем нужно винде виста для работы епто
раскрыть ветку (4)
Мощности железа другие сейчас хоть пол компа запусти с браузером на 50 вкладок и это всеравно не забивает оперативку, и где-то там телеграмм на 700мб вообще не ощущается
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
у меня в домашнем ноуте 6. и это я расширял.. а сайты стали что звездец. и озон этот, и спортс.ру и этот пикабу. как вот пикабу оптимизировать страницу, не подскажите?
так они туда наверно броузер засунули, + часть приложения на js, вместе со всеми
фреймворками, библиотеками и их зависимостями
Например варианты интерфейсов под все возможные комбинации экранов. Альтернатива - писать отдельное оптимизированное приложение под каждый телефон. Тогда приложения будут маленькие и быстрые, но для твоего конкретного телефона ты его можешь не дождаться.
раскрыть ветку (6)
Почему тогда разные лаунчеры, которые как бы тоже содержат всякие вариации для разных экранов и т.д. весят по 10-20 мб.
раскрыть ветку (1)
Лаунчер в принципе проще. Его можно долго вылизывать. Банковское приложение постоянно подстраивается под нужды бизнеса.
Собственно, Гугл плей сейчас грузит на телефон именно оптимизированное приложение под конкретную платформу.
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
Нет - как раз разметка это основная масса объёма. Вообще если глубже лезть в тему кроссплатформенность сегодня достигается средствами типа electron-а. А там ассеты как раз и занимают весь объем. И вся отрисовка это просто веб приложение со всеми вытекающими. Вообще тут выбор или качественно или быстро. Или у вас все и сразу в приложении но неоптимизировано или "подождите - мы оптимизируем" и добро пожаловать в офис.
Дьябла первая и старкрафт первый на винте в 180 Мб как-то уживались, ещё раз!!! 180 Мб и две акуительные игры + виндовоз 95!!!
Во всем, тут уже ниже ответили, дань за использование фреймворков. Иначе получим сроки такие, что никому не понравится.
раскрыть ветку (13)
раскрыть ветку (12)
У Сбера прекрасное приложение, да в целом у всех топ банков классные приложения и работает все здорово.
А то что оно могло весить 100мб, а весит 350мб, да похер, смысл бизнесу тратить миллионы что бы 1% юзеров оценили и главное это принесет 0 денег.
раскрыть ветку (9)
раскрыть ветку (8)
Я бы даже сказал что это цена в баксах. Зп только 10 программистов на месяц работы порядка 3 миллионов рублей. За месяц они хрена справятся. С учетом тестов, разработки и на скольких моделях телефонов это должно безупречно работать. И еще не известно сколько будет стоит поддержка этой оптимизации в долгосрочной перспективе.
раскрыть ветку (3)
а если заложить на будущее? да, сейчас на фрейворках, но уже готовить свою новую разработку, на продуманной архитектуре, со взглядом в будущее, и отбор фрейворков тщательней. чтоб потом приятно и летало, и в будущем на этой платформе уже продолжать? или это тоже нахрен не сдалось. и вобще, нам пох что потом, нам сейчас, а в будущем может я уже и не здесь буду командовать. я далек от програмирования и управления бизнесом. вот читаю всю вету. вникаю. охреневаю от мимолетности и типа что потом нам пох. это только в росии так, или мировая тенденция?
раскрыть ветку (2)
Давайте так, я не специалист по разработке мобильных приложений, поэтому будет в общих чертах и без деталей.
Представьте что есть определенный framework, он позволяет писать достаточно просто приложения и поддерживает широкий спектр мобильных телефонов. Этот framework известен, в случае чего можно найти специалистов, которые с ним работали и знают как он устроен. Более того, он постоянно развивается. И пишет его команда в несколько сотен специалистов. Зарабатывает тем, что широко его продает в те же банки, условно. И другим желающим написать свою приложуху.
Если Вы пишите свой, то вам нужна команда, которая будет дружить его все с новыми и новыми мобильниками. Поддерживать и разрабатывать новые функции, которые могут появлятся в этих мобильниках. Не дай боже будет переход на какой-то новый стандарт связи или wifi протокол. Это уже огромные затраты. Если еще держать специалистов в штаты по протоколам связи, проблема будет еще в том, что им без работы будет скучно, они будут терять квалификацию. А найти быстро, когда появится новый - та еще проблема. Ну, и еще момент, пока ваша команда будет адаптировать свой фрейм под новые телефоны и стандарты - это время. А конкуренты уже будут работать. И вот тут думай, лучше жалобы пользователей на 600 мб приложение или массовый переход в други банки, потому что приложение по полгода не работает. Если время разработки framework ускорить, то команда должна быть сравнима с коммерческой, которая свой frame продает.
Потом, нанимая нового разработчика, Вам придется его обучать с полгода работе с вашим framework, как минимум.
Вот просто представьте примерно уровень затрат на разработку и поддержку своего этого самого framework. А для чего? 300 мб сэкономить? Ну, как бы задача в такой постановке выглядит просто идиотски.
Что же касается подхода, то он везде плюс минус такой. Россия тут не какое-то исключение. Скорость разработки критически важна в любом бизнесе, оптимизация и красивая архитектура стоит дорого и по сути не нужна никому. Этим всем занимаются только в случае когда вот эти направления являются критическими для приложения. В условной космической отрасли, где просто так лишний гиг памяти не вхерачишь, например. А для пользователя, плюс минус гигабайт - похрен.
раскрыть ветку (1)
Это может стоить и миллиарды. Вы представляете, сколько человеко часов на это уйдет? У меня вот по примерным подсчетам в команде уйдет год чтобы перевести проект на новую версию фремворка. Это год времени десяти человек. По зарплате только - уже лямов тридцать выйдет. Это еще без упущенной выгоды от того, что эти люди не разрабатывают новые фичи.
Код старый, в нем надо разобраться полностью, переписать большую часть, покрыть тестами, оттестировать вручную, выкатить на одобрение, потом доработки, баги и тд. Это не просто так делается, что мы херак херак, приложение стало на 300мб меньше
Код старый, в нем надо разобраться полностью, переписать большую часть, покрыть тестами, оттестировать вручную, выкатить на одобрение, потом доработки, баги и тд. Это не просто так делается, что мы херак херак, приложение стало на 300мб меньше
раскрыть ветку (1)
Команда программистов, пусть 10 человек с зп от 200к/мес. Плюс столько же тестировщиков с зп от 100к/мес.
За месяц работы эта команда на зп съест 3 ляма. И это только на руки. Работодатель потратит ещё столько же в разные фонды/налоги. И это без учёта других участников. Да, оптимизация стоит миллионы.
Да. Десяток интеграций со сторонними сдк и там накапало, тут накапало. Там целые команды писали эти сдк. И что теперь все с нуля, но самим, с отладочкой, по чужой документации писать, которой нет и не предоставят? Чтобы через пару месяцев они теряли совместимость так как эти сторонние сервисы обновились?
Ну или под последний айпад с каким-нибудь квадро hd экраном нужно вставить соответствующую тяжеловесную графику. Ты что будешь писать второе приложение под них или дополнительно загружаемый пакет, требующий ожидания и подтверждения владельца таких девайсов? Да ебал ты все эти проблемы. Впихнешь все в один пакет и оно все равно запустится у большинства. Кроме сотни Олегов и Сереж, засравших память на своих нишевых девайсах, и которым лишние 250мб критичны.
Тут скорее вечное противостояние идеализма и реализма. Я от тоже к лету худел, но взял и растолстел 😁
А зачем что-то оптимизировать по размеру? В этом есть какая-то необходимость? У вас на телефоне памяти мало? Или может быть трафика мобильного не хватает? И вайфая домашнего нет? И стоит диалап? Какая разница, скачается приложение за 10 секунд или за 20?
Оптимизация это же тоже труд, который нужно оплачивать, и время. Зачем тратить время и деньги на бесполезные вещи?
раскрыть ветку (12)
раскрыть ветку (9)
А по существу есть что возразить?
Есть разумные ограничения. Если приложение банка будет весить пару Гб, то это уже причина для оптимизации. Говорить же, что 350 мб это много - ну не знаю. Т.е это конечно много, это сильно больше, чем нужно. Но благодаря этому скорость разработки вырастает существенно
раскрыть ветку (8)
по существу - пришлось мне как то качать как раз вот это ебучее приложение зеленого банка, в месте с не самым хорошим мобильным инетом, прямо сцуко в отделении этого банка, чуть не перед банкоматом. Дело не в гигах и мегабайтах - если приложение может весить в 10 раз меньше - почему оно весит в десять раз больше??? потому что всем похуй??
раскрыть ветку (7)
Потому что в 10 раз меньше оно может весить не бесплатно. Игры/приложения раньше оптимизировали, чтобы они влезли на диск, или чтобы их можно было скачать с тогдашним интернетом, или потому что у людей были не очень большие жесткие диски/объем ОЗУ. Сейчас этих всех проблем просто нет. И если приложение имеет разумный размер (не минимальный, а разумный, подчёркиваю), никакой бизнес не будет просто так тратить деньги на уменьшение размера.
раскрыть ветку (4)
именно поэтому сцуко я матерюсь, видя что сраная дота 2 весит 45гигов, вместо 14.
С приложениями на мобилах так же - весило 30, стало весить 300, и всем пох
раскрыть ветку (3)
Ты не понимаешь как это устроено. Хуже не стало. Стало по-другому. Конечные программисты не при чем. Пока продукт запускается у 80-90% приносящих дивиденды аудитории менять ничего не будут. Иначе тебя опередят конкуренты пока ты будешь рвать жопу ради 100%.
раскрыть ветку (2)
Не может оно весить в 10 раз меньше. Его делают универсальным и ориентируются на последние флагманы с их экраном и графикой. Иначе надо держать актуальными 2 приложения, а это форменый пиздец. Но иногда такое делают. Вообще это проблема самой среды и правил установки конкретно андроида и айоса. Возможно потом сделают возможность легкого способа установки разных версий, но, скорее. мобильный инет ваш обновят на месте и все.
раскрыть ветку (1)
Ну вот зачем ты так? Я просто объясняю, как это работает и почему так происходит.
@moderator, по-моему, тут перебор
Ну например в том, в чем не разбирается. Например в том, что такие приложения собраны в режиме DEBUG и имеют кучу включенного кода для отладки. С одним я только согласен - нахуя это делать в, казалось бы, релизе. Но это не показатель неграмотности программистов, это скорее показатель похуистичности менеджеров и руководятлов, что не могут реализовать нормально тестировку. Или жлобство собственников, которые не хотят платить тестировщикам и считают, что простой люд им всё оттестирует за так.
раскрыть ветку (6)
на мобилку в дебаг ты не соберешь приложение, точнее на площадку выложить такое не получится
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
А вы релизным сертификатом переподпишите) А внутри хоть дебаг панель, хоть логи на каждый чих, хоть черт лысый.
под программистами вся команда разрабов имеется ввиду, я так понял. Ну у одних задание хз, у других тестировка у третьих кошка рожает и тп. Я не говорю что кодеры писать код не умеют, они вообще люди подневольные наверное - сказали "сделать так" вот и делают
баги бывают с "подвывертом", поэтому даже если тестировщики есть, то отладочные журналы ведут
Просто используются общие полноразмерные библиотеки, в которых используется только пара функций, а остальные пару тысяч не используется. Можно, например, взглянуть на всякие jar файлы, мелкая херня может весить десяток мегов, причем используется она для минимум действий, например забор из кафки и перенос на бд. Почти весь вес берётся из библиотекам к ней, который может составлять все 99% от веса. Просто раньше разрабатывали с нуля, используя все средства. Сейчас такой нужды нет.
раскрыть ветку (3)
Я помню исследователи нашли что одна и та же библиотека добавлена 4 раза в приложении фейсбука
раскрыть ветку (2)
Вообще неудивительно) Ща много где микросервисные архитектуры, где может быть 10 сервисов и у каждого одна и та же библиотека, которая хранится у каждого сервиса отдельно)
раскрыть ветку (1)
Во всем он не прав. Приложения весят столь, из-за используемых библиотек и апи. Допустим есть у тебя библиотека на 350 функций из пользуешь ты только вприложении 10-20 но в билд попадет полная библиотека, либо будь добр написать свою, а это время, время это деньги. Вот и вся логика.
Во-первых, не все программисты такие.
Во-вторых, нормальных программистов такие «программисты» бесят намного больше, чем людей не из айти.
В-третьих, вы попробуйте продать тому же Сбербанку какую-нибудь подпрограмму для их приложения - они захотят, чтобы она весила не больше 2-3 мегабайт, даже если это сложная биометрическая сетка.
Ну и главное - толерантность наших людей к глупым. Говорите им об этом, а не молчите. Эти программисты, не оптимизирующие ничего никогда, в большинстве случаев ПТУшники в самом плохом смысле этого слова. Однажды я от таких слышал «а вы что думали, что мы будем без ошибок код писать», т.е. человека не смущает, что он делает кучу ошибок, и он считает своим правом писать говнокод
раскрыть ветку (30)
Давайте так, писать код без ошибок невозможно. Другое дело что ошибки не должны добираться до прода - раз. Для этого придумали тестирование - ручное, автоматическое, интеграционное и пр. Всякие NASA разрабатывают методики и даже специальные языки программирования и все равно случаются ошибки.
Второе, представьте что приложением пользуется 100500 человек год и тут один находит ошибку, что 29 февраля, в хитрый отчет не строится. Т.е. 100499 этот отчет нах. не нужен, а вот одному вперлось. Так вот, чтобы пофиксить баг вам надо заново потратить 200 человеко-часов, читайте заплатить х.ххх $.
Заниматься багами которые затрагивают менее 1% пользователей вообще бессмысленно и экономически не выгодно(за рядом исключений вида репутационных потерь).
раскрыть ветку (1)
Я писал не про случайные баги, которые еще надо поискать с помощью того самого тестирования, чтобы найти. Есть очень обширный слой "программистов", которые даже не запускают то, что напрогали. Запрогали, а запускают пусть тестировщики, я же не тестировщик. И самое ужасное, что с "рангом" процент таких программистов растет. Т.е. люди хотят получать 300-400-500к, но при этом делают работу на уровне "это вам надо, а не мне, мне нужна только зарплата". Понятие репутация перестает существовать. Однажды я уволил одного сеньора, который на сеньора тупо не тянул. Он пошел искать работу. Мне позвонили несколько компаний (малых и средних), спросить, что до как. А вот Сбер не позвонил и взял его тимлидом.
раскрыть ветку (1)
Абсолютно согласен. Но существуют разработчики, которые считают, что отдел тестирования нужен не для того, чтобы искать баги, а для того, чтобы проверять, работает вообще их код хоть как-то или нет
Да, да, везде работают ПТУшники. И в сбере и в яндексе и в яблоке и в гугле, один Вы Дартаньян.
раскрыть ветку (11)
Вам рассказать историю, как группа СберТеха год не могла уволить такого "птушника", а потом решила сбагрить его на повышение? И теперь этот ПТУшник там еще решения принимает?
Не знаю, что в Яндексе сейчас (он очень сильно испортился после смерти Сегаловича), но 10 лет назад человек без образования мехмата или физтеха их суточные собеседования пройти не мог
раскрыть ветку (10)
Какой-то Вы не последовательный. В посте речь идет о размере приложения. Ваш коммент ответ на слова «ну и в чем он не прав???»
И в вашем комменте есть такое: «Эти программисты, не оптимизирующие ничего никогда, в большинстве случаев ПТУшники в самом плохом смысле этого слова.»
А теперь посмотрите на размер таких прил:
Pages, Numbers, Keynote - 400+ MB, ПТУшники в Apple
Facebook - 310 MB, ПТУшники в фейсбуке
TikTok - 328 MB, и тут тоже
HP Smart(прила для принтеров на iOS) - 271 MB, даже до HP ПТУшники добрались
ПТУшники, они повсюду.
раскрыть ветку (9)
Что написано в моем ответе - нормальные программисты все оптимизируют. Также там написано, что существует куча птушников (которые прям по определению птушники), которые этого не делают. По Вашим примерам - фейсбук все съоптимизировал донельзя, его 310 мегабайт - это не код, а веса сетей. Не уверен, но в случае ТикТока аналогично. Фейсбук, Гугл, Майкрософт - это раньше был топ по программистам, аналогично Яндексу 10 лет назад. А вот про Эпл я этого сказать не могу. Почему - потому что не знаю, что там, зато знаю однокурсников, гуляющих между первыми тремя и никогда даже не думавших заглянуть в Эпл. Подозреваю, что Эпл специально делает приложения огромными, чтобы покупали более дорогие версии айфонов и макбуков. Ведь в обычный комп можно купить ssdшку побольше по рыночной цене, в андроиды можно купить карту памяти по рыночной цене, а вот для техники Эпл этого сделать не удастся.
раскрыть ветку (8)
«Подозреваю, что Эпл специально делает приложения огромными, чтобы покупали более дорогие версии айфонов и макбуков»
После этих слов в принципе не вижу смысла спорить, сначала снимите шапочку из фольги.
раскрыть ветку (3)
Пусть я в шапочке, а Ваша-то версия какая? Откуда у приложений Apple такие требования по месту?
раскрыть ветку (2)
По моей версии - дело во встроенных медиа файлах. По мне - это главный бич размера приложений. Даже если грузить картинки с бэка - это все равно либо увеличивает размер кэша, либо скорость загрузки страничек.
раскрыть ветку (1)
Если Вам интересно, то я провел небольшое исследование, что же там у HP внутри 300 мегов. Конечно, они не могли обойтись без кучи шрифтов и картинок на десятки мегабайт. Хотел добавить гифку с двумя буквами HP, которая весит 30 мегов, но это слишком много для Пикабу) На мой взгляд, это чистой воды брак тех, кто делал, потому что в этих картинках нет ничего, что нельзя было бы сделать векторным. Даже больше скажу - там оригинал точно был векторным. Так что вот то, что я называю "плохими программистами".
Но там есть еще кое-что, что занимает львиную долю:
"WinMLTools using keras2onnx1.4.2-1.8.1"onnxmltools", "ConvertImageToTensorAsync", "block4a_bn"BatchNormalization*" "gaussian mixture model" - там сетки, причем нелегкие, и статистические модельки.
Оптимизация это бизнес задача, которая ставится только когда это действительно необходимо. За 10 лет моего опыта, в командах в которых я работал, в т.ч. банковских проектах, была только 1 раз задача на оптимизацию, когда выкатили изменение для микросервиса, которое увеличило счет за aws чот типа на 7 тысяч долларов) Это был единственный раз, когда я на работе запустил профайлер.
раскрыть ветку (3)
Смотрите, реальный случай - проект связанный с machine learning, внутри sdk есть сети, которые весят в сумме пару гигабайт. SDK необходимо собрать под несколько платформ (штук 10). Существует отдельный арендуемый сервер для гитлаба, на котором «неожиданно» заканчивается место и требуется доп оплата. Причина - программист решил, что ему удобнее для каждой сборки делать копию сетей (те самые гигабайты). Дальше ещё интереснее - в офисе кроме программистов сидит рисеч, который по роду своих занятий сеть наружу занимает существенно. И вот в один прекрасный день интернет становится подозрительно медленным. Причина - программист собирает десять сборок, десять раз выкачивая снаружи одни и те же гигабайты. Вот как вы считаете - на изменение данной ситуации нужно заводить отдельное ишью? Или все-таки нормальный программист (тимлид) должен был сам изначально сделать нормально?
раскрыть ветку (2)
Ну если это решение тимлида, то это проёб конеш, тимлиды на то и нужны, чтоб такой херни не было.
раскрыть ветку (1)
раскрыть ветку (13)
раскрыть ветку (12)
Верим. А увольнение программистов - это видимо показатель крутости и профессионализма, который сильнее увеличивает нашу веру
раскрыть ветку (11)
Ну т.е. результат работы плохих программистов нам не нравится, но увольнять-то их за что?! Это самодурство начальства!!! Так?
Смотрите, если вы видите такой продукт (продукт, занимающий неадекватно много места). То возможны следующие варианты:
1) вы не понимаете, почему он столько занимает места (в реальности такого варианта с продуктами для физиков почти не бывает)
2) продукт писали плохие программисты, которые «делали сортировку пузырьком»
3) было принято менеджерское решение, что в продукте должно быть то-то и то-то, а на размер менеджеру чихать
Пункты 2) и 3) - это плохие руководители, а не программисты. Потому что пункт 2) не может быть допущен до релиза, а пункт 3) - если у вас калькулятор слушает микрофон, анализирует тяжелой сеткой все произносимое вокруг и потом, в лучшем случае, продаёт контекстную рекламу, то значит, менеджеры этого продукта-калькулятора не очень хорошие люди.
раскрыть ветку (10)
Ну во первых, требование к размеру файла - очень специфическая задача, которую ставят в условиях нехватки этой самой памяти. Когда ты говоришь про оптимизацию ты явно путаешь занимаемое установочным файлом место/занимаемое установленной программой место с производительностью.
Если говорить о приложении скажем банка, то то уже давно не место где ты смотришь баланс. Это суперапп где ты разве что проститутку вызвать не можешь(и то не факт). Это требует места. Разработка с нуля почти невозможно в приемлемые для бизнеса сроки, а значит использование фреймворков необходимо. Это требует места.
Кроме того банки и не такое уже давно и успешно собирают не только персональные данные, но и метрики устройств ведут и прекрасно понимают какими устройствами в среднем обладают и будут обладать их клиенты. Если в среднем по больнице места будет не хватать то они станут выбирать что поставить, а куда по вебморде заходить. Это никому не надо. Следовательно имеется определённый консенсус между текущими возможностями устройств и оптимизацией толщины приложения.
Теперь про убогое "плохие программисты". Тут конечно больше вопросов чем ответов.
Во первых, с чего ты решил, что программисты были плохие а ты хороший менеджер? Ой не факт ой не факт.
Во вторых что такое " Плохой программист"? Судя по одному из твоих предыдуших сообщений этот тот, который не предугадывает всё хотелки, даже те, которые задачей не учитывались. И да, на оптимизацию ставят отдельную задачу. Если гениальный менеджер не знает, что в задаче на добавление функционала принято делать то, что задачей и предусмотрено а не в е подряд то моё почтение... Предвосхищая нытьё типа "чтооооо значит можно делать всё тяп-ляп лишь функционал был реализован пляк пляк" отвечу что нет и никто так не делает. Но есть объективные рамки между решением бизнес задачи в срок и качеством. Качество должно быть приемлемым всегда, но оптимизация производительности или размера - это очевидно даже таксисту - отдельная задача, которая банально может быть не видна на уровне "сделай выгрузку в эксель".
Ну и до кучи смешались кони, люди. Программисты, работа которых не нравится, плохие(по какому критерию) программисты... Сдаётся мне, джентльмены, ты банально не умеешь нанимать, ищешь самых дешёвых специалистов а потом ездишь на них. Такие местечковые конторы я видел, где переработки норма, команды составляют из одного Сеньора который готов тащить всё на себе и днём и ночью и пятерых джунов за 30ку, которые либо уходят через год набравшись опыта от щедрого предложения в 40к либо выгорают нахуй
раскрыть ветку (9)
Товарищ, извини, но ты опять не попал, прям как с опытом. Не попал даже в том, что я менеджер. Про зарплату вообще смешно, потому что дело было пару лет назад и зарплата была 400+ плюс доля в компании. Я извиняюсь, но начиная с некой суммы ты не бегаешь и не ставишь задачи дословно с абсолютно формальной постановкой, все же взрослые люди. Если человеку задачу надо ставить на уровне псевдокода со всеми подводными камнями, то нафига он нужен?
Про специфичность задачи размера - нифига она не неспецифическая. Это нам, китайцам, корейцам и ещё нескольким странам повезло, а во всех остальных будет нечто типа «40 мегабайт, вы что, это очень много, как наши пользователи столько скачают? Это очень долго(дорого)!!!» Вот предположим сбер перестало устраивать распознавание по лицу (все лица в открытом доступе, лайвнесс обманывают, ну его нафиг, давайте добавим вторую модальность) и решил добавить кроме лица распознавание по фото попы (норм задача 😜). Вот попробуйте им предложить что-нибудь, что будет больше 10 мегабайт :) А код-то там весит вообще почти ноль, ещё чуть больше нуля Фреймворк, основная часть сеть, которую сделать маленькой и рабочей - без комментариев, сколько усилий надо. А потом ты видишь итоговое приложение, которое весит полгига и сильно печалишься…
В общем, что я пытался сказать своими комментариями, а вы не поняли. Основная причина описанной проблемы - толерантность оценивания работы (начиная со школы, продолжая в универе и заканчивая на работе). Мне повезло - и в школе, и в универе, и на работе меня оценивали по результату, а не по процессу. Должно быть пофиг, сколько ты времени потратил на работу, если ты ее сделал плохо/неправильно, то ты ее не сделал. Нельзя ставить тройки/зачеты за работы про по факту того, что их делали. Если ты писал месяц диплом, написал 100 страниц, а на первой ошибки, то твоя оценка два, иди и переделывай. Если в образовании будут такие критерии везде, а не только в небольшом количестве мест, то тогда и не будет описанных мною ситуаций, когда люди не понимают, почему ими недовольны, они же работали, написали 100500 строчек кода, плохого кода 🤷♂️
раскрыть ветку (8)
Если в компании сумма в квиточке коррелирует с постановкой задач, хоть со стороны того кто ставит, хоть со стороны тому кому ставят, то это конечно знатная помойка))) ну и классика передергивпний ололо неужели формализовать до буковки11!! 1!. Здесь как и в любой ипостаси нужна умеренность и консенсус. Иначе нахуй тебе трекер задач то вообще? Подходи просто на бумажке пиши - Вася, сегодня делай интеграцию с клиентским фидом какой нибудь маркет даты. Вас умный Вася должен сам додуматься какая маркет дата нужна, как её интегрировать, для чего он же получает 400к) иначе он "плязой программист" увольнять увольнять)
Насчёт задачи - пишешь что неспецифическая она и тут же выкатываешь специфические условия. Где логика?
А на счёт толерантности - это видимо какой то комплекс, триггер больной на слово. Нигде, кроме каких то сугубо единичных случаев никто не продолжает сотрудничать с исполнителями, которые систематически не исполняют, проваливают, как либо ещё способствуют получению неудовлетворительного результата.
Я полагаю у тебя какие то сложности с таким аспектом командной разработки как софтскиллс. Быть мудаком даже если кто то косячит не эффективно, всё это давно уже поняли. Почти все
раскрыть ветку (7)
Ну Вы пишите неправду - размер приложения на телефон во всем мире неспецифическая задача.
Дальше Вы пишете неправду про сотрудничество с неэффективными исполнителями. Вы российский ТК видели? Человека невозможно уволить, если он мудак, который прочитал ТК и хочет над вами поиздеваться. Я знаю кучу примеров, где единственным способом избавится от такого человека было «переложить эту проблему на других»
Ну и передергиваете Вы про постановку задачи. Ещё раз - если программист (да и любой другой специалист) хочет получать хорошее вознаграждение, то он не может требовать, чтобы с ним вели себя как с ребёнком в детском саду. Он должен уметь принимать решения, уметь отстаивать эти решения, уметь отвечать за них. В том числе он должен понимать, что про выбор между “i = i + 1 vs i++” он сообщать другим не должен, а про выбор конкретного алгоритма, как он будет выбирать из миллиарда значений топК - надо сообщить и обсудить. И выбор того, о чем сообщать, а о чем нет, должен быть на нем, потому что иначе он джун. И специалист, который приходит и говорит «я вот тут хочу сделать так, но не уверен, что это оптимально, что думаешь» намного ценнее, чем специалист, который изобретает велосипед кривой, а потом приходит и говорит, что что-то херь получилась, надо бы исправить. А Вы сейчас пропагандируете подход «я специалист, я все знаю, но если вдруг я что-то сделаю криво, то это будет ваша проблема, так как вы отдельно до меня не донесли, что надо было делать вот так»
раскрыть ветку (6)
Размер приложения на телефон никому вообще не важен, даже пользакам(кроме единичных экземпляров) поэтому никто не рвёт жопу что бы сэкономить 3 мегабайта. И правильно делают в условиях рынка. Но вы почему то ноете про плохих программистов. А специфичкская это задача потому, что есть класс приложений, которые должны работать в условиях ограниченного количества Зу и ОЗУ. И для них специалисты напрягают свои мозги - потому что это их бизнес задача.
Не надо вот этой софистики и нытья про тк. Я вот знаю кучу примеров где работадателя тк не смущает и он вполне себе издевается над сотрудниками. И чем твои примеры лучше моих? Я вот думаю что ты говоришь неправду.
Нет ч не пропагандирую такой подход. Я пропагандирую эффективность. Её формула хоть и известна уже не один год, регулярно находятся люди которым невдомёк.
раскрыть ветку (5)
Ну класс, "размер приложения на телефон никому вообще не важен" - а с чего тогда топик-то весь начался? Вы когда-нибудь пробовали писать какие-либо продукты под телефоны? Вы заблуждаетесь, что размер никому не важен. Он относительно не важен в странах с хорошим и доступным мобильным интернетом и то, это "не важен" превращается в то, что заказчики готовы терпеть 50 мегов, а не 10.
Если работодателя не смущает ТК, то он либо идиот, либо уверен на 100% в своих холопах, которые не пойдут и не нажалуются. Во всех иных случаях работодатель очень вежливо и аккуратно себя ведет.
Я правильно понял, что Ваша эффективность заключается в том, что надо терпеть плохо работающих и ни в коем случае не говорить им об этом - это касается и плохих программистов, и плохих работодателей и т.д.?
раскрыть ветку (4)
Вам объяснять что то бесполезно, вы явно не способны работать в больших и разношерстных коллективах.
раскрыть ветку (3)
Ну что за бред про большие коллективы? Вы продолжаете утверждать, что держать работников, которые работают, но не дают результат, это норма? Теперь, правда, вы это утверждаете для «больших» коллективов. Видимо, сами понимаете, что коллектив из 10 человек быстро сам решит проблему «зайца», независимо от того, начальник он или работяга. Но за право разводить «Зайцев» в большом коллективе Вы будете бороться до конца?
раскрыть ветку (2)
Вы несёте бред. Во первых абстрактное "плохие программисты", во вторых столь же абстрактное " Не приносят результат". Что это нахуй значит вообще? Это когда Вася в поставленной вами рамочной задаче не догадался что вы от него хотели функциональные, оптимизацию и зажигательный танец? Это когда разработчик сделал баг? Этого уже хватит что бы оттаскатт на хуях, а потом видимо идти плакать к себе в каморку ибо злой тк не даёт увольнять?
Или у вас может правило трёх ошибок? А может вы используете интуицию?
Я думаю что ваш подход проистекает из ваших умений. Точнее неумения подбирать команду. А возможно и работать с ней до кучи. Хотя может в конторке на 25 чел это и не важно?
раскрыть ветку (1)
Вот Вы на все эти вопросы ответов не знаете, уточняющий вопросы не задаёте, но уже не первое сообщения, перейдя на личности, пишите то, что Вы себе придумали в голове. Если Вы так же работаете, то Вы тоже плохой работник.
Ну и для кучи - что такой плохой сантехник, плохой водитель, плохой программист все почему-то знают, а что такое плохой программист, вроде как сотрудник айти делает вид, что не знает. Смешно!
Ну это очень ограниченный взгляд. Да, приложения много занимают, но почему это кого-то вообще должно волновать сейчас ? Когда приложения были маленькие - на удивление в телефонах и на компах тоже места постоянно не хватало. Сейчас же телефонов с 256ГБ+ много и с местом проблем нет. На компе 4ТБ ssd стоили абсолютные копейки в 2020 году - я до сих пор едва половину использую, хотя место вообще не чищу.
Конкретно размер приложения там 30я метрика по важности сейчас.
Да во всем. Он не понимает, что две трети объема это какие-нибудь ролики и графика высокого разрешения под флагманы. И что не будут делать 2 приложения еще и под слабые аппараты. Ну и SDK(среда, библиотеки) предоставляется самим гуглом и эплом. И иже с ними фейсбуком, инстаграмом и прочими-прочими интеграциями, которые бог знает что пихают в свои библиотеки для поддержки кучи версий. У конечного разработчика связаны руки. Это раньше все было просто теперь же без сторонних сдк тупо невозможно использовать их же сервисы. Или сиди пиши их с нуля, но через пару месяцев они потеряют совместимость.
в том, что долбаеб и не понимает ничего в современном программировании. Сейчас тапок с 256ГБ на борту стоит 10к, а он зажопил 400мб на приложение, которое использует каждый день. Скучает по старому, пусть пользуется наличкой и сберегательной книжкой.
раскрыть ветку (2)
Ну 10к не так уж и мало то, их заработать надо, а с зп условной 30-40к это соответственно 33% - 25% месячного заработка..
раскрыть ветку (1)
Типичный программист
1.5K постов6.7K подписчиков