Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые: создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 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, когда раскидывают объекты.
Менеджеры традиционно считают разработчиков ленивыми и хитрыми. Они уверены, что без их контроля и наблюдения всё развалится. Руководители компаний видят в сотрудниках свою собственность. Они считают законным правом распоряжаться их временем. Шаг влево, шаг вправо — измена «хозяину».
Классическое описание говноменеджера, такие сами не работают и вообще не понимают что такое управление и другим только мешают.
А если в вашей компании люди не хотят работать - нанимаете не тех и люди занимаются не тем.
Сейчас на удаленке, менеджер тоже на удаленке, менеджер, к слову женщина - просто огонь, мироменеджментом не занимается. Следит за договоренностями, кто на чьей грядке работат и в верном ли идет направлении. Пожалуй одина из лучших наемных управленцев с которой работал.
Такое чувство что автор не пишет код.
документация к приватному методу может вполне содержать инфу для чего выделили этот метод и что он делает.
Да бывает что пишут дубликат, но это скорее заглушка, но никто не мешает указать причину почему принято то или иное решение.
Автору статьи (Генри) надо просто научиться извлекать пользу.
потому что вполне может быть String location, а в комменте может быть написано, location format: xxxxx, пример не очень удачный, но все же.
Очередные инфоцигане учат работать, все что здесь написано (переведено), относится к UML диаграмме «use cases», где очевидным образом присуствует «роль»(кто), действие(что), обоснование (для чего/по какой причине), а уж сформулировать это в эпик/стори или что хотите не требует каких-то необычных навыков.
Как-то все сложно написано, а самое главное никакой абстракции.
Очевидно, что чтение с базы должно быть каким-то пачками, а не зачитать все сразу. Для чего тут хибернейт вообще непонятно.
try (DatabaseRader dbReader= new DatabaseRader(query, params, rowMapper )) //в datareader настроить все параметры для чтения/кеширования и так далее
try (ExcelWriter excelWriter = new ExcelWriter(file, header)) {
excelWriter.write(dbReader.readeNext()) // тут можно добавить любые конвертации
}
Вся логика записи выделена в интерфейсы, можно перфомансы измерять, настраивать асинхронность и так далее, никаких JPA и MessageData, максимум что надо, так это добавить конвертацию типа базы в тип екселя, но это делается элементарно.
И полная гибкость, в настройке как источников, так и потребителей. И зачитать можно хоть 100млн, в память ничего не упадет.
Если уж совсем хочется быстрого, то писать xml потоково руками, там еще будет все быстрее, Опять таки для ускорения чтения, можно стараться генерить меньше мусора, миллион аллокаций, это все таки много, если уж совсем упороться, то при чтении все переменные выделять на стеке, данных мало, пролезут, работать будет как самолет.
Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые:
создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 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, когда раскидывают объекты.
Классическое описание говноменеджера, такие сами не работают и вообще не понимают что такое управление и другим только мешают.
А если в вашей компании люди не хотят работать - нанимаете не тех и люди занимаются не тем.
Сейчас на удаленке, менеджер тоже на удаленке, менеджер, к слову женщина - просто огонь, мироменеджментом не занимается. Следит за договоренностями, кто на чьей грядке работат и в верном ли идет направлении.
Пожалуй одина из лучших наемных управленцев с которой работал.
Очень поверхностный анализ, больше напоминающий инфоциганство, с непоятными плюсами и минусами обоих архитектур.
Что там в микросервисах с ACID? В монолите например с ним все гораздо проще.
Микросервисной архитектурой в платежной системе пользовались еще в 2007 году, а в 2009 уже сделали свое private облако.
документация к приватному методу может вполне содержать инфу для чего выделили этот метод и что он делает.
Да бывает что пишут дубликат, но это скорее заглушка, но никто не мешает указать причину почему принято то или иное решение.
Автору статьи (Генри) надо просто научиться извлекать пользу.
потому что вполне может быть String location, а в комменте может быть написано, location format: xxxxx, пример не очень удачный, но все же.
Очевидно, что чтение с базы должно быть каким-то пачками, а не зачитать все сразу. Для чего тут хибернейт вообще непонятно.
Вся логика записи выделена в интерфейсы, можно перфомансы измерять, настраивать асинхронность и так далее, никаких JPA и MessageData, максимум что надо, так это добавить конвертацию типа базы в тип екселя, но это делается элементарно.
И полная гибкость, в настройке как источников, так и потребителей. И зачитать можно хоть 100млн, в память ничего не упадет.
Если уж совсем хочется быстрого, то писать xml потоково руками, там еще будет все быстрее, Опять таки для ускорения чтения, можно стараться генерить меньше мусора, миллион аллокаций, это все таки много, если уж совсем упороться, то при чтении все переменные выделять на стеке, данных мало, пролезут, работать будет как самолет.