Вот с этим я могу поспорить - большая часть людей в России покупает продукты и товары в магазинах.
Ну я бы сказал, что это зависит от многого. Скажем, в ковид я как раз почти не ходил по магазинам, в основном доставка. А потом наоборот, стал предпочитать посетить живьем, ибо так надоело дома сидеть. Ну да, стоимость доставки для кого-то может быть существенна - но зато ты можешь заказать килограмм 20, и тебе их принесут к двери. И у меня доставка из Ашана Сбермаркетом стоит 59 рублей - о чем тут вообще говорить при такой-то стоимости услуги? На даче в области мы вообще по магазинам не ходим, только доставка.
Я прекрасно понимаю, что так тоже бывает. Тем не менее, в нормальном месте подойти к руководителю, и мотивированно объяснить, что хочешь повышения - вполне нормальный подход. Мотивированно - очень важная вещь (хотя непосредственный руководитель обычно и так знает, кто заслуживает повышения, а кто не особо). Худшее что ты рискуешь услышать - что либо на сегодня нет денег/такой позиции, или что нужно взять на себя какие-то обязательства. По сути - это нормальные переговоры. Где-то это происходит регулярно и по плану, где-то нет.
Было бы неплохо, если бы все программисты на личном опыте понимали, зачем придуман SOLID.
Ну вот заметьте, я чуть выше ровно о том же - что автор упоминает это самое "зачем" один раз в начале, в списке из еще нескольких пунктов, а потом про него забывает напрочь. И может быть он даже знает эти самые принципы назубок - но все равно забыл об их назначении. При этом если понимать его, это назначение, ну хотя бы на уровне, как вы тут пишете:
рекомендаций/лайфхаков, как делать код гибким/понятным
Уже становится ясно, что эти рекомендации а) субъективны, потому что что одному понятно, то другому мрак и ужас б) не обязательны, потому что текущей команде и так может быть хорошо, и проблем с сопровождением и развитием у них не возникает. Не говоря уже о том, что это может быть MVP/POC, и развивать его никто не планирует вообще.
Более того, если немного подумать, то все принципы солид в общем про одно - как снизить связность разных компонент кода. Просто эта связность в каждом случае разного вида. А когда компоненты независимы - тут-то код и становится проще для понимания, и гибче.
Если один кусок кода лезет в другой, это просто невозможно тестировать
Не, ну тут обычно речь о другом. Я вот видел код, где некий коннект к базе создавался внутри определенного класса. Это зависимость. И в таком виде ее правда невозможно тестировать, потому что нельзя подсунуть классу другой коннект, он работает только с пром базой. А вот если создание зависимости вынести наружу, и сделать inject этого коннекта к базе в класс - тестирование становится возможным и достаточно удобным. Это правда про dependency inject, но суть надеюсь ясна.
А вы думаете, что авторы не пробовали эту вашу neo4j? Пробовали конечно, все что существовало на тот момент. Не устроило. Я не настолько знаком с ситуацией, чтобы детальнее комментировать, поэтому и не стану с вашего позволения.
Почему вы её ещё не продаете-то?
А зачем? Не всегда бизнес предполагает продажи на сторону. Многие внутри потребляют. Не то чтобы специально, а просто - прикиньте, насколько дороже будет разработка софта отчуждаемого по сравнению с тем, что эксплуатируется в компании, при наличии авторов в качестве третьей линии поддержки?
И потом, а кто купит-то? Вы сами сказали, что многих (как вот и вас) устраивают опенсорсные решения, а те кого не устраивают - их можно пересчитать по пальцам одной ноги. Это сотовые операторы, ВТБ, Сбер, VK, Яндекс, да пожалуй и все. Чуть больше пяти получилось. И где гарантия, что хоть кто-то купит?
В общем, я это к тому что сделать и продать успешно - это совсем не тоже самое, что успешно сделать и пользоваться.
Я именно это сразу сделал (заглянул в обе). Отсюда и комментарий, что слова про однопоточность - изобретение исключительно автора русской вики.
Совершенно не понимаю, при чем тут однопоточность. Синглтон - про гарантию единственности экземпляра чего-либо, в определенном контексте. Если в программе много потоков - им могут быть нужны как экземпляр чего-то на поток, так и общий экземпляр чего-то другого на все потоки. Обе гарантии единственности вполне имеют смысл.
Более того, скажем spring называет нечто похожее scope, и гарантирует, что некий бин существует один на приложение, один на запрос, или один на какой-то другой scope из вот такого списка:
singleton
prototype
request
session
application
websocket
Это вполне осмысленное обобщение сиглтона. А синглтон только на поток - это какое-то странное ограничение.
Ну да, эта работа единичная, ее делали может три-четыре человека. Но при этом ниоткуда не следует, что нет любой другой похожей работы, где библиотечные функции не подходят.
И не разу не видел чтобы кто-то реализовывал с нуля в проекте свою сортировку или графовый алгоритм эффективнее чем он есть в доступных библиотеках.
Ну, зависит от размеров графа. У нас тут в соседнем проекте напряглись и сделали поддержку графов размером с большую соцсеть масштабов VK например - в чем я уверен точно, так это в том, что библиотечного такого не существует.
Ну, как терпят. Я скажем перестал покупать что-либо на Озоне И Я.Маркете. Во втором случае - в первую очередь потому, что поиск полностью сломали и сделали бессмысленным. Ну т.е. вот конкретно прямо Амазон, ищу Milwaukee 18G, надеюсь найти нейлер на гвозди 18G. Нахожу, как ни странно (возможно потому что вчера уже искал), но еще нахожу кучу нерелевантных товаров. Самое безобидное - это другие товары Milwaukee, или нейлеры, но на другой гвоздь (и другой компании). Что наводит на мысль, что для их поиска один нейлер и другой нейлер таки чем-то похожи, то есть, оно "понимает", что я ищу. И сознательно подсовывает еще что-то. Мотивация мне непонятна совершенно, потому что если я ищу артикул - я очень маловероятно куплю что-то совсем другое.
Вам везет. Я даже по производителю и известному их артикулу далеко не всегда могу найти. Ну или мне приходит в голову вывод, что например из ассортимента производителя инструмента на амазоне продается процентов 20. Вот что я ну никак не могу поверить.
Да казалось бы, куда уж хуже-то? Поиск амазона и так уже такое г.
Ну вот реально, ищу я скажем ... пилу. Я знаю производителя, и его артикул, казалось бы, щас мы все найдем, ан нет. Нахожу хоть что-то от Milwau..., вижу в заголовке "Раздел производителя", ну думаю ладно, у них-то хоть свой товар весь в наличии показан? Тоже фигу. Скажем, у Milwau... есть штук 300 инструментов на их 18В платформе. А в разделе амазона у них всего штук 50 товаров. Где еще сотни наименований зарыты? Амазон их не продает? Что, серьезно?
Разумеется. Так я об этом в том числе и говорю - все что у нас есть, это результаты конкретных измерений, согласно которым Вася лучше бегает на 100 метров, чем Петя, причем он в 10 раз быстрее. Если кто-то обобщает это на марафон - разве это проблемы того, кто проводил измерение? Кто-то выяснил, что эти коэффициенты далеко не константы? Спасибо, Кэп, но я лично и так догадывался, что производительность изменчива.
Все исследования что я видел, основаны на некотором ограниченном измерении. Если мы намеряли, что Вася быстрее Пети в 10 раз - как можно из этого делать вывод, что он и завтра тоже будет быстрее, если при этом задачи изменятся? Сегодня они бежали на 100 метров, а завтра у них марафон.
Не вижу никаких причин такие исследования обобщать так сильно. Но если послезавтра нам снова бежать 100 метров - я таки поставлю Васю.
На основе исследования, приведённого ниже будет ясно, что:
только половина разницы в затратах на разработку объясняется разницей между разработчиками
вторая половина объясняется разной производительностью одного и того же разработчика на разных заданиях
Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
По сути, все что тут доказали - это то что факторов много, и повышать производительность можно по-разному. Так никто и не утверждал обратного.
А что мерять производительность сложно, и надо учиться делать это лучше - так это тоже достаточно очевидно.
Ну так я и говорю, что скорее всего тут разные есть истории. По-хорошему, надо исследовать.
Ну я бы сказал, что это зависит от многого. Скажем, в ковид я как раз почти не ходил по магазинам, в основном доставка. А потом наоборот, стал предпочитать посетить живьем, ибо так надоело дома сидеть. Ну да, стоимость доставки для кого-то может быть существенна - но зато ты можешь заказать килограмм 20, и тебе их принесут к двери. И у меня доставка из Ашана Сбермаркетом стоит 59 рублей - о чем тут вообще говорить при такой-то стоимости услуги? На даче в области мы вообще по магазинам не ходим, только доставка.
Я прекрасно понимаю, что так тоже бывает. Тем не менее, в нормальном месте подойти к руководителю, и мотивированно объяснить, что хочешь повышения - вполне нормальный подход. Мотивированно - очень важная вещь (хотя непосредственный руководитель обычно и так знает, кто заслуживает повышения, а кто не особо). Худшее что ты рискуешь услышать - что либо на сегодня нет денег/такой позиции, или что нужно взять на себя какие-то обязательства. По сути - это нормальные переговоры. Где-то это происходит регулярно и по плану, где-то нет.
Я точно так же делаю. С тем же результатом. И что характерно - я тоже техлид.
Ну вот заметьте, я чуть выше ровно о том же - что автор упоминает это самое "зачем" один раз в начале, в списке из еще нескольких пунктов, а потом про него забывает напрочь. И может быть он даже знает эти самые принципы назубок - но все равно забыл об их назначении. При этом если понимать его, это назначение, ну хотя бы на уровне, как вы тут пишете:
Уже становится ясно, что эти рекомендации а) субъективны, потому что что одному понятно, то другому мрак и ужас б) не обязательны, потому что текущей команде и так может быть хорошо, и проблем с сопровождением и развитием у них не возникает. Не говоря уже о том, что это может быть MVP/POC, и развивать его никто не планирует вообще.
Более того, если немного подумать, то все принципы солид в общем про одно - как снизить связность разных компонент кода. Просто эта связность в каждом случае разного вида. А когда компоненты независимы - тут-то код и становится проще для понимания, и гибче.
Не, ну тут обычно речь о другом. Я вот видел код, где некий коннект к базе создавался внутри определенного класса. Это зависимость. И в таком виде ее правда невозможно тестировать, потому что нельзя подсунуть классу другой коннект, он работает только с пром базой. А вот если создание зависимости вынести наружу, и сделать inject этого коннекта к базе в класс - тестирование становится возможным и достаточно удобным. Это правда про dependency inject, но суть надеюсь ясна.
Ну вот почему каждый первый автор, кто пытается писать про SOLID, при этом умудряется даже не упомянуть то, для чего эти принципы нужны?
Ведь из этого очевидно следует все остальное. Ну или почти все.
Вот и тут. Куча слов - и ни одного упоминания назначения принципов.
А вы думаете, что авторы не пробовали эту вашу neo4j? Пробовали конечно, все что существовало на тот момент. Не устроило. Я не настолько знаком с ситуацией, чтобы детальнее комментировать, поэтому и не стану с вашего позволения.
А зачем? Не всегда бизнес предполагает продажи на сторону. Многие внутри потребляют. Не то чтобы специально, а просто - прикиньте, насколько дороже будет разработка софта отчуждаемого по сравнению с тем, что эксплуатируется в компании, при наличии авторов в качестве третьей линии поддержки?
И потом, а кто купит-то? Вы сами сказали, что многих (как вот и вас) устраивают опенсорсные решения, а те кого не устраивают - их можно пересчитать по пальцам одной ноги. Это сотовые операторы, ВТБ, Сбер, VK, Яндекс, да пожалуй и все. Чуть больше пяти получилось. И где гарантия, что хоть кто-то купит?
В общем, я это к тому что сделать и продать успешно - это совсем не тоже самое, что успешно сделать и пользоваться.
Я именно это сразу сделал (заглянул в обе). Отсюда и комментарий, что слова про однопоточность - изобретение исключительно автора русской вики.
Совершенно не понимаю, при чем тут однопоточность. Синглтон - про гарантию единственности экземпляра чего-либо, в определенном контексте. Если в программе много потоков - им могут быть нужны как экземпляр чего-то на поток, так и общий экземпляр чего-то другого на все потоки. Обе гарантии единственности вполне имеют смысл.
Более того, скажем spring называет нечто похожее scope, и гарантирует, что некий бин существует один на приложение, один на запрос, или один на какой-то другой scope из вот такого списка:
singleton
prototype
request
session
application
websocket
Это вполне осмысленное обобщение сиглтона. А синглтон только на поток - это какое-то странное ограничение.
Если вы посмотрите еще раз, то в английской вики ничего нет про однопоточность.
Заранее конечно нет, но некоторая базовая подготовка как правило сильно сокращает сроки оного РНД.
Ну да, эта работа единичная, ее делали может три-четыре человека. Но при этом ниоткуда не следует, что нет любой другой похожей работы, где библиотечные функции не подходят.
Ну, зависит от размеров графа. У нас тут в соседнем проекте напряглись и сделали поддержку графов размером с большую соцсеть масштабов VK например - в чем я уверен точно, так это в том, что библиотечного такого не существует.
Ну... с другой стороны, есть такой "анекдот" - никто так невосприимчив к рекламе, как мужчина со списком покупок :)
Ну, как терпят. Я скажем перестал покупать что-либо на Озоне И Я.Маркете. Во втором случае - в первую очередь потому, что поиск полностью сломали и сделали бессмысленным. Ну т.е. вот конкретно прямо Амазон, ищу Milwaukee 18G, надеюсь найти нейлер на гвозди 18G. Нахожу, как ни странно (возможно потому что вчера уже искал), но еще нахожу кучу нерелевантных товаров. Самое безобидное - это другие товары Milwaukee, или нейлеры, но на другой гвоздь (и другой компании). Что наводит на мысль, что для их поиска один нейлер и другой нейлер таки чем-то похожи, то есть, оно "понимает", что я ищу. И сознательно подсовывает еще что-то. Мотивация мне непонятна совершенно, потому что если я ищу артикул - я очень маловероятно куплю что-то совсем другое.
Вам везет. Я даже по производителю и известному их артикулу далеко не всегда могу найти. Ну или мне приходит в голову вывод, что например из ассортимента производителя инструмента на амазоне продается процентов 20. Вот что я ну никак не могу поверить.
Да казалось бы, куда уж хуже-то? Поиск амазона и так уже такое г.
Ну вот реально, ищу я скажем ... пилу. Я знаю производителя, и его артикул, казалось бы, щас мы все найдем, ан нет. Нахожу хоть что-то от Milwau..., вижу в заголовке "Раздел производителя", ну думаю ладно, у них-то хоть свой товар весь в наличии показан? Тоже фигу. Скажем, у Milwau... есть штук 300 инструментов на их 18В платформе. А в разделе амазона у них всего штук 50 товаров. Где еще сотни наименований зарыты? Амазон их не продает? Что, серьезно?
Разумеется. Так я об этом в том числе и говорю - все что у нас есть, это результаты конкретных измерений, согласно которым Вася лучше бегает на 100 метров, чем Петя, причем он в 10 раз быстрее. Если кто-то обобщает это на марафон - разве это проблемы того, кто проводил измерение? Кто-то выяснил, что эти коэффициенты далеко не константы? Спасибо, Кэп, но я лично и так догадывался, что производительность изменчива.
Не-не. Не бежать - а бежать 100 метров! Это большая разница! Марафон побежит Витя :)
Все исследования что я видел, основаны на некотором ограниченном измерении. Если мы намеряли, что Вася быстрее Пети в 10 раз - как можно из этого делать вывод, что он и завтра тоже будет быстрее, если при этом задачи изменятся? Сегодня они бежали на 100 метров, а завтра у них марафон.
Не вижу никаких причин такие исследования обобщать так сильно. Но если послезавтра нам снова бежать 100 метров - я таки поставлю Васю.
Пардон, но это никаким образом не развенчивает "миф" о том, что производительность разработчиков таки бывает сильно разная. Потому что половина разницы тоже может быть очень большой.
А во втором случае, производительность опытного разработчика, который уже делал похожую задачу, может быть просто на несколько порядков выше производительности того, кто никогда с подобным не сталкивался.
По сути, все что тут доказали - это то что факторов много, и повышать производительность можно по-разному. Так никто и не утверждал обратного.
А что мерять производительность сложно, и надо учиться делать это лучше - так это тоже достаточно очевидно.