Статья, мне кажется, немного не соответствует заголовку. В ней как будто есть подтекст: говорится об абстрактных проблемах, но в основном - о том, что разработчик должен уметь адаптироваться и иногда брать на себя функции менеджера. Мультиплатформенность - это хорошо, но важно глубоко знать платформенное API. Здесь есть классическое противоречие. Создается ощущение, что между строк звучит мысль: "Быть программистом-арестром это хорошо". Но вот проблема: такой разработчик вряд ли сможет в совершенстве овладеть конкретной технологией.
Велосипеды изобретать будут всегда. Некоторые библиотеки забрасываются, быстро устаревают, а найти им надежную замену не всегда получается. Вот и приходится писать свое решение.
Я прошу прощения конечно, лично на вас я не гоню, просто на хабре стал замечать много статей, где пытаются поносить ООП в пользу фукционала. И данная статья мне опять показалась такой же. Лично мне кажется, что новочки(это не про вас) ошибочно думают, что функционал проще, так как там не надо изучать всякие SOLID и прочее. Плюс на собесах часто стали про эту хрень спрашивать и это конечно всех бесит. Поэтому и проще топить за функционал. Но лично я считаю это все это ошибки новичков. ООП не так сложно понять, надо просто покатать на нем пару лет плотно, на разных задачах, и еще лучше если в самом начале начать изучение именно с функуиональных языков, а потом плавно катать на ООП языках, что бы понять плюсы ООП.
PS. SOLID, по моему, вообще мало кто практикует на полную, но как буд-то по ошибке выжевшего, в блогах видно только тех людей, кто пишет про с SOLID.
Ребята, одержимые функциональщиной опять пытаются доказать, что лесенки и индуский код это лучше чем код разложенный по полочкам и переиспользуемый, за счет ооп?
В идеальном мире вы клепаете блоги и точно можете дать оценку. Но в реале, на больших проектах, при нехватке разработчиков, вы будете выполнять параллельно несколько задачи да еще и на тех проектах с которыми вы плохо знакомы. Если вы реально можете сказать точно оценку, то вы Ванга
Что бы иметь представление что есть в rails и чего нет в Java наверное надо получить не маленький опыт на Rails и Java Spring что бы сравнивать. Но в rails из коробки идет очень много простых инструментов разработки. Например система миграций в Rails, простая и понятная, легко накатить и откатить в БД изменения. Система роутов очень простая и понятная. Архитектура Rails построена так, что приложения делаются простыми и понятными. Rails очень простой и подходит для разных проектов и он подходит для маленьких организаций, потому что все приложение rails может тянуть один разработчик. Я не знаю как объяснить, что Rails это самый простой из всех инструментов что я видел для разработки веб-приложений. Пока вы сами не попробуете поиметь на нем опыт около года, то на вряд ли поймете. Либо нужна очень длинная статья об этом.
Одни говорят что надо учить и совершенствоваться в одном языке, другие что надо учить все языки. Я согласен с первыми, потому что если учить много языков, то высокого уровня знаний технологий и самих языков не достичь и эффективность такого программиста будет очень низкой, да и до кучи ведет к выгоранию. По мимо языков нужно к ним учить их экосистемы, языки в основном сами по себе не сложные. Но обстоятельства вынуждают учить много языков, потому что компании "ресктруктурируются" и требуют, что бы сотрудник брал на себя больше задач и других технологий. Что бы сотрудник замещал собой целый оркестр. Это тупой но дешевый подход. В этом ничего хорошего нет.
Просто храню там свой код, всякий. время флешек и компакт дисков прошло. Просто одни говорят что там должна быть красота, это дело каждого. Но с другой стороны, там можно увидеть историю развития навыков.
Что бы сохранялась мотивация студента, нужны условия которые не ведут к выгораниям.
Про возраст, чем человек дольше имеет опыт тем лучше его интуиция в своей области.
Молодые могут на зубок знать алгоритмы и тп, но их энтузиазм приводит к тому, что они заливают проект разными не нужными модными технологиями, которые потом не кому поддерживать.
Почему тут сравнивают со странами экономика которых сильно впереди Российской, кроме одной Индии? Сравнивать надо со странами СНГ и Восточной Европы, типа Польши и т.д. Тогда было бы честно.
Есть такое слово "единодушный". Это почти тоже что и "единогласный" или "общий". Так почему же "единоответствие" не должно означать общую ответственность?
А, вы не ошиблись со словом "единоответствие"? Первая часть слова, видимо, образована от слова "Единый", то есть общий, общая ответственность? Это как раз противоречит первому принципу единственной ответственности. Да и слова такого в русском языке вроде бы нет.
На мой взгляд, Rails до сих пор останется лучшим и удобным средством разработки веб приложений. Так как предоставляет очень много удобных и быстро осваиваемых инструментов.
А как трудная задача может быть халявной?
Статья, мне кажется, немного не соответствует заголовку.
В ней как будто есть подтекст: говорится об абстрактных проблемах, но в основном - о том, что разработчик должен уметь адаптироваться и иногда брать на себя функции менеджера. Мультиплатформенность - это хорошо, но важно глубоко знать платформенное API.
Здесь есть классическое противоречие. Создается ощущение, что между строк звучит мысль: "Быть программистом-арестром это хорошо".
Но вот проблема: такой разработчик вряд ли сможет в совершенстве овладеть конкретной технологией.
Велосипеды изобретать будут всегда. Некоторые библиотеки забрасываются, быстро устаревают, а найти им надежную замену не всегда получается. Вот и приходится писать свое решение.
Я прошу прощения конечно, лично на вас я не гоню, просто на хабре стал замечать много статей, где пытаются поносить ООП в пользу фукционала. И данная статья мне опять показалась такой же.
Лично мне кажется, что новочки(это не про вас) ошибочно думают, что функционал проще, так как там не надо изучать всякие SOLID и прочее.
Плюс на собесах часто стали про эту хрень спрашивать и это конечно всех бесит.
Поэтому и проще топить за функционал.
Но лично я считаю это все это ошибки новичков. ООП не так сложно понять, надо просто покатать на нем пару лет плотно, на разных задачах, и еще лучше если в самом начале начать изучение именно с функуиональных языков, а потом плавно катать на ООП языках, что бы понять плюсы ООП.
PS.
SOLID, по моему, вообще мало кто практикует на полную, но как буд-то по ошибке выжевшего, в блогах видно только тех людей, кто пишет про с SOLID.
Ребята, одержимые функциональщиной опять пытаются доказать, что лесенки и индуский код это лучше чем код разложенный по полочкам и переиспользуемый, за счет ооп?
В идеальном мире вы клепаете блоги и точно можете дать оценку. Но в реале, на больших проектах, при нехватке разработчиков, вы будете выполнять параллельно несколько задачи да еще и на тех проектах с которыми вы плохо знакомы. Если вы реально можете сказать точно оценку, то вы Ванга
Что бы иметь представление что есть в rails и чего нет в Java наверное надо получить не маленький опыт на Rails и Java Spring что бы сравнивать.
Но в rails из коробки идет очень много простых инструментов разработки.
Например система миграций в Rails, простая и понятная, легко накатить и откатить в БД изменения. Система роутов очень простая и понятная.
Архитектура Rails построена так, что приложения делаются простыми и понятными.
Rails очень простой и подходит для разных проектов и он подходит для маленьких организаций, потому что все приложение rails может тянуть один разработчик.
Я не знаю как объяснить, что Rails это самый простой из всех инструментов что я видел для разработки веб-приложений.
Пока вы сами не попробуете поиметь на нем опыт около года, то на вряд ли поймете.
Либо нужна очень длинная статья об этом.
Одни говорят что надо учить и совершенствоваться в одном языке, другие что надо учить все языки.
Я согласен с первыми, потому что если учить много языков, то высокого уровня знаний технологий и самих языков не достичь и эффективность такого программиста будет очень низкой, да и до кучи ведет к выгоранию.
По мимо языков нужно к ним учить их экосистемы, языки в основном сами по себе не сложные.
Но обстоятельства вынуждают учить много языков, потому что компании "ресктруктурируются" и требуют, что бы сотрудник брал на себя больше задач и других технологий.
Что бы сотрудник замещал собой целый оркестр. Это тупой но дешевый подход.
В этом ничего хорошего нет.
Теперь появятся курсы подготовки по прохождению сертификации ИТшников на госуслугах.
Просто храню там свой код, всякий. время флешек и компакт дисков прошло. Просто одни говорят что там должна быть красота, это дело каждого. Но с другой стороны, там можно увидеть историю развития навыков.
Это больше похоже на точечный удар по ИТ сектору в стране, который усугубит ситуацию.
Контора по типу «Рога и копыта» по американски.
А, почему надо делать имитацию поверх? Даже без SwiftUI можно рисовать сразу все что угодно и с анимациями. То есть зачем вам невидимый прогрессБар?
Что бы сохранялась мотивация студента, нужны условия которые не ведут к выгораниям.
Про возраст, чем человек дольше имеет опыт тем лучше его интуиция в своей области.
Молодые могут на зубок знать алгоритмы и тп, но их энтузиазм приводит к тому, что они заливают проект разными не нужными модными технологиями, которые потом не кому поддерживать.
Они еще блокируют доступ к своим библиотекам и плагинам.
Почему тут сравнивают со странами экономика которых сильно впереди Российской, кроме одной Индии? Сравнивать надо со странами СНГ и Восточной Европы, типа Польши и т.д. Тогда было бы честно.
Можно еще чуть-чуть подсахорить пронумерованным параметром "_1":
Они думают что специалисты растут на деревьях.
Есть такое слово "единодушный". Это почти тоже что и "единогласный" или "общий".
Так почему же "единоответствие" не должно означать общую ответственность?
А, вы не ошиблись со словом "единоответствие"? Первая часть слова, видимо, образована от слова "Единый", то есть общий, общая ответственность? Это как раз противоречит первому принципу единственной ответственности. Да и слова такого в русском языке вроде бы нет.
На мой взгляд, Rails до сих пор останется лучшим и удобным средством разработки веб приложений. Так как предоставляет очень много удобных и быстро осваиваемых инструментов.