Как вы подходите к решению новых для вас задач

Вопрос имеет с одной стороны косвенное, а с другой прямое отношение к программированию и языку С++. Задаю данный вопрос в данном разделе потому как сам пишу на языке С++ и соответственно интересно мнение людей которые пишут на этом же ЯП.

Иногда встречаются задачи решение которых не то чтобы нетривиально, просто никогда раньше не сталкивался с подобным. Возникает вопрос подхода к решению подобных задач именно в программировании. Стоит ли сидеть скажем 2 (и то не факт что два) дня в попытках реализовать что-то, или же, если есть возможность, подсмотреть решение, разобрать и затем попробовать реализовать то что в примере?

Кто как поступает в данных ситуациях? После того как разобрали какое-то решение, переписываете ли вы его с примера, или же составляете план и затем пробуете реализовать собственными силами, в общем говоря, как вы его запоминаете?

0

Сообщение от Ryuk Иногда встречаются задачи решение которых не то чтобы нетривиально, просто никогда раньше не сталкивался с подобным. Стоит ли сидеть скажем 2 (и то не факт что два) дня в попытках реализовать что-то, или же, если есть возможность, подсмотреть решение, разобрать и затем попробовать реализовать то что в примере?

Никакого кодинга.
Разбираться до упора в новой предметной области, изучать материал, посвященный этому (статьи, книги, мануалы), разговаривать, если доступны, со специалистами. И только потом (возможно спустя несколько месяцев), после того, как все понятно, приступать к проектированию архитектуры, а затем к кодированию.

Решение не надо запоминать, его надо понять. Вообще, я убежден, что программист, занимающийся разработками в определенной предметной области, должен разбираться в ней чуть хуже, чем средний специалист с соответствующим образованием. Иначе неизменно на выходе будет в разной степени "не то", в зависимости от распространенности готовых программных решений. Бывает такие сферы науки и техники, где вообще нет ничего готового в части программной автоматизации. Неоткуда взять реализацию на языке программирования, и подглядеть там что-то. И здесь путь один - знать и понимать что нужно сделать, а без изучения предметной области на должном уровне этого не достичь.

8

Сообщение от DrOffset Неоткуда взять реализацию на языке программирования, и подглядеть там что-то.

Я имел ввиду что если есть некая академическая задача, приближенная к реальной, и ее решение можно подсмотреть.

0

Сообщение от Ryuk Я имел ввиду что если есть некая академическая задача, приближенная к реальной, и ее решение можно подсмотреть.

Конечно, если есть доступ к готовым решениям, их можно изучить. Но в любом случае, чтобы изучить что-то готовое, нужно уже иметь представление, что нужно сделать. Иначе получится вариант "испорченного телефона", когда один программист, скажем, на определенную долю освоил предметную область и написал реализацию, затем другой программист, еще менее знакомый с ней "подсмотрел". Через пару-тройку таких подходов, можно получить совершенно не то. Поэтому, если мы чем-то серьезно занимаемся, то сперва все-таки нужно изучить "теорию".

Или, может я слишком серьезно воспринял, и речь в теме идет вообще о чисто программистских вещах?
В любом случае, программист ведь не пишет программы в вакууме. Обычно есть какая-то область, куда его программы относятся. И вот применительно к этому я и высказал свое мнение.

0

Сообщение от Ryuk Кто как поступает в данных ситуациях?

гуглю, если есть готовый вариант - суппер, беру его, если нет - смотрю что-то похожее и доделываю под себя. "изобретать" велосипед по 100500 дней - а смысл?

0

Сообщение от Ryuk Кто как поступает в данных ситуациях? После того как разобрали какое-то решение, переписываете ли вы его с примера, или же составляете план и затем пробуете реализовать собственными силами, в общем говоря, как вы его запоминаете?

Я обычно поступаю следующим образом.

Сначала читаю документацию по соответствующей тематике, если она есть.

Затем лезу в Гугл и делаю "штурм" запросов по нужным ключевым словам, стараясь
получить максимум полезной практической информации еще до того, как начну
работать с кодом. Попутно отмечаю непонятные для себя моменты и стараюсь с
каждым из них разобраться до конца, чтобы не осталось никаких "белых пятен".

Потом работаю с исходными кодами примеров, если такие имеются, изучаю их.
И только после этого пытаюсь самостоятельно "слепить" свой аналог.

Копипасты стараюсь избегать всеми силами. Копипасте не доверяю вообще
ни в каких проявлениях. Даже если это 100% проверенный и тысячу раз
перепроверенный код, который пользуется популярностью и постоянно
используется большим количеством программистов.

По ходу работы все сделанные "открытия" (недокументированное поведение,
ошибки в документации, что-то неочевидное и т.п.) стараюсь записывать в
специальном текстовом файле, его храню вместе с исходниками в
системе контроля версий.

7

Сообщение от DrOffset Никакого кодинга. Разбираться до упора в новой предметной области, изучать материал, посвященный этому (статьи, книги, мануалы), разговаривать, если доступны, со специалистами. И только потом (возможно спустя несколько месяцев), после того, как все понятно, приступать к проектированию архитектуры, а затем к кодированию.

Согласен по поводу того, что материал нужно много и упорно изучать, но для меня кодинг все же важен. Какие-то небольшие прототипы лепить, я бы даже сказал, просто необходимо. Так проще понять натуру задачи. И эти эксперименты зачастую задают направление куда копать дальше, а без этого направления можно просадить тучу времени не в то русло. Я серьёзно знаю одного человека, который что бы начать пользоваться гитом и гитхабом, решил сначала прочитать КНИГУ по git'у, а потом уже... Я все к чему, теорию с практикой надо балансировать, но балансировать не по времени, а скорее по нужде, что ли, в зависимости от области.

Сообщение от Убежденный Копипасты стараюсь избегать всеми силами. Копипасте не доверяю вообще ни в каких проявлениях. Даже если это 100% проверенный и тысячу раз перепроверенный код, который пользуется популярностью и постоянно используется большим количеством программистов.

Это у Вас принцип такой или был неблагоприятный опыт? И как же библиотеки? Чем проверенный скопированный код хуже библиотек? Или это только по отношению к нетривиальным задачам?

1

Сообщение от Ryuk Иногда встречаются задачи решение которых не то чтобы нетривиально, просто никогда раньше не сталкивался с подобным. Возникает вопрос подхода к решению подобных задач именно в программировании. Стоит ли сидеть скажем 2 (и то не факт что два) дня в попытках реализовать что-то, или же, если есть возможность, подсмотреть решение, разобрать и затем попробовать реализовать то что в примере?

Ну, от целей зависит. Если это задача учебная, то они для того и даются, чтобы в процессе решения теорию освоить.
Если же практическая, то можно и готовое решение поискать. Но и в этом случае никто собственные мозги поразмять не запрещает.

1

Сообщение от dimcoder Это у Вас принцип такой или был неблагоприятный опыт?

Это принцип. Который вырос из неблагоприятного опыта.

И как же библиотеки? Чем проверенный скопированный код хуже библиотек?

Не-не, я против библиотек ничего не имею.
Я против подхода в духе "оу, я тут нашел какой-то код непонятно
на какой помойке, не понимаю ни фига, как он работает, а сегодня
он почему-то вдруг у меня не работает".

0

Сообщение от dimcoder Согласен по поводу того, что материал нужно много и упорно изучать, но для меня кодинг все же важен. Какие-то небольшие прототипы лепить, я бы даже сказал, просто необходимо.

Прототипирование - это очень хорошо. Я не против прототипирования.
Я немного другое имел в виду под категоричной фразой "никакого кодинга". Поясню: если мы пишем прототип, то мы уже примерно представляем себе что нужно сделать. Прототип - это уже процентов на 40% сформированная мысль, нуждающаяся в эксперименте. А я говорил про другое, я говорил про попытку "с места в карьер" написать реализацию на основе обрывочных сведений, по наитию или просто использовав чужой код, не осознавая что это и как это будет работать.

1

Сообщение от Ryuk Я имел ввиду что если есть некая академическая задача, приближенная к реальной, и ее решение можно подсмотреть.

А, так речь все же идет об учебных задачах. Ну так они даются для закрепления теории. Тут надо грызть гранит науки, пока решение не станет ясным и очевидным, иначе теряется смысл решения задач.
Списывает учебные задачи тот, кому лень учиться. Тот же, кому учиться нравится и интересно, еще и дополнительно себе задачи выискивает.
У нас вот на мехмате был один, так он постоянно имел в голове какую-нибудь сложную математическую задачу, которую решал просто для интереса (иногда по месяцу и более), для разминки мозгов, так сказать. Про одну такую задачу он после узнал, что ее один студент в Израиле защитил в качестве кандидатской.

Добавлено через 23 минуты

Сообщение от Ryuk Иногда встречаются задачи решение которых не то чтобы нетривиально, просто никогда раньше не сталкивался с подобным.

Ну так обучение в том и состоит, чтобы узнать то, чего вы до этого не знали, и научиться тому, чего вы до этого не умели.

Сообщение от Ryuk Стоит ли сидеть скажем 2 (и то не факт что два) дня в попытках реализовать что-то

Ну, если учебные задачи у вас идут туго, то это означает, что вы либо вообще не учитесь, либо делаете это неэффективно. Здесь нужно подумать как усовершенствовать процесс обучения.

1

Сообщение от Mr.X Ну, если учебные задачи у вас идут туго, то это означает, что вы либо вообще не учитесь, либо делаете это неэффективно. Здесь нужно подумать как усовершенствовать процесс обучения.

Нет, подхожу я очень даже и с удовольствием и со всей ответственностью, просто хочу более оптимизировать процесс "изобретения" решения. Борюсь сейчас с такой вещью как "я не уверен что это будет работать, а значит писать код и проверять не буду", иначе вообще ничего не делается. Т.е. по факту в голове есть скажем 2 решения одной задачи, которые не факт что зайдут (т.е. в них я не уверен), но и реализовывать их я не горю желанием. Так вот вопрос с том что стоит ли "перебирать" эти решения, чтобы потом возможно дорваться до того третьего решения или можно как-то сидеть "на попе ровно" и пытаться придумать что-то другое (то третье решение, только без перебора), что-то, в чем я буду уверен? Вопрос конечно индивидуальный, но мне интересно кто как делает)

0

Сообщение от Ryuk Борюсь сейчас с такой вещью как "я не уверен что это будет работать, а значит писать код и проверять не буду", иначе вообще ничего не делается.

Ну, здесь вы рассуждаете о том как решать неинтересные задачи. Зачем же решать неинтересные, когда полно интересных?
Мне кажется, задача может быть неинтересна по трем причинам. Либо она слишком простая, либо слишком сложная, либо из ненужной сферы. Интуитивно нам кажутся интересными именно те задачи, которые нас наиболее эффективно развивают.

Добавлено через 3 часа 54 минуты
Если задача интересная, то над ней начинает работать наша интуиция на уровне подсознания, и решения сами всплывают оттуда, иногда даже во сне. Если интуиция не работает, значит задача неинтересная, и на нее надо плюнуть, либо как-то простимулировать себя, чтобы появился интерес.

2