на этапе составления требований упустили очевидное бизнес-правило: когда у каждого клиента должен быть свой персональный менеджер.
Вы так говорите, как будто системы проектируют один раз на берегу, и они потом живут годами долго и счастливо без изменений. Так не бывает. В конкретном примере может быть так, что при первичном внедрении понятие "персональный менеджер" просто отсутствовало в бизнесе. А потом появилось. Реальный живой бизнес динамичен, он меняется и подстраивается под рынок, клиента, владельцев. IT-системы должны быть не препятствием в этом, а помощником.
А что, если содержимое карточки описывается подчинённой таблицей, где каждая строка соответствует отдельному полю карточки?
А если нет? И одной подчиненной таблицей вы не обойдетесь, т.к. поля могут быть разного типа данных (в том числе ссылочные, следовательно надо обеспечить ссылочную целостность). Можно конечно сделать "широкую" таблицу со всевозможными типами. Или хранить всё в строках, или в JSONах. Но с такими подходами рано или поздно вас ждет инженерный ад - посмотрите на Битрикс (недавно была статья), там как раз так сделано.
> Расширить API бэкенда
Интересно, что Вы имеете здесь в виду?
Фронтенд (веб-морда) как-то общается с бэк-эндом (сервером), верно? Это называется API. Чтобы фронт получил/записал данные нового поля, в API оно должно появиться, верно?
Неужели трудно в подавляющих случаях строить интерфейс на лету.
Хорошо бы. Но в команде есть UI/UX специалист, который думает иначе, и проектирует интерфейсы исходя из удобства пользвателя а не удобства программиста.
А какие тест-кейсы Вы здесь ожидаете?
Банальный CRUD с новым полем и валидацию, хотя бы.
Есть такой давнишний архитектурный концепт как Аспектно-ориентированное программирование, но в реальных проектах я за 20 лет его почти не встречал. В своих личных небольших проектах частично использовал - отличная концепция, особенно для бизнес-приложений и информационных систем, где сущности плодятся и разрастаются со страшной скоростью
А мировой ВВП – 111 триллионов. Что эти числа нам должны дать?
Ну, если вы считаете что десятки ярдов, которые заплатили клиенты только одному SAPу за ПО во 2024 году - "узкий и малоплатёжеспособный рынок" - я не знаю что вам еще ответить
Рынок конечных потребителей программ самих по себе очень узок и малоплатёжеспособен.
Вы шутите или серьезно? Бизнес во всем мире сотни миллиардов долларов тратит на программное обеспечение. А может и триллионы уже.
По очевидным причинам, никакая программа никогда не приблизится по стоимости к авианосцу.
А сколько авианосцев в мире, действующих? Десятка два? А сколько новых в год строится? 0.5-1? Даже при сумасшедшей цене в десяток-полтора миллиардов долларов это относительно небольшой рынок.
У SAP например выручка за 2024 год - 33 млрд евро. Выручка 1С, работающего почти только на небольшом российском рынке - почти три ярда долларов. А есть IT-компании куда богаче и крупнее SAP и 1C, как вы знаете.
однако желателен ещё какой-то объективный критерий для сравнения своих успехов с достижениями, известными в обществе
Вы все-таки про публичное признание говорите. Объективность этого критерия вызывает вопросики (лично у меня). Но если человеку это важно - то конечно вы правы.
Лично мне как-то никогда это не было нужно. Для меня объективный критерий - довольный моей работой заказчик, который приходит ко мне снова и снова. ну и собственное удовлетворение от работы (но это уже субъективное). В сороковник - тем более ))
Сейчас в российских школах частенько можно питон встретить. Но это же временная история. В мои школьные годы это был паскаль. Через лет 10-20 ХЗ что будет.
Смотря какой смысл вы вкладываете в понятие "делать карьеру"
Должность, влияние, деньги
профессионального роста (который объективно измеряется: патентами, научными публикациями, вкладом в известные проекты, выступлениями на профессиональных конференциях и т.д.)
На мой взгляд, профессиональный рост заключается в способности с каждым годом решать все более сложные и/или масштабные задачи, и/или делать это быстрее и качественнее с каждым годом.
А публикации и конференции - это про славу и признание. У меня был научный руководитель, профессор с кафедры. Я и еще ряд студентов и аспирантов ему писали статьи. Поболтать и попиариться мастер был, но в реальной науке давным давно ничерта не соображал уже и даже не пытался. За то "автор" методичек, статей и спикер конференций.
Хотя металлургический комбинат сам по себе – не бог весть какой хайтек, но я, например, всегда с интересом читаю на хабре статьи про его автоматизацию (спасибо авторам), да и не только я, судя по рейтингу.
Если цель - признание читающей аудитории, то можно и в металлургию разрабом АСУТП.
Я как раз пишу о том, что IT, как самостоятельная отрасль – это в общем-то нишевая и часто не самая сложная сфера работы для программиста.
Имеете в виду компании, которые зарабатывают именно разработкой программного обеспечения (на заказ, тиражируемого, сервисов - не важно)?
За несколькими хорошо известными исключениями, основная масса кода пишется в компаниях, занимающихся тем или иным железом
Не могу с этим согласиться.
то есть продуктами, ценными для конечного заказчика или потребителя
А программы сами по себе разве не используются конечным потребителем? И в бизнесе и физиками? Вы нам случайно не из 70х годов пишите?
В общем-то, нормальным карьерным ростом для программиста скорее является выбраться из IT в большое производство, чем наоборот.
Неожиданные вы вещи пишите, ей-богу. Программист в не-IT компании почти всегда зарабатывает меньше и медленнее делает карьеру. Например, какой-нибудь разработчик внутреннего сервиса для металлургического предприятия - да там можно жизнь провести на одном стуле за одними и теми же задачами на одном и том же стеке. Опять же, поищите статьи про вечную боль разработчиков АСУТП, которые как раз таки работают в "большом производстве"
Это правда, сам писал много лет на С++. Это ожидание полной пересборки - ужасно. Но здесь скорее проблема конкретного компилируемого языка (С++) а не компилятора.
Вряд ли кому придёт в голову идея, например, писать компилятор на Питоне
Кстати, а почему нет? Для компилятора экстремальная производительность уровня С++ не важна, а возможность выразительно и посто описать сложную логику - важна, и с этим Python отлично справляется.
С бейсиком как раз все просто - когда он был популярен, он был самым простым, стал массовым. Для компов 70-80 он стал стандартом прикладного языка, обязательным условием входа на рынок. По этим причинам его выбрали в Майкрософт и интегрировали в свою экосистему, что сильно добавило популярности.
Потом оказалось, что для все более усложняющихся задач разработки он совсем не годится, и популярность сошла на нет.
C# и особенно Java намного сложнее Питона для первоначального изучения.
Категорически с этим не согласен, писал код на всех трёх. Java и C# - сами по себе очень простые языки, особенно для первоначального изучения. А вы не путаете изучение популярных библиотек с изучением языка?
Не совсем так. Вряд ли кому придёт в голову идея, например, писать компилятор на Питоне (хотя исключения всегда возможны). И в основном в сложных задачах Питон используется как клей к библиотекам или исполняемым модулям, которые сами пишутся на других языках.
Python активно используется например в ML и нейронках, а это сложные задачи.
Но более важно даже не это, а то, что сам сайт hh редко используется для поиска исполнителей сложных работ. Вакансии профессоров или главных конструкторов вы там вряд ли найдёте.
Профессоров ищут институты и университеты, у них просто нет бюджета на конские цены HH для работодателей. Главные конструктора - мимо, это не про IT. За то разного рода IT-архитекторов, синьоров, СТО ищут именно через НН.
Раз уж подняли эту тему, а никого никогда не смущает, что в более-менее традиционной слоистой архитектуре приложений, любое изменение структуры данных требует изменений почти на всех слоях?
Пример: допустим, есть какая-нибудь CRM. Бизнес захотел, чтобы в карточке клиента появился аттрибут "персональный менеджер". Для этого нам нужно: 1. Добавить поле в БД, написать миграцию для этого. 2. Добавить работу с этим полем в 3 SQL-запроса (insert, update, select) или в аналогичные выражения ORM 3. Добавить атрибут в объект данных (entity), возможно не в один 4. В зависимости от архитектуры, изменить интерфейсы и добавить новую логику в несколько слоев бэкенда: репозиторий, сервис, контроллер, допилить валидацию 5. Расширить API бэкенда 6. Дополнить еще пару слоёв во Фронтенде 7. И только теперь добавить в UI новый элемент. 8. Дописать тесты
А ведь бизнес с такими простыми запросами приходит каждую неделю.
Есть дешевый VPS-сервачок с кодом на пэхапэ в пару страниц и базой MySQL, который прожевывает примерно вдвое бОльшую нагрузку уже четвертый год. Написан и отлажен за пару вечеров
KISS
Не многовато ли? Почему именно 1000? Меня лично начинают напрягать модули больше 200 строк.
Вы так говорите, как будто системы проектируют один раз на берегу, и они потом живут годами долго и счастливо без изменений. Так не бывает. В конкретном примере может быть так, что при первичном внедрении понятие "персональный менеджер" просто отсутствовало в бизнесе. А потом появилось. Реальный живой бизнес динамичен, он меняется и подстраивается под рынок, клиента, владельцев. IT-системы должны быть не препятствием в этом, а помощником.
А если нет? И одной подчиненной таблицей вы не обойдетесь, т.к. поля могут быть разного типа данных (в том числе ссылочные, следовательно надо обеспечить ссылочную целостность). Можно конечно сделать "широкую" таблицу со всевозможными типами. Или хранить всё в строках, или в JSONах. Но с такими подходами рано или поздно вас ждет инженерный ад - посмотрите на Битрикс (недавно была статья), там как раз так сделано.
Фронтенд (веб-морда) как-то общается с бэк-эндом (сервером), верно? Это называется API. Чтобы фронт получил/записал данные нового поля, в API оно должно появиться, верно?
Хорошо бы. Но в команде есть UI/UX специалист, который думает иначе, и проектирует интерфейсы исходя из удобства пользвателя а не удобства программиста.
Банальный CRU
Dс новым полем и валидацию, хотя бы.Есть такой давнишний архитектурный концепт как Аспектно-ориентированное программирование, но в реальных проектах я за 20 лет его почти не встречал. В своих личных небольших проектах частично использовал - отличная концепция, особенно для бизнес-приложений и информационных систем, где сущности плодятся и разрастаются со страшной скоростью
Ну, если вы считаете что десятки ярдов, которые заплатили клиенты только одному SAPу за ПО во 2024 году - "узкий и малоплатёжеспособный рынок" - я не знаю что вам еще ответить
Вы шутите или серьезно? Бизнес во всем мире сотни миллиардов долларов тратит на программное обеспечение. А может и триллионы уже.
А сколько авианосцев в мире, действующих? Десятка два? А сколько новых в год строится? 0.5-1? Даже при сумасшедшей цене в десяток-полтора миллиардов долларов это относительно небольшой рынок.
У SAP например выручка за 2024 год - 33 млрд евро. Выручка 1С, работающего почти только на небольшом российском рынке - почти три ярда долларов. А есть IT-компании куда богаче и крупнее SAP и 1C, как вы знаете.
Вы так говорите, как будто это что-то плохое :)
Вы все-таки про публичное признание говорите. Объективность этого критерия вызывает вопросики (лично у меня). Но если человеку это важно - то конечно вы правы.
Лично мне как-то никогда это не было нужно. Для меня объективный критерий - довольный моей работой заказчик, который приходит ко мне снова и снова. ну и собственное удовлетворение от работы (но это уже субъективное). В сороковник - тем более ))
Сейчас в российских школах частенько можно питон встретить. Но это же временная история. В мои школьные годы это был паскаль. Через лет 10-20 ХЗ что будет.
Должность, влияние, деньги
На мой взгляд, профессиональный рост заключается в способности с каждым годом решать все более сложные и/или масштабные задачи, и/или делать это быстрее и качественнее с каждым годом.
А публикации и конференции - это про славу и признание. У меня был научный руководитель, профессор с кафедры. Я и еще ряд студентов и аспирантов ему писали статьи. Поболтать и попиариться мастер был, но в реальной науке давным давно ничерта не соображал уже и даже не пытался. За то "автор" методичек, статей и спикер конференций.
Если цель - признание читающей аудитории, то можно и в металлургию разрабом АСУТП.
Сугубо десктопные CRM - это какая доля рынка? 1% хотя бы есть?
А как вы представляете архитектуру CRM для хотя бы двух пользователей? А для 1000, в разных городах, странах, языках и часовых поясах?
Имеете в виду компании, которые зарабатывают именно разработкой программного обеспечения (на заказ, тиражируемого, сервисов - не важно)?
Не могу с этим согласиться.
А программы сами по себе разве не используются конечным потребителем? И в бизнесе и физиками? Вы нам случайно не из 70х годов пишите?
Неожиданные вы вещи пишите, ей-богу. Программист в не-IT компании почти всегда зарабатывает меньше и медленнее делает карьеру. Например, какой-нибудь разработчик внутреннего сервиса для металлургического предприятия - да там можно жизнь провести на одном стуле за одними и теми же задачами на одном и том же стеке. Опять же, поищите статьи про вечную боль разработчиков АСУТП, которые как раз таки работают в "большом производстве"
Это правда, сам писал много лет на С++. Это ожидание полной пересборки - ужасно. Но здесь скорее проблема конкретного компилируемого языка (С++) а не компилятора.
Кстати, а почему нет? Для компилятора экстремальная производительность уровня С++ не важна, а возможность выразительно и посто описать сложную логику - важна, и с этим Python отлично справляется.
.
С бейсиком как раз все просто - когда он был популярен, он был самым простым, стал массовым. Для компов 70-80 он стал стандартом прикладного языка, обязательным условием входа на рынок. По этим причинам его выбрали в Майкрософт и интегрировали в свою экосистему, что сильно добавило популярности.
Потом оказалось, что для все более усложняющихся задач разработки он совсем не годится, и популярность сошла на нет.
Категорически с этим не согласен, писал код на всех трёх. Java и C# - сами по себе очень простые языки, особенно для первоначального изучения. А вы не путаете изучение популярных библиотек с изучением языка?
Python активно используется например в ML и нейронках, а это сложные задачи.
Профессоров ищут институты и университеты, у них просто нет бюджета на конские цены HH для работодателей. Главные конструктора - мимо, это не про IT. За то разного рода IT-архитекторов, синьоров, СТО ищут именно через НН.
Раз уж подняли эту тему, а никого никогда не смущает, что в более-менее традиционной слоистой архитектуре приложений, любое изменение структуры данных требует изменений почти на всех слоях?
Пример: допустим, есть какая-нибудь CRM. Бизнес захотел, чтобы в карточке клиента появился аттрибут "персональный менеджер". Для этого нам нужно:
1. Добавить поле в БД, написать миграцию для этого.
2. Добавить работу с этим полем в 3 SQL-запроса (insert, update, select) или в аналогичные выражения ORM
3. Добавить атрибут в объект данных (entity), возможно не в один
4. В зависимости от архитектуры, изменить интерфейсы и добавить новую логику в несколько слоев бэкенда: репозиторий, сервис, контроллер, допилить валидацию
5. Расширить API бэкенда
6. Дополнить еще пару слоёв во Фронтенде
7. И только теперь добавить в UI новый элемент.
8. Дописать тесты
А ведь бизнес с такими простыми запросами приходит каждую неделю.
Есть дешевый VPS-сервачок с кодом на пэхапэ в пару страниц и базой MySQL, который прожевывает примерно вдвое бОльшую нагрузку уже четвертый год. Написан и отлажен за пару вечеров
Но есть много других простых языков - JavaScript, Java, C#, PHP. Почему именно с Python такая ситуация?
И простой язык не означает простых задач.