В 2020 году появился новый инструмент для реализации приведенных выше пунктов или это какая-то новейшая методика о которой ни кто раньше не знал и не подозревал?
Для технологического прорыва нужно не миллион IT специалистов, а с десяток гениев. Потому что бесконечное количество обезьян за бесконечное количество времени конечно напишут «Войну и мир», но лучше если это сделает один Толстой. А производить банковское ПО и прочие примитивные свисто-перделки может любой (сам этим занимаюсь :( ), технологическое отставание это не покроет.
…
— Команда должна организовываться самостоятельно.
— Тогда какая же задача у Scrum мастера, если команда должна сама организовываться?
— Как это какая? Создавать атмосферу конечно-же!
Можно поделить компании на группы:
1. Компании имеющие собственный продукт продающийся как есть. Тогда в случае невыполнения спринта мы просто пишем список новых фич и не включаем туда какую-то анонсированную которую не успели выпустить. А дальше пусть менеджмент разгребает, нечего было обещать и поднимать шумиху раньше времени (для этого кстати и нужна секретность и утечки информации, чтобы не делать официальных заявлений).
2. Компания интегратор часто имеющая собственную систему которую она старается всячески везде интегрировать. Если клиент заплатил за интеграцию и не получил ее в указанные сроки то это плохо для интегратора, так делать нельзя.
3. Тоже самое для производителя индивидуальных решений, компания клепает сайты-визитки. Если запланировано 3 сайта на спринт, и один не доделан то нужно выкручиваться, ведь обычно деньги получены заранее.
4. Компания не IT направления имеющая собственное подразделение разработки для внутренних нужд, например банк. Банкиры создали бизнес — проект, проект ориентирован на незанятую нишу и нужно ее срочно занять и выйти на рынок с новым финансовым продуктом в установленные сроки. Если разработка эти сроки завалит то банк просто не успеет выйти с продуктом и вся разработка это просто — деньги в шредор.
Системный анализ проблемы не подходит там где нужен комплексный. В данном случае проблема в планировании, нужна статья о том как планировать факапы. Ни разу не видел в IT чтобы кто-то сформировал график с трендом ожиданий и границами суммы погрешности оценок, для того чтобы отслеживать картину отклонений, собирать статистику и подбирать подходящий размер спринтов или иным способом регулировать работу команд.
Джун, это программист который может решить простую задачу «так чтоб работало», такого человека можно брать на работу, а дальше его должны научить старшие товарищи.
Раз уж Вы практически весь мой пост процитировали)
Ну вся программа обучения от школы до университета, по большей части требует от нас зубрежки. Преобладающее большинство отличников с которыми я имел честь общаться, просто зубрили информацию. Они даже спустя 15 лет ее помнят, но дальше уровня блеснуть знанием информации обычно ничего не доходит. Несправедливо требовать от новичка без опыта, умения применять свои знания на практике. Разум новичка в программировании просто не создаст ту ситуацию для которой потребуется тот или иной паттерн, ведь паттерны появились не сразу, их придумывали и полировали годами решая проблемы. Если взять нынешнего джуна с его багажом знаний и старого «морского волка» на том уровне когда он только начинал, я думаю, что первый еще фору сможет дать. Джун, это программист который может решить простую задачу «так чтоб работало», такого человека можно брать на работу, а дальше его должны научить старшие товарищи.
Знание просто багаж, понимание это умение оперировать знаниями, сопоставлять их с опытом, находить пробелы в своем понимании и восполнять пробелы новыми знаниями. Просто знать мало для того чтобы применять. Человек без опыта может заучить все паттерны проектирования, но если задача выходит за рамки предоставленных примеров, или находится на их границе то без опыта трудно найти подходящее решение которое не породит кучу проблем в будущем.
Знание — информация
Понимание — совокупность опыта и знаний.
Во время второй мировой войны помимо сражений на фронтах происходила «гонка заводов», когда каждая из противоборствующих сторон старалась произвести как можно больше качественного боеспособного вооружения. Немецкий подход строился на мастерах, например в обработке листового алюминия, самолеты (например) собирались вручную и очень качественно, с другой стороны использовали подход когда в процессе производства преобладали не настолько квалифицированные рабочие. Конструкция танков, самолетов и т.д. позволяла их производить без выдающихся навыков. В результате каждая из сторон в отдельных отраслях произвела больше вооружения чем Германия. Проводя аналогию с программированием, нам дали хорошие инструменты, нам не надо часами выколачивать элемент фюзеляжа, достаточно пару раз бахнуть прессом. Что в этом плохого? «Стране» нужно больше софта, 60% программистов не нужно разбираться в тонкостях сопромата, свойствах металлов и так далее, ему просто нужно бахнуть прессом по куску железа. Со временем такой программист ошибется и положит не тот металл на пресс, и у него не получится, он начнет учиться и перейдет в следующие 40% где история будет повторяться до тех пор пока он не сделает свой пресс. А может быть он никогда не дойдет до этого уровня. Возвращаясь к зарплатам, это вранье, что через пол года курсов вас возьмут на работу за 100 в месяц, потолок 40. Другое дело если вы не только программист, а пришли в программирование как к прикладной дисциплине и являетесь специалистом в инженерии к примеру, тогда вы можете найти работодателя которому нужны именно вы и да, зарплата будет и 100 и 200 как договоритесь потому что нам платят до тех пор пока нас тяжело заменить.
Если я правильно понял, то вам нужно:
1. Прочитать данные из кеша.
2. В случае отсутствия данных выполнить расчет.
3. В случае выполнения расчета, записать данные в кеш.
4. Вернуть результат.
Где проблема? Я чего-то не понимаю?
Конечно будет медленнее, конечно будет больше накладных расходов, асинхронность не для синхронных операций придумана. С точки зрения здравого смысла, зачем математическую операцию делать асинхронной? Она не падает в ожидание в процессе выполнения (разве что на уровне квантов). О чем статья, какой посыл?
Для «широких масс» PUT всегда ожидает положительного результата, даже если по факту он отрицательный, если вы считаете что в момент обновления данных может быть ошибка используйте POST.
Есть такая технология как «мозговой штурм», когда идеи высказываются без критики — просто чтобы были. И иногда именно таким образом находится оригинальное хорошее решение.
Я об этом высказался, про высказывание идей без критики и дальнейший их анализ.
— Команда должна организовываться самостоятельно.
— Тогда какая же задача у Scrum мастера, если команда должна сама организовываться?
— Как это какая? Создавать атмосферу конечно-же!
1. Компании имеющие собственный продукт продающийся как есть. Тогда в случае невыполнения спринта мы просто пишем список новых фич и не включаем туда какую-то анонсированную которую не успели выпустить. А дальше пусть менеджмент разгребает, нечего было обещать и поднимать шумиху раньше времени (для этого кстати и нужна секретность и утечки информации, чтобы не делать официальных заявлений).
2. Компания интегратор часто имеющая собственную систему которую она старается всячески везде интегрировать. Если клиент заплатил за интеграцию и не получил ее в указанные сроки то это плохо для интегратора, так делать нельзя.
3. Тоже самое для производителя индивидуальных решений, компания клепает сайты-визитки. Если запланировано 3 сайта на спринт, и один не доделан то нужно выкручиваться, ведь обычно деньги получены заранее.
4. Компания не IT направления имеющая собственное подразделение разработки для внутренних нужд, например банк. Банкиры создали бизнес — проект, проект ориентирован на незанятую нишу и нужно ее срочно занять и выйти на рынок с новым финансовым продуктом в установленные сроки. Если разработка эти сроки завалит то банк просто не успеет выйти с продуктом и вся разработка это просто — деньги в шредор.
Системный анализ проблемы не подходит там где нужен комплексный. В данном случае проблема в планировании, нужна статья о том как планировать факапы. Ни разу не видел в IT чтобы кто-то сформировал график с трендом ожиданий и границами суммы погрешности оценок, для того чтобы отслеживать картину отклонений, собирать статистику и подбирать подходящий размер спринтов или иным способом регулировать работу команд.
Раз уж Вы практически весь мой пост процитировали)
Знание — информация
Понимание — совокупность опыта и знаний.
1. Прочитать данные из кеша.
2. В случае отсутствия данных выполнить расчет.
3. В случае выполнения расчета, записать данные в кеш.
4. Вернуть результат.
Где проблема? Я чего-то не понимаю?
Я об этом высказался, про высказывание идей без критики и дальнейший их анализ.