Pull to refresh
12
0
Анатолий Юдов @misato

Пользователь

Send message

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

Однако, Битрикс как CMS для веб-сайта ужасен и с точки зрения продукта!

Изначальный смысл любой CMS - это разделить функции разработчиков и пользователей которые управляют контентом. Разработчики добавили фичи, натянули дизайн, выдали логины/пароли и отдали в эксплуатацию, осталось только посматривать в логи и мониторы, реагировать на технические сбои или атаки.

По факту Битрикс настолько замороченный и сложный в плане интерфейса админки, что сложности с ним испытывают абсолютно все. В качестве контрпримера могу привести другой печально известный своей допотопностью движок WordPress - да, это тоже дырявое PHP, но когда там ставишь там новый модуль или плагин, у него появляется удобная закладочка для управления данными, которую не надо полчаса искать, просматривая все разделы и блоки меню.

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

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

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

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

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

Чтобы программировать на PHP не обязательно знать, как переводятся слова while, switch, yield, надо просто знать, как они работают.

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

Язык ключевых слов и команд в ЯП не имеет никакого значения.

Непонятно, как вы перешли от тезиса

новую технологию, снижающие издержки, таким образом, что может снизить цену деталей

к тезису

Таким образом, делая за 8 часов те же N деталей, рабочий получает уже 80 рублей в день

В этом же нет никакой логики.

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

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

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

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

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

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

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

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

Если просто внимательно посмотреть на программу, то на первых трёх курсах у инженеров как раз всякие общие знания, а на последних двух - уже специальные, типа (что-нибудь типа "тепловые процессы в энергетике").

Потому бакалаврам и квалификацию дают другую, более обобщённую, чтобы обозначить, что никакой он не специалист, а просто человек, получивший некоторые основы в нужном направлении. Если специалист может быть "инженер-программист", то бакалавр будет "бакалавр техники" или типа того.

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

У вас много рассуждений про качество, которое противопоставляется назначению товара или услуги.

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

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

Тут как раз мы подходим и ко второму спорному тезису: "Очевидно, что свойство 'качество' продукта создаётся научно-инженерным корпусом специалистов". Как раз-таки работа по поиску баланса между ожиданиями, требованиями и потребностями - это очень важная часть труда в рыночной экономике, которую сложнее было реализовать в плановой. И это не задача научно-инженерных специалистов, для этого есть более экономические и гуманитарные науки. Есть ещё задачи управленческие, но к ним относились ответственнее, потому что они как раз ближе к инженерным, однако они тоже прозябали на вторых ролях, по причинам связанным с природой планового хозяйства.

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

Вообще, если углубиться в тему того, что такое качество, то можно зайти очень далеко. Например, что качество - это некая категория, описывающая взаимодействие объекта и субъекта, и что она гораздо шире, чем инженерно-технические аспекты какого-то продукта. Очень рекомендую роман "Дзен и искусство ухода за мотоциклом" Роберта Пирсига, который не то триллер, не то философский трактат - очень глубоко заходит в эту тему, в том числе с чисто практической стороны.

Это ещё далеко не факт, что объект должен инкапсулировать в себе взаимодействие с базой данных.

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

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

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

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

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

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

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

Пятьдесят лет назад работа программиста заключалась в том, чтобы реализовать конкретную задачу для конкретной железки. Железка чаще всего была специализированной, её функциональность, технические возможности и сценарии использования были подробно спроектированы и задокументированы ещё до того, как программисты узнавали о работе, поэтому все работали по ТЗ в понятном цикле "анализ-проектирование-код-тестирование-эксплуатация" и всё было хорошо.

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

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

За это приходится платить бОльшей конечной стоимостью продукта, и отказом от некоторых гарантий: сроков или функциональности. Это особенно важно понимать потому, что в первую очередь эту цену должны заплатить не разработчики, а руководство организации. Именно в там в первую очередь нужно внедрять agile, ещё до того, как на созвон подключится скрам-мастер и начнёт назначать еженедельные груминги.

Если руководство не готово постоянно участвовать в поиске баланса между стоимостью/сроками и функциональностью продукта, а хочет по привычке требовать "дату завершения проекта" и дрючить за опоздание - никакого agile здесь никогда не получится.

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

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

В общем, масса полезных преимуществ в таком подходе.

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

Перечитайте еще раз книжки про проектирование распределенных систем

Кто-нибудь, посоветуйте, пожалуйста, хорошую книжку на эту тему. Можно на английском.

Я тоже думаю, что в долгосрочной перспективе Черноруссию это не приведёт к успеху. В отсутствии глобальных перспектив, айтишники в закрытых НИИ будут больше думать о самодеятельности, турпоходах на Алтай и прочих отвлечённых занятиях.

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

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

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

Более того, в условиях кризисной экономики, если уж дойдет дело до прямых запретов, то "высокая средняя зарплата" вообще может трансформироваться в некий "улучшенный набор благ". Иными словами, айтишникам построят условно-закрытые города или районы с закрытыми условно-коммерческими НИИ, с улучшенным продовольственным снабжением, с некоторой допустимой вольницей, но и повышенным вниманием со стороны ответственных товарищей. Перспектива для кого-то ужасающая, а для кого-то, возможно, и вполне приемлемая - у всех людей, даже у IT-шников, разные взгляды на мир, ценности и отношение к жизни.

Information

Rating
Does not participate
Location
Зеленоград, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Scrum Master
Lead
From 5,000 €
PHP
OOP
Git
Agile
Business process management
Project management
JavaScript
MySQL
Web development