Изучаю язык. Допустим, в учебнике или курсе есть задача, не важно какая, её нужно реализовать в коде. Вот я разбил её на несколько маленьких, может даже написал какие-то отдельные паттерны, а вместе их все соединить не получается.
Наверно, каждый начинающий программист с этим сталкивался. Можно конечно посмотреть готовые решения таких задач, но это не даст понимания и совершенно не запомнится. Или главное не стопориться, подсмотреть готовый ответ, а потом само как-нибудь приложится? Прошу вашего совета, сеньоры, и джуниоры)
Другие языки программирования и технологии
Вопрос программистам. Умение решать задачи.
Поясню общее недоумение, выраженное в ответах: у программистов, подобных проблем не возникает - так как подзадачи едины с задачей (одна и та же сущность в разном масштабе, при разном "зуме"), и взаимосвязи логических компонентов формируются естественным путем при topdown-проектировании. Проще говоря, не приходится об этих взаимосвязях думать, ведь они уже есть - натурально сформированы сами собой.
Наличие проблемы показывает ошибку в подходе к проектированию (или даже полное отсутствие осмысленного подхода). То есть, деятельность "непрограммистская", и от этого беда. Пофиксишь это - пофиксишь проблему, как следствие.
Для понимания сути, приведу аналогию из другой области: если начать рисовать портрет с черт лица, каждая из них будет "сама по себе" и неизбежно возникнет искажение пропорций из-за отсутствия связности - а если сначала наметить общую форму головы с планами (плоскостями) и уровнями расположения черт, двигаясь от больших деталей к малым, то все будет ок.
В программинге то же самое: сначала общее, затем частное. Подход "нафигачить утилити кода и сшивать его", не программерский - это быдлкодингом попахивает, сорри. Переиспользование кода достигается иначе, а именно либо подключаемыми модулями (зависимостями), либо сниппетами... из-за их малой отвественности, они просто не могут быть первичными сущностями в разработке. Первична всегда архитектура решения, общая логика, каркас.
Наличие проблемы показывает ошибку в подходе к проектированию (или даже полное отсутствие осмысленного подхода). То есть, деятельность "непрограммистская", и от этого беда. Пофиксишь это - пофиксишь проблему, как следствие.
Для понимания сути, приведу аналогию из другой области: если начать рисовать портрет с черт лица, каждая из них будет "сама по себе" и неизбежно возникнет искажение пропорций из-за отсутствия связности - а если сначала наметить общую форму головы с планами (плоскостями) и уровнями расположения черт, двигаясь от больших деталей к малым, то все будет ок.
В программинге то же самое: сначала общее, затем частное. Подход "нафигачить утилити кода и сшивать его", не программерский - это быдлкодингом попахивает, сорри. Переиспользование кода достигается иначе, а именно либо подключаемыми модулями (зависимостями), либо сниппетами... из-за их малой отвественности, они просто не могут быть первичными сущностями в разработке. Первична всегда архитектура решения, общая логика, каркас.
Паттерны? Сколько лет работаю - ни одного готового не знаю
Не с того края подходишь к задаче. Никаких готовых решений заучивать не надо. Задача разбивается не на "паттерны", а на собственные подзадачи, всегда разные
Не с того края подходишь к задаче. Никаких готовых решений заучивать не надо. Задача разбивается не на "паттерны", а на собственные подзадачи, всегда разные
Иван Большоков
Я это и имел в виду
Канат Камзин
Паттерны можно использовать и не зная об этом (изобретая велосипед) - и это норм... но по сравнению с отточенными типовыми решениями, контрпродуктивно.
Не очень понял, каким образом ты смог их разбить на подзадачи, если потом собрать не можешь.
Иван Большоков
Как как, ломать не строить. Проблема собрать чисто механическая, ну или синтаксическая, в данном случае
Будто математику все с нуля изобретают)) В школе и вузе нам тоже дают кучу готовых решений и формул, на которых построена вся учеба. Другое дело, что все по разному воспринимают поданный материал... Не вижу ничего страшного, чтобы подсматривать чужие решения и учиться на них.
P.s. и всё же, какая задача была?))
P.s. и всё же, какая задача была?))
Иван Большоков
Во вложенных циклах запутался, уже неважно... я только неделю как начал изучать js. Кстати, мне очень нравятся ваши ответы, всегда чётко, без воды.
Изучай похожие алгоритмы и хорошо высыпайся. Поверь, мозг в конце концов даст ответ .
Иван Большоков
Где их изучать?
Похожие вопросы
- Если человеку было сложно решать задачи по математике, то как это может отразиться на работе программиста?
- Как вы решаете задачи?
- Почему для программиста который решает прикладные задачи нужна физика?
- Как научиться решать задачи по программированию?
- программисты помогите срочно задача на Delphi
- Несколько вопросов программистам по поводу устройства на работу. Вспомните, как вы впервые устраивались...
- Вопрос программистам со стажем. Какой язык программирования учить начинающему программисту?
- Вопрос программистам
- Помогите до решать задачу на паскале
- Как решать задачи по VBA
Когда хочется выпить чая, мы же не глотаем напрямую из чайника кипяток, и затем берем пустую кружку, болтаем в ней ложкой и бросаем внутрь пакетик - это лишено смысла. Но почему-то именно такая логика у некоторых в контексте разработки: действия беспорядочны, и когда из-за этого возникает логическая ошибка (выпит кипяток из чайника), причину ищут в коде (наверное, пакетик чая работает неправильно, или кружка не того цвета).