По моему разумению второй и четвёртый пункт довольно ситуативны и не всегда на них стоит опираться.
К шестому пункту оставлю пометку, что если разработчик всё же делает комиты редко и ему потребуется отменить изменения – ему не обязательно придётся откатываться на несколько дней назад. В некоторых случаях достаточно отменить изменения лишь отдельных файлов, а не всех сразу.
Девятый пункт хорош как совет, но подводка к нему слишком категорична. Плохая новость — не получится.Если это касается особенностей работы незнакомого движка или библиотек, скорее всего, не получится. Но в целом при разработке можно привести очень много примеров, когда самостоятельная попытка разобраться в коде приводит к тому, что ты понимаешь из-за чего возникает проблема и как следствие, решаешь её.
От того, что ты потратил несколько часов перебирая неработающие решения своей проблемы, ты не станешь лучше разбираться в коде.Это тоже не так. Перебирая варианты, программист лучше понимает поведение своей программы при разных условиях, даже если все составленные варианты не приводят к успеху. Совершение ошибок при написании алгоритмов — неотъемлемая часть любой разработки и тем более обучения, если только ты не штампуешь одно и то же. И дело не в том, что разработчик только учится и у него низкая вероятность быстрого успеха. А в том, что если кругозор разработчика будет наполнен лишь успешными вариантами, кругозор будет ограничен и разработчик будет слабо представлять поведение неуспешных вариантов и как следствие, будет плохо ориентироваться при возникновении таких ситуаций.
А если подсмотришь у других, как эту проблему правильно решать, то станешь — вот и вся наука.Только если знать меру. Необдуманные попытки черпать из чужой реализации могут привести к тому, что разработчик как раз не станет лучше разбираться в коде. Особенно, если он копипастит не вдумываясь в то, как именно оно внутри подетально работает. А вот самостоятельные попытки изучить код, экспериментировать, постоянно ошибаться, как раз помогут лучше разбираться в том как функционирует инструмент. Это касается по большей части алгоритмизации. Если говорить о документации инструмента — безусловно, лучше гуглить и искать инфу, так как разработчик должен знать как работает его инструмент и сделать это без открытых источников, действительно, невозможно.
Пишу по своему опыту, но, безусловно, у многих людей он может и будет отличаться, так что и на мои слова всецело опираться не стоит.
Статья хорошая. Автор, в любом случае, молодец, поделился своим опытом и даёт знатные советы. В этом контексте могу только сделать поклон. Успехов в дальнейших свершениях.
Спасибо за развернутый коммент! Всё так, у всех разработчиков свои нюансы и у всех проектов свои нюансы тоже. В целом, согласен со всем, описанным выше , особенно про "знать меру" - это вообще универсальное правило :)
По моему разумению второй и четвёртый пункт довольно ситуативны и не всегда на них стоит опираться.
К шестому пункту оставлю пометку, что если разработчик всё же делает комиты редко и ему потребуется отменить изменения – ему не обязательно придётся откатываться на несколько дней назад. В некоторых случаях достаточно отменить изменения лишь отдельных файлов, а не всех сразу.
Девятый пункт хорош как совет, но подводка к нему слишком категорична.
Плохая новость — не получится.Если это касается особенностей работы незнакомого движка или библиотек, скорее всего, не получится. Но в целом при разработке можно привести очень много примеров, когда самостоятельная попытка разобраться в коде приводит к тому, что ты понимаешь из-за чего возникает проблема и как следствие, решаешь её.
От того, что ты потратил несколько часов перебирая неработающие решения своей проблемы, ты не станешь лучше разбираться в коде.Это тоже не так. Перебирая варианты, программист лучше понимает поведение своей программы при разных условиях, даже если все составленные варианты не приводят к успеху. Совершение ошибок при написании алгоритмов — неотъемлемая часть любой разработки и тем более обучения, если только ты не штампуешь одно и то же. И дело не в том, что разработчик только учится и у него низкая вероятность быстрого успеха. А в том, что если кругозор разработчика будет наполнен лишь успешными вариантами, кругозор будет ограничен и разработчик будет слабо представлять поведение неуспешных вариантов и как следствие, будет плохо ориентироваться при возникновении таких ситуаций.
А если подсмотришь у других, как эту проблему правильно решать, то станешь — вот и вся наука.Только если знать меру. Необдуманные попытки черпать из чужой реализации могут привести к тому, что разработчик как раз не станет лучше разбираться в коде. Особенно, если он копипастит не вдумываясь в то, как именно оно внутри подетально работает. А вот самостоятельные попытки изучить код, экспериментировать, постоянно ошибаться, как раз помогут лучше разбираться в том как функционирует инструмент.
Это касается по большей части алгоритмизации. Если говорить о документации инструмента — безусловно, лучше гуглить и искать инфу, так как разработчик должен знать как работает его инструмент и сделать это без открытых источников, действительно, невозможно.
Пишу по своему опыту, но, безусловно, у многих людей он может и будет отличаться, так что и на мои слова всецело опираться не стоит.
Статья хорошая. Автор, в любом случае, молодец, поделился своим опытом и даёт знатные советы. В этом контексте могу только сделать поклон. Успехов в дальнейших свершениях.
Спасибо за развернутый коммент! Всё так, у всех разработчиков свои нюансы и у всех проектов свои нюансы тоже. В целом, согласен со всем, описанным выше , особенно про "знать меру" - это вообще универсальное правило :)