плюсанул бы да кармы нет. Микросервисный и cloud-based подход лепят везде и всюду усложняя инфраструктуру и добавляя себе гемора. Вместо обычного подхода, накидали сервисы с разумной детализацией, закинули на сервак(виртуалку), подняли несколько инстансов в разных ДЦ и погнали. Но нет же для простых сервисов, возьмут куберы, контейнеры, прокси, балансеры, облачные базы, и вроде все должно работать но все равно летят ошибки из-за инфраструктуры, в 70% проектов вообще нафиг не нужен этот cloud-based подход. Да и потом для масштабирования в реальном времени из-за нагрузки, такого куска можно применить cloud-based подход. Более того есть бизнес процессы, которые в принципе масштабируются сложнее из-за длинных цепочек и мест синхронизаций
Тут еще следует упомнуть про бонусы и опционы (это даже не акции) и что эта ЗП до налогов.
У меня все равно есть разрыв шаблона, спрашивают литкод, который в жизни применяют разве что датабазники какие-нить, писатели поисковых движков и прочего, может еще системщиков где-то цепляет. Но условно не решил литкод хард - тебя не берут, но почему никто не оценивает реальный опыт и умение решать реальные проблемы просто - ведь именно за это компания получает деньги - за умение решать проблемы, а не задачи, как технические, так и организационные.
Но есть ощущение, что фанги переоценены и это рынок работодателя.
Вера это вообще не научно. Есть практики воспоминания прошлого опыта и такое проверяется очень легко, например если зарыл клад и можешь вспомнить это место, то надо прийти и проверить. Или например есть какие-то особенности, которые известны только тебе и которые можно проверить только сейчас. Если проверка не срабатывает вполне может быть фантазия.
Со своей стороны у меня есть такие доказательства того, что я работал в определенной области и мои навыки в это области есть, при этом в текущей жизни я этим не занимался от слова вообще. Есть другие косвенные подтверждения у других людей. Но полностью прошлая память так или иначе "зашита" в текущем воплощении, видимо для того, чтобы нарабатывать новый опыт, ну и воспоминания о смерти, болезни и прочих мучениях могут быть совсем неражужными и будут только мешать нарабатывать опыт.
Мне регулярно сыпят минусы в карму и на харб я хожу только из-за того, что доступны ленты сообщений. Но раз сыпят, то люди не хотят воспринимать мою инфу - на то их полное право.
Человек и так бессмертен, правда относительно. Физическое тело - инструмент накопления опыта. С каждой новой жизнью человек нарабатывает новый опыт и то, что дается человеку легко, просто говорит о том, что у него в этой области отлично наработанный опыт. И если человек 5 жизней был связан с музыкой, много ли ему надо чтобы начать играть? Нет. Тот кто никогда не занимался музыкой либо очень давно, то ему этот опыт будет даваться очень тяжело.
Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые: создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 2 года он работал, за ЗП ключевого в роли создателя. Такой же подход можно использовать и для рядового.
Итоговая стратегия строится так, что обещания+текущая позиция дешевле, чем инфляция на рынке. Чтобы нанять кого-то со стороны, необходимо докинуть денег для того, чтобы человек поменял место.
При этом, работая на одном месте бОльшая часть времени у большинства уходит на рутину, которая удешевляет вашу цену рынке и то, что востребовано у вас в компании, может быть совсем не востребовано где-то еще.
Регулируя разные параметры модели можно получить разные результаты. Есть примеры когда люди сидят по 15 лет на одном месте, со средней ЗП и лайтовыми условиями труда, есть те кто скачут пробуют, но при этом из-за нервов и времен страдает личная жизнь. Кому какую стратегию выбирать: выбор каждого и там и там есть плюсы и минусы. Но чтобы получить максимальную цену, надо досканально знать рынок.
Ретро, спринты, скрамы. Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому. Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт. Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей? Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя. Я не хочу читать, что это работает, я хочу запустить и проверить что это работает. Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует. Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать. Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
может вопрос дилетантский, но почему нельзя написать какой-нить фронтент для LVVM или написать какой-нить диалект для С++ или Java, как например это сделал JetBrains с котлином. Котлин ООП язык с примесью функциональности, по сути фронтенд для Java, Native и т.д. При этом если писать для JRE, то можно использовать все либы для java, на что-то там есть мапинги, на что-то нет. Почему не взять какую-то стандартную платформу и заиспользовать всю ее мощность и комьюнити, при этом перкомпилить все конфигурации, ну или компилить конфигурации во время сборки? добавить какие-то тулы для фомроклепа, но поверх стандартных либ. С учетом кроссс платформенности перевести на англ язык и захватить например какие-то азиатские рынки, хотя там свое написано уже, но тем не менее это бы значительно расширило долю рынка.
Спецы по 1С можете прокоментировать? я код 1С выидел пару раз, и очень примерно представляю как этоработает.
А я в какой-то степени понимаю боль собеседущего. Если у тебя в резюме указано что ты знаешь A и B, но не можешь сказать каких-то ключевых характеристик, то этоточно говорит о том, что человек их не знает. одно дело спрашивать какой хедер надо указать чтобы передать xml. но если указан SOAP и REST, то он как минимум должен это знать, если гражданин знает матан (я его например не знаю, ну т.е. пределы, интегралы и прочее это понятно), то базовые вещи, пределы и теоремы он знать должен иначе это вранье, либо рассказать в каком объеме знает. Автор абсолютно правильно спрашивает про рассуждение, потому что все IT это постоянное принятие решений и для чего тебе м***ак решение которого надо контролировать постоянно? Который мог просто банально понатаскаться на типичные вопросы, а думать не умеет. То же самое и с программированием, типовые задачи, типовые вопрсоы, а на выходе г-но. Потому что проблемы это всегда задачи с каким-то тонкостями и надо правильно выработать или выбрать решение.
С точки зрения юзера 2000 и WinXp были отличными системами. Добавив туда мультирабочий стол из коробки, каких-то плюшек из 7ки была бы отличная ОС. при установке 1.5-2 Гб на диске, как уже написали никуда не лезет в инет и в целом все доступно и кастомизируемо (привет реестр). Все системы после XP это какой-то разброд и шатание в поисках чего-то нового, при этом похоронив все старое. Если в XP я спокойно работал в проводнике на клавитуре и вообще мог сделать все на клавиатуре, элементов фокуса было меньше, то сейчас такая работа вообще не реальна. Перепиливание UI каждый раз приводит к тому, что мне вообоще все равно какой он, я его перестал настраивать от слова совсем. Если бы мне винда не требовалась для работы, у меня бы остался только линукс.
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи Заголовок: сделать восстановление пароля Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>. Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину. Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
P.S. и еще бросилось в глаза: "Устные договоренности ничего не значат!" - брехня. Может звучит грубо, но:"за базар надо отвечать", потому что люди за него помнят и могут спросить. И прежде всего этой аксиоме должен следовать руководитель - его слово куда весомее его подчиненных
Если прочитать про водопад http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf "Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps" (К сожалению, для приведенного процесса итерации разработки никогда не ограничиваются последовательными шагами) об итеративности уже тогда говорили. И вообще в документике "сквозит" аджайлом, и много где написано, что не делайте больше, чем надо. При этом надо еще понимать что бумажка 1970г создана на основе разработки до этого 1970г.
Все что ниже гугли по быстренькому: примеры компов второй половины 60х годов https://en.wikipedia.org/wiki/SDS_9_Series https://en.wikipedia.org/wiki/Honeywell_316 При этом надо понимать что никаких intellisense, CI, testing framworks , дебагеров и прочего не было, по этому к процессу разработки готовились куда тщательнее, что вполне разумно.
Еще кстати Agile/Scrum апологеты очень любят про избыточную документацию, при этом если посмотреть на любой SDK, то чем лучшге он документирован, чем больше примеров, тем проще писать код. Решил копнуть про языки https://en.wikipedia.org/wiki/History_of_programming_languages скорее всего писали на FORTAN'е и вот вам дают кусок какого-то когда, и хрен пойми чего он делает, при том, что там либо что-нить математическое либо machine level. Как в таком разобраться без доков, а если еще и модуль такой дадут, так он к тому же еще и ресурсы жрет и непонятно сколько.
Agile апологеты опять таки забывают про Rational Software и их RUP и UML, на мой взгляд наиболее полная формализация процесса разработки с единым языком UML, где на каждом этапе ключевую или специфичную инфу можно переложить в графические фигуры.
Весь этот Agile (XP, Scum, Kanban, Lean, LeSS) очень умело проданный продукт, для новичков, которые не знают истории разработки компов и софта. Конечно все эти подходы объединяют полезные практики, которые могут быть вполне полезны.
Причиной популярности agile и процессам послужил резкий рост производительности в конце 90х и начале нулевых и резкое удешевление персональных компьютеров, сюда же распространение винды и формоклепа от борланда позволило практически кому угодно начать программировать "с нуля", в отличии от ситуации до 90х, когда компы стояли либо на заводах, либо в НИИ, и никто там никакой Agile не купит.
Данный опросник для грейдов - дичь. Почему-то менеджмент вместо общения с людьми и оценки их полезности пытается наиболее критичный процесс заменить и автоматизировать. Какие цели ставились перед сотрудником, куда сотрудник хотел расти, как он вырос устраивает ли компанию и работника? Мнеджера, который придумал этот опросник возможно стоит переключить на административную работу или работу по поддержке. Разработка она не про задачи, а про продукт, ценные и реализованные идеи, а не про выполненные задачи. Банальная операционщина - удел администраторов.
Ни слова не написано про жильё, сколько стоит, какая ипотека, сколько стоят коммунальные услуги? Сейчас модно покидать РФ, при этом никто объективно не взвешивает плюсы и минусы.
1) Самое важное - свое жильё. Крыша над головой без ипотеки все таки позволяет пользоваться многими благами даже аггрессивной РФ. 2) Образование как вузовское, так и школьное. Сколько стоят и как организованы те же бассейны, спорт кружки и так далее, какой уровень педагогов? Мск конечно не Россия, но в Мск можно найти очень достойные как клубы так и педагоги, за весьма небольшие деньги (а ля фитнес клуб за бассейном, тренажерами, групповыми занятиями и саунами за 30-40к в год на человека). Куда ездят Шведы отдыхать на море в теплые края?
Сколько стоит купить участок, построить дом и подвести коммуникации к нему и какая удаленность от города?
Сколько стоит владеть машиной (понятно что она не всегда нужна), но условно если в РФ можно купить ведро(а ля какой-нить ВАЗ) + гараж, то это будет в районе 300-400к, налог можно не считать, все равно мало, но свою задачу это авто выполнит на все 100% и будет выполнять пока не сгниет(и этот процесс можно даже тормознуть, но потребуется время)
Много кто пишет о том, что они приобретают за рубежом и какой там толератное отношение к тридварасам и собачкам/кошечкам, но никто не пишет о том, что они теряют при отъезде.
Т.е. вот есть например квартира, дом, семья(родители, дети, братья, сестры), местами даже весьма неплохо климат. И тут вдруг бац это все плохо и релогация в счастливую швецию/финляндию и так далее. И либо едут совсем бедные, кто ничего особо не нажил, либо действительно богатые, которые ввалив денег могут вполне себе сохранить тот уровень жизни который был в РФ. А ехать в европу или куда-то там, снимать жилье и жить в 0, на старость так себе перспектива.
А что мешает взять грамматический фреймфорк, написать нужную себе грамматику и дальше на основе этой грамматики вызывать свое API? И написать можно все так, как хочется.
А что на счет тренировки бактерий в животных, которым колят антибиотики. Птица, свинина, говядина, молочка. Мне кажется проблема то совсем не в людях. Сколько за год съедает антибиотиков человек и животное и сколько мутаций у бактерий проявляет резистентность к антибиотикам? А потом эти бактерии попадают в человека и конечно же их антибиотики не берут и виноваты в этом люди, ну ну.
У меня вся родня с завода, плюс я также был в IT подразделении на другом заводе. То, что вы пишите с одной стороны правда, бюррократия и старый подход, который не пытается обойти конкуренцию, а наоборот ее подавить.
Но я бы хотел акцентировать внимание на другом. Если в софте можно откатить много чего и вернуть все назад в 95% случаев, то косяки на производстве стоят просто на порядки дороже. Завод это прежде всего материальное производство, необходимо управлять запасами. Косяки в производстве сложных деталей могут просто заруинить все изделие (например ракету) и откат там невозможен в принципе. Связи между цехами, людьми и этапами намного жесче, чем в IT и управление всем этим балаганом требует куда больших усилий, чем когда одна команда использует api сервис другой.
"2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели."
Вот это вот какая-то дичь, которая говорит о том, что менеджмент в компании дно, которые понятия не имеют о том, что такое обратная связь. Вендор vs in-house тема спорная и просто так брать и инвестить в in-house может быть опрометчиво, там критерии совсем другие, хотя в вашем случае надо было просто сменить работу с вендорами.
Я из тех кто не любит Scrum, хотя бы только за то, что все факторы производительности сводятся в burndown chart и velocity, как понять какие факторы повлияли на эти значения - непонятно. Бывает операционная и спонтанная активность, которая непредсказуема, мы ее просто логируем, хотя это уже как бы не scrum/
Вообще история создания Scrum мутная и не фундаментальная, тот же RUP, куда более фундаментальный, хотя по нему никто особо и не работал. Ну и продавцы scrum очень любят противопоставлять waterfall vs scrum, но waterfall это была первая формализация процесса, с выделением этапов и сам же автор говорил о цикличности этих этапов, об этом почему-то продацы scrum умалчивают.
Качество процесса определяет результат, ядро Linux пишут без скрама, а оно работает от калькуляторов до супер компьютеров.
Вообще за более, чем 20 летний опыт написания софта, я пришел к выводу, что если команда(в том числе менеджмент) не может придумать себе процессы для облегчения взаимодействия между собой, то это слабая команда и не более того. Более формализованные процессы нужны, когда взаимодействует несколько команд, но и там всегда можно договориться.
Если же смотреть шире, то производство софта это детский утренник по сравнению с процессами и сложностью авиазавода например.
это вы скажите толпам индусов, которые берут пачками стандартные фреймворки и гоняют террабатый джейсона, ведь вычислительные мощности позволяют. Приправляя это все скриптами, гоняя стриминговый трафик через централизованные платформы. А здесь гугл просто с себя снимает отвественность и мол показывает какие вы плохие, хотя с его же сервисов ютуба в день насматривают мемасиков или алкоголичка на сотни кубометров СО2.
Полностью согласен, на ревью я прежде всего смотрю, а не поломается ли что-то, если замержат этот код, нет ли каких-то дефектов. SOLID обычно проверяется на design review, когда раскидывают объекты.
плюсанул бы да кармы нет. Микросервисный и cloud-based подход лепят везде и всюду усложняя инфраструктуру и добавляя себе гемора.
Вместо обычного подхода, накидали сервисы с разумной детализацией, закинули на сервак(виртуалку), подняли несколько инстансов в разных ДЦ и погнали.
Но нет же для простых сервисов, возьмут куберы, контейнеры, прокси, балансеры, облачные базы, и вроде все должно работать но все равно летят ошибки из-за инфраструктуры, в 70% проектов вообще нафиг не нужен этот cloud-based подход.
Да и потом для масштабирования в реальном времени из-за нагрузки, такого куска можно применить cloud-based подход.
Более того есть бизнес процессы, которые в принципе масштабируются сложнее из-за длинных цепочек и мест синхронизаций
А можете озвучить таких конкурентов, для расчширения кругозора.
Тут еще следует упомнуть про бонусы и опционы (это даже не акции) и что эта ЗП до налогов.
У меня все равно есть разрыв шаблона, спрашивают литкод, который в жизни применяют разве что датабазники какие-нить, писатели поисковых движков и прочего, может еще системщиков где-то цепляет.
Но условно не решил литкод хард - тебя не берут, но почему никто не оценивает реальный опыт и умение решать реальные проблемы просто - ведь именно за это компания получает деньги - за умение решать проблемы, а не задачи, как технические, так и организационные.
Но есть ощущение, что фанги переоценены и это рынок работодателя.
Вера это вообще не научно.
Есть практики воспоминания прошлого опыта и такое проверяется очень легко, например если зарыл клад и можешь вспомнить это место, то надо прийти и проверить. Или например есть какие-то особенности, которые известны только тебе и которые можно проверить только сейчас.
Если проверка не срабатывает вполне может быть фантазия.
Со своей стороны у меня есть такие доказательства того, что я работал в определенной области и мои навыки в это области есть, при этом в текущей жизни я этим не занимался от слова вообще.
Есть другие косвенные подтверждения у других людей. Но полностью прошлая память так или иначе "зашита" в текущем воплощении, видимо для того, чтобы нарабатывать новый опыт, ну и воспоминания о смерти, болезни и прочих мучениях могут быть совсем неражужными и будут только мешать нарабатывать опыт.
Мне регулярно сыпят минусы в карму и на харб я хожу только из-за того, что доступны ленты сообщений. Но раз сыпят, то люди не хотят воспринимать мою инфу - на то их полное право.
Человек и так бессмертен, правда относительно. Физическое тело - инструмент накопления опыта. С каждой новой жизнью человек нарабатывает новый опыт и то, что дается человеку легко, просто говорит о том, что у него в этой области отлично наработанный опыт.
И если человек 5 жизней был связан с музыкой, много ли ему надо чтобы начать играть? Нет. Тот кто никогда не занимался музыкой либо очень давно, то ему этот опыт будет даваться очень тяжело.
Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые:
создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 2 года он работал, за ЗП ключевого в роли создателя. Такой же подход можно использовать и для рядового.
Итоговая стратегия строится так, что обещания+текущая позиция дешевле, чем инфляция на рынке. Чтобы нанять кого-то со стороны, необходимо докинуть денег для того, чтобы человек поменял место.
При этом, работая на одном месте бОльшая часть времени у большинства уходит на рутину, которая удешевляет вашу цену рынке и то, что востребовано у вас в компании, может быть совсем не востребовано где-то еще.
Регулируя разные параметры модели можно получить разные результаты. Есть примеры когда люди сидят по 15 лет на одном месте, со средней ЗП и лайтовыми условиями труда, есть те кто скачут пробуют, но при этом из-за нервов и времен страдает личная жизнь.
Кому какую стратегию выбирать: выбор каждого и там и там есть плюсы и минусы.
Но чтобы получить максимальную цену, надо досканально знать рынок.
Ретро, спринты, скрамы.
Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому.
Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт.
Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей?
Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя.
Я не хочу читать, что это работает, я хочу запустить и проверить что это работает.
Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует.
Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать.
Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
может вопрос дилетантский, но почему нельзя написать какой-нить фронтент для LVVM или написать какой-нить диалект для С++ или Java, как например это сделал JetBrains с котлином.
Котлин ООП язык с примесью функциональности, по сути фронтенд для Java, Native и т.д.
При этом если писать для JRE, то можно использовать все либы для java, на что-то там есть мапинги, на что-то нет.
Почему не взять какую-то стандартную платформу и заиспользовать всю ее мощность и комьюнити, при этом перкомпилить все конфигурации, ну или компилить конфигурации во время сборки? добавить какие-то тулы для фомроклепа, но поверх стандартных либ.
С учетом кроссс платформенности перевести на англ язык и захватить например какие-то азиатские рынки, хотя там свое написано уже, но тем не менее это бы значительно расширило долю рынка.
Спецы по 1С можете прокоментировать? я код 1С выидел пару раз, и очень примерно представляю как этоработает.
А я в какой-то степени понимаю боль собеседущего.
Если у тебя в резюме указано что ты знаешь A и B, но не можешь сказать каких-то ключевых характеристик, то этоточно говорит о том, что человек их не знает.
одно дело спрашивать какой хедер надо указать чтобы передать xml.
но если указан SOAP и REST, то он как минимум должен это знать, если гражданин знает матан (я его например не знаю, ну т.е. пределы, интегралы и прочее это понятно), то базовые вещи, пределы и теоремы он знать должен иначе это вранье, либо рассказать в каком объеме знает.
Автор абсолютно правильно спрашивает про рассуждение, потому что все IT это постоянное принятие решений и для чего тебе м***ак решение которого надо контролировать постоянно?
Который мог просто банально понатаскаться на типичные вопросы, а думать не умеет.
То же самое и с программированием, типовые задачи, типовые вопрсоы, а на выходе г-но. Потому что проблемы это всегда задачи с каким-то тонкостями и надо правильно выработать или выбрать решение.
С точки зрения юзера 2000 и WinXp были отличными системами. Добавив туда мультирабочий стол из коробки, каких-то плюшек из 7ки была бы отличная ОС.
при установке 1.5-2 Гб на диске, как уже написали никуда не лезет в инет и в целом все доступно и кастомизируемо (привет реестр). Все системы после XP это какой-то разброд и шатание в поисках чего-то нового, при этом похоронив все старое. Если в XP я спокойно работал в проводнике на клавитуре и вообще мог сделать все на клавиатуре, элементов фокуса было меньше, то сейчас такая работа вообще не реальна.
Перепиливание UI каждый раз приводит к тому, что мне вообоще все равно какой он, я его перестал настраивать от слова совсем. Если бы мне винда не требовалась для работы, у меня бы остался только линукс.
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи
Заголовок: сделать восстановление пароля
Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>.
Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
P.S. и еще бросилось в глаза: "Устные договоренности ничего не значат!" - брехня. Может звучит грубо, но:"за базар надо отвечать", потому что люди за него помнят и могут спросить.
И прежде всего этой аксиоме должен следовать руководитель - его слово куда весомее его подчиненных
Если прочитать про водопад http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
"Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps" (К сожалению, для приведенного процесса итерации разработки никогда не ограничиваются последовательными шагами) об итеративности уже тогда говорили.
И вообще в документике "сквозит" аджайлом, и много где написано, что не делайте больше, чем надо. При этом надо еще понимать что бумажка 1970г создана на основе разработки до этого 1970г.
Все что ниже гугли по быстренькому:
примеры компов второй половины 60х годов
https://en.wikipedia.org/wiki/SDS_9_Series
https://en.wikipedia.org/wiki/Honeywell_316
При этом надо понимать что никаких intellisense, CI, testing framworks , дебагеров и прочего не было, по этому к процессу разработки готовились куда тщательнее, что вполне разумно.
Еще кстати Agile/Scrum апологеты очень любят про избыточную документацию, при этом если посмотреть на любой SDK, то чем лучшге он документирован, чем больше примеров, тем проще писать код.
Решил копнуть про языки https://en.wikipedia.org/wiki/History_of_programming_languages
скорее всего писали на FORTAN'е и вот вам дают кусок какого-то когда, и хрен пойми чего он делает, при том, что там либо что-нить математическое либо machine level. Как в таком разобраться без доков, а если еще и модуль такой дадут, так он к тому же еще и ресурсы жрет и непонятно сколько.
Agile апологеты опять таки забывают про Rational Software и их RUP и UML, на мой взгляд наиболее полная формализация процесса разработки с единым языком UML, где на каждом этапе ключевую или специфичную инфу можно переложить в графические фигуры.
Весь этот Agile (XP, Scum, Kanban, Lean, LeSS) очень умело проданный продукт, для новичков, которые не знают истории разработки компов и софта. Конечно все эти подходы объединяют полезные практики, которые могут быть вполне полезны.
Причиной популярности agile и процессам послужил резкий рост производительности в конце 90х и начале нулевых и резкое удешевление персональных компьютеров, сюда же распространение винды и формоклепа от борланда позволило практически кому угодно начать программировать "с нуля", в отличии от ситуации до 90х, когда компы стояли либо на заводах, либо в НИИ, и никто там никакой Agile не купит.
Данный опросник для грейдов - дичь. Почему-то менеджмент вместо общения с людьми и оценки их полезности пытается наиболее критичный процесс заменить и автоматизировать.
Какие цели ставились перед сотрудником, куда сотрудник хотел расти, как он вырос устраивает ли компанию и работника?
Мнеджера, который придумал этот опросник возможно стоит переключить на административную работу или работу по поддержке. Разработка она не про задачи, а про продукт, ценные и реализованные идеи, а не про выполненные задачи.
Банальная операционщина - удел администраторов.
Ни слова не написано про жильё, сколько стоит, какая ипотека, сколько стоят коммунальные услуги?
Сейчас модно покидать РФ, при этом никто объективно не взвешивает плюсы и минусы.
1) Самое важное - свое жильё. Крыша над головой без ипотеки все таки позволяет пользоваться многими благами даже аггрессивной РФ.
2) Образование как вузовское, так и школьное. Сколько стоят и как организованы те же бассейны, спорт кружки и так далее, какой уровень педагогов?
Мск конечно не Россия, но в Мск можно найти очень достойные как клубы так и педагоги, за весьма небольшие деньги (а ля фитнес клуб за бассейном, тренажерами, групповыми занятиями и саунами за 30-40к в год на человека).
Куда ездят Шведы отдыхать на море в теплые края?
Сколько стоит купить участок, построить дом и подвести коммуникации к нему и какая удаленность от города?
Сколько стоит владеть машиной (понятно что она не всегда нужна), но условно если в РФ можно купить ведро(а ля какой-нить ВАЗ) + гараж, то это будет в районе 300-400к, налог можно не считать, все равно мало, но свою задачу это авто выполнит на все 100% и будет выполнять пока не сгниет(и этот процесс можно даже тормознуть, но потребуется время)
Много кто пишет о том, что они приобретают за рубежом и какой там толератное отношение к тридварасам и собачкам/кошечкам, но никто не пишет о том, что они теряют при отъезде.
Т.е. вот есть например квартира, дом, семья(родители, дети, братья, сестры), местами даже весьма неплохо климат. И тут вдруг бац это все плохо и релогация в счастливую швецию/финляндию и так далее. И либо едут совсем бедные, кто ничего особо не нажил, либо действительно богатые, которые ввалив денег могут вполне себе сохранить тот уровень жизни который был в РФ.
А ехать в европу или куда-то там, снимать жилье и жить в 0, на старость так себе перспектива.
А что мешает взять грамматический фреймфорк, написать нужную себе грамматику и дальше на основе этой грамматики вызывать свое API? И написать можно все так, как хочется.
А что на счет тренировки бактерий в животных, которым колят антибиотики.
Птица, свинина, говядина, молочка.
Мне кажется проблема то совсем не в людях. Сколько за год съедает антибиотиков человек и животное и сколько мутаций у бактерий проявляет резистентность к антибиотикам?
А потом эти бактерии попадают в человека и конечно же их антибиотики не берут и виноваты в этом люди, ну ну.
У меня вся родня с завода, плюс я также был в IT подразделении на другом заводе. То, что вы пишите с одной стороны правда, бюррократия и старый подход, который не пытается обойти конкуренцию, а наоборот ее подавить.
Но я бы хотел акцентировать внимание на другом. Если в софте можно откатить много чего и вернуть все назад в 95% случаев, то косяки на производстве стоят просто на порядки дороже.
Завод это прежде всего материальное производство, необходимо управлять запасами. Косяки в производстве сложных деталей могут просто заруинить все изделие (например ракету) и откат там невозможен в принципе.
Связи между цехами, людьми и этапами намного жесче, чем в IT и управление всем этим балаганом требует куда больших усилий, чем когда одна команда использует api сервис другой.
"2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели."
Вот это вот какая-то дичь, которая говорит о том, что менеджмент в компании дно, которые понятия не имеют о том, что такое обратная связь.
Вендор vs in-house тема спорная и просто так брать и инвестить в in-house может быть опрометчиво, там критерии совсем другие, хотя в вашем случае надо было просто сменить работу с вендорами.
Я из тех кто не любит Scrum, хотя бы только за то, что все факторы производительности сводятся в burndown chart и velocity, как понять какие факторы повлияли на эти значения - непонятно.
Бывает операционная и спонтанная активность, которая непредсказуема, мы ее просто логируем, хотя это уже как бы не scrum/
Вообще история создания Scrum мутная и не фундаментальная, тот же RUP, куда более фундаментальный, хотя по нему никто особо и не работал. Ну и продавцы scrum очень любят противопоставлять waterfall vs scrum, но waterfall это была первая формализация процесса, с выделением этапов и сам же автор говорил о цикличности этих этапов, об этом почему-то продацы scrum умалчивают.
Качество процесса определяет результат, ядро Linux пишут без скрама, а оно работает от калькуляторов до супер компьютеров.
Вообще за более, чем 20 летний опыт написания софта, я пришел к выводу, что если команда(в том числе менеджмент) не может придумать себе процессы для облегчения взаимодействия между собой, то это слабая команда и не более того.
Более формализованные процессы нужны, когда взаимодействует несколько команд, но и там всегда можно договориться.
Если же смотреть шире, то производство софта это детский утренник по сравнению с процессами и сложностью авиазавода например.
это вы скажите толпам индусов, которые берут пачками стандартные фреймворки и гоняют террабатый джейсона, ведь вычислительные мощности позволяют. Приправляя это все скриптами, гоняя стриминговый трафик через централизованные платформы.
А здесь гугл просто с себя снимает отвественность и мол показывает какие вы плохие, хотя с его же сервисов ютуба в день насматривают мемасиков или алкоголичка на сотни кубометров СО2.
Полностью согласен, на ревью я прежде всего смотрю, а не поломается ли что-то, если замержат этот код, нет ли каких-то дефектов.
SOLID обычно проверяется на design review, когда раскидывают объекты.