Если поразмышлять о том, какие качества характерны для того, кого можно назвать «хорошим программистом», то на ум тут же придут некоторые привычки. Такие привычки, которые, с чем согласится большинство разработчиков, иметь весьма полезно. Но, на самом деле, большинство таких разработчиков сами подобных привычек не имеют.
Как все мы знаем, привычки определяют нашу жизнь. Тому, кто хочет вырасти над собой в сфере программирования, нужно попытаться сформировать у себя соответствующие привычки.
Предлагаю поговорить о шести привычках, которые стоит постараться сформировать у себя тому, кто хочет выделяться из серой толпы.
Любому программисту полезно сформировать у себя привычку улучшать код, который ему когда-либо приходится менять. При этом неважно, идёт ли речь об исправлении единственной строки кода, или о добавлении в существующий проект целой новой подсистемы.
Роберт Мартин высказал одну ценную идею по этому поводу. Он называет это «правилом бойскаута». Звучит это так: «Всегда оставляйте код, который вы редактируете, в более чистом состоянии, чем он был до вас».
Вы будете поражены тем, как много всяких мелочей вы можете улучшить, когда просто читаете какой-то код. Изменения, которые вы вносите в код, могут быть весьма незначительными — вроде переименования переменной или функции. Просто старайтесь всегда, когда это возможно, улучшить хоть что-то. В результате код после вас будет выглядеть лучше, в нём будет меньше явных проблем.
Эту привычку крайне полезно иметь из-за того, что она означает постоянное обучение. То, что мы считали хорошим вчера, уже сегодня можно улучшить, переделав это каким-то новым, более удачным, способом. Со временем код имеет свойство «портиться», поэтому забота о коде чрезвычайно важна для сохранения его в таком состоянии, в котором его удобно поддерживать.
Когда бы вы ни писали фрагмент кода, вам следует думать о том, что увидит кто-то другой, взглянувший на этот код.
Пишите код, настроившись на то, чтобы он получился бы читабельным, чтобы его было бы легко понять. Соотношение времени, которое уходит на чтение и на создание кода — это значительно больше, чем 10 к 1. Это значит, что вы, в долгосрочной перспективе, можете сэкономить массу человеко-часов, просто прилагая больше усилий к тому, чтобы писать читабельный код.
Программируя, не стремитесь ко всяческим «выкрутасам». Пишите простой код, который будет понятен любому, кто станет его читать. Согласитесь, обычно нет реальной необходимости пользоваться таинственными однострочниками, скопированными со Stack Overflow, которые вы и сами толком не понимаете.
У разработчиков встречается своеобразная привычка к ненужному усложнению и расширению того, чем они занимаются. Большинство разработчиков, сталкиваясь с задачей по реализации некоей возможности, сделают, «на всякий случай», что-то сверх того, что должны.
Это то, что называют «оверинжинирингом» — «искусством перебарщивания». Код делают более надёжным или более сложным, чем нужно. Оверинжиниринг — это то, у стремления к чему нет ни одной веской причины.
Чаще всего в основе причин, по которым разработчики создают более сложные программы, чем требуется, лежат догадки. Например, разработчик может добавить в проект код, который, возможно, может оказаться полезным в будущем. Делается это только на основании предположений данного разработчика. Этот дополнительный код попадает в кодовую базу проекта, но он, вполне возможно, так никогда никому и не пригодится.
Оверинжиниринг может привести к появлению кода, который спроектирован в настолько общем виде, что в нём будут потеряны признаки основной задачи, для выполнения которой он был изначально предназначен. В результате таким кодом не только будет сложно пользоваться. Такой код будет ещё и очень непонятным.
Настоящие программисты любят заниматься одним и только одним делом: программированием. Вас не должно это удивлять. Учитывая это, очевидно то, что большинство программистов, когда им дают задание, тут же принимаются за своё любимое дело. Они сразу же начинают писать код.
Поначалу идея уйти в код с головой может показаться восхитительной. Но за это «восхищение», вполне возможно, придётся платить временем. Когда программист, без раздумий, бросается писать код, он, в итоге, перестаёт видеть общую картину.
Прежде чем начинать писать программу, нужно всё спланировать и организовать. Стоит подумать о сложностях, которые могут встретиться на пути, и о том, как их решать. Полезно поразмыслить о структурировании кода, о том, почему планируется реализовать ту или иную возможность проекта.
Всё это — отличные вопросы, которыми стоит задаться до начала работы над кодом. Эти вопросы дадут вам возможность осознать то, что перед тем, как писать код, можно и нужно о многом поразмыслить.
Знаю — документирование кода — не самая привлекательная привычка в этом списке. Но это — очень и очень хорошая привычка. Писать документацию — это очень важно.
Попадался ли вам когда-нибудь репозиторий, в котором нет никаких сведений о том, как всё правильно настроить, или о том, как должно работать приложение, находящееся в этом репозитории?
После того, как вы проведёте пару часов, читая код, хранящийся в таком репозитории, велика вероятность того, что вы ни в чём так и не разберётесь. Вот тогда-то вы и ощутите ценность документации.
Абсолютный минимум документации, которым я порекомендовал бы оснащать любой проект, это адекватный файл
В сфере документирования программных проектов есть одно замечательное явление. Оно заключается в возможности документирования кода в процессе его написания. Дайте себе некоторое время на то, чтобы придумать описательные имена переменных. Это себя окупит. Выбор хороших имён для переменных, методов и классов требует времени. Но хорошие имена позволят сэкономить больше времени, чем нужно на их выдумывание.
Если вас интересует вопрос подбора осмысленных имён для различных сущностей — взгляните на этот материал.
Айзек Азимов сказал: «День, когда вы перестанете учиться, это день, когда вы начнёте деградировать». Эти слова особенно справедливы для мира компьютерных технологий, в котором всё меняется очень быстро.
Невозможно поспеть за всем, что меняется, и даже если кто-то на такое способен, я не советовал бы к этому стремиться. Не стоит доводить подобное стремление до крайности, но полезно время от времени осваивать новый фреймворк или язык программирования.
Это не значит, что необходимо становиться экспертом во всех таких фреймворках или языках. Полезно экспериментировать с чем-то новым для того чтобы узнать, нравится ли это вам.
Изучая новое, программист видит, как различные задачи решаются с помощью инструментов, о которых он раньше не знал. Это помогает ему профессионально расти.
Тот, кто стремится к тому, чтобы стать выдающимся программистов, может идти к этой цели, развивая у себя множество различных привычек. Мы здесь разобрали шесть привычек, которых нет у большинства разработчиков.
Вот приведённые здесь советы, касающиеся формирования полезных программистских привычек:
Постарайтесь развить у себя эти привычки. Не спешите, развивайте их у себя постепенно, по одной. Помните о том, что за один день вам ими не обзавестись. Для того чтобы развить привычки, нужно время и постоянство.
Какие привычки хороших программистов вы добавили бы к тем, о которых шла речь в этой статье?
Как все мы знаем, привычки определяют нашу жизнь. Тому, кто хочет вырасти над собой в сфере программирования, нужно попытаться сформировать у себя соответствующие привычки.
Предлагаю поговорить о шести привычках, которые стоит постараться сформировать у себя тому, кто хочет выделяться из серой толпы.
1. Наводите порядок в коде, с которым работаете
Любому программисту полезно сформировать у себя привычку улучшать код, который ему когда-либо приходится менять. При этом неважно, идёт ли речь об исправлении единственной строки кода, или о добавлении в существующий проект целой новой подсистемы.
Роберт Мартин высказал одну ценную идею по этому поводу. Он называет это «правилом бойскаута». Звучит это так: «Всегда оставляйте код, который вы редактируете, в более чистом состоянии, чем он был до вас».
Вы будете поражены тем, как много всяких мелочей вы можете улучшить, когда просто читаете какой-то код. Изменения, которые вы вносите в код, могут быть весьма незначительными — вроде переименования переменной или функции. Просто старайтесь всегда, когда это возможно, улучшить хоть что-то. В результате код после вас будет выглядеть лучше, в нём будет меньше явных проблем.
Эту привычку крайне полезно иметь из-за того, что она означает постоянное обучение. То, что мы считали хорошим вчера, уже сегодня можно улучшить, переделав это каким-то новым, более удачным, способом. Со временем код имеет свойство «портиться», поэтому забота о коде чрезвычайно важна для сохранения его в таком состоянии, в котором его удобно поддерживать.
2. Заботьтесь о тех, кто будет работать с вашим кодом после вас
Когда бы вы ни писали фрагмент кода, вам следует думать о том, что увидит кто-то другой, взглянувший на этот код.
Пишите код, настроившись на то, чтобы он получился бы читабельным, чтобы его было бы легко понять. Соотношение времени, которое уходит на чтение и на создание кода — это значительно больше, чем 10 к 1. Это значит, что вы, в долгосрочной перспективе, можете сэкономить массу человеко-часов, просто прилагая больше усилий к тому, чтобы писать читабельный код.
Программируя, не стремитесь ко всяческим «выкрутасам». Пишите простой код, который будет понятен любому, кто станет его читать. Согласитесь, обычно нет реальной необходимости пользоваться таинственными однострочниками, скопированными со Stack Overflow, которые вы и сами толком не понимаете.
3. Делайте то, что нужно, но не более того
У разработчиков встречается своеобразная привычка к ненужному усложнению и расширению того, чем они занимаются. Большинство разработчиков, сталкиваясь с задачей по реализации некоей возможности, сделают, «на всякий случай», что-то сверх того, что должны.
Это то, что называют «оверинжинирингом» — «искусством перебарщивания». Код делают более надёжным или более сложным, чем нужно. Оверинжиниринг — это то, у стремления к чему нет ни одной веской причины.
Чаще всего в основе причин, по которым разработчики создают более сложные программы, чем требуется, лежат догадки. Например, разработчик может добавить в проект код, который, возможно, может оказаться полезным в будущем. Делается это только на основании предположений данного разработчика. Этот дополнительный код попадает в кодовую базу проекта, но он, вполне возможно, так никогда никому и не пригодится.
Оверинжиниринг может привести к появлению кода, который спроектирован в настолько общем виде, что в нём будут потеряны признаки основной задачи, для выполнения которой он был изначально предназначен. В результате таким кодом не только будет сложно пользоваться. Такой код будет ещё и очень непонятным.
4. Планируйте работу над кодом
Настоящие программисты любят заниматься одним и только одним делом: программированием. Вас не должно это удивлять. Учитывая это, очевидно то, что большинство программистов, когда им дают задание, тут же принимаются за своё любимое дело. Они сразу же начинают писать код.
Поначалу идея уйти в код с головой может показаться восхитительной. Но за это «восхищение», вполне возможно, придётся платить временем. Когда программист, без раздумий, бросается писать код, он, в итоге, перестаёт видеть общую картину.
Прежде чем начинать писать программу, нужно всё спланировать и организовать. Стоит подумать о сложностях, которые могут встретиться на пути, и о том, как их решать. Полезно поразмыслить о структурировании кода, о том, почему планируется реализовать ту или иную возможность проекта.
Всё это — отличные вопросы, которыми стоит задаться до начала работы над кодом. Эти вопросы дадут вам возможность осознать то, что перед тем, как писать код, можно и нужно о многом поразмыслить.
5. Документируйте свои проекты
Знаю — документирование кода — не самая привлекательная привычка в этом списке. Но это — очень и очень хорошая привычка. Писать документацию — это очень важно.
Попадался ли вам когда-нибудь репозиторий, в котором нет никаких сведений о том, как всё правильно настроить, или о том, как должно работать приложение, находящееся в этом репозитории?
После того, как вы проведёте пару часов, читая код, хранящийся в таком репозитории, велика вероятность того, что вы ни в чём так и не разберётесь. Вот тогда-то вы и ощутите ценность документации.
Абсолютный минимум документации, которым я порекомендовал бы оснащать любой проект, это адекватный файл
readme.md, в котором рассказывается о том, для чего предназначен этот проект, и о том, как его правильно настроить и запустить.В сфере документирования программных проектов есть одно замечательное явление. Оно заключается в возможности документирования кода в процессе его написания. Дайте себе некоторое время на то, чтобы придумать описательные имена переменных. Это себя окупит. Выбор хороших имён для переменных, методов и классов требует времени. Но хорошие имена позволят сэкономить больше времени, чем нужно на их выдумывание.
Если вас интересует вопрос подбора осмысленных имён для различных сущностей — взгляните на этот материал.
6. Никогда не прекращайте учиться
Айзек Азимов сказал: «День, когда вы перестанете учиться, это день, когда вы начнёте деградировать». Эти слова особенно справедливы для мира компьютерных технологий, в котором всё меняется очень быстро.
Невозможно поспеть за всем, что меняется, и даже если кто-то на такое способен, я не советовал бы к этому стремиться. Не стоит доводить подобное стремление до крайности, но полезно время от времени осваивать новый фреймворк или язык программирования.
Это не значит, что необходимо становиться экспертом во всех таких фреймворках или языках. Полезно экспериментировать с чем-то новым для того чтобы узнать, нравится ли это вам.
Изучая новое, программист видит, как различные задачи решаются с помощью инструментов, о которых он раньше не знал. Это помогает ему профессионально расти.
Итоги
Тот, кто стремится к тому, чтобы стать выдающимся программистов, может идти к этой цели, развивая у себя множество различных привычек. Мы здесь разобрали шесть привычек, которых нет у большинства разработчиков.
Вот приведённые здесь советы, касающиеся формирования полезных программистских привычек:
- Наводите порядок в коде, с которым работаете.
- Заботьтесь о тех, кто будет работать с вашим кодом после вас.
- Делайте то, что нужно, но не более того.
- Планируйте работу над кодом.
- Документируйте свои проекты.
- Никогда не прекращайте учиться.
Постарайтесь развить у себя эти привычки. Не спешите, развивайте их у себя постепенно, по одной. Помните о том, что за один день вам ими не обзавестись. Для того чтобы развить привычки, нужно время и постоянство.
Какие привычки хороших программистов вы добавили бы к тем, о которых шла речь в этой статье?
