Comments 168
И все же авторизация это ~2 часа со всем девопсом... Так что можно и бизнес функций продать за два то месяца.
P.S — это всё без учёта самой вёрстки, которой я не занимался
Найдется заказчик, который скажет - и что ты там целых 2 часа собрался делать-то? Поясни!
Набрать воды в чайник
Дождаться, пока чайник закипит
Вспомнить, что кофе закончился
Добыть новый кофе
Вскипятить чайник заново
Заварить кофе
Дождаться, пока достигнет комфортной температуры
Написать двести строк тестов
Написать две строчки кода
Три часа глубокой отладки в коде тестов, обнаружение опечатки
Profit!
"пытаться забыть тебя и твое понимание процессов"
Вот-вот, гонят со сроками, а потом удивляются, почему ПО такое дырявое.
http://admin.shor10.ru/
поднято меньше чем за 15 минут, тестируйте, логин: pintest@pintest.test
К слову, у него тоже регулярно находят уязвимости www.cvedetails.com/vulnerability-list/vendor_id-16542/Laravel.html
Примитивная защита от брутфорса есть и идёт из коробки. На роут достаточно повесить миддлварю троттлинга (которая Illuminate\Routing\Middleware\ThrottleRequestsWithRedis).
Но это я так, просто мимокрокодил и солидарен с вашими тезисами...
А я где-то обещал не использовать фреймворк? За лист уязвимостей - спасибо.
Только в статье речь шла про регистрацию, а не один из ее этапов - аутентификацию (вы ведь это имели ввиду?)
Ну и оценивать не зная их реалий - не кажется зрелым подходом.
Сама авторизация - возможно. Но прежде чем авторизовываться надо зарегистрироваться. А там форма на 3 шага с 5 полями в каждом со своей бизнес-логикой (матчинг адресов, валидация номера телефона, загрузка фото паспорта и пр.). Вот и набегает целый человеко-месяц.
P.S. Ой, да - защиту от брутфорса забыл, аналитику, подключение Sentry... ну и т.д.
А мне два часа понадобилось только чтобы понять (и поверить), что в сафари (в последних версиях починили) есть баг с кроссдоменными куками.
А потом оказалось, что какой то парень из компании заказчика, замучавшись делать однообразные отчёты вручную и ждать, пока на протяжении месяца делают форму регистрации, включил режим "теневого айти" и за 2 недели сделал себе в экселе на vba софтинку, которая реализует весь основной бизнес функционал.
Ага, и потом подрядчик изойдя на желчь будет доказывать, что там не такие методы и неправильно сделано. Но, что самое удивительное , vba все делает и без свистелок-перделок, митингов, стендапов и прочей организационной лабуды.
Правда, потом может перерасти коммерческий продукт из говна и палок на костылях с кучей legasy. Но рабочим и выполняющим все хотелки. Ибо писан человеком сидящим га хотелках и прикручиваемых самолично. Без архитектора, аналитика, сеньора, хрюш и прочая.
Правда, в большинстве случаев он будет кататься на Ford Focus ибо талант программера редко совместим с талантом продавана.
Это все оттого происходит, что заказчик часто хочет получить круто тюнингованный Бентли, по цене Лада-Веста, да еще и быстро. А описанная самоделка обычно и вовсе представляет из себя зверски заколхоженный древний Запорожец, который, конечно, как-то там передвигается, это да!
Одна из ключевых концепций аджайла, как раз в том, что сделайте хотя бы в эксельке на бэйсике работающее поделие, убедитесь, что заказчика устраивает функционал, а потом можете его воплощать в продакшине по-взрослому хоть на коболе.
Другое дело, что заказчик, увидев протопип в эксельке, скажет - зашибись, это нас полностью устраивает. И весьма возможно, что ему действительно нафиг не нужны более взрослые решения. Да, эксельку будет сложно адаптировать к новым требованиям по функционалу, т.к. ее архитектура такого вообще не предполагает, зато ее будет просто переписать с нуля за 2 недели.
Но денюшек за эксельку с vba кодом не стрясешь так же много, как за решение на стэке Java + Spring + Hiberante + Spark + Oracle + Kubernetes.
Ну да, ну да. Видел я эти поделки "талантливых самоучек".
В итоге, руководство прознает об этой самоделке и радостно скажет - ну вот видите, мы же говорили что все это можно сделать проще и дешевле! Вот тебе премия, давай обучай всех работников тому как это использовать!
И тут вдруг (!!!!) оказывается что в этой самописке масса багов, она крайне медленно работает с более-менее большими количествами данных, несколько пользователей работающих одновременно вообще никак не поддерживает, а любые новые фичи в нее внедряются месяцами, через боль и страдания давно уже пожалевшего о своей инициативе сотрудника.
И это все я сам на себе испытал, на заре трудовой карьеры был в шкуре такого "самоучки". Бизнес не понимая всех тонкостей и сложностей разработки хочет экономии прямо вот здесь и сейчас, потому часто нанимает каких-либо студентов плана "сын маминой подруги", которые в меру своих способностей что-то там делают. И вроде все ок - софт худо-бедно работает, заплатили за это какие-то смешные деньги (если вообще заплатили), запилено все относительно быстро. Только вот когда возникает желание в нем что-то улучшить, или на софт повышаются нагрузки, или в нем внезапно всплывают серьезные ошибки, оказывается что поддержка этого великолепия или вовсе невозможна, или за это хотят нехилых денег, потому что желания разбираться во всем этом говнокоде за копейки, нет даже у его автора.
Но часто бывает и так, что человек не разбирается в логике всей программы, а только "дергает" те данные которые ему интересны. И хорошо, если он их только читает, а не пытается в обход логики записать. Но даже читающий может создать проблем в работе программы хотя бы тем что может "криво" законнектиться, сделав невозможным автоматическое отключение, или написать неоптимальный запрос, который сильно просадит производительность, или вмешается в тот момент, когда выполняется какая-нибудь операция обслуживания. И вот тогда разбор полетов и кто-то отгребает по полной, так как те кто искал причину обычно не рассчитывают на вмешательство "умных" пользователей и ищут причины не там где нужно.
А что касается риторического вопроса, вынесенного в заголовок статьи, ответ на него такой:
Добавить две кнопки — почему так дорого?
- 1% случаев — данное изменение требует существенных доработок в архитектуре
- 29% случаев — разработчик ошибочно занизил сложность при оценке проекта, и теперь пытается втихаря раскидать свои косты по дополнительным задачам
- 70% случаев — это энтерпрайз, детка. Тут всё дорого
Просто сделать авторизацию по e-mail-password — Это одно. Куда интереснее, что за этим следует. Ведь у пользователя должна быть какая-то возможность, которая недоступна неавторизованным? В каждом случае — возможности разные (создавать посты, ставить отметки, покупать товар, продавать товар, голосовать за что-то и тд и тп.). Более того, у разных авторизованных людей могут быть разные «полномочия». Будь на всё готовые решения — программисты бы стали не нужны
Да даже стандартная — в каждом движке и фреймворке она по-своему стандартная.
Я исхожу из того, что в общем случае вы делаете проект на движке/фреймворке, который вы уже знаете и использовали :)
В каждом случае — возможности разные (создавать посты, ставить отметки, покупать товар, продавать товар, голосовать за что-то и тд и тп.).
Ну вы же не будете всё это изобретать заново или там как-то хардкодить в движке авторизации. Вы будете использовать систему ролей или утверждений, и она будет одинаково работать в любом вашем проекте, просто вы будете добавлять под каждую область свой набор ролей/утверждений, в процессе разработки этой области, а не в процессе разработки системы аутентификации.
Просто поймите, что нет универсальных решений в программировании на все случаи жизни.
Универсальных на все случаи жизни нет. Но зато в плане таких общеупотребительных функций, как аутентификация, навалом есть таких решений, которые покрывают 99% типовых кейсов, и этого достаточно. Да вы вон сами в одном абзаце перечислили практически всё сколь-нибудь вероятное, что вы встретите у клиентов. И более того, в ряде фреймворков (тот же ASP.NET Core, например) это в массе своей вообще встроено из коробки. Вариантов-то не слишком много по факту. Локальное хранилище учёток, федеративная аутентификация, аутентификация по внешнему провайдеру, виндовый домен. Плюс опционально двухфакторка, провайдеры — емейл, телефон, смс, мессенджеры. Ничего не забыл? И вот это, наверное, и всё, что-то иное встречается редко. Так что вполне реально реализовать один раз и пользоваться всегда. Да, или нагуглить уже реализованное, если ваш фреймворк достаточно распространённый.
Вариантов-то не слишком много по факту. Локальное хранилище учёток, федеративная аутентификация, аутентификация по внешнему провайдеру, виндовый домен. Плюс опционально двухфакторка, провайдеры — емейл, телефон, смс, мессенджеры.
Напомнило шахматы. Всего лишь 64 клетки и 32 фигуры. А количество возможных комбинаций… Число Шеннона
Напомнило шахматы. Всего лишь 64 клетки и 32 фигуры. А количество возможных комбинаций…
… не играет роли, т.к. все компоненты в общем-то независимы и могут быть произвольно включены/выключены по желанию клиента :)
Я, пока не перешёл полностью в серверные решения (без взаимодействия с каким-либо фронтом), написал несколько десятков веб-авторизаций.
У меня тоже был такой период. А потом я перестал писать новые
все они используют одинаковый движок авторизацииа движок самописный? Или опенсорсный? Или ещё что-то?
Можно ли строчками в конфиге решить эту задачу? habr.com/ru/post/573424/#comment_23381742
P.S. Не воспринимайте как критику, просто реально интересно. Возможно, я просто лошара был в этой области.
Движок - уже упомянутая аутентификация ASP.NET Core с самописными расширениями.
Что касается задачи, строчками в конфиге сделать, например, разные формы регистрации можно. Сделать проверку паспорта или генерацию договора, естественно, нельзя, но это и не имеет отношения к авторизации/аутентификации, это же чистой воды бизнес-логика.
Сделать проверку паспорта или генерацию договора, естественно, нельзя, но это и не имеет отношения к авторизации/аутентификации, это же чистой воды бизнес-логика
Так ведь вся статья о том, что клиент не делит авторизацию/аутентификацию на бизнес логику и сервисы. Для него это одна неделимая функция сайта. Поэтому за кажущейся простотой бизнес логики, идет ворох работы по вспомогательным сервисам, тестированию, коммуникациям. И по всему надо обосновать сроки.
Клиенту не нужна бизнес логика в вакууме. Если вы отдадите только бизнес логику даже за 2 дня - клиент вас пошлет с этим неработающим функционалом, это не рабочий функционал который ожидает клиент. Вопрос в том, а заложили ли вы время на расширение бизнес логики до требований заказчика или продали только два дня.
Если резюмировать, то месяца озвучиваемые выше - это не срок реализации бизнес логики, а срок доведения ее до ожиданий клиента. И эти сроки всегда разные, т.к. клиенты разные, опыт разработчиков разный, качество коммуникации разное, подробность и формулировка требований разные, люди и их мотивы разные.
Так ведь вся статья о том, что клиент не делит авторизацию/аутентификацию на бизнес логику и сервисы. Для него это одна неделимая функция сайта
Для меня эта проблема совсем уж неочевидная. В моём опыте в 100 случаев из 100 экселевская табличка, где были укрупнённо расписаны работы вида
«Дизайн формы регистрации» — столько-то времени/денег
«Обработка формы регистрации» — столько-то времени/денег
«Валидация паспортных данных» — столько-то времени/денег
«Создание договора на основе регистрационных данных» — столько-то времени/денег
… избавляла от подобного непонимания со стороны клиента. Получив предварительную смету, он изначально понимает, что сие есть отдельные работы, непосредственно к регистрации не относящиеся.
Я исхожу из того, что в общем случае вы делаете проект на движке/фреймворке, который вы уже знаете и использовали :)Дак в том то и дело. Что в каждом движке/фреймворке это по-разному. Стандартная авторизация — это очень растяжимое понятие, и для каждого она своя.
Я, пока не перешёл полностью в серверные решения (без взаимодействия с каким-либо фронтом), написал несколько десятков веб-авторизаций. И ни одна не была точно такой же, как другая. Похожий функционал, часть которого можно скопировать — да. Точно такого же — нет. Везде были различные доработки или же написание с нуля (не считая возможности фреймворка).
"единая точка входа", прозрачная авторизация
смарт карты
аппаратные токены типа таблеток или YubiKey (у нас например юбики во все щели интегрированы, включая NFC режим)
И да, кому-то это нужно, и тут штатные механизмы уже не выполняют задачи. Плюс их комбинации. А если и делать комбайн который всё умеет - это будет очень медленно, дорого, долго, требовать мощного железа и вообще будет боль. А уж баги там править..
Ещё можно затронуть тему ЯП и фреймворков…
Мне лень дальше писать, иначе комментарий на статью выйдет. Просто поймите, что нет универсальных решений в программировании на все случаи жизни. У всех свои прихоти. Даже комбинации прихотей. Этих комбинаций — миллиарды. Будь решения на все случаи жизни — все бы их и использовали. (P.S. тут речь даже не конкретно про авторизацию)
Сделайте один раз все перечисленные фичи в авторизации, а потом просто выключайте то, что не требуется в том или ином случае.
В 99% случаев клиент не запросит ничего нового. А если запросит, добавьте и его фичу тоже в свой набор, чтобы при необходимости ее можно было всегда включить или выключить.
Это вы к тому, что есть нечто готовое под полуярные фреймворки "со всеми фичами" (причем не только перечисленными, а вообще со всеми возможными)?
Типа в конфиге прописал хочу/не хочу ЕСИА, сертификат или Стим, и все заработало?
И даже если так, что что заработало-то? Я сильно сомневаюсь, что заказчик хотел в качестве этапа просто формочку с вводом имени/email увидеть. Наверняка хотел, что бы при входе под разными учетками разные права выдавались.
Причем совершенно нормально, когда зайти в аккаунт можешь, к примеру, с именем/паролем. Если еще и по SMS подтвердил, больше возможностей. А вот для чего-то важного еще и код из Symantec VIP Access ввести требуется.
И вот это вот все требует предварительной проработки, абсолютно невидимой снаружи. Сама по себе "формочка авторизации" нафиг не нужна. Важно, как ее результаты будут в приложении использоваться.
И даже если так, что что заработало-то? Я сильно сомневаюсь, что заказчик хотел в качестве этапа просто формочку с вводом имени/email увидеть. Наверняка хотел, что бы при входе под разными учетками разные права выдавались.
Причем совершенно нормально, когда зайти в аккаунт можешь, к примеру, с именем/паролем. Если еще и по SMS подтвердил, больше возможностей. А вот для чего-то важного еще и код из Symantec VIP Access ввести требуется
Вообще, да. Оно именно так в aspnetcore и работает. Вход по паролю / телефону / внешнему сервису / 2fa / что угодно.
Значит завтра придет заказчик который захочет LDAP/NTLM или Kerberos версии неподерживаемой aspnetcore из коробки, либо объявленной устаревшей.
>неподерживаемой aspnetcore из коробки, либо объявленной устаревшей.
Что LDAP / Kerberos цепляются в одну команду, но, вообще, там можно инжектить в пайплайн обработки аутентификации что угодно, так что в дотнете нужно сильно постараться, чтобы код добавления нового типа аутентификации превысил сотню строк.
Тут не учитывается влияние рынка. Чтобы продать, ты должен быть лучше конкурентов.
И одного этого стремления достаточно, чтобы в работе натыкаться на разный набор требований. И приближаться по удобству к мейнстримовым сервисам, навороченным функциям соц. сети N или "быть как apple" :).
Мне как программисту удобно всем отдать одно и тоже проверенное и протестированное. А вот бизнесу это не нужно, как он рынок то завоевывать будет? Он не для этого деньги вкладывает, чтобы быть как все.
Можно стандартно ввести логин, стандартно пароль. Получить токен сессии и иметь табличку, где эти токены обитают. В каком-то зародышном виде может быть распределение ролей и приватное хранилище. Если решение готовое, в 2 часа возможно даже вписать какую нибудь стандартную 2fa, и можно, в принципе, не напрягаться над правильностью реализации. А дальше... Ничего! Дальше сами. Вот вам и вся стандартность. Стоит она примерно ничего, в первую очередь, уверенности том, что внутри система работает и все ошибки по другую сторону интерфейса. У всех разработчиков и без того есть заготовки на общие случаи, и они и так максимально абстрактны, чтобы закрывать максимум хотелок с минимальными доработками. А советчиков я призываю где нибудь посидеть ручку покрутить или со штампиком и бумажкой поиграться. Отсутствие шума - тоже польза.
Просто автор криво назвал свою статью.
Статья про то что создать первые две кнопки дорого и долго, а вот добавить к ним уже две последующие будет гораздо быстрей и дешевле.
Ну и если так говорить заказчику - мы сделали две стандартных кнопки - конечно он будет думать что это лохотрон какой то.
Вы должны пояснить что вы создаете даже без какого либо функционала, так чтобы заказчик понял за что он платит. И тут уже проблема не заказчика, а производителя, в том что он не может рассказать чем он занимается заказчику.
Очередная статья, где разрабочики открывают для себя секрет айсберга.
Ну ёлки ж палки, сколько можно? Цитата:
Вы знаете, что 90% айсберга находится под водой? Ну и с большинством программ то же самое – есть красивенький интерфейс, который занимает 10% работы и потом 90% программистской работы «за кулисами». И если вы примете во внимание, что около половины времени уходит на исправление ошибок, то на пользовательский интерфейс уходит только 5% работы. И если вы ограничиваете себя только визуальной частью интерфейса, картинками, которые показываются в PowerPoint, то мы говорим сейчас менее, чем об 1%.
Это не секрет. Секрет в том, что люди, которые не являются программистами, не понимают этого.
Выгравируйте себе, блин, это и заучите наизусть.
И нефиг писать дурацкие статьи. Сделайте так, чтобы на экране всё время появлялись новые пикселы по мере разработки — и получите и большие сроки и больше денег, чем при попытке объяснить заказчику, что он идиот.
Вы же профессионалы, пишите сразу без ошибок! (с)
Вы что — думаете эффект характерен только для разработки ПО? Да воьмите пример, которым автор статьи пытается что-то объяснить: строительство.
Какой процент затрат в строительстве дома уходит на “коробку”, непосредственно на стены? Процентов 15 (на самом деле от 12-18 для типичных одно-двухэтажных строений).
При этом вы можете либо вбухать деньги в фундамент (и потом использовать газоблоки какие-нибудь), либо сделать ленточный фундамент (который будет “жить”), тогда газоблоки использовать будет нельзя.
Придумывают разные способы объяснить клиенту, согласовать всё, статьи просветительные пишут… но это как раз не слишком хорошо работает.
А вот “показ процесса” так, чтобы клиент видел, что бригада работает, а не баклуши бьёт — работает лучше.
И там и там ситуация одна и та же: клиент непрофессионал и нифига не понимает в том, что вы делаете. Но если он, как ему кажется, видит, куда уходит деньги и время — он будет за это всё платить. А если не будет видеть — не будет.
А то, что вы показали одно, а деньги, на самом деле, ушли совсем на другое — это как раз неважно: если конечный результат будет заказчика устраивать, проблем не будет.
— Мы делаем НЕ ТОЛЬКО регистрацию, мы стартанем и другие задачи, которые просто завершатся позднее установленной даты. Выкинуть все остальное - не получится, это скелет платформы. Если не спроектировать модель данных, некуда будет сохранять регистрационные данные и неоткуда будет брать данные для других функций
— Я просто не понимаю, почему так сложно? Регистрация — это ведь стандартная функция? Давайте возьмем готовый модуль и просто прикрутим его, например из WordPress. Можем так сделать?
Проходил такое несколько раз. Все это значит только одно - разработчиками руководит человек, не соображающий в разработке, а тем более в управлении разработкой.
Результат всегда будет плохой, околонулевой, с огромными сроками и кучей нервотрепки на объяснения эффективному менеджеру как работают компьютеры.
Сколько не объясняй - не поймет. Потому что не учился, потому что не хочет, потому что ему это выгодно.
Выторгует у вас неделю-месяц, а потом, когда не успеете, виноваты будете вы.
И так по кругу.
Просто не нужно работать в таких компаниях. Есть куча крутых мест, где все хорошо, зачем тратить жизнь на помойки.
На Хабре это универсальная мантра на все случаи жизни - не нужно работать там, не нужно работать сям. В компании А сроки сжатые, в компании B начальник токсичный, в C слишком мало платят, в D очень много бюрократизма, а в E вообще каким то криминалом занимаются.
Видимо нужно вообще нигде не работать.
Видимо нужно вообще нигде не работать.
Почему? Работать надо на бирюзовых единорогов на Заокраинном Западе, это же очевидно!
Если человек настолько хорошо знает иностранный язык, что может работать на иностранцев, то он и так уже скорее всего на них работает. Просто освоить ин.яз. для большинства задача на порядки более сложная, чем освоить питон, джаву и т.п.
1000-2000 слов это словарный запас 3-4 летнего ребенка. Как можно нормально общаться на таком уровне? 4000 слов это уровень первоклассника (по некоторым источникам дети в таком возрасте подходят к отметке в 10000 слов, по видимому разные методы подсчета)
В принципе общаться то можно, но далеко не каждый работодатель захочет нанимать такого молодца, который на видео-митингах и половину сказанного не понимает.
Например, как часто вы используете в повседневной речи такие слова, как «квант», «ионизация», «растр», «изомер», «митохондрия»? Или хотя бы «ледник», «Юпитер», «разлом»?
Судя по результатам этого теста, мой словарный запас порядка 9000 слов. При этом я совершенно свободно общаюсь на произвольные темы с нативами и/или другими иностранцами.
Кроме того, интересная статистика с самого этого сайта:
Thanks for taking the test! Based on participations so far, we've already got some decent statistics. Most native English adult speakers who have taken the test fall in the range 20,000–35,000 words.
And for foreign learners of English, we've found that the most common vocabulary size is from 2,500–9,000 words.
Ну про пару дней это уж совсем загнули. Только если с Java на C# перейти, ведь он является её клоном.
Но в принципе да, даже если вы с Java на Haskell переключитесь, т.е. языки между которыми вообще нет ничего общего, вы это сделаете явно быстрее, чем изучите английский до такого уровня, чтобы общаться по видео конференциям с англоязычными коллегами.
проработать архитектуру, спроектировать модель данных, сформировать UI-kit и реализовать какие-то базовые механизмы
В защиту бизнеса скажу, что ui kit на первом этапе можно и опустить, раз из ui Вы только вход в систему видимо и делаете. 'Какие то базовые механизмы' тоже расписать бы, прорабатывать архитектуру чего? Авторизации? Модель данных чего? Надеюсь Вы заказчику подробнее объяснили)
А так сам знаю, что нам лишь бы архитектуру заранее продумать, нужно искать середину всё же
Это ж два важных скилла - по максимуму декомпозировать всё и не брать лишнего, и уметь это всё объяснить заказчику
вспоминая южный парк:
- мне нужно средство передвижения
- вот вам колесо с педалями
- нет, мне нужно с комфортом
- подождите минутку... ваши деньги всё
А может это просто не ваш клиент, если так сложно выстроить понимание и доверие? Или других клиентов вообще нет?
А что если дать клиенту выбор: ну ок, делаем авторизацию за неделю (да хоть за день!) без всяких вот этих наших планирований и умных штук, а потом просто на каждую дополнительную фичу делаем рефакторинг (чтобы система оставалась понятной) или просто прикручиваем костыли (чтобы дальнейшая разработка дорожала). Накидайте ему на листочке стоимость стартовых и дальнейших расходов на разработку. Пусть сам выбирает, какой путь разработки ему нравится.
Ну или ещё вариант. Хотите авторизацию от вордпресса? Да пожалуйста! Тогда ответственность за факапы безопасности на вас. По рукам?
Ну или ещё вариант. Хотите авторизацию от вордпресса? Да пожалуйста! Тогда ответственность за факапы безопасности на вас. По рукам?
Ооо! Это вообще отличное предложение.
Грамотный менеджер тут же ударит по рукам, подпишет договор, за три копейки получит гавно.
После чего подаст на вас в суд и заставит всё бесплатно переделать, так как вы, оказывается, нарушили 100500 законов, а их, как бы, в дорог вносить и не надо: они должны исполняться “по умолчанию”.
Заказчики на фрилансе хотят мобильное приложение а_ля Яндекс Go получить «с нуля» за 35тр, о чем вы говорите... Причем, заметил что самые дурные сочетания сроков и стоимости - у бывших разрабов. «Да я такое сделал бы за неделю, с изучением разработки под андроид с нуля». Ну вы поняли :)
Пилил я как-то пол года С2С стартап. Потом надо было запилить другой, уже B2B. За 2 недели управился, используя уже написанные ранее компоненты. И фронт, и бэк, и даже без говнокода обошлось, и без кранчей.
Ваша проблема же не в том, что заказчик не понимает размеры морковки. А в том, что он как раз понимает, что его дурят. Он хочет от вас типовое решение, как в миллионах других проектах, а вы ему продаёте месяц разработки, словно у вас нет никаких наработок. И тут варианта два:
Либо наработки есть, а вы хотите получить больше денег и/или растянуть сроки.
Либо переносимых наработок действительно нет, что свидетельствует о низком профессионализме.
Причём, самое печальное, что по моим наблюдениям превалирует у программистов именно второй вариант. Они берут гибкие (а порой и не очень), но крайне низкоуровневые технологии и из раза в раз копипастят типовой код. При этом рассказывая сказки про невозможность переноса целой бизнес функции, про "все фреймворки похожи друг на друга", и про "90% задач - типовые".
Пишут все эти бесконечные роуты на недорегулярках, а потом обмазываются сваггерами, чтобы в них не заблудиться. Вручную перекладывают данные туда-сюда, а потом зашиваются с тестированием и рефакторингом гор копипасты. Пишут схемы данных в нескольких местах на разных языках, а потом мучительно дебажат разъехавшиеся контракты. Джойнят таблички в разных позах, (де)нормализуют данные по 10 раз только потому, что "так заведено", а потом борятся с комбинаторными взрывами на ровном месте.
Обосновывается этот кривой выбор технологий тем, что известные коробочные решения слишком дубовые, поэтому надо каждый раз собирать кастомное из говна и палок. Собрать своё коробочное и гибкое - на грани подвига. Да что уж там, даже к другим решениям присмотреться толком не могут, свято убеждённые, что высокоуровневое решение не может быть гибким.
Например, были у меня отдельные приложения: мессенджер и вайтбоард. И решил я на днях добавить чат на вайтбоард. Всё про всё это заняло где-то пол часа. Из них 2/3 времени - написание компонента чата встраивающего на страницу мессенджер, а оставшееся время - вставка этого компонента не только в вайтбоард, но и в ещё пару приложений за компанию. При этом гибкость такая, что этот чат в конкретном приложении можно кастомизировать как угодно с минимальной вероятностью сломать будущую совместимость.
Но что мне говорит типовой программист, когда я рассказываю в своих статьях, как этого достичь?
Всё вы врёте. Это невозможно.
Да это никому не нужно.
Не хочу разбираться, ибо синтаксис конфигов у вас не похож на HTML.
У вас тут мелкая бага вооон в том в компоненте, а вот мы-то пишем без багов.
Отойди мальчик, не мешай серьёзным дядям работать.
Например, были у меня отдельные приложения: мессенджер и вайтбоард. И решил я на днях добавить чат на вайтбоард. Всё про всё это заняло где-то пол часа
Речь о приложениях на Вашем $mol фреймворке?
Ваша проблема же не в том, что заказчик не понимает размеры морковки. А в том, что он как раз понимает, что его дурят. Он хочет от вас типовое решение, как в миллионах других проектах, а вы ему продаёте месяц разработки, словно у вас нет никаких наработок.
С языка сняли. Заказчик точно хочет типовое решение, а ему продают уникальный предмет искусства ручной работы. Причём это похоже на бизнес заказчика, область, в которой уже давно сделали все возможные фреймворки, но ему продают очередной такой фреймворк, видимо чтобы он побольше страдал в будущем.
Заказчик точно хочет типовое решение, а ему продают уникальный предмет искусства ручной работы.
Заказчик хочет дешёвое решение. И для начала ему достаточно типового. И действительно вообще не проблема взять какой-нибудь "конструктор" и слепить ему это типовое решение на нём.
Вот только большая часть заказчиков приходит через месяц и хочет чтобы вы ему к этому типовому решению прикрутили его собственные уже совсем не типовые хотелки. И вот это уже часто не особо хорошо работает с имеющимся "типовым решением". И либо надо всё выкидывать и писать заново, либо начинать лепить костыли чтобы всё это как-то работало.
И чем больше хотелок появляется у заказчика тем больше вероятность что придётся делать заново.
Причём это похоже на бизнес заказчика, область, в которой уже давно сделали все возможные фреймворки
Ну расскажите мне про фреймворк который имеет готовое типовое решение для полноценной интеграции вашего магазина или там системы логистики в системы амазона. Про интергацию с какими-нибудь Rewe/Aldi/Metro или Nagel-Group я вообще молчу.
Заказчик хочет дешёвое решение.
С этого надо начинать. Если заказчик согласен на дешёвое одноразовое решение - хозяин-барин. Если горизонт планирования превосходит несколько месяцев, надо донести, что скупой платит дважды.
Ну так вся статья и написана про это "надо донести". И про то как хорошо это работает, или точнее не работает, в реальности.
Да и вообще если заказчик адекватный, точно понимает чего хочет, понимает куда всё это дожно или не должно развиваться, имеет грамотное ТЗ, оперативно отвечает на вопросы и так далее и тому подобное, то такому заказчику и "не типовое" решение можно сделать относительно быстро и относительно дешёво. Вот только я пока таких заказчиков не встречал. Даже среди крупных фирм и концернов.
Заказчик хочет дешёвое решение.
Не думаю, что есть такие заказчики, которые хотят самое дешевое решение несмотря ни на что. Заказчик обычно ищет оптимальное соотношение цена-качество. Моя проблема со всеми фреймворками ровно в том, что заказчика чаще всего вводят в заблуждение касательно реальной стоимости разработки, а главное поддержки этого агрегата. Если бы заказчику сразу сказали, тебе теперь нужна команда из 3х человек и ФОТ для них в 12 млн в год, то он бы очень сильно подумал о нетиповых хотелках.
Ну расскажите мне про фреймворк который имеет готовое типовое решение для полноценной интеграции вашего магазина или там системы логистики в системы амазона. Про интергацию с какими-нибудь Rewe/Aldi/Metro или Nagel-Group я вообще молчу.
Если получив задачу интеграции с Rewe/Aldi/Metro или Nagel-Group вы 2 месяца тратите на фреймворк для интеграций, то вы точно что-то делаете не так. Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет. Штуки вроде доставки сообщений, их хранение, повтор в случае ошибки, всякие панели управления и мониторинги, оркестрация разных сервисов, все это давно решено. То есть получив задачу на интеграцию будет правильно просто сделать интеграцию, а не разрабатывать фреймворк для описания интеграций.
Вот смотрите
К нам обратилась компания, которой была нужна система, предполагающая некоторое взаимодействие между пользователями разных ролей. Функционала было много, развивать платформу предполагалось итерационно.
Выглядит как типовая задача - бизнес процесс надо организовать, есть миллион решений, но сразу же речь идет о "платформе". Задача о взаимодействии разных ролей стара как персональный компьютер. Игнорировать последние 30 лет развития и писать свою платформу для этого глупо. Заказчик не дурак, он то понимает, что что-то идет не так и сопротивляется.
Если получив задачу интеграции с Rewe/Aldi/Metro или Nagel-Group вы 2 месяца тратите на фреймворк для интеграций, то вы точно что-то делаете не так.
Вы по моему не правильно поняли. Я не собираюсь делать никакой фреймворк для интеграций. Тут просто люди рассказывают что такие фреймворки уже существуют. Или что в каких-то там фреймворках есть уже готовые решения. Вот мне и интересно увидеть примеры.
Выглядит как типовая задача — бизнес процесс надо организовать, есть миллион решений, но сразу же речь идет о "платформе".
А я вам привожу тоже пример из реальной жизни. Который начинался как такая же "типовая задача" и был изначально реализован в виде одного из таких "миллиона готовых решений". А потом понадобилась такая вот интеграция. И ещё одна. И потом ещё одна. И в результате пришли к нам и писали всё заново.
Если заказчик сидел на типовом решении, то можно предположить, что интеграции с компаниями типа Nagel-Group для пользователей этого решения не редкость. Не обязательно конкретно Nagel-Group, не обязательно именно такая интеграция какую вы в итоге сделали. Но следует ожидать, что у пользователей коробки проблемы примерно одинаковые и решения тоже. Тогда должно получаться, что как только пользователь коробки дорос до Nagel-Group, то все, баста, приехали. Опытный интегратор об этих ограничениях должен знать, а неопытный провести достаточно исследований чтобы распознать.
Я думаю, что на самом деле происходит не так. А сначала интегратор, который плохо понимает платформу и учится по ходу, лепит решение, а затем оказывается, что оно плохое. Либо типовое решение изначально было выбрано неверное. Либо компания переросла это решение, как Washington Post перерос WordPress. В любом случае, кроме первого, все нормально, типовые решения не обязаны быть абсолютно универсальными.
А вот первый случай это пример непрофессионализма и защищать его не стоит. Также непрофессионально (и вредно для доходов) впаривать кастомное решение заказчику, который явно требует типовое решение. Я полагаю, что проблема автора статьи в том, что имея в руках Java/C#/PHP все кажется кастомной программой. Не имея опыта в конкретной области заказчика ему впихивают ненужное решение, а он сопротивляется. И все это выдается как поучительная история о том, какие заказчики дебилы.
Возвращаясь к дихотомии Washington Post - WordPress мне хочется вам задать вопрос. WordPress не подходит крупной газете (как минимум) из-за размеров организации, штата редакторов, продажи рекламы и всяких процессов которые с этим связаны и требуют автоматизации. В WordPress я могу указать на массу функций, которых в нем просто нет и обосновать, что добавлять все это в него сложнее, чем писать систему с нуля. А в чем был фатальный недостаток того типового решения, которое вы заменяли?
Если заказчик сидел на типовом решении, то можно предположить, что интеграции с компаниями типа Nagel-Group для пользователей этого решения не редкость
Предположить можно. Есть только одна проблема. А именно что это будет в корне неверное предположение :)
Но следует ожидать, что у пользователей коробки проблемы примерно одинаковые и решения тоже
Хм. Мы сейчас о реальном мире говорим или о том как оно должно было бы выглядеть в теории? Как минимум в моей реальности ситуация выглядит так что предложения из коробки берут в основном из-за начальной дешивизны. Не особо задумываясь о будущем.
ходу, лепит решение, а затем оказывается, что оно плохое. Либо типовое решение изначально было выбрано неверное.
Либо конкретно такое решение нужно не такому уж большому количеству людей. И поэтому никто не заморачивается типовым решением. Но конечно я могу и ошибаться. И где-то существует это самое типовое решение для интеграции с Nagel-Group. Не подскажете где?
Предположить можно. Есть только одна проблема. А именно что это будет в корне неверное предположение :)
Тогда возникает сомнение, что это типовое решение... Ну в самом деле, типовое решение, которое не решает типовые проблемы, это очень странно.
Хм. Мы сейчас о реальном мире говорим или о том как оно должно было бы выглядеть в теории? Как минимум в моей реальности ситуация выглядит так что предложения из коробки берут в основном из-за начальной дешивизны. Не особо задумываясь о будущем.
Вот тут совсем непонятно. Как может типовое решение быть хуже самопала для типичного использования? Понятно, что оно дешевле, потому что продается на потоке. Но оно еще может быть и лучше, потому что в него денег вливается предположительно сильно больше, чем покупатель может себе позволить.
Либо конкретно такое решение нужно не такому уж большому количеству людей. И поэтому никто не заморачивается типовым решением. Но конечно я могу и ошибаться. И где-то существует это самое типовое решение для интеграции с Nagel-Group. Не подскажете где?
AWS SNS/Lambda/Step Functions + C# не поможет? Возможно есть что-то более специализированное и тогда следует взять это решение, при прочих равных.
Тогда возникает сомнение, что это типовое решение… Ну в самом деле, типовое решение, которое не решает типовые проблемы, это очень странно.
Когда люди выбриают решение они далеко не всегда понимают какие проблемы у них есть. И самое главное они далеко не всегда понимают ккаие проблемы у них могут появиться в будущем.
Понятно, что оно дешевле, потому что продается на потоке. Но оно еще может быть и лучше, потому что в него денег вливается предположительно сильно больше, чем покупатель может себе позволить.
Вон у нас недавно был релиз новой версии джумлы. Я бы ене сказал что в неё вливается мало денег. Но при этом как минимум половиной тех фич, которые они добавили только сейчас, я пользуюсь последние лет пять или даже десять.
AWS SNS/Lambda/Step Functions + C# не поможет?
Ну так что из этого имеет готовое типовое решение для интеграции с Nagel-Group? Ну вот чтобы только пару вещей сконфигуритовать и потом только время от времени апдейты ставить? Или это всё-таки фреймворки/технологии, а именно решение мне надо будет писать самому?
>Или это всё-таки фреймворки/технологии, а именно решение мне надо будет писать самому?
Процитирую самого себя
>Обработка событий, которые возникают в рамках интеграции может быть произвольно сложной, но это и есть бизнес логика, которую никто за вас не напишет.
Да, вам нужно собрать решение и часто нужно для этого писать код.
Да, вам нужно собрать решение и часто нужно для этого писать код.
Ну так и получается что я не могу взять какой-то готовый кусок и просто его использовать а ля "Давайте возьмем готовый модуль и просто прикрутим его, например из WordPress."
То есть мне всё равно нужно писать кастомное решение для заказчика.
И ясное дело что я не будут под это дело каждый раз писать с нуля какой-нибудь условный ангуляр. И естественно я буду использовать для всех проектов примерно одни и теже фреймворки/технологии/ЯП. Но типового решения в данном случае не существует.
В отличии от ситуации "мне нужен онлайн-шоп на примерно 500 наименований с регистрацией клиентов и интеграцией стандартных платёжных систем/курьерских служб".
И проблема как раз в том что заказчик не в состоянии адекватно оценить будет ли у него когда-то переход от второго к первому.
Берём стандартный вордпресс, с его стандартной авторизацией. Даже если не берём допиливания "фрилансером за 3 бакса в час", который не знает даже азов и в коде нет багов типа "sql инъекции", а всё-равно находят баги, в том же вордпрессе далеко не 1 критический баг был, даже в ядре, а есть ещё компоненты. Помню, ловили мы крит баг в каком-то модуле магазина...
Так вот, кто в теме веба - часто видят в логах попытки стучать во всякие wp-login. И чем популярнее коробка, тем больше там всего найдено, и тем больше и чаще такое будут сканнить. И второй момент - да, сделали сайт на wp, прошло 5 лет... и вот уже там 2 десятка багов средней критичности и пара критичных. Но никто закрывать бесплатно не будет, так что нужно платить программистам. А если кастомизировали базовые модули то просто кнопкой "обновить" уже ничего не работает, тоже проходили. modx, bitrix, laravel-october... просто обновить версию до месяца программиста занимало. В этом плане "кастом" лучше минимум тем, что его не берут скрипт-кидди, а профи на мелкие сайты не обращают внимание.
И последнее. Сложно представить себе амазон, ютуб, вк и прочее на том же вп. Каждой задаче - свой инструмент.
Так может вы вышеописанный "талантливый самоучка" со своим великом? Сделаете вы быстро бизнесу задачу на велике очень быстро, бизнес останется довольный. А потом вы уйдёте, и бизнес, когда будет дальше развивать продукт, не найдёт спеца на рынке, знающего $мол. И тут уже сумма простых с виду доработок будет куда дороже, потому что 99% человек не будет знаком с вашим фреймворком. А бизнес не поймёт, почему всё стало дольше и дороже, ведь вы-то сделали всё очень быстро, почему случайный человек так же не может?
Собрать своё коробочное и гибкое - на грани подвига.
Так вы же лично сразу возмутитесь - я плачу только за нужный мне функционал, а коробочное решение мне не нужно! Вот и нет коробочного решения. Всё как вы хотите. А сделать так, как вы не хотите - на грани подвига, потому что это всё будет за счёт личного времени разработчика, вы ведь не оплатите то, что вам кажется ненужным.
даже к другим решениям присмотреться толком не могут
Ну здесь же опять вы мешаете. Вы опять скажете - мне нужно только то, что я сказал, ничего другого я знать не хочу (и оплачивать - тем более не хочу). А "присмотреться" ведь стоит денег. Вы не в курсе, сколько времени уходит на понимание нового фреймворка? А на освоение его на профессиональном уровне? Вот столько с вас попросят, если "присматриваться" будут за ваш счёт. И вы реально готовы столько отдать? Это, так сказать, вопрос-проверка. Если ответите "да" - вы скорее всего врёте. А если "нет" - вы обязаны изменить свой тон и пересмотреть отношение к затратам времени на разработку.
Например, были у меня отдельные приложения: мессенджер и вайтбоард. И решил я на днях добавить чат на вайтбоард. Всё про всё это заняло где-то пол часа.
За кадром осталось время, потраченное на архитектуру чата и второй приблуды. Они же ваши, правильно? Значит вы, можно предположить, потратили время на модуляризацию обоих поделок. Та же авторизация, я надеюсь в вашем франкенштейне она выполняется один раз, а не два? И сколько времени вы потратили на реализацию именно модульной настраиваемой авторизации, позволяющей одним конфигом прикрутить друг к другу ваши компоненты? А сколько времени вы потратили на понимание, что добавить/убавить для прикручивания компонентов? Это всё задачи, котроый вы решали на этапе, который скромно спрятали за рамками рассмотрения обсуждаемого вопроса. И теперь, забыв про все накладные расходы, громко заявляете про "пол часа на всё".
Даже ладно, пусть ваша оценка останется на вашей совести, но вот вам внезапно потребуется свести пользователя чата и второй приблуды - что делать? Базы данных разные? Или для чата вы вообще базу не использовали? Всё поди в файлик льёте, что бы быстрее разработать? И сколько теперь нужно времени на разработку парсера того файлика? И сколько ресурсов должен обеспечить заказчик для парсинга гигабайтного файла с чатами на всех пользователей каждый раз, когда нужно свести воедино пользователя чата и второй приблуды? А во второй приблуде тоже поди файлик вместо БД? Ну вот и посчитайте накладные расходы, которые вместо "пол часа" получатся.
И таких внезапных пожеланий заказчика, я вас уверяю, будет вагон. Посмотрим, как вы их за пол часа будете реализовывать.
Эм.. я как бы не заказчик. Тем более не заказчик-самодур. Но если бы я даже что-то и заказывал - я бы предпочёл коробочное решение при прочих равных.
Я прекрасно знаю и сколько времени нужно для осваивания фреймворка, и на его написание. Переусложнённые фреймворки я осваивать не советую, а разрабатывать тем более.
Если какая-то технология потенциально позволит вам повысить эффективность своей работы в несколько раз, то это довольно эффективное вложение своего времени. Это называется саморазвитие.
Создание компонента чата - одноразовая задача. Сделал один раз и встраиваешь в любые проекты за 5 минут. Это с учётом прокидывания авторизации.
"Модуляризация" в правильной архитектуре ничего не стоит и получается автоматически. А не после пары месяцев рефакторинга.
Конкретно в этом франкенштейне компонент авторизации ещё не реализован. Поэтому я и привёл пример с чатом, а не авторизацией. Тем не менее, реактивные потоки позволяют довольно легко связывать компоненты между собой.
В том B2B проект, о котором я говорил, авторизация просто перекочевала из предыдущего проекта. Но если вас интересует именно франкенштейн, то немного подробностей:
База данных общая. Сейчас это PostgreSQL.
Авторизация, соответственно, происходить будет один раз.
У каждого клиента локально свой срез этой базы.
Обмен данных идёт по вебсокетам.
Состояния мёржатся через CRDT.
Важные клиенту данные хранятся у него локально.
Можно работать в оффлайне.
Сейчас прорабатываю новый, ещё более быстрый алгоритм синхронизации баз.
Я посчитал накладные расходы, когда закончу эту инфраструктуру, приложения будут вообще как пирожки выходить. А когда допилю ещё и ноукод конструктор, так вообще за пол часа можно будет накликивать информационные системы.
Он хочет от вас типовое решение, как в миллионах других проектах, а вы ему продаёте месяц разработки, словно у вас нет никаких наработок.
Покажите мне "типовое решение" даже для банальной формы регистрации с полем для паспорта.
С одной стороны, глупо создавать Оптимуса Прайма для того, чтобы перевезти прицеп.
С другой стороны глупо надеяться, что в стандартный грузовик сможет уничтожить Десиптикона.
Нужно понять, что нужно в итоге или что скорее всего понадобиться.
Например, были у меня отдельные приложения: мессенджер и вайтбоард. И решил я на днях добавить чат на вайтбоард.
Круто, добавили чат. А если туда зайдёт 10 000 000 пользователей одновременно?
Вот такой поворот. Бизнесу нужна такая возможность. Что случиться? Ваша архитектура готова к этому испытанию? В смысле нет? Как! Ваши приложения выдерживают 10 пользователей? Ну, ок, добавим оперативки на серваки. Почему не поможет?
Статья не про конкретный технический кейс, а про заказчиков, которые не понимают за что платят. И не хотят понимать. Они заплатили $N и ожидают увидеть рыбу на столе.
Они платят, в конкретном кейсе, за адекватный фундамент для всего портала. Это упростит жизнь абсолютно всем. win-win-win ситуация. Бизнесу будет хороший и стабильный продукт, который можно дешево, легко и быстро доработать нужным функционалом. Разрабам будет хороший продукт , от которого не хочеться умереть, пока добавляешь "кнопочку вооон там". Пользователям будет хороший сервис, не лаганутый, доработанный, у которого нет утечек данных паспортов каждые N месяцев. Но для этого несбыточного рая нужно чтобы случилось немысленное.
Нужно, чтобы бизнес заплатил немалые деньги за то, что он никогда не увидит явно.
Да, потом все будут довольны, но сначала бизнесу нужно стать недовольным.
"И так несколько раз по кругу. Я пытался рассказать о том, как строятся системы, почему не бывает “стандартной регистрации”
Неплохо бы выслушать и противоположную сторону. Бывают, конечно, непрошибаемые дебилы, но в сфере бизнеса их все-таки естественный отбор стремится отсеивать, поэтому есть подозрение, что не смогли правильно объяснить простую суть: изначально закладывается основа, это занимает время и ресурсы, поэтому первый результат будет визуально скромен, зато потом с каждым релизом будет что потрогать.
Нужно было взять пример, близкий деятельности вашего заказчика, чтобы ему было понятно, и проблемы бы не было. Ваша ошибка в том, что вы на немецком пытались объяснить немецкую грамматику человеку, не знающему немецкий.
Если первый шаг все равно в прод не идет, почему нельзя было сначала запилить какую-то бизнес фичу, а регистрацию уже потом прикрутить? :)
Не надо решать за заказчика.
Хочет человек вордпрес - ну так пусть берет вордпрес, там действительно регистрация уже из коробки есть.
Вы, как специалист, должны объяснить ему риски и преимущества того и иного подхода, а решать должен он сам. Если вы грамотно и доходчиво ему всё объяснили, он выбрал тот вариант, который его устраивает, а потом оказалось, что он выбрал неправильно - давайте уж на чистоту, это его ошибка и это его проблема.
Возьмём строительство, как наглядный пример. Если человеку объяснили, что без фундамента можно построить разве что сарай, и он с этим согласился, а через полгода хочет нарастить на построенном сарае ещё два этажа, превратив его в дом для постоянного проживания - это его личные ошибки планирования. Пусть сносит сарай и начинает всё заново - за ошибки всегда приходится платить.
Возврашаясь к разработке - по крайней мере, ему потом не надо будет делать заново абсолютно всё. Как минимум, интерфейс останется, так что на второй итерации дизайнер уже не будет нужен или у него будет меньше работы. Да и технические требования будут лучше проработаны, чем когда начинаешь вообще без ничего. Это называется "прототипирование", и это вполне адекватный способ разработки.
вот поэтому заказчики делают на прости хоспади Тильде. Потому что месяц работы команды программистов чтобы делать одну авторизацию и «прорабатывать модель данных»это ту мач. Ах да, еще же:
фаза проектирования, мы проработаем модель данных — месяц что ли?
базовые механизмы — они что, настолько сложные, что месяц нужно. Он ж «базовые»
кучу сопутствующих вещей — отличная характеристика
и начнем реализацию больших блоков, которые завершатся позднее — еще более отличная (хотя куда уж более отличней) — «начнем» — может означать поставить 1 пробел в IDE
фаза проектирования, мы проработаем модель данных — месяц что ли? базовые механизмы — они что, настолько сложные, что месяц нужно. Он ж «базовые»
Месяц это ещё достаточно оптимистично. Потому что обычно возникают вопросы и на них нужны ответы от клиента. И если "повезёт", то эти ответы можно неделями ждать.
Поэтому самой работы там может быть и на пару дней. Но весь процесс спокойно растягивается на месяц-два-полгода и при этом блокирует как минимум отдельных людей.
вот поэтому заказчики делают на прости хоспади Тильде.
А потом как минимум приличное количество из них делают ещё раз но уже не на Тильде. Если не большинство.
То есть если что-то можно сделатъ на Тильде, то делайте и будет вам счастье. Зачем идти куда-то ещё и просить чтобы они вам на Тильде что-то сделали?
Я не заказчик Почему Вы мне советуете Тильду?
Повторю, речь идет о базовых. Если о базовых не договорились еще, то как ж к работе приступили?
Если вы посмотрите на кртинку, то увидите что первый этап(тот который длиной в месяц) включает в себя "проектирование" и "модель данных". То есть в моём понимании о базовых вещах ещё никто окончательно не договорился.
И кроме "базовых вещей" он включает в себя и регистрацию и авторизацию и какую-то часть двух "бизнес-функций". На мой взгляд вполне себе достаточно для месяца на самом старте проекта. И даже скорее это ещё и слишком оптимистично.
по мне, договорились о базовых вещах, когда есть ТЗ, хотя бы какое-т
базовые вещи это «делаем фейсбук» или «делаем твиттер» или делаем интернет магазин аналог «Озон» — ну хотя бы. Описаны функции. разделы, накидан примерно дизайн
А как иначе
но с другой стороны, не понятно, почему авторизацию нельзя делать параллельно? что за нагнетание сложности. Суть авторизации-аутентификации — внести в базу данных логин, пароль, роль юзера и выслать ему по почте/телефону подтверждения. Собственно все (да, нельзя просто взять с вордпресса эту функцию, но можно ее тупо списать, если разработчики никогда не делали авторизацию). А что там дальше будет цепляться к роли — дело 10-е и может меняться сколькр угодно. что, эти ребята-разработчики, в первый раз SQL видят? или они до сих пор не определились, как будут базу данных делать? то ли в текстовых файлах, то ли в квантовом компьютере.
в базе то это будет одна таблица с полями (имейл, телефон, логин, «пароль», роль") опционально добавляется еще какая-то нужная обвязка. И что тут делать «месяц»
Ладно, клиент не шарит, перейдем к донесению инфы клиенту
Клиенту надо сказать, что месяц мы будем страдать херней (мы ж опытные прогеры, для нас каждый заказ это как полет в космос в первый раз), а саму авторизацию можно написать за 2 дня (день будем отходить от пропивания денег поступивших за первый месяц)
Если серьёзно, то базовые вещи, «модель данных» обсуждается по факту с клиентом еще на этапе согласования договора, так что и клиент и менеджер понимает «че надо»
Выше писали про строительство. Ну так у строителей, тоже, сначала согласовывается ТЗ, рисуется документ, где описаны размеры, фундамент и прочее прочее и это при том тоже стоит денег иногда. То есть уже есть понимание «модели данных» и «базовых вещей». Но если это опытная строительная компания, то у них не будет рисоваться один документ месяц силами нескольких дорогостоящих людей. Месяц может конечно рисоваться, то это когда рисовалщик балду пинает
ну если не договорились о базовых вещах, то нет смысла вообще что-то начинать
по мне, договорились о базовых вещах, когда есть ТЗ
Договорились "о базовых вещах" это в реальности договорились о бюджете и примерном обьёме работ. Конкретное ТЗ очень часто пишется уже совместно и бесплатно это делать тоже никто не будет.
«делаем фейсбук» или «делаем твиттер» или делаем интернет магазин аналог «Озон» — ну хотя бы.
Ну ок. "Примерно фейсбук" или "примерно озон" это "примерно 10 лет работы". Например потому что там под капотом дофига интеграции со всем чего не лень. И всё это куча работы. А если вам всё это не нужно, то тогда это уже и не "примерно озон".
Суть авторизации-аутентификации — внести в базу данных логин, пароль, роль юзера и выслать ему по почте/телефону подтверждения.
А потом вы хотите интегрироваться в экосистему какого-нибудь условного амазона и внезапно выясняется что у них есть определённые требования по безопасности. И ваша система авторизации им не удовлетворяет. Или вы например захотите функцию а ля "залогиниться через вконтакте". Или ещё что-то в этом роде.
А что, интеграция в экосистему Амазаон перечеркнет требования наличия полей в базе данных, как логин, пароль и тд? Эта интеграция просто добавляет сложности, не перечеркивая уже сделанной работы. И это будет «потом». хотите документально раз и навсегда согласовать ТЗ — так кто ж мешает — оформляйте договор, пропишите неустойки. Это тоже входит в базовые вещи. типа клиент грит, я интернет-магазин, буду продавать через сайт, соцсетки, вайлдбериз, озон-амазон. Мне нужно собирать от юзеров как зовут их маму, собаку и девьчью фамилию матери (кровь девственниц опционально)
Логинится в контакте — это тоже уже давно сделанное решение. Да наверно и у Амазона также. Ведь если я подключу модуль к ворпдрессу «авторизация через социалки» это не разрушит обычный модуль авторизации, а дополнит? почему у «фреймворк-писателей кода» каждая новая фича это ужас-ужас-ужас? ну да. ужас. но не ужас-ужас-ужас. Может надо менять прогеров? на менее пугливых или тех, кто хоть раз видел CMS и систему плагинов-модулей?
ну мне кажется бюджет и сроки это не базовые вещи, а не знаю что. Как можно договариваться о бюджете и сроках не договорившись о каком-нибудь ТЗ?
Очень просто можно. И регулярно делается.
А что, интеграция в экосистему Амазаон перечеркнет требования наличия полей в базе данных, как логин, пароль и тд?
Она например может потребовать чтобы определённые поля хранились в шифрованном виде. Или например чтобы пароли были определённой длины. Или чтобы ваша система "просто" соответствовала какому-нибудь GDPR.
Эта интеграция просто добавляет сложности, не перечеркивая уже сделанной работы.
Эта интеграция "просто" добавляет сложности уже на старте проекта. И таких "просто добавляет сложности" может набраться столько что вы вот эти вот самые "базовые вещи" в результате и будете полгода писать.
Логинится в контакте — это тоже уже давно сделанное решение. Да наверно и у Амазона также. Ведь если я подключу модуль к ворпдрессу «авторизация через социалки» это не разрушит обычный модуль авторизации, а дополнит? почему у «фреймворк-писателей кода» каждая новая фича это ужас-ужас-ужас?
Потому что этот самый условный "модуль авторизиции к вродпрессу" писался не одним программистом за пол дня работы. Если вы хотите точно такой же, то не проблема. Но это само по себе может занять месяц. Или два. Или полгода. В любом случае это будет дольше и/или дороже чем абсолютно примитивная авторизация которая ничего этого не может. И как вы думаете что выберет средний заказчик и что он будет готов оплатить как "типовое решение"?
Клиент хочет авторизацию через месяц? нет проблем, берите с него ТЗ. пилите авторизацию
Какая разница что там будет «потом», захочет потом интеграшку с Амазоном — это будет отдельная работа и отдельные деньги. ТЗ вообще всегда переписывается. К этому надо быть готовым. шифрование? шифрование отменяет сделанные поля в базе данных? А требование длины пароля перечеркивает всю сделанную работу? Вы кому лапшу то вешаете? Я не Ваш клиент.
Месяц-2 повторить код из ВП? Вы точно прогер?
Вы придумываете сложности, которые настанут потом. Но не факт
Как раз таки наоборот. "Типовое решeние" должно их обязательно учитывать. Или должно быть несколько "типовых решений" на все случаи жизни.
А если я делаю что-то кастомное, то я могу спросить у клиента что конкретно он хочет. И написать ему именно это.
Какая разница что там будет «потом», захочет потом интеграшку с Амазоном — это будет отдельная работа и отдельные деньги.
Вот только если выясниться что интеграция с Амазоном требует полностью переписать приложение с нуля, то я эти деньги точно не получу.
Месяц-2 повторить код из ВП? Вы точно прогер?
Создать ещё один ВП с таким же функционалом? Гораздо больше чем месяц-два.
И ещё раз: если клиент счтиает что ему на 100% достаточно функционала, который даёт вордпресс, то зачем ему идти к фирме которая делает кастмомые решения? Пусть нанимает эникея и он ему настроит этот самый вордпресс. Вот только на данный момент реальность выглядит так что у всех "конструкторов" вроде вордпресса есть потолок возможностей. И он относительно низок.
Зачем переписывать с нуля? получите ли Вы деньги или нет — это вообще отдельный вопрос. Тема этой статьи про клиента, который хочет в первый месяц авторизацию
Зачем создавать еще один ВП? Я писал про взять модуль авторизации
Клиенту достаточно функционала модуля авторизации в Водпрессе. Но не достаточно других требуемых ему фич. И да, раз клиент знает про Вордпресс, значит ему он чем-то не устраивает. И это возможность заработать, а не причина отфутболить клиента
откуда взялось «типовое решение»? клиент просил авторизацию, а не «типовое решение.
Потому что либо решение кастомное и тогда мы выясняем что конкретно хочет клиент. И пишем это с нуля. Или он получает что-то уже готовое. И это "готовое" и есть "типовое решение".
Если для него типовое это как у Вордпресса — то еще проще
Зачем переписывать с нуля?
Потому что "типовое как у вордпресса" это значит не вордпресс, но при этом как у него. Откуда такое должно взяться?
Я писал про взять модуль авторизации
Клиенту достаточно функционала модуля авторизации в Водпрессе.
То есть вы предлагаете "просто" взять модуль авторизации у вордпресса и использовать его в каком-то своём решении? Даже если это решение использует совсем другие технологии? А потом ему понравится условный модуль регистрации у джумлы и мы его "просто" так возьмём и сбоку прикрутим? Теперь у меня возник вопрос: а вы точно программист?
И это я ещё про вопросы вроде лицензирования начинать не хочу...
2.Откуда взяться? — Написать. Неужто мало месяца работы одного квалифицированного разработчика?
3. Я предлагаю посмотреть как сделан модуль авторизации и повторить это у себя в системе. Учитывая, что функция/модуль авторизации у Ворпдресс не является биномом ньютона, то и повторить это не составляет труда. Ну и вообще. Вы в первый раз пишите авторизацию? У Вас вообще никаких наработок?
Что лицензировать? 2 поля для ввода логина и пароля? а может хранение логина, пароля, отсылка уведомления по электронке? хранение солей в базе? Вы точно юрист?
Откуда взяться? — Написать. Неужто мало месяца?
На что? На "проектирование"/"модель данных" + регистрация/авторизация + какие-то ещё бизнес-фичи? :)
Я предлагаю посмотреть как сделан модуль авторизации и повторить это у себя в системе.
И это во первых может иметь кучу лишних вещей, который существуют исключительно ради интеграции в этот самый вродпресс. А во вторых может местами иметь особенности связанные с конкретными использованными технологиями. И в третьих не у всех контрукторов/существующих на рынке решений есть доступ к коду.
То есть в принципе конечно можно, но тоже займёт кучу времени если не просто тупо копипастить с опенсорса.
Вы в первый раз пишите авторизацию? У Вас вообще никаких наработок?
Естественно у нас есть наработки. Но во первых как раз таки мой опыт показывает что рано или поздно всё приходится кастомизировать.
А во вторых речь же идёт о ситуации в целом и авторизация это только пример.
Что лицензировать?
Далеко не все "конструкторы" это опен-сорс. И если вы тащите чужой код, то это может аукнуться. То есть в России на это может и забивают. У нас таким лучше не заниматься.
Зачем Вам доступ ко всем конструкторам на рынке, когда мы говорим про Вордпресс?
А что, кастомизация перечеркивает все наработки? а не дополняет? может стоит посмотреть (я уже писал про это) как сделана система модулей? ведь в ВП доп. модули не перечеркивают работу остальных модулей? Какая нить «логинза» не ломает стандартный модуль авторизации. Почему же, с Ваших слов, любое доп. требования (типа длины пароля) сразу перечеркивает всю проделанную работу? Не задумывались. что что-то тут не так?
Месяц на авторизацию как у ВП. разумеется лишнее тащить не надо. Скажите, это много или мало? Сколько это это человек-часов в вашей организации?
Как только вы мне напишите что конкренто в вашем понимании означает "как у ВП". Такой же вид формы длай ввода?
Авторизация с плагинами, которая позволяет подключать заранее ограниченный набор типов авторизации?
Модулярный подход, позволяющий интегрировать плюс-минус любую теоретическую функциональмость?
А что, кастомизация перечеркивает все наработки?
Не все. Но местами перечёркивает.
ведь в ВП доп. модули не перечеркивают работу остальных модулей?
Ну так в ВП у вас вся система построена на модулях. Но это имеет как свои плюсы, так и свои минусы.
Какая нить «логинза» не ломает стандартный модуль авторизации.
Но при этом у нас в ВП есть вагон и маленькая тележка плагинов реистрации/авторизации и они почему-то не совместимы между собой.
Почему же, с Ваших слов, любое доп. требования (типа длины пароля) сразу перечеркивает всю проделанную работу?
Хм, в каком месте я утверждал что любое дополнительное требование что-то там перечёркивает? Я макисмум писал что существуют те или иные дополнительне требования которые могут перечекнуть.
Такой же вид формы длай ввода? — да
Авторизация с плагинами, которая позволяет подключать заранее ограниченный набор типов авторизации? да
Модулярный подход, позволяющий интегрировать плюс-минус любую теоретическую функциональмость? а такое у ВП есть? значит да
А по мне не должно быть таких доп. требований, который могут перечеркнуть всю сделанную работу. (у меня фантазии для этого не хватает)
Иначе это хреновая архитектура, ибо ТЗ меняется всегда.
А вообще, вы тему увели в другую сторону. Обсуждаль то, что за месяц реально запилить авторизацию по ТЗ клиента, которая похожа на авторизацию у ВП
А вы жалуетесь на то, что «потом может все поменяться». Да, потом может поменяться, но это не имеет отношения к проблеме, которая сейчас. Клиента хотят налюбить прикрываясь умными словами, а клиент тож не дурак
Модулярный подход, позволяющий интегрировать плюс-минус любую теоретическую функциональмость? а такое у ВП есть? значит да
Ну то есть вы хотите получить не просто авторизацию, а каркас этого самого ВП и ещё и авторизацию сверху. И вы считаете что для этого надо меньше месяца работы?
Иначе это хреновая архитектура, ибо ТЗ меняется всегда.
Ну тогда расскажите мне почему мы имеем "WordPress 5.8", a не 1.х.х. :)
На всякий случай скажу, что я полностью поддерживаю вашу точку зрения, просто решил проинформировать, что версия WordPress 5.8 это, по-сути "58-й релиз" т.к. WordPress не следует semver. Можно посмотреть историю релизов в Wiki, там видно, что после X.9 идёт X+1.0
Нельзя в строительном магазине купить коробку с горячим водоснабжением - можно купить отдельно трубы, краны и котел, все смонтировать, настроить, и закрыть плиткой.
Можно. Погуглите "бойлер на кран"
Ну вот как раз это и есть "сделать на Тильде". А когда заказчик захочет воду погорячее, или чтобы работало на газе, или чтобы грело не только кран, но ещё и в душе — ему придётся выкинуть эту коробку и делать всё с нуля.
А в худшем случае окажется, что у заказчика нет водоснабжения или электричества, но в отсутствии горячей воды он винит вас и проданную ему вами коробку.
А это вопросы к заказчику
Хотите погорячее - можно прикрутить кран, поток уменьшится, вода станет горячее
Хотите горячую воду с хорошим потоком - накопительный электробойлер на 20 литров
Хотите, чтобы хватало на душ семье из трёх человек - бойлер на 100 литров, а лучше на 200
Нет электричества - тогда дровяной котел
Хочется не ждать нагрева, чтобы открыл и течёт, и минимум обслуживания и максимум комфорта - получаем техусловия, составляем проект, находим фирму, проводим газ, ставим газовый проточный котел, возможно сразу двухконтурный, разводку по всему дому, теплые полы, термостаты на стену и смесители. От трёх до 9 месяцев. Любой каприз за ваши деньги.
Каждая строчка приносит business value, но стоит денег. Но только заказчик знает, что он именно хочет, когда, и с чем может временно мириться.
Может вариант "сегодня бойлер на кран", а параллельно заниматься "газификацией дома" - это лучшее решение.
И мы вернулись к тому, с чего всё и началось — "объяснить заказчику".
Мы вернулись к моменту "выяснить, что точно хочет заказчик", а не "объяснить заказчику, из чего складывается самое лучшее, по нашему мнению, решение".
Так в том то и проблема что заказчик хочет полноценную отопительную систему по цене бойлера на кран. А вам надо ему объяснить почему оно так не получится.
Но, у заказчика тоже есть какое-то понимание и он чувствует, что его хотят налюбить. Поэтому и просит, что-то сделать за первый месяц (модуль авторизации аналогичный ВП), а не платить за то что «наш тимлид подумает»
А раз заказчик доволен авторизацией как у ВП (если не доволен, можно уточнить), то и с ТЗ все достаточно просто
то есть, как говорил Хрущев: наши цели ясны, задачи определены, за работу, товарищи!
Это не я придумал. Об этом статья которую мы обсуждаем. то есть например:
Мы хотим по итогам первого этапа увидеть весь основной функционал, а все остальное давайте делать позднее
То есть люди хотят за месяц практически с нуля получить весь основной функционал.
Короче, кто-то тут свистит. возможно оба. Нет у нас полной инфы
Ладно, в любом случае, разработчик пролюбил коммуникацию с клиентом.
Прошу прощения за резкий тон
у людей, которые врут, есть характерные паттерны поведения
у людей, которые врут, есть характерные паттерны поведения
"Как определить что политик врёт? Очень просто: когда он врёт, то у него шевелятся губы" (с) кто-то.
А так, звонок другу, помощь зала, убрать 50% вариантов. Ничего не забыл? :)
Вы конечно можете спросить «а что если», а смысл этих вопросов? Что если завтра прилетит метеорит и убьет?
Если не хочется ждать нагрева "открыл и течет" - это еще рециркуляцию надо организовать. Просто котел - это "открыл и ждешь, пока стечет". Больная тема для меня.
И так несколько раз по кругу. Я пытался рассказать о том, как строятся системы, почему не бывает “стандартной регистрации” и в чем риск строить mission critical систему в конструкторе сайтов, но особого эффекта это не возымело.
Если заказчик знает про риски, это зафиксировано и хочет сделать все равно на вордпрессе, почему он не может получить то, что хочет?
В статье всё-таки нет ответа, как вы договорились (успокоили, оставили довольным) клиента или предполагаете работать со следующими, есть только про неудачный компромисс. Вы будете ему ссылку на эту статью кидать, или как? Кстати, двойной комментарий под иллюстрацией, в дополнительных комментариях не нуждающейся, это замечательно.
Да, заказчик не понимает специфику исполнителя, но будь иначе - не факт, что исполнитель вообще бы понадобился. Конечно, заказчики бывают очень разные (например, я во время шабашки на стройке не смог одному объяснить необходимость дать бетонной подушке застыть, он так и был уверен, что я так взял выходной), но большинству с упором на деньги можно объяснить, почему так, а не иначе.
В итоге удалось (вроде) объяснить, почему нельзя к кастомной разработке быстренько прикрутить авторизацию из вордпресса. К написанию статьи подтолкнул тот момент на переговорах, когда мы оба сделали круглые глаза: заказчик от удивления, что невозможно переиспользовать готовый кусок и сэкономить на этом время (критично было именно время, а не деньги), а я - от "крамольности" такого предложения.
хуже всего когда менеджер типа меня разбирается в разработке (20 лет разрабом) и инструментах)
Всё по делу
Есть известная поговорка. Мы делаем быстро, дешево и качественно. Выберите любые два. Не нужно за заказчика решать, какие варианты он выберет, так как выбор субъективен и зависит от его текущих бизнес-задач и стратегии.
Если он хочет за месяц весь функционал, то он выбирает первые два. В данном случае, качественно или нет - это вовсе не значит, что все будет ломаться. Это может быть, например, ограничения, с которыми он готов смириться.
Например, когда выбирается любая высокоуровневая платформа для разработки, то заказчик соглашается с ее ограничениями в пользу скорости и стоимости. Причем, чем быстрее и дешевле, тем, как правило, больше ограничений.
Простите, а на чем вы делаете сайт, что вам надо программировать авторизацию? Все известные мне фреймворки и шаблоны УЖЕ содержат ГОТОВУЮ аутентификацию и возможности подключения авторизации на любом веб-вызове.
План в котором не видно результатов отдельных пунктов работ - это развод. Потому что никто, даже сами разработчики, не смогут сказать реально ли эта работа закончена или нет.
Почему бы не заниматься проектированием и моделью данных во время реализации бизнес-функции? Настолько насколько это необходимо чтобы реализовать именно эту бизнес-функцию.
Почему бы не использовать существующие библиотеки и шаблоны для регистрации и авторизации пока в рамках реализации бизнес-функции не потребуется их переделать?
Собственно поэтому и существует agile, где один из принципов - "working software over comprehensive documentation". Это не просто отказ от огромных томов документации, но и планирование работ в рамках которых вы будете создавать работающее ПО, а не хрен пойми что.
В том и дело, что авторизацию с нуля никто не программировал, в этом проекте использовался Laravel. Сама авторизация заняла, я не знаю, меньше дня, плюс еще несколько дней на регистрацию - там было много работ по фронту, плюс UI для админа, который проверяет учетную запись и одобряет ее.
Для того, чтобы решить эту несложную задачу, нужно было, нарисовать дизайн макеты, согласовать их, сверстать фронт и только потом уже что-то кодить. Параллельно делались и другие задачи. В итоге по планам выходило, что к условному 31му числу эти две задачи завершены полностью, а другие - не полностью и формально их сдать нельзя.
Заказчик это воспринял как "месяц на авторизацию" и предложил сократить время способом, описанным в статье.
Представьте, что вы строите дом на заказ, вам нужно 12 месяцев на это. К вам через 11 месяцев приходит заказчик и говорит: "Вам что, не хватило 11 месяцев на то, чтоб поклеить обои и расставить цветки в горшках?"
По моему опыту. Такого рода статьи не интересны (моим клиентам), тк общие слова - типа вам поездом или самокатом, или ой как сложно-сложно и в целом сложно, мягко говоря, недооценивать интеллектуальный уровень. Если рассказывать, то терминами его бизнеса, но и конкретно технически приводить аналогии из вашего. Никогда не надо недооценивать клиента - проектируете - покажите тз или диаграмму классов из предыдущих проектов и тп. Расскажите сколько человек и чего делали КОНКРЕТНО ЭТУ диаграмму и без нее будет УГ, почему? - реальные кейсы. Не надо оперировать мифическими историями, или мифическим тех долгом и critical чего-то там. Сделали на конструкторе тильда - не можем прикрутить платежку Альфа банка, тк требования безопасности - конкретно такое, ну и в том же духе.
Второе - если чел начинает топить что тут 2 кнопки и я видел дешевле, это какого уровня проект? Обычно есть задача что-то автоматизировать, есть вилка бюджета. По ней - решения дорого и богато и что входит, или MVP + тех долг. Все расшифровать по человечьи, не считая заказчика "...".
Еще вариант клиента - сделайте максимально дешево и дешевле, это головняк в 90%. Оно вам надо?
Возвращаясь к статье. Кто конкретно ваша ЦА (это риторический вопрос если что, но явно не клиенты)? Более менее крупняк делегирует эти задачи или "тех-кому-то" из конторы или помощнику Васе. Если тех - он обычно в курсе че-почем и как, если Васе - ему чтобы готово было и красиво (можно с откатом) и меньше движений. Если частник и которому дешево - он уже все знает, и "меня не нае..шь я цены знаю!", (бывают частники с деньгами, но редко). Поэтому как мне видится по статье вы не совсем понимаете кто ваш клиент и скорее всего указанный кейс это не ВАШ клиент.
PS это личный опыт, ничего никому не декларирую и не поучаю.
Я писал такую же статью здесь 8 лет назад :)
Очень понравились метафоры в тексте: про свечу и лампочку, про горячее водоснабжение из строительного магазина, про топор для кошения травы и про приваренный к кузову капот.
— сервис будет работать только в отдельном сегменте внутренней сети, за всеми возможными защитами
— доступ с сети и сервису будут иметь только строго определенные люди, надежность которых принимается равной 100%
Это решение позволило сэкономить массу времени на дизайне и разработке, т.к. вся «защита» была сделана в виде простейшей парольной системы, смысл которой был не в самой защите от чего-либо злонамеренного, а в ограничении возможных действий пользователя. Просто как предохранитель, чтобы пользователь по недомыслию или из-за незнания не сделал чего-либо, что ему делать не надо. Все было отлично, заказчик был доволен, система работала несколько лет без всяких нареканий.
Потом в результате некоторых процессов проект перешел в другие руки, и новый руководитель захотел, чтобы система была видна снаружи и доступ к ней мог получить любой, у кого есть соответствующие логин/пароль. После чего он вышел с предложением (барабанная дробь) добавить к сервису модуль безопасности, чтобы его можно было выставить напрямую в интернет. Никакие объяснения, что для этого надо переделывать весь дизайн проекта фактически с нуля, понимания не находили.
И не найдут, потому что не надо все переделывать. Непонятно как вообще надо сделать систему, чтобы в неё нельзя было добавить авторизацию. В каждом фреймворке это есть, что надо было сделать, чтобы нельзя было просто включить встроенную функцию?
Простите, но вы понимаете безопасность системы, выставленной в интернет, примерно как описанный в моем посте руководитель. При чем тут авторизация, которая к слову в системе есть (о чем я писал)? Защита от брутфорса, DDOS, инжекций, format string, переполения буфера, фильтрация технической информации в сообщениях об ошибках и еще 1024 возможных атаки вы не рассматриватете? Или по вашему все это можно просто привинтить без адских костылей в виде отдельного модуля к системе, в которой защита не закладывалась на уровне дизайна?
Защита от брутфорса, DDOS, инжекций, format string, переполения буфера, фильтрация технической информации в сообщениях об ошибках и еще 1024 возможных атаки вы не рассматриватете? Или по вашему все это можно просто привинтить без адских костылей в виде отдельного модуля к системе, в которой защита не закладывалась на уровне дизайна?
Именно так, если вы используете нормальный фреймворк, то все это у вас уже есть, осталось включить в конфиге. Скорее всего не будет защиты от DDoS, но тут вам помогут облака и/или cloudflare. Если же у вас нет фреймворка и вы все написани на чистом C, то вам поможет AWS API GW. Хотя тут, конечно, вопросы будут к SQL injection и аналогам, то есть ошибкам и небрежностям в кодировании.
Мне не очень понятно что означает "закладывать защиту на уровне дизайна". Защита это аспект, которые все известные мне среды разработки стараются максимально отделить от бизнес логики. Потому и включается все это в конфиге или подключением модулей/библиотек.
Если же у вас нет фреймворка и вы все написали на чистом C, то вам поможет AWS API GW. Хотя тут, конечно, вопросы будут к SQL injection и аналогам, то есть ошибкам и небрежностям в кодировании.
Фреймворка там не было, и как вы сами же написали, вопросы к обрабатываемым данным остаются полностью незакрытыми. Не только к SQL, но и к format string, переполнениям и т.д. И защиты от всего этого в сервисе не было по причинам, которые я описал выше.
Мне не очень понятно что означает «закладывать защиту на уровне дизайна».
Я. вероятно, не совсем понятно написал. Имелось в виду, что сам протокол клиент <-> сервис был бы совершенно другим. Например, там была команда, которая выделяет память для бизнес-логики по данным из другой команды со стороны клиента, а освобождалась память после команды со стороны клиента, что его все устраивает. При этом не было никаких проверок на выделение слишком большого количества памяти и никаких проверок на несовобождение памяти. Я прекрасно понимаю, что в обычном случае так делать нельзя по определению, но конкретно в данном сервисе это было сделано его авторами совершенно сознательно, т.к. заказчик гарантировал достоверность данных и неиспользование команд для злонамеренных действий. И все это прекрасно работало без каких-либо сбоев несколько лет, т.к., как я писал выше, сервис крутился в отдельном сегменте за всеми возможными защитами, и пользовались сервисом только «отфильтрованные» люди. Ну и сама обработка данных, разумеется, тоже была бы совершенно другой с обертыванием всего для защиты от инжекций и т.п.
Нашли чем удивить, даже на добавление одной кнопки может уйти больше месяца работы, по принципу верхушки айсберга. Поэтому опытные тимлиды понимают насколько важно хорошо проработанное ТЗ.
Статья больше похоже на "крик души". Я полностью поддерживаю продуманную и поэтапную организацию работы, но хотелось бы отметить, в реальности так не получается сделать чуть более чем никогда. Нужно всегда уметь приспосабливаться к любым переменам настроения заказчика. И если заказчику нужен автомобиль, у которого капот приварен к кузову, то не стоит думать о том, как поменять масло, поскольку вам такую задачу пока не ставили. Нужно относиться проще и решать задачи по мере их поступления.
На самом деле все намного проще, вы просто не подходите друг другу с данным заказчиком. И нет смысла что-то доказывать и объяснять. Его правильный исполнитель как раз тот самый сын маминой подруги, который накидает прототип на wordpress со всем нужным функционалом в один вечер, еще предложит три десятка вариантов шаблонов, про регистрацию никто даже не вспомнит. И это абсолютно нормально.
Бывают противоположные кейсы, в таких ситуациях заказчик может одобрить разработку прототипа возможно в годы, с бесчисленными митингами привлечением юристов, и прочими плюшками корпоративной разработки. Стартовать этот продукт будет с масштабированием из коробки обмазанный метриками и логами. Все будет красиво и хорошо, если так бывает =)
Стоит определится с "вашим" клиентом и возможно отказав однажды вы встретитесь с тем же заказчиком, когда заказчик "дорастет" и ему будут очевидны сроки, а ваши месяцы на доработку авторизации покажутся мгновением в океане тасок утопающих в легаси.
Все-таки надо уже вводить нормативку в программирование. Перед созданием/реконструкцией чего-то нового будь добр сделать проект и согласовать его с причастными структурами. Иначе это так и будет - я попросил всего лишь пристроить мне гараж, а вы хотите делать это два года.
Развод
У исполнителя вышедшего на рынок уже должны быть разработаны все кирпичики бекенда
Никто ж не оплачивает снова и снова создание вордпресса
Добавить две кнопки — почему так дорого?