Я бы сказал это не плохой работник, а джун. Джун прибегает постоянно с уточняющими вопросами, а более опытный человек делает сам в силу своей экспертизы. Когда я даю задачу, особенно объемную, я хочу чтобы разработчик сам додумал все детали, проанализировал и выбрал наилучший вариант в силу своего опыта и экспертизы. А уточнять каждую деталь - это какой-то микроменеджмент
Такие вопросы надо ПМам задавать, и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным. И если ПМ написал просто тикет: "нарисуй домик", такой тикет просто не должен пройти.
Если же в тикете будет написано: "Поскольку мы заметили, что в Арктике в последнее время недостаток домов для слепых жирафов, надо нарисовать домик - жилмассив в 20 этажей - возле дома маленький ледовый парк.". И вопросов ни у кого не будет, а все технические детали разработчик знает и сам
Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа. А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?
Также можно ответить на вопрос "почему integer, а не string": дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают - это удобство чтения таких данных в одной конкретной таблице без использования SQL запросов с применением JOIN функций.
Не стоит недооценивать удобство чтения.
У int есть один недостаток, через n лет красивый int enum превратится в: enum StatusEnum: int { case New = 0; case Legacy = 1; case Done = 2; case Failed = 3; case Deleted = 4;
Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal
противоречит
Можем ли мы удалить startup.cs и объединить все в один класс с Program.cs?
Ответ: Да,
На самом деле, нам достаточно определить Configure и ConfigureServices. Например:
Потому что, это естественная потребность. Самые дорогие и восстребованные проститутки - это те, которые приятны в общении, могут поддержать разговор. Можно почитать, например, отзывы на их сайтах.
Самый пик мастерства у них, это когда клиент как-будто пришел к старой знакомой, они хорошо провели время и нет ощущения, что побывал у проститутки. И физический контакт в нем вообще не главное
Смысл этого предложения несколько кривой, наверное ты подразумевал «иметь одну ответственность».
Uncle Bob настаивает именно на этом определении: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Если функция выполняет «А», то причина изменения может быть, то что бизнес требование «А» поменялось. Если есть другая бизнес задача «Б» , которая по совпадению имеет такой же код как и «А», то, согласно принципу они должны лежать в разных местах, и если требование к «А» (но не «Б») поменялись, то можно без проблем поменять код в одном месте
Ну понятно, в программировании вообще нет абсолютных правил, только гайдлайны.
Когда мы выносим в одну функцию код, который не связан логикой мы нарушаем Single Responsibility Principle: каждый класс должен иметь только одну причину для изменения. Все дальнейшие проблемы от этого
Когда читал статью думал, что это сарказм -- "вредные советы" для "эффективных" менеджеров. Прочитав комментарии, понял, что я единственный так подумал
Я бы сказал это не плохой работник, а джун. Джун прибегает постоянно с уточняющими вопросами, а более опытный человек делает сам в силу своей экспертизы.
Когда я даю задачу, особенно объемную, я хочу чтобы разработчик сам додумал все детали, проанализировал и выбрал наилучший вариант в силу своего опыта и экспертизы. А уточнять каждую деталь - это какой-то микроменеджмент
Такие вопросы надо ПМам задавать, и опытный ПМ уже знает, что если в тикете написано: "нарисуй домик", разработчик нарисует так, как представляется ему наиболее правильным.
И если ПМ написал просто тикет: "нарисуй домик", такой тикет просто не должен пройти.
Если же в тикете будет написано: "Поскольку мы заметили, что в Арктике в последнее время недостаток домов для слепых жирафов, надо нарисовать домик
- жилмассив в 20 этажей
- возле дома маленький ледовый парк.". И вопросов ни у кого не будет, а все технические детали разработчик знает и сам
Никогда не понимал смысла таких вопросов на собеседовании, если компания занимается недвижимостью для слепых жирафов, и человеку говорят "Нарисуйте домик", нормальный работник нарисует домик для слепого жирафа.
А они хотят нанять человека, который соберет 20 митингов, где будет уточнять для слона нужен домик или для жирафа?
То есть надо покупать и электронную и аудиокнигу?
Я думаю, это проблемы переходного периода. В будущем уже будут ИИ-звезды, защищенные копирайтом, а фильмы с реальными актерами будут нишей хипстеров
Не стоит недооценивать удобство чтения.
У int есть один недостаток, через n лет красивый int enum превратится в:
enum StatusEnum: int{
case New = 0;
case Legacy = 1;
case Done = 2;
case Failed = 3;
case Deleted = 4;
case NewStatus = 376;case AnotherNewStatus = 378;}
Не понятно почему Visual studio и VsCode вместе, между ними столько же общего как у java с javascript
противоречит
На самом деле, нам достаточно определить Configure и ConfigureServices. Например:
Потому что, это естественная потребность. Самые дорогие и восстребованные проститутки - это те, которые приятны в общении, могут поддержать разговор. Можно почитать, например, отзывы на их сайтах.
Самый пик мастерства у них, это когда клиент как-будто пришел к старой знакомой, они хорошо провели время и нет ощущения, что побывал у проститутки. И физический контакт в нем вообще не главное
А что не так с мигрантами?
Uncle Bob настаивает именно на этом определении: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Если функция выполняет «А», то причина изменения может быть, то что бизнес требование «А» поменялось. Если есть другая бизнес задача «Б» , которая по совпадению имеет такой же код как и «А», то, согласно принципу они должны лежать в разных местах, и если требование к «А» (но не «Б») поменялись, то можно без проблем поменять код в одном месте
https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Ну понятно, в программировании вообще нет абсолютных правил, только гайдлайны.
Когда мы выносим в одну функцию код, который не связан логикой мы нарушаем Single Responsibility Principle: каждый класс должен иметь только одну причину для изменения. Все дальнейшие проблемы от этого
Вот она причина, повторяется она по чистому совпадению. Если нельзя разбить на логические утилитнные функции, я всегда против переиспользования
Давайте посмотрим на автора вопроса. Он находится в Израиле, может позволить себе не работать 1.5 года, не имеет обязательств.
Такие стартовые условия мало у кого есть, и когда он добьется успеха, можно будет сказать: "Это все удача"
По закону больших чисел, такие "удачи" приходят к каждому, просто кто-то использует ее, а кто-то нет
А если автор письма устроится на работу, он также будет писать кому-нибудь из stackoverflow, с советом не попадаться на глаза?
Я думал как раз преимущество более старших работников в готовности брать на себя
отвественность.
Когда читал статью думал, что это сарказм -- "вредные советы" для "эффективных" менеджеров. Прочитав комментарии, понял, что я единственный так подумал
github.com/serilog/serilog-sinks-elasticsearch