Ученики послабее записывали решение по шагам и тратили существенно больше времени.
Нам, отличникам, всё это ни к чему. Зачем писать столько ненужных промежуточных действий, когда можно сразу готовый ответ? Мы же хотим поскорее разделаться с этим примером, чтобы перейти к следующему!
Гипотеза. Чем умнее программист (чем более объёмной рабочей памятью он располагает), тем более длинные методы и функции он пишет.
Какой-то странный для меня вывод.
Имхо как раз логичнее будет что троечник привыкнув расписывать все по шагам будет так же писать длинные методы. К тому же писать код в одном большом методе на много проще чем разбивать его на меньшие.
Троечнику сложнее думать абстрактно чем отличнику, а что бы писать короткие методы надо держать в голове код других методов вынесенных из текущего, а в идеале держать в голове весь код, что бы повторно использовать уже существующий код.
А портянки можно писать особо не запоминая даже что делалось на 10 строк выше.
Ну уменьшите количество строк до 500, вероятность того что изменения запрошены от одной роли будут намного выше.
Если вы пишете обычно, значит описанная мной ситуация возможна.
Так все же такой метод соответствует SRP?
SRP: The Single Responsibility Principle
В этом принципе речь идет о том, что изменения в модуле может запрашивать одна и только одна роль. Например, есть модуль, реализующий некую бизнес-логику, запросить изменения в этом модуле может только Аналитик, но никак не DBA или UX.
То есть если метод состоит из 3k+ строк он соответствует этому принципу главное что бы изменения запрашивались от одной роли?
OCP: The Open Closed Principle
…
Используя dependency inversion, наш модуль объявляет только интерфейс отправки уведомлений, но не реализацию.
Зачем же тогда отдельно выделены dependency inversion principle?
Да, о последних тенденциях в вузах не рассказывают
Но если вуз нормальный там можно получить вполне хорошую базу
Для веб разработчика, как минимум, это — протоколы, работа браузера, основы баз данных
Дело в том, что наука программирования постоянно развивается и итерируется, а значит старые методы мы смело забываем и осваиваем новые.
Имхо лучше поизучать написанное давным давно Фаулером, Макконнеллом, бандой четырех и писать нормальный код чем говнокодить в соответствии с новыми веяниями.
Интересно как безусловный доход соотносится с постоянным повышением пенсионного возраста в богатых странах.
Уже сейчас большое количество пенсионеров во многих странах становится важной проблемой, что будет если к ним еще прибавят людей получающий безусловный доход?
Как правило, информацию о развитии проекта можно выбить из определенных людей :) А вот время вернуть сложно. В любом случае можно организовывать митинг в формате «сейчас новая инфа: бла-бла-бла. А теперь остаются те, кто не в курсе последних событий».
Еще бы знать заранее нужна тебе эта информация или нет.
А может наоборот не тебе что то полезное сообщат, а ты чью то глобальную проблему решишь.
Я понял что вы хотели сказать в статье.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Но все же не все митинги бывают полезными.
Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.
Они заставляли меня ходить на митинги полные пустых разговоров.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше. Опять же это полезный опыт.
Что то я когда сталкивался с инициативами руководства по внедрению «самоорганизованных команд» это было связано с неумением руководства управлять сотрудниками и фактически выливалось в перекладывание всей ответственности на исполнителей.
При прочих равных невыгодны выигрывать в продажах, снижая маржинальность. Рано или поздно кто-то опустится ниже вас по цене и ваши покупатели уйдут туда
Другой момент, если у вас есть удобное постгарантийное обслуживание, доставка товаров на заказ, другие какие-то конкурентные преимущества. .
Это понятно, но если по другим параметрам конкурировать не получается, условия доставки у всех одинаковые, с гарантией тоже у всех все нормально, приходится конкурировать ценой.
Тем более для большинства людей цена это главный критерий при покупке.
Какой-то странный для меня вывод.
Имхо как раз логичнее будет что троечник привыкнув расписывать все по шагам будет так же писать длинные методы. К тому же писать код в одном большом методе на много проще чем разбивать его на меньшие.
Троечнику сложнее думать абстрактно чем отличнику, а что бы писать короткие методы надо держать в голове код других методов вынесенных из текущего, а в идеале держать в голове весь код, что бы повторно использовать уже существующий код.
А портянки можно писать особо не запоминая даже что делалось на 10 строк выше.
Ответ на критерий по которому автор определяет соответствие кода принципу SRP я дал.
Если вы пишете обычно, значит описанная мной ситуация возможна.
Так все же такой метод соответствует SRP?
Зачем же тогда отдельно выделены dependency inversion principle?
Но если вуз нормальный там можно получить вполне хорошую базу
Для веб разработчика, как минимум, это — протоколы, работа браузера, основы баз данных
Имхо лучше поизучать написанное давным давно Фаулером, Макконнеллом, бандой четырех и писать нормальный код чем говнокодить в соответствии с новыми веяниями.
Уже сейчас большое количество пенсионеров во многих странах становится важной проблемой, что будет если к ним еще прибавят людей получающий безусловный доход?
Мое видение меньше кормить — это набрать в проект junior менеджеров и программистов а ждать от них результата как от топовой команды сеньоров.
Еще бы знать заранее нужна тебе эта информация или нет.
А может наоборот не тебе что то полезное сообщат, а ты чью то глобальную проблему решишь.
Просто меня удивляет общая тенденция, да и практика тоже, что программистам митинги не нужны, потому я и выделил вашу строку.
Это да. Но как по мне нельзя однозначно сказать что хуже — потерянное время на прослушивание уже известных вещей или отсутствие информации о развитии проекта.
Не понимаю почему считается что разработчику ненужно участвовать в митингах.
Без них у него не будет представления о развитии проекта, какой должен быть конечный результат, не получиться по максимуму использовать опыт разработчиков, может с текущими проблемами кто то уже сталкивался раньше. Опять же это полезный опыт.
Негативные отзывы есть у всех есть, их количество скорее от величины фирмы зависит
Тем более для большинства людей цена это главный критерий при покупке.