Плюсы и минусы разработки приложений на Ionic

Ionic — это технология, позволяющая разрабатывать полноценные приложения для iOS и Android. Для этого не нужно иметь глубокие знания в каждой из платформ. Конечно же, есть некоторые ограничения, но в целом необходимо быть знакомым с Angular (популярный веб-фреймворк), чтобы начать разработку приложения. Для применения стилей можно использовать SCSS — это придаст приложению нужный вид. В этой статье рассмотрим главные преимущества и недостатки Ionic.

В Ionic есть встроенная библиотека стандартных элементов, которые можно использовать аналогично элементам Bootstrap: карточки, кнопки, переключатели, сегменты, попапы, поля ввода, списки, сетка из строк и колонок и т. д. По умолчанию эти элементы меняются так, чтобы выглядеть как нативные на iOS и Android, но их вид можно изменить и при необходимости.

Также с Ionic вам доступно множество плагинов, которые позволяют использовать железо смартфона (Ionic Native/Cordova). Но не забудьте проследить, чтобы ваши платформы активно поддерживали выбранные плагины. В большинстве случаев такие плагины работают хорошо, но иногда может возникнуть ошибка билда или конфликт даже с широко используемыми плагинами вроде входа через Facebook или Firebase Analytics. Такие проблемы обычно решаются либо чисткой и ребилдом проекта, либо обновлением плагина (при условии, что уже есть его новая версия, которая решает проблему). Также можно заменить плагин на альтернативный или в некоторых случаях — добавить параметры, разрешающие перезапись в config/xml/.

Несколько заметок о нашем опыте с определёнными Ionic Native/Cordova модулями:

  • Для правильной работы некоторых плагинов потребуется тонкая настройка, например глубинных ссылок — модуль легко подключить, но сложно заставить работать как следует.
  • Для работы входа через Facebook в консоли Facebook для разработчиков понадобится добавить base64, использованный для подписи вашего приложения.
  • «Поделиться на Facebook» открывает сообщение, но его нельзя заранее заполнить нужным текстом. Однако можно показать пользователю подсказку о том, что текст или ссылку можно вставить. При этом важно использовать только валидные HTML-ссылки.
  • Также мы использовали следующие плагины без больших сложностей: Поделиться на Twitter, Копировать в буфер обмена, Выбрать изображение из галереи/использовать камеру, Обрезать изображение, Блокировка поворота экрана, Браузер в приложении, вызов редактора email, а также Локализацию/Глобализацию.

У Ionic есть ещё один большой плюс — скорость разработки. Поскольку он основан на Angular, проект на Ionic можно запускать в браузере и видеть, как будет выглядеть приложение во время разработки. Для того чтобы увидеть такое превью, не обязательно устанавливать приложение на смартфон или эмулятор. Это существенно помогает экономить время при изменении UI. А когда вы работаете над функциями, требующими проверки на смартфоне (например, сделать фото), сборка билда и установка его на смартфон займет всего несколько минут. На Android устанавливать приложения можно прямо из командной строки, а на iOS билд нужно открыть в Xcode.

Гибридные vs нативные приложения

Недавно появилось несколько фреймворков, позволяющих разрабатывать настоящие нативные приложения с использованием Angular (NativeScript) или React (React Native). Они имеют важное преимущество перед гибридным подходом Ionic — ничто не может сравниться с производительностью нативных приложений. Однако нативные приложения имеют не менее важный минус. Используя Ionic, вы работаете с HTML- и SCSS-файлами, а для нативной разработки вам понадобятся другие навыки для работы с разметкой и стилями. Этих навыков нет у большинства веб-разработчиков.

Деплой в Google Play Store

Чтобы выпустить завершенное приложение, вам понадобится его сначала собрать:
ionic cordova build android --prod --release. Затем его нужно подписать с помощью jarsigner (инструмент для подписи APK), используя свой JKS-ключ и zipalign (инструмент для превращения подписанного приложения в APK в готовое для загрузки на Google Play Store). При этом важно использовать тот же JKS-ключ, который загружен в вашу консоль разработчика Play Store.

iOS

Исходя из нашего опыта, Ionic для iOS не настолько отлажен, как для Android. Мы сталкивались со странным поведением такого элемента разметки, как сегмент — иногда он может конфликтовать со скроллингом. Также многие элементы требуют отдельных SCSS- стилей для того, чтобы они выглядели как вам нужно на обеих платформах. То же относится к плагину Flurry Analytics. Его легко установить и использовать в Android, а на iOS этот плагин не устанавливался простыми способами и потребовал использовать CocoaPods — пакетный менеджер для установки плагинов на iOS. И даже после правильной установки этот плагин не инициализируется так же, как на Android.

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

Плюсы

  • Быстрая разработка и минимальное время выхода на рынок.
  • Можно вести основную часть разработки в браузере (кроме нативной функциональности смартфона — тут понадобится использовать смартфон для дебага).
  • Можно разрабатывать приложение для iOS и Android одновременно (с некоторыми ограничениями — такими как особенности платформ, касающиеся стилей и плагинов).
  • Навыки в Angular, HTML, CSS и JavaScript — это практически всё, что понадобится для начала разработки. Нет необходимости знать Java и Swift или Objective-C.
  • Множество UI-компонентов доступны и просты в использовании — карточки, кнопки, переключатели, сегменты, попапы, поля ввода, списки, сетка из строк и колонок и т. д.
  • Множество плагинов, позволяющих использовать функции смартфонов, такие как: камера, сканер отпечатков пальцев, NFC, геолокация, отправка аналитики на Firebase, оповещения и глубинные ссылки.

Минусы

Нативные плагины могут стать проблемой, если какие-то из используемых плагинов конфликтуют или если в одном из них баг. Например, недавно в плагине для логина с помощью Facebook был баг: если юзер хоть раз сделал log out, то больше логин уже не работал. А плагин FCM (Firebase Cloud Messaging) не работает с firebase-analytics. Но есть плагин под названием Firebase, которым можно заменить их оба. Дебаг может быть довольно сложным: иногда трудно понять, откуда приходит ошибка, поскольку сообщения об ошибках могут быть неинформативными.

Билд может ломаться без причин, что-то оказывается поврежденным в оригинальной папке. Так что делайте коммиты часто и используйте ветки для каждой новой функции или страницы. Если что-то сломается, просто сделайте клон репозитория в новой папке, запустите npm install и попробуйте собрать проект заново.

Вывод

Ionic — отличная технология, позволяющая сделать готовое для выпуска приложение гораздо быстрее, чем при традиционной разработке. Большой плюс этого подхода — то, что вместо Java/Swift/Objective-C можно использовать стандартные технологии веб-разработки, такие как HTML, CSS, JavaScript/TypeScript и Angular. Есть небольшой минус в производительности — нативное приложение может быть более отзывчивым на старых устройствах, но на любом современном смартфоне разница будет незначительной.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn



79 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Ничего себе. Я думал, это забылось еще году в 2015, а оказывается про него еще статьи пишут.

а angular зразу так і назвали — типу ми вас попередили там гострі кути , готуйте напилки ;)

Отличная статья! Сразу стало ясно, что с платформой лучше не связываться. Спасибо!

Если что-то сломается, просто сделайте клон репозитория в новой папке, запустите npm install и попробуйте собрать проект заново.

Платформа мечты.

просто сделайте клон репозитория в новой папке

git clean -xdf

PhoneGap — це ліцензійна й пропріетарна версія кордови (майже у правому кутку), а це — надстройка на нею :D

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

Так не будет. 80/20 с Иоником работают как часы. Баги их друзья. И для того, чтобы «быстро набросанное» приложение заработало, нужно будет потратить времени х3 от запланированного.
PS Смотрю, они баги из открытого доступа убрали. Раньше эти простыни были на видном месте. Остался гитхаб и там более 1200 тикетов.

баги будут всегда, но:
на этом проекте были нативные версии на Android и iOS.
iOS версия была лучшей, точно такой же производительности от Ionic не стоит ожидать.
Android версия была очень плохой; было много багов, многих фич в ней не было. люди менялись, а результата не было.

изначально мы написали версию на Ionic ради Android.
за то время, которое я потратил на весь функционал на Ionic (обе платформы без стилей) в нативном Android приложении может быть можно было бы отловить пару багов.

позже мы перевели и iOS на Ionic и теперь выпускаем апдейты на обе платформы в один день.

Хорошая статья, хотелось бы еще увидеть аналитику по user experience, потому что разработка может быть дешевле/быстрее, но вопрос в удовлетворенности пользователей не раскрыт.

btw, skype хороший пример того, почему не нативная кросс-платформа это плохо

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

Прототипчик накидать — наверное можно, а вот полноценный продукт я бы наверное не делал.

поработал со всем этим начиная еще с чистого фонгепа, и заканчивая 3й. кажется, ионикой. ионика от лукавого. проще и быстрее java/swift выучить, чем все проблемы отлавливать и дебажить...

на оной приходилось и в продакшн продукты выпускать, увы..

наш проект давно в проде.

с одной стороны аргумент верный.

но если вас устраивает скорость работы сайтов в браузере на телефоне, то почему не устроит такая же скорость в Ionic (ведь это фактически обёртка Chrome/Safari)?

Для этого не нужно иметь глубокие знания в каждой из платформ.

Профессия программиста с каждым днем опускается ниже плинтуса. Теперь «программировать» могут даже домохозяйки. А завтра появится новый вид программиста — программист «Лего».

Грустно все это.

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

Так что появление «волшебных» конструкторов ведет к деградации не только будущих программистов, но и их нанимателей. Это ИМХО.

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

Знаете какие техническопознавательные статьи в программировании мне нравятся?! Это когда автор статьи берет какой-то модуль на 600 строк кода из подобного проекта и переписывает его функционал в 15 строк кода! Пару лет назад видел такую статейку про питон.

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

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

Давно уволился )) Но встречал такие закидоны часто у разных заказчиков.

Кто-то из этих кирпичиков софт для котиков лепить, кто-то будет другой софт писать.

Тут тогда вопрос, зачем такие конструктора создавать? Я думал, для получения прибыли, типа платная система — дешево и сердито. Если система платная, то ради котиков вряд ли будут платить. А если бесплатная, то какой профит создателям?

Ну, я надеюсь, что у них все получится и они заработают денег.

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

Переставайте работать на идиотов или обучайте их, чтобы они перестали быть идиотами (с заказчиками из пост-совка не сработает).

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

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

Я понимаю вашу боль касательно неадекватных нанимателей, но, в целом, прогресс идёт именно в направлении дешёвого и быстрого построения решений из типовых компонентов. Разрабатывать что-то новаторское и нестандартное могут себе позволить, в основном, или крупные компании, которых не устраивают имеющиеся на рынке штатные решения, или стартапы, сознательно «окучивающие» определённую узкую нишу.

А «деградация», о которой вы говорите, отнюдь не новое явление в мире ИТ. Ещё в 1980х было деление на «системщиков» и «прикладников», причём, первые считали вторых программистами «второго сорта»

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

вообще не понятно где.

out there

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

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

а когда смотришь на современный программинг, то тенденции практически все строго наоборот. кроме быстрее.

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

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

Бітовий зсув використовували для цілочисельних операцій, бо у ті часи навіть операції множення ділення були надто дорогими, а ігрові двіжки були софтовими — статті Майкла Абраша, «одне ділення на скан-лайн» — вот ето вот всьо.
Там, де використовувався арифметичний сопроцесор, бітові зсуви би не помогли — інший формат числа :)

дякую за корекцію. в житті не стикався, підзабув, що FPU — то саме для float arithmetic

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

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

по факту сейчас тем же ж компиляторы занимаются стали шибко умные я на днях switch обычный копал даже интересно стало в дебаге таки да простой if else пакован генерируется а вот в релизе с оптимизациями уже всё сложнее и хотя я его «встроенный» сразу обогнал но совсем ненамного надо опускаться ещё на уровень ниже только зачем а сегодня чувачки новички получается приходят и получают всё это «с каропки».

ЗЫ: только они про это не знают и даже пользоваться тем что уже есть всё равно не умеют вот это скорее «то чего мы потеряли со времён золотой поры».

да я ж не спорю
просто я речь о другом вел

Уже с видео, всякими AR, VR уперлись в производительность железа. Фрэймворки для лайкания котиков через некоторое время тоже упрутся.

всё будет же ж в облаках а там квантовые компьютеры же ж! ))

Ещё в 1980х было деление на «системщиков» и «прикладников», причём, первые считали вторых программистами «второго сорта»

типа сичас это всё пропало ушло в прошлом ))

формошлепы как были (прикладники) так и остались

считали ядреные реакторы

ну і зараз для таких є React — на ньому також можна рахувати реактори

Не переживайте! Конкуренція серед замовників помножена на конкуренцію серед розробників буде тримати в тонусі програмістів

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

для большинства приложений возможностей и производительности Ionic будет достаточно.

Дело в том, что если оглянуться немного назад, когда появились всякие CMS, типа Джумла, Вордпрес, Друпал и другие, то все начали говорить, что это и есть спасение. Теперь сайт до уровня портала можно накликать мышкой любому пользователю-ламеру. Целые огромные бизнесы строились на этих платформах. И в какой-то момент пришло понимание, а как сделать «тоже самое, но с перламутровыми пуговицами»? В общем каждой компании нужно было все немного под себя заточить. И погнали, появились программисты на друпал, вордпрес и т.д. Казалось, эра нативного кода и фреймворков должна закатится, но вот незадача. 90% своего времени программисты на готовых платформах тратили не на разработку бизнес задачи, а на всякие костыли, которые позволяют обойти ограничения системы. Про то, что каждую неделю хакеры-школьники ломали тысячи этих типовых сайтов, даже молчу. Поэтому, появление подобной платформы для мобильных приложений вполне понятно, но судьба этого всего будет очень противоречивая. Будет, как всегда, три фазы: 1) Прорыв, 2) Е..ля, 3) Поиск альтернативного решения.

для большинства приложений возможностей и производительности Ionic будет достаточно

Что это за такие приложения и чем они все будут отличаться друг от друга? Если зайти в гугл плей, то наверное, процентов 90 всех приложений, что там, на фиг никому не нужны. А они написаны на нативе. Поэтому у меня огромные сомнения во всем этом мероприятии с «доступной разработкой».

в общем всё что связано с look & feel можно кастомить как угодно как любой сайт.

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

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

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

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

А, ну если это все запросы, то конечно ionic за глаза. Я уже просто отвык от того, что это тоже называется приложением )))

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

вход, несколько статических страниц, свежий контент с сервера (новости например), формы/опросы, снять/прикрепить картинку, оставить комментарий, отправить аналитику и т.д. всё это доступно. если задуматься, то почти все приложения именно такие.

а нафига? бровзер же есть

90% своего времени программисты

Ну, нет же. типовые задачи стали решаться написанием реюзабельных модулей, а не cp project1/src project2/src. или даже написания модулей не требуется — берешь готовый.
так можно сожалеть о развитии фич IDE(шоооааа, рефакторинг одним пунктом менюуууу?), системах контроля версий(мой дед в нумерованных архивах код держал и мне завещал), виртуализации(шо за докер? лучше по старинке filezilla’ой...)

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

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

Я бы с огромным удовольствием посмотрел, как бы вы в гит поместили, например Друпал 7, который все свои системные и программные настройки держит в базе. Все инструменты, что вы перечислили, все это в помощь именно программисту! Все CMS и конструкторы для пользователей и малоимущих. И если они не могут с чем-то справиться, тогда нанимают специалиста по платформе (Вордпресс, Джумла, Друпал и т.д.). А если и он не может справится, то тогда уже реального программиста.

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

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

Энтерпрайз — он сильно разный бывает. Нередко, именно в энтерпрайзе возникают типовые задачи а-ля запилить очередной «CRUD с формочками», и вот именно такие приложения экономически куда более целесообразно собирать на конвейере из готовых блоков, чем, например, изобретать с нуля собственную ORM, библиотеку валидации пользовательского ввода, или элемент управления data grid.

Да, наверное, с нуля и из любви к искусству можно было бы написать более изящно и оптимально. Но грусть-печаль в том, что бизнес не готов за это платить.

С одной стороны я с вами согласен. С другой — не совсем. Для старта проекта можно запилить и на стоковом решении. Но всегда возникают у бизнеса требования, которые далеко выходят за рамки стандартных решений. Например, я делал форум для портала недвижимости (самого крупного в Украине ))) на SPA (и фронт и бэк делал). И нужно было в одном запросе забрать посты форума для конкретной темы конкретного форума, со всеми профилями пользователей, служебной информацией для админпанели, всеми результатами голосовалки в данной теме, всеми схожими темами для блока похожих тем, со всеми застройщиками (для вывода в теме их рекламы), которые возможно обсуждаются в теме, с блоком новостей за конкретный период, которые хоть как-то связаны с темой и еще куча всего. Запрос на постгресе был размеров в 40-50 строк!!! Ни одна ORM просто не в состоянии это грамотно собрать, не то что обработать в приемлемое количество времени. Огромное количество форматов JSONB тоже невозможно было аккуратно через стоковый ORM обрабатывать. Потом начались приколы с ролями и пермишенами, которые не только могут быть у пользователей, но и у клиентов этих пользователей во внутренней CRM. Тут не то что готовых блоков и решений нет, тут вообще мало кто может сообразить, как это вообще сделать грамотно. Организация вывода данных — это тоже отдельная песня. Вначале могут обойтись и простыми шаблонами, а потом обязательно захотят посреди текста вставлять какую-нибудь рекламу и понеслось. Не, больше бизнесы с миллионом хотелок — это боль.

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

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

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

А склепать сайтик, это что-то сакральное, для этого надо владеть какими-то сверхъестественными знаниями? Это должно быть уделом избранных?

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

А склепать сайтик, это что-то сакральное, для этого надо владеть какими-то сверхъестественными знаниями? Это должно быть уделом избранных?

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

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

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

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

Омг, еще один с претензией на богоизбранность отрасли. Спасибо за совет. Как-нибудь справляюсь.

ПС О детях поговорим, когда они у тебя появятся.

Да не, не поговорим. Ты скучен.

Посмотрел его профиль на Линкидине. Думал не меньше, чем Артемий Лебедев. Но увы и ах.

Это интернет, детка. Здесь, если что, могут и на уй послать.

Да, нужно предупредить себя, чтобы быть начеку.

так подобные статьи всячески поощряют это дело:

Плюсы
Быстрая разработка и минимальное время выхода на рынок.

что в переводе означает «ху%;к, ху%;к и в продакшн»

Я когда работал в minfin.com.ua у нас плакат такой висел на стене )) Походу, директива была спущена с самого верха ))

Підписатись на коментарі