Старикам здесь не место? Программируем после тридцати пяти

ну если мы говорим об отчетной системе типа QlikView то тогда наверное да

но вот это

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

Абсолютли, Code Smelling.

Лет восемь назад учился со мной чувак в институте на вечерних курсах на второе образование. АйТи (2 года, по вечерам). Он закончил мореходку, но с морем не сложилось. Работал на фабрике по производству мебели. Так вот. После окончания 2-х летнего обучения его СРАЗУ забрали в программерскую контору. А я продолжил админить. Он щаз бабки закалачивает, а я за своими сотрудниками косяки чиню и под столами с проводами лазаю. Так шо если есть ум, упертость и цель- всего можно достичь.

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

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

на одной из предыдущих работ был коллега, он всегда хотел заработать побольше. ну есть такая категория людей. в общем-то, похвально.
как и я - программист с#.
так вот он однажды увидел предложение по работе, но на python с космической ЗП с ротацией в США. он так сокрушался, что кодит на c# и решил изучать питон. поднатарел в нем, молодец.
спустя год видит другое предложение, но на java с еще более космической ЗП и тоже с ротацией в США)) и снова начал сокрушаться, что занимался не тем языком программирования))

в итоге оказался в Москве в одном из банков с хорошей ЗП и должностью и пишет на c#)))

Я что-то не понял тут с возрастом?

C# он разрабатывал с 2000-го, когда ему было уже как раз под сорок. А в 2012-м (в 62 года) Хейлсберг начал создавать TypeScript

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

Сдается мне тут несколько статья неправильно описывает все "опасения".
Кодить с 16 лет и продолжить заниматься этим же в 35-50 дапочемубыинет
А вот начать с ноля в 35 уже тяжело.
Вот это вот основная "боязнь" идти в профессию в "пожилом" для нее возрасте.

Размещено через приложение ЯПлакалъ

Дело не в этом и не в возрасте. Когда ты уже уровня Senior или Principal, ты просто уже знаешь какой паттерн или алгоритм применить и используешь их вместо "изящного" велосипеда.

Это сообщение отредактировал Mamboking - 14.06.2019 - 15:13

Нет, я вот о чем, на примере. Так как речь выше вел про торговую сеть, то на их доках:
Надо сделать возврат товара поставщику. Юзер набивает в простейшем интерфейсе список позиций, сохраняет кнопочкой, дергает процедуру:
Процедура сохраняет документ в таблицах, проверяет корректность данных (контрагенты площадки отгрузки, статусы точек актуальности, доступные остатки, статусы номенклатуры -все это в БД, оно рядом), сохраняет черновик. Проверяет контрагентов получателя (и возможно транспортную контору) - все атрибуты типа статусов, действующих договоров, коэффициентов наценок, адресов доставки и прочего. Проверяются исходные поставки, возможно получаются их них данные по первичке (например в ЕГАИС это исходные партии бухла). Создает расходные документы на возврат со всеми реквизитами. Отдает управление юзеру и тот печатает накладные, ставит печать. Скуль может отправить отчет по почте (вообще без проблем, поставщики любят такие уведомления). Может дернуть веб-сервис внешней системы и он переподтянет/отдаст данные о возврате (например провайдеру EDI). Сформирует xml (а там пииииздец сколько атрибутов) и скинет в ЕГАИС если это бухло. На любом этапе отработает транзакция в пределах своего блока. В огромных таблицах все будет быстро, никуда не надо выгружать данные чтобы все проверить. В фунциях CLR (внутри шарп) я могу проверять веб-сервисы внешних систем одним селектом, и в случае каких-то условий откатить все обратно - всегда консистентные данные.
А у юзера это одна кнопочка и вызов хранимки. Можно такую кнопочку хоть в WinForms сделать, хоть в MVC, хоть в вебе - пофигу где.

Вот эта описываемая логика - это бизнес-логика?

Это сообщение отредактировал 28e - 14.06.2019 - 15:16

28e

Я ушел из программирования, да и из IT, во многом из-за этого. 38 лет - работа в небольших компаниях, разработка с нуля, бэкенд, фронтенд, всякое железо, аналитика - перл, пхп, бд, циско/микротик. В итоге, знаю и могу много, но нигде не досконально. Искал работу, в основном задания - реально не сложный проект, которые я делал в обычном функциональном стиле, но нет, надо фреймворк, писать только по феншую, проект работает? Да. Написан правильно - нет. Вот и все.В почти 40 идти в юниоры?

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

Подпишусь под каждым словом.

На счет SQL есть LINQ in EntityFramework ... в этом говне на нормальный запрос в 2-3 раза больше времени уходит...

SantaJohn

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

Изучите историю SQL. Это была изначальная цель сиквела - язык для бухгалторов и от туда бизнеслогика! Времена бизнес логики в базах данных прошли. Причем тут расход памяти?! У вас что микроконтроллеры?! Какие к черту расходы на ифы ? Что запрос + логика+ подзапрос присланный с БЛ уровня в базу что запрос с БЛ->через хранимку->запрос+логика+подзапрос.
Это вообще не о том!
Изучите вопрос проблем хранения логики в базе данных. Все минусы.

Вот кстати вы - типичный пример того, кому сложно после 40 найти работу. Вы где-то что-то там научились без "школы" кодить, у коллег подсмотрели, которые тоже делали неправильно, книг не читая и варились в этом своём котле годами среди таких же писателей. А потом посмотреть на проблему шире, под другим углом, принять, что был столько лет не прав уже гордость и лень не позволяют. Тут и любые оправдания можно придумать, отметая всё то, что неудобно.
Как у жены на работе старая бухгалтерша сокрушалась и удивлялась, что она не могла 15 лет неправильно рассчитывать командировочные. Могла

Это сообщение отредактировал artivenom - 14.06.2019 - 15:22

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

Это сообщение отредактировал Mamboking - 14.06.2019 - 15:25

У меня сын заканчивал 12 лет назад ХПИ по специальности, связанной с IT. Но занимался совсем другим. Когда все стало валиться, походил на 2-3 курса по программированию, тоже Харьков. Теперь у же 2 года работает программистом и чистыми имеет 2000 долл, ему 37. Доволен как слон, сейчас осваивается тимлидом, говорит, добавилось лишней работы, но системно стал мыслить шире.
Так что все возможно, удачи

Попахивает? Это первый в списке на увольнение.

Никуда эти времена не ушли, где речь идет о больших данных.

Как бы вы реализовали такое: поставщик присылает xml на 2кк строк, вам нужно на его основе и пары таблиц с 30кк строками сформировать тысячу документов в базе, с проверкой по всяческим атрибутам. Я это сделаю все на sql вызовом одной процедуры, куда передам xml.
Поддерживать (править) эту процедуру сможет любой сервис-мен, для ее правки не нужны студии и хватит знаний синтаксиса скуля, не нужны никакие особые компиляции и публикации. Минимальное время на выкат/фикс на продакшне.

Ну или наоборот, как пример чуваках у которого храмнимка делает больше, чем должны были бы 2 микросервиса

Иногда требуется написать утилиту в 400 строк кода - и в таких случаях наворачивать паттерны на врапперы через COM-объекты будет не самым лучшим решением. Я вообще ратую за адекватную оценку задачи и применение сообразной случаю методологии - ибо видел, когда люди пытались почерпнутое из GOF впихивать по делу и без оного и выходило только хуже.

Это сообщение отредактировал Voronezher - 14.06.2019 - 15:37

А я это сделаю микросервисами, параллельно с помощью 3-4 реплик базы на чтение.

2000 000 срок у меня прочитает в 4 потока сервис или даже 4 сервиса, потом параллельно прочитаю все нужные данные (30кк которые) из 3-4 реплик базы на чтение. Чего вы (3-4 реплики) не сделаете из-за своих хранимок никогда. И потом спокойненько всё это сохраню через очередь без потери данных в одну базу, которая потом ещё это размножит по остальным репликам.

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


А ваше решение умрёт после того, как строк станет не 2 а 5 миллионов. И нужно будет вместо просто 2ого сервера за 1000$ бежать и покупать ультродорогой и проивзодительный сервак (скалировать вертикально) за охулиард. Но это не надолго. В случае хабраэффекта (или как его там), такого небольшого ддос на базу, всё просто ляжет в вашем случае. Рано или поздно.
Но не это самое страшное. А то, что вы не можете гарантировать, что это говно работает! Потому что он не протестировано на 10-20 тесткейсах каждый раз после очередного фикса.

Это сообщение отредактировал artivenom - 14.06.2019 - 15:45

Вот отличный пример современных говнокодеров:

Вместо одной процедуры они бы использовали два микросервиса.

Микросервис, полагаю, это http-сервер, который работает через http-запросы. А значит мы имеем веселуху с повышенным трафиком в mime/urlencode/итп, это отдельные сервера/службы (за которыми надо следить), это отдельные сетевые коннекты, это дополнительные обработки ошибки не уровня бизнес-логики ("сетевое имя больше не доступно" и прочие системные ошибки с доступом к веб-сервису и его доступом к данным). В клиенте не примитивный вызов процедуры на скуле, а обвязка с вебметодами, которые обернуты в объекты, и не дай бог микросервисы изменят адрес в сети (раньше был скуль, теперь + веб-сервер).
А самое главное - еботня с единой транзакционностью одной операции - создание документаю. зато блять два микросервиса! Которые надо написать, опубликовать, когда что нибудь свалится надо дебажить их и гонять данные между базой и клиентом (которыми являются эти микросервисы по отношению к скулю).

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

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

1. шаблон на то и шаблон, что это типовое решение для типовой задачи. Если задача типовая то для неё есть типовое самое быстрое решение. Не бывает типовых задач на которые шаблоны - какой-то пиздец.

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

Вы же не думаете что мы можем позволить себе создать половину документов если вдруг на части товаров запрещающие флаги?
Разумеется речь идет о транзакции - переписывать все нахуй!