Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи Заголовок: сделать восстановление пароля Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>. Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину. Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
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 потоково руками, там еще будет все быстрее, Опять таки для ускорения чтения, можно стараться генерить меньше мусора, миллион аллокаций, это все таки много, если уж совсем упороться, то при чтении все переменные выделять на стеке, данных мало, пролезут, работать будет как самолет.
Стало в нынешние времена модно хейтить гражданина за его слова и какие-то мысли и самое главное предлагать какие-то совсем странные меры, которые ни коим образом не соотносятся с действительностью.
Если он там что-то наговорил, напиши заявление и пусть уполномоченные органы разберутся, заведут дело и накажут.
Если же состава преступления нет, то и осуждать его не за что.
А требовать каких-то мер от человека только потому, что тебе не нравятся его рассуждения — бардак и хаос.
На западе любят пиариться на группах «терпил», которых постоянно кто-то обижает и чего-то этим группам не додает, а кто обязан собственно?
Судя по статье и каментам он рассуждает о сексе с 17 летней по обоюдному согласию. Если это уголовно наказуемо — дайте срок, если нет отвалите в сторону. Если нет закона, то издатей закон, почему конкретно он не может рассуждать, тоже ущемление прав.
Это каким образом?
Симбиан и n72 — отличный кнопочный смартфон.
Если бы они составили конкуренцию эппл и шагнули в сторону тачскринов — был бы новый виток.
радует что компании начинают смотреть в сторону так называемых софт скилов.
Но вообще хантить надо голову, а не умения ибо голова уникальна и вполне может привнести что-то новое в компанию.
А по технологиям сейчас очень много информации, изучение технологии до определенного уровня — банальная функция времени.
Исключение позволяет разрушить нужный контекст, в случае монады разрушение этого контекста откладывается, более того, его придется контролировать результат на каждом уровне. (привет WinApi)
Условно есть CarService.GetOwnedCars(User user), RetailService.GetHouses(User user)
которые в каких-то разных местах вызываются с user'ом и придется всегда знать о какой-то начальной точке где надо проверить юзера и не создавать/ходить в эти сервисы, либо проверять каждый раз user'а внутри этих сервисов, что крайне усложняет поддержку кода
Исключение позволяет всего этого избежать и разрушить контекст немедленно, приведенная монада c case это точно такое же отложенное разрушение контекста как c кодом ошибки.
Научитесь писать контракт модуля обдуманно и не изобретайте велосипедов.
В своем проекте, когда метод может вернуть null, всегда помечали его как CanBeNull, если не помечен, значит вернется либо exception либо валидный результат. И если возвращается exception разрушаем контекст вызова до определенного уровня. А вместе разрушения неважно, то ли юзера нет в базе, то ли база упала — неважно, важно что у контекста нет валидных данных для продолжения работы, по незявисящим от него причинам.
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи
Заголовок: сделать восстановление пароля
Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>.
Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
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 потоково руками, там еще будет все быстрее, Опять таки для ускорения чтения, можно стараться генерить меньше мусора, миллион аллокаций, это все таки много, если уж совсем упороться, то при чтении все переменные выделять на стеке, данных мало, пролезут, работать будет как самолет.
Если он там что-то наговорил, напиши заявление и пусть уполномоченные органы разберутся, заведут дело и накажут.
Если же состава преступления нет, то и осуждать его не за что.
А требовать каких-то мер от человека только потому, что тебе не нравятся его рассуждения — бардак и хаос.
На западе любят пиариться на группах «терпил», которых постоянно кто-то обижает и чего-то этим группам не додает, а кто обязан собственно?
Судя по статье и каментам он рассуждает о сексе с 17 летней по обоюдному согласию. Если это уголовно наказуемо — дайте срок, если нет отвалите в сторону. Если нет закона, то издатей закон, почему конкретно он не может рассуждать, тоже ущемление прав.
Симбиан и n72 — отличный кнопочный смартфон.
Если бы они составили конкуренцию эппл и шагнули в сторону тачскринов — был бы новый виток.
Но вообще хантить надо голову, а не умения ибо голова уникальна и вполне может привнести что-то новое в компанию.
А по технологиям сейчас очень много информации, изучение технологии до определенного уровня — банальная функция времени.
Условно есть CarService.GetOwnedCars(User user), RetailService.GetHouses(User user)
которые в каких-то разных местах вызываются с user'ом и придется всегда знать о какой-то начальной точке где надо проверить юзера и не создавать/ходить в эти сервисы, либо проверять каждый раз user'а внутри этих сервисов, что крайне усложняет поддержку кода
Исключение позволяет всего этого избежать и разрушить контекст немедленно, приведенная монада c case это точно такое же отложенное разрушение контекста как c кодом ошибки.
Научитесь писать контракт модуля обдуманно и не изобретайте велосипедов.
В своем проекте, когда метод может вернуть null, всегда помечали его как CanBeNull, если не помечен, значит вернется либо exception либо валидный результат. И если возвращается exception разрушаем контекст вызова до определенного уровня. А вместе разрушения неважно, то ли юзера нет в базе, то ли база упала — неважно, важно что у контекста нет валидных данных для продолжения работы, по незявисящим от него причинам.