Понятно. Я вполне допускаю что есть такие люди как вы, которые заботятся о конфиденциальности своих данных. Если с софтом для контроля не получается, то как насчет удаленного рабочего окружения? Попросите заказчика организовать удаленное рабочее место, на котором он сможет следить за тем что вы фактически работаете а не придумываете часы. В таком случае вы готовы будете работать в таких условиях?
Проблема о которой вы говорите, существует не вчера. Она существует с любым фрилансером. Ситуация изначально такая, что работодатель хочет больше работы и меньше платить, а исполнитель наоборот хочет работать меньше но получить больше. Тут нужны компромиссы с двух сторон. Контроль за исполнителями дает прозрачность процессов. Ни у кого вопросов не останется.
Вы путаете работу между компаниями и работу нанятого исполнителя. Facebook нанял на работу сотрудника, а не заключал договор с компанией индусов. Это обман работодателя. С сотрудником ведь был заключен трудовой договор.
Это не норма прибыли, это обман заказчика. Это не издержки на производство, это раздутие чека услугами которые не были оказаны. Вам продали часы работы, которых фактические не было. Если вы не поняли проблему с автосервисом я могу привести вам другой пример. Представьте что вы наняли музыкантов играть сложный концерт на мероприятии которое не понятно сколько продлится и на котором вы лично не присутствовали. В итоге вы не знаете сколько оно продлилось потому что вас там не было. Они сыграли 2 часа и просят вас оплатить за 5 часов. Оплатите? Условия не нарушены, они обещали сыграть концерт.
Вы продаете свою работу в часах, но при этом вписываете их в чек постфактум. И вас удивляет что заказчик хочет быть уверен, что покупает именно то что указано в чеке, а не придуманную цифру? Вам кажется что есть какое то среднее комфортное значение для заказчика которое он готов платить поэтому он и должен его платить. Но это не так. Заказчик готов платить исключительно за те часы которые фактически были затрачены, а не за те которые придумали и вписали в счет.
На рынке уже есть много компаний которые работают в этих сферах много лет, но вы почему то считаете что это шпионский софт. Как вы вообще софтом пользуетесь, если любой из них может за вами шпионить? Вы ведь знаете истории что Google, Microsoft, Apple много раз уличали в сборе слишком большого количества информации?
По вашему, у Facebook не должно быть претензий к разработчику который на свою зарплату нанимает 4х индусов вместо себя и не работает? Соотношение X/Y ведь устраивает?
Вы не знаете попали ваши работники в этот врущий процент или не попали. У вас могут все разработчики врать, или могут все не врать. Вы не ответили на вопрос о том как лично вы собираетесь это проверять? Поставьте себя на его место, и ответьте, как лично вы собираетесь контролировать то что человек работал 2 часа, а в счете написал 8? Вы ведь понимаете что с учетом времени переплата будет существенной? Ваши суждения про X/Y очень поверхностные. Если представить что все ваши разработчики врут, то ничего страшного что вы им переплачиваете, ведь X/Y устроил?
Для вас 70к это не деньги, но готовы ли вы их из своего кармана заплатить человеку который обманул вас в работе? Представьте что вы приехали в свой постоянный автосервис, и вам говорят что работа такая сложная что займет 7 дней и будет стоить 70к, а по факту она была простая и заняла 2 дня что стоило бы 30к. По вашему X/Y сходится, и если бы вы узнали уже после оплаты, что авто сервис вас обманул, то у вас бы претензий не было? Где та грань, когда вы предьявите автосервису, что они берут деньги и не работают?
Этот диалог касается управления техническим долгом, и, вы почему то, начали его не с самого начала. Возникает вопрос: перед тем как приступить к задаче, менеджер вообще запрашивал у вас оценку? Вы ведь предупреждали его, что это «смысловая работа», в которой сложно прогнозировать сроки, и указали связанные с этим риски? И разве менеджер не принял эти риски осознанно, прежде чем передать задачу вам?
Далее ситуация становится ещё интереснее. Получается, вы не обсуждали статус задачи с менеджером в процессе выполнения? В ходе интенсивной работы над такой задачей обычно становится яснее, сколько времени она занимает, и какие подзадачи можно выделить в Jira для большей прозрачности. Почему не было таких промежуточных синков?
Ещё один важный момент — доверие со стороны менеджера к вашему учёту времени. Попробуйте взглянуть на ситуацию с его стороны: как он может проверить, действительно ли вы работали столько, сколько зафиксировали, или просто указали удобную вам цифру? Как он может быть уверен, что вы не завысили время без оснований?
Предложите конкретный способ подтверждения: установите специальный софт для отслеживания рабочего времени, чтобы менеджер мог сверяться с ним. Тогда подобные вопросы отпадут сами собой. А задумайтесь также: почему многие сотрудники сопротивляются использованию такого ПО?
Если у вас есть только одно место вызова этого хука module_name_form_after, то наверное лучше будет сделать свой EventSubscriber.
Не будет больше кода с проверкам:
if ($form['#id'] === 'some_name_1') {}
if ($form['#id'] === 'some_name_2') {}
if ($form['#id'] === 'some_name_3') {}
Все сведется к коду вида:
function module_name_form_after($form) {
$subscriber->dispatch(new ModuleNameFormEventAfter(id: $form['id']));
}
// и уже внутри сабскрайбера будет что то типа
public function dispatch(Event $event) {
foreach ($this->subscribers as $subscriber) {
if ($subscriber->supports($event)) {
$subscriber->handle($event);
}
}
}
Разве не наоборот? Человек хочет работать в FAANG, и именно поэтому уделяет время на тренировки с литкодом. Для компаний это тоже плюс, потому что они получают кандидатов, которые стремятся попасть именно к ним. То есть потенциально, кандидаты хотят работать у них долго, и готовы тратить время на подготовку к собеседованиям. Сравните это с навыком иностранного языка. Человек изучает язык, чтобы работать в иностранной компании. Если не хочет изучать, то работает там где работает. Хочешь в высшую лигу, качай литкод, не хочешь работай там где это не требуют. Совсем другой вопрос в том, что другие компании смотрят как делают FAANG и бездумно за ними повторяют, превращая все это в карго культ.
Ну это ведь очень дорого. Все это оправдано, только если у вас есть какая то песочница, где вы набираете кучу кандидатов на испытательный срок, а потом оставляете лучших. Представьте, каждому надо платить на испытательном, каждого надо менеджерить. Тратить ресурсы на онбординг и т.п. Ну представьте, ваши топовые разработчики тратят время не на работу за которую вы можете платить им зарплату, а на ревью кода который льют ваши стажеры на испытательном. Наоборот, крупные компании не хотят и близко с этим связываться, потому что все это очень дорого. Проще оптимизировать процесс найма.
Испытательный срок это все же не инструмент при найме, это по большей части страховка от ошибок совершенных при найме. Если кандидату не продлили испытательный, то значит люди которые занимались наймом, выполнили свою работу плохо. Более того, надо учитывать время, потому что условно, если бы взяли сразу нужного кандидата то он бы принес N пользы, а если кандидату не продлили испытательный срок, то явно пользы принесено меньше чем N. И в это самое время, пока вы играетесь с испытательным сроком, ваши конкуренты нанимают нужных специалистов с первого раза.
В вашем примере с литкодом, все немного не так. Все эти алгоритмические задачи, не для того чтобы нанять человека, который постоянно будет работать с такими задачами. Все это для того чтобы отсеять большое количество кандидатов. Если взять условно двух одинаковых кандидатов, которые по всем параметрам совпадают кроме решения задач с литкода, то я бы отдал предпочтение тому из них кто все же натренировался решать такие задачи ради собеса. Ну и на сколько я помню, крупные компании собрав статистику, поняли что кандидаты умеющие решать задачи с литкода, работают лучше чем те кто не умеют.
Так это ведь не новая проблема, все это существует уже кучу времени. Тонна статей написана о том как проводить собеседование, где то вон по 5 этапов вводят и другие компании подхватывают этот карго культ. Проблема ведь в том что нет одного универсального теста, который позволит точно определить с первого раза, какой уровень кандидата. Ошибки найма стоят очень дорого, поэтому все хотят взять на работу звезду а не получить потом проблемы. Учитывая статистику по вакансиям/кандидатам вполне закономерный результат в сторону викторин и ужесточения отбора. Времена душевных бесед с просмотром гитхаба давно закончились. Им на смену пришли времена написания кода на листочках и угадывание мыслей интервьюера.
Если вы говорите про много нюансов под капотом о которых обязаны знать старшие программисты, то надо перечислить хотя бы некоторые из них. Может быть их окажется не так много, либо они будут не такими значимыми как вам кажется?
Можете привести примеры такой забагованности именно из за незнания нюансов? Может быть покрытие тестами позволит бизнесу не нести многомиллионые потери в этих случаях?
Функции, использующие указатели или ссылки на базовые классы, должны иметь возможность использовать объекты классов-наследников, не зная об этом
Мне кажется ваш тест ни как это не учитывает. Вы тестируете внутреннюю реализацию, проверяете что аргумент конструктора записался в длину и ширину правильно, но зачем такие тесты? Зачем тесты которые тестируют геттеры или assertInstanceOf ?
Чтобы проверить LSP вам нужна некая 3ая функция, например calcPerimeter(Rectangle $rect): float|int; а в тесте нужно запустить ее с Rectangle и Square, и ничего не должно сломаться.
Мне нравится практика диспутов у буддистов в Тибете. После того как они поспорят, и судьи вынесут решение о том кто был убедительнее из них, участники спора меняются местами, и пытаются доказать противоположную сторону! И самые крутые из монахов могут убедительно доказывать обе стороны спора!
Аргументация должна была быть на основе плюсов и минусов микросервисной архитектуры. Какие проблемы перед нами стояли, из за которых выбор пал именно на эту архитектуру а ни на какую то другую. Тут же как в анекдоте получается, будем делать микросервисы потому что монолит у меня уже есть в резюме.
Я не эксперт конечно, но на сколько я понимаю Будда как раз и учил о том, что не верьте ни единому слову только потому что так говорил Будда. В буддизме не вкладывается столько значений в доказательство правдивости источников, как это происходит в аврамических религиях потому что конечный путь достигается при жизни а не после смерти. В них это все важно, потому что там, тексты это слова одного всемогущего, всевышнего Бога творца. Он все это устроил, на все его воля и желание, нет ничего что он не смог бы. Он передал через пророков для всего человечества эти текста с правилами! И очень важно, чтобы, то что передал такой ключевой Бог всем людям, не было искажено ни кем и никогда, потому что в конце каждого ждет страшный суд на котором Бог будет судья и судить он будет именно по правилам из этих самых переданных текстов. Важно чтобы эти источники совпадали с теми по которым будет происходить суд. В буддизме же, вы сами определяете приближает вас эти текста к пробуждению или нет. Если вы говорите о том что Будда мог в камне записать все сам как это сделал Моисей, то и аврамический Бог мог записать все это таким образом, что сомнений не останется ни у кого из живущих. На небе написать например, он же всемогущий! Так бы ни у кого из родившихся на земле вопросов не осталось есть Бог или нет? И что в буддизме, и что в а аврамических религиях, есть огромный смысл в том, что все это не было таким образом записано. У каждого начинающего последователя присутствуют сомнения в правдивости учений. Из за сомнений у них появляется потребность изучать и определять во что верить а во что нет, до такого уровня что никаких сомнений не должно оставаться! Написал бы Будда все это на камнях что не сотрешь и не исказишь, или Бог на небе, и сомнений в подделках бы не было и ни в чем разбираться не нужно. НО даже так сомнения будут остаться. А Будда ли это написал? Даже то что когда то Моисей записал заповеди на скрижалях, не привело к тому, что все люди вдруг в них поверили и стали их соблюдать. Все ровно, у людей появились сомнения которые заставляют из разбираться и решать верить или нет..
Будда же учил так что, он может показать один путь, который он лично сам прошел. И не факт что ты последуешь по нему, и достигнешь такого же результата как он. И он не утверждал что путь для всех один и только такой как он показал! Точно такой же результат можно получить другими путями. Отсюда и столько различных течений и школ в буддизме. И в каждом есть свой пример достижения того же, но каким то своим способом. Намного больше внимания уделяется учителю. Именно наставник может сократить путь и показать нужное направление. И ученики могут превосходить учителей, а некоторые учителя так и не достигнуть уровня пробуждения. При таком положении, какой смысл записанного на бумаге текста? Можно получить ситуацию, когда все читают один и тот же правильный исходный текст от Будды, следуют всему что в нем написано и при этом никто из них просветления не достигнет. В результате исходный текст будет выброшен и отмечен как нерабочий хотя он полностью правдивый! При жизни Будды по его пути прошли тысячи людей и достигли успеха, а дальше все меньше и меньше. И проблема не в текстах, а в учителе. Нету какого то одного судьи, который решает для всех что вот этот человек пробудился, а вот этот еще нет. Нет какого то одного экзамена, который гарантировано выдаст результат достигнул ты того же что и Будда или нет.
Гарантий того что какая то школа заблуждается или ошибается или намерено искажает знания нету. Их никто вам не даст. Под сомнения может будет поставить что угодно. Но сами же они конечно сомневаться не будут. Вы сами должны будете понять в ходе своего пути что приближает вас к цели а что нет. Сам Будда вон скитался от одних монахов к другим и пробовал то одни то другие практики и учения, и каждое ему обещало результат, и везде он не достиг результата и забросил все. Даже живя в Тибете и обучаясь у самого Далай Ламы, вы все ровно не сможете спросить у какого то независимого судьи, правильно ли он вас учит или нет. Это только вы сами можете понять, определить и прочувствовать, приближает ли вас это обучение к нужной цели или нет. Судья который это решает это лично вы сами и никто кроме вас.
Если наука докажет что буддизм ошибается, то буддизм должен будет изменится. Взять верные решения из науки, и применить их к себе. А если наука докажет что авраамические религии ошибаются, то они должны будут просто перестать существовать или серьезно так переобуться. Типа мы не то небо имели виду, Бог не на том небе что над нами а на каком то другом которое мы не видим!
Тимлиду лучше проводить личные беседы, потому что в них наиболее полная и правдивая обратная связь. Не скатываться в надоедливые всем опросы, а проводить все это именно как взаимовыгодный разговор. Так можно будет пользоваться различными уловками, типа например сперва похвалить сотрудника а потом задавать вопросы. Можно даже дать сотруднику обратный фидбек по результатам такой беседы. Это HR могут проводить такое через почту, на все отделы разом, а у тимлида команда в разы меньше и отношения между сотрудниками ближе.
Время этих бесед надо подбирать персонально под сотрудника. С кем то может потребоваться обсуждать все это раз в месяц, а с кем то вполне можно и раз в год. С кем то может не прокатить формат личного общения и придется просить пройти опрос в другом виде. Тут тимлиду должно быть виднее кто есть кто в его команде и к кому какой подход нужен.
Технический долг ничего не стоит именно клиенту а не владельцу продукта. Вам написали, о том что невозможно в счет клиенту написать пункт "рефакторинг". Согласитесь было бы странно, если бы вас какой то сервис, попросил заплатить им за рефакторинг?
Но в целом эта тема не новая и уже много много раз поднималась. Все это лечиться правильной культурой разработки. Как продавать руководству тех долг написано очень много статей. Если коротко, то нужен компромисс с двух сторон. Директор и руководители должны понять, что технический долг в итоге убьет всю компанию, а команды разработки должны понять что они не пишут код ради кода. Они пишут код который приносит деньги.
Плюс можно добавить Modulite и/или Deeptrac и все будет еще лучше и чище.
Честно сказать, из текста статьи вообще не понятно ничего. Ни одного примера нету, где мы нарушили SOLID и как мы переписали код, таким образом чтобы соблюдать SOLID. Мало примеров кода и картинок. Советы типа делать UserOrderCheckoutService, приводят к тому что появляется куча однотипных названий сервисов, и потом никто не знает какой из них использовать в той или иной ситуации.
Например что делать, если наши юзеры разбиваются еще на группы, у этих групп есть разные настройки и разные права. Получаться разработчики захотят создать UserSallerCheckoutService, UserOptovikWhithoutRuleReservCheckoutService и т.д.
Ничем не плох, это такой же инструмент. Какой выбрать решать вам. Статья ведь не про SymfonyMessenger. Тег стоит Laravel, с чего вдруг symfony стал стандартным? Можно ведь ваш комментарий перефразировать для Prooph или Tactician. А представьте каждый напишет комментарий с ссылкой на свой CommanBus инструмент?
В приведенном примере, скорее всего, начальная реализация OrderService подразумевала не просто пустой ответ, а результат работы сервиса (order_id, notification_result, shipped_result).
С переходом на асинхронные сообщения, мы также переходим и на асинхронные ответы. В случае когда формат ответа нужно сохранить, мы должны будем не переписывать старый контроллер, а добавить новый. После чего нужно ждать когда все кто использовал этот контроллер перейдут на новую асинхронную версию.
И как быть, если наши партнеры не особо то и хотят этим заниматься? Их все устраивало раньше, они отправляли запрос и получали ответ, а теперь им надо городить какие то сокеты, пинги, лонгпулинг или что то еще.
А в чем проблема переопределения стилей? Я ведь могу условно обернуть Bootstrap компонент в какой то .class-wrapper и переопределить все что внутри него через условный .class-wrapper .btn ? Более того эти библиотеки ведь дают как то настраивать тему.
Понятно. Я вполне допускаю что есть такие люди как вы, которые заботятся о конфиденциальности своих данных. Если с софтом для контроля не получается, то как насчет удаленного рабочего окружения? Попросите заказчика организовать удаленное рабочее место, на котором он сможет следить за тем что вы фактически работаете а не придумываете часы. В таком случае вы готовы будете работать в таких условиях?
Проблема о которой вы говорите, существует не вчера. Она существует с любым фрилансером. Ситуация изначально такая, что работодатель хочет больше работы и меньше платить, а исполнитель наоборот хочет работать меньше но получить больше. Тут нужны компромиссы с двух сторон. Контроль за исполнителями дает прозрачность процессов. Ни у кого вопросов не останется.
Вы путаете работу между компаниями и работу нанятого исполнителя. Facebook нанял на работу сотрудника, а не заключал договор с компанией индусов. Это обман работодателя. С сотрудником ведь был заключен трудовой договор.
Это не норма прибыли, это обман заказчика. Это не издержки на производство, это раздутие чека услугами которые не были оказаны. Вам продали часы работы, которых фактические не было. Если вы не поняли проблему с автосервисом я могу привести вам другой пример. Представьте что вы наняли музыкантов играть сложный концерт на мероприятии которое не понятно сколько продлится и на котором вы лично не присутствовали. В итоге вы не знаете сколько оно продлилось потому что вас там не было. Они сыграли 2 часа и просят вас оплатить за 5 часов. Оплатите? Условия не нарушены, они обещали сыграть концерт.
Вы продаете свою работу в часах, но при этом вписываете их в чек постфактум. И вас удивляет что заказчик хочет быть уверен, что покупает именно то что указано в чеке, а не придуманную цифру? Вам кажется что есть какое то среднее комфортное значение для заказчика которое он готов платить поэтому он и должен его платить. Но это не так. Заказчик готов платить исключительно за те часы которые фактически были затрачены, а не за те которые придумали и вписали в счет.
На рынке уже есть много компаний которые работают в этих сферах много лет, но вы почему то считаете что это шпионский софт. Как вы вообще софтом пользуетесь, если любой из них может за вами шпионить? Вы ведь знаете истории что Google, Microsoft, Apple много раз уличали в сборе слишком большого количества информации?
По вашему, у Facebook не должно быть претензий к разработчику который на свою зарплату нанимает 4х индусов вместо себя и не работает? Соотношение X/Y ведь устраивает?
Вы не знаете попали ваши работники в этот врущий процент или не попали. У вас могут все разработчики врать, или могут все не врать. Вы не ответили на вопрос о том как лично вы собираетесь это проверять? Поставьте себя на его место, и ответьте, как лично вы собираетесь контролировать то что человек работал 2 часа, а в счете написал 8? Вы ведь понимаете что с учетом времени переплата будет существенной? Ваши суждения про X/Y очень поверхностные. Если представить что все ваши разработчики врут, то ничего страшного что вы им переплачиваете, ведь X/Y устроил?
Для вас 70к это не деньги, но готовы ли вы их из своего кармана заплатить человеку который обманул вас в работе? Представьте что вы приехали в свой постоянный автосервис, и вам говорят что работа такая сложная что займет 7 дней и будет стоить 70к, а по факту она была простая и заняла 2 дня что стоило бы 30к. По вашему X/Y сходится, и если бы вы узнали уже после оплаты, что авто сервис вас обманул, то у вас бы претензий не было? Где та грань, когда вы предьявите автосервису, что они берут деньги и не работают?
Лучше уже тогда оценивать таски по сторипоинтам. Сколько по вашему займет задача замены favicon на сайте? не 15 минут а час, два, три?
Этот диалог касается управления техническим долгом, и, вы почему то, начали его не с самого начала. Возникает вопрос: перед тем как приступить к задаче, менеджер вообще запрашивал у вас оценку? Вы ведь предупреждали его, что это «смысловая работа», в которой сложно прогнозировать сроки, и указали связанные с этим риски? И разве менеджер не принял эти риски осознанно, прежде чем передать задачу вам?
Далее ситуация становится ещё интереснее. Получается, вы не обсуждали статус задачи с менеджером в процессе выполнения? В ходе интенсивной работы над такой задачей обычно становится яснее, сколько времени она занимает, и какие подзадачи можно выделить в Jira для большей прозрачности. Почему не было таких промежуточных синков?
Ещё один важный момент — доверие со стороны менеджера к вашему учёту времени. Попробуйте взглянуть на ситуацию с его стороны: как он может проверить, действительно ли вы работали столько, сколько зафиксировали, или просто указали удобную вам цифру? Как он может быть уверен, что вы не завысили время без оснований?
Предложите конкретный способ подтверждения: установите специальный софт для отслеживания рабочего времени, чтобы менеджер мог сверяться с ним. Тогда подобные вопросы отпадут сами собой. А задумайтесь также: почему многие сотрудники сопротивляются использованию такого ПО?
Если у вас есть только одно место вызова этого хука module_name_form_after, то наверное лучше будет сделать свой EventSubscriber.
Не будет больше кода с проверкам:
Все сведется к коду вида:
Разве не наоборот? Человек хочет работать в FAANG, и именно поэтому уделяет время на тренировки с литкодом. Для компаний это тоже плюс, потому что они получают кандидатов, которые стремятся попасть именно к ним. То есть потенциально, кандидаты хотят работать у них долго, и готовы тратить время на подготовку к собеседованиям. Сравните это с навыком иностранного языка. Человек изучает язык, чтобы работать в иностранной компании. Если не хочет изучать, то работает там где работает. Хочешь в высшую лигу, качай литкод, не хочешь работай там где это не требуют. Совсем другой вопрос в том, что другие компании смотрят как делают FAANG и бездумно за ними повторяют, превращая все это в карго культ.
Ну это ведь очень дорого. Все это оправдано, только если у вас есть какая то песочница, где вы набираете кучу кандидатов на испытательный срок, а потом оставляете лучших. Представьте, каждому надо платить на испытательном, каждого надо менеджерить. Тратить ресурсы на онбординг и т.п. Ну представьте, ваши топовые разработчики тратят время не на работу за которую вы можете платить им зарплату, а на ревью кода который льют ваши стажеры на испытательном. Наоборот, крупные компании не хотят и близко с этим связываться, потому что все это очень дорого. Проще оптимизировать процесс найма.
Испытательный срок это все же не инструмент при найме, это по большей части страховка от ошибок совершенных при найме. Если кандидату не продлили испытательный, то значит люди которые занимались наймом, выполнили свою работу плохо. Более того, надо учитывать время, потому что условно, если бы взяли сразу нужного кандидата то он бы принес N пользы, а если кандидату не продлили испытательный срок, то явно пользы принесено меньше чем N. И в это самое время, пока вы играетесь с испытательным сроком, ваши конкуренты нанимают нужных специалистов с первого раза.
В вашем примере с литкодом, все немного не так. Все эти алгоритмические задачи, не для того чтобы нанять человека, который постоянно будет работать с такими задачами. Все это для того чтобы отсеять большое количество кандидатов. Если взять условно двух одинаковых кандидатов, которые по всем параметрам совпадают кроме решения задач с литкода, то я бы отдал предпочтение тому из них кто все же натренировался решать такие задачи ради собеса. Ну и на сколько я помню, крупные компании собрав статистику, поняли что кандидаты умеющие решать задачи с литкода, работают лучше чем те кто не умеют.
Так это ведь не новая проблема, все это существует уже кучу времени. Тонна статей написана о том как проводить собеседование, где то вон по 5 этапов вводят и другие компании подхватывают этот карго культ. Проблема ведь в том что нет одного универсального теста, который позволит точно определить с первого раза, какой уровень кандидата. Ошибки найма стоят очень дорого, поэтому все хотят взять на работу звезду а не получить потом проблемы. Учитывая статистику по вакансиям/кандидатам вполне закономерный результат в сторону викторин и ужесточения отбора. Времена душевных бесед с просмотром гитхаба давно закончились. Им на смену пришли времена написания кода на листочках и угадывание мыслей интервьюера.
Если вы говорите про много нюансов под капотом о которых обязаны знать старшие программисты, то надо перечислить хотя бы некоторые из них. Может быть их окажется не так много, либо они будут не такими значимыми как вам кажется?
Можете привести примеры такой забагованности именно из за незнания нюансов? Может быть покрытие тестами позволит бизнесу не нести многомиллионые потери в этих случаях?
Мне кажется ваш тест ни как это не учитывает. Вы тестируете внутреннюю реализацию, проверяете что аргумент конструктора записался в длину и ширину правильно, но зачем такие тесты? Зачем тесты которые тестируют геттеры или
assertInstanceOf ?
Чтобы проверить LSP вам нужна некая 3ая функция, например calcPerimeter(Rectangle $rect): float|int; а в тесте нужно запустить ее с Rectangle и Square, и ничего не должно сломаться.
Мне нравится практика диспутов у буддистов в Тибете. После того как они поспорят, и судьи вынесут решение о том кто был убедительнее из них, участники спора меняются местами, и пытаются доказать противоположную сторону! И самые крутые из монахов могут убедительно доказывать обе стороны спора!
Аргументация должна была быть на основе плюсов и минусов микросервисной архитектуры. Какие проблемы перед нами стояли, из за которых выбор пал именно на эту архитектуру а ни на какую то другую. Тут же как в анекдоте получается, будем делать микросервисы потому что монолит у меня уже есть в резюме.
Я не эксперт конечно, но на сколько я понимаю Будда как раз и учил о том, что не верьте ни единому слову только потому что так говорил Будда. В буддизме не вкладывается столько значений в доказательство правдивости источников, как это происходит в аврамических религиях потому что конечный путь достигается при жизни а не после смерти. В них это все важно, потому что там, тексты это слова одного всемогущего, всевышнего Бога творца. Он все это устроил, на все его воля и желание, нет ничего что он не смог бы. Он передал через пророков для всего человечества эти текста с правилами! И очень важно, чтобы, то что передал такой ключевой Бог всем людям, не было искажено ни кем и никогда, потому что в конце каждого ждет страшный суд на котором Бог будет судья и судить он будет именно по правилам из этих самых переданных текстов. Важно чтобы эти источники совпадали с теми по которым будет происходить суд. В буддизме же, вы сами определяете приближает вас эти текста к пробуждению или нет. Если вы говорите о том что Будда мог в камне записать все сам как это сделал Моисей, то и аврамический Бог мог записать все это таким образом, что сомнений не останется ни у кого из живущих. На небе написать например, он же всемогущий! Так бы ни у кого из родившихся на земле вопросов не осталось есть Бог или нет? И что в буддизме, и что в а аврамических религиях, есть огромный смысл в том, что все это не было таким образом записано. У каждого начинающего последователя присутствуют сомнения в правдивости учений. Из за сомнений у них появляется потребность изучать и определять во что верить а во что нет, до такого уровня что никаких сомнений не должно оставаться! Написал бы Будда все это на камнях что не сотрешь и не исказишь, или Бог на небе, и сомнений в подделках бы не было и ни в чем разбираться не нужно. НО даже так сомнения будут остаться. А Будда ли это написал? Даже то что когда то Моисей записал заповеди на скрижалях, не привело к тому, что все люди вдруг в них поверили и стали их соблюдать. Все ровно, у людей появились сомнения которые заставляют из разбираться и решать верить или нет..
Будда же учил так что, он может показать один путь, который он лично сам прошел. И не факт что ты последуешь по нему, и достигнешь такого же результата как он. И он не утверждал что путь для всех один и только такой как он показал! Точно такой же результат можно получить другими путями. Отсюда и столько различных течений и школ в буддизме. И в каждом есть свой пример достижения того же, но каким то своим способом. Намного больше внимания уделяется учителю. Именно наставник может сократить путь и показать нужное направление. И ученики могут превосходить учителей, а некоторые учителя так и не достигнуть уровня пробуждения. При таком положении, какой смысл записанного на бумаге текста? Можно получить ситуацию, когда все читают один и тот же правильный исходный текст от Будды, следуют всему что в нем написано и при этом никто из них просветления не достигнет. В результате исходный текст будет выброшен и отмечен как нерабочий хотя он полностью правдивый! При жизни Будды по его пути прошли тысячи людей и достигли успеха, а дальше все меньше и меньше. И проблема не в текстах, а в учителе. Нету какого то одного судьи, который решает для всех что вот этот человек пробудился, а вот этот еще нет. Нет какого то одного экзамена, который гарантировано выдаст результат достигнул ты того же что и Будда или нет.
Гарантий того что какая то школа заблуждается или ошибается или намерено искажает знания нету. Их никто вам не даст. Под сомнения может будет поставить что угодно. Но сами же они конечно сомневаться не будут. Вы сами должны будете понять в ходе своего пути что приближает вас к цели а что нет. Сам Будда вон скитался от одних монахов к другим и пробовал то одни то другие практики и учения, и каждое ему обещало результат, и везде он не достиг результата и забросил все. Даже живя в Тибете и обучаясь у самого Далай Ламы, вы все ровно не сможете спросить у какого то независимого судьи, правильно ли он вас учит или нет. Это только вы сами можете понять, определить и прочувствовать, приближает ли вас это обучение к нужной цели или нет. Судья который это решает это лично вы сами и никто кроме вас.
Если наука докажет что буддизм ошибается, то буддизм должен будет изменится. Взять верные решения из науки, и применить их к себе. А если наука докажет что авраамические религии ошибаются, то они должны будут просто перестать существовать или серьезно так переобуться. Типа мы не то небо имели виду, Бог не на том небе что над нами а на каком то другом которое мы не видим!
Тимлиду лучше проводить личные беседы, потому что в них наиболее полная и правдивая обратная связь. Не скатываться в надоедливые всем опросы, а проводить все это именно как взаимовыгодный разговор. Так можно будет пользоваться различными уловками, типа например сперва похвалить сотрудника а потом задавать вопросы. Можно даже дать сотруднику обратный фидбек по результатам такой беседы. Это HR могут проводить такое через почту, на все отделы разом, а у тимлида команда в разы меньше и отношения между сотрудниками ближе.
Время этих бесед надо подбирать персонально под сотрудника. С кем то может потребоваться обсуждать все это раз в месяц, а с кем то вполне можно и раз в год. С кем то может не прокатить формат личного общения и придется просить пройти опрос в другом виде. Тут тимлиду должно быть виднее кто есть кто в его команде и к кому какой подход нужен.
Технический долг ничего не стоит именно клиенту а не владельцу продукта. Вам написали, о том что невозможно в счет клиенту написать пункт "рефакторинг". Согласитесь было бы странно, если бы вас какой то сервис, попросил заплатить им за рефакторинг?
Нужно также отличать намеренный тех долг или случайный. Есть хорошая статья по этому поводу https://habr.com/ru/companies/vk/articles/486098/ Можете дать ее почитать вашим руководителям.
Но в целом эта тема не новая и уже много много раз поднималась. Все это лечиться правильной культурой разработки. Как продавать руководству тех долг написано очень много статей. Если коротко, то нужен компромисс с двух сторон. Директор и руководители должны понять, что технический долг в итоге убьет всю компанию, а команды разработки должны понять что они не пишут код ради кода. Они пишут код который приносит деньги.
Плюс можно добавить Modulite и/или Deeptrac и все будет еще лучше и чище.
Честно сказать, из текста статьи вообще не понятно ничего. Ни одного примера нету, где мы нарушили SOLID и как мы переписали код, таким образом чтобы соблюдать SOLID. Мало примеров кода и картинок. Советы типа делать UserOrderCheckoutService, приводят к тому что появляется куча однотипных названий сервисов, и потом никто не знает какой из них использовать в той или иной ситуации.
Например что делать, если наши юзеры разбиваются еще на группы, у этих групп есть разные настройки и разные права. Получаться разработчики захотят создать UserSallerCheckoutService, UserOptovikWhithoutRuleReservCheckoutService и т.д.
Ничем не плох, это такой же инструмент. Какой выбрать решать вам. Статья ведь не про SymfonyMessenger. Тег стоит Laravel, с чего вдруг symfony стал стандартным? Можно ведь ваш комментарий перефразировать для Prooph или Tactician. А представьте каждый напишет комментарий с ссылкой на свой CommanBus инструмент?
В приведенном примере, скорее всего, начальная реализация OrderService подразумевала не просто пустой ответ, а результат работы сервиса (order_id, notification_result, shipped_result).
С переходом на асинхронные сообщения, мы также переходим и на асинхронные ответы. В случае когда формат ответа нужно сохранить, мы должны будем не переписывать старый контроллер, а добавить новый. После чего нужно ждать когда все кто использовал этот контроллер перейдут на новую асинхронную версию.
И как быть, если наши партнеры не особо то и хотят этим заниматься? Их все устраивало раньше, они отправляли запрос и получали ответ, а теперь им надо городить какие то сокеты, пинги, лонгпулинг или что то еще.
А в чем проблема переопределения стилей? Я ведь могу условно обернуть Bootstrap компонент в какой то .class-wrapper и переопределить все что внутри него через условный .class-wrapper .btn ? Более того эти библиотеки ведь дают как то настраивать тему.