Как писать код быстрее с меньшим количеством ошибок

Попалась небольшая статья на просторах интернета о том как стать хорошим программистом. Далее вольный перевод оригинала

Практикуйтесь. Просто продолжайте делать то, что делаете. Создавайте больше софта, используйте больше инструментов, делайте больше ошибок, анализируйте их, разбирайтесь с ними и учитесь на них. Всегда практикуйте свои умения. Никогда не оценивайте их. Если вы будете сожалеть, что долго писали или дебажили что-то. Или как много ошибок допустили. Вы лишь испытаете ненужный стресс и усложните обучение.

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

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

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

Проведите некоторое время планируя проект, но не сильно много. Начиная проект, я в первую очередь обдумываю обобщенно какие компоненты нужны для работы системы. Но не трачу много времени на протоколы взаимодействия или деление на более мелкие подсистемы пока не погружусь в код. Иногда более эфективно бывает написать какой-то компонент “неправильно” вначале. И переписать его при необходимости, когда другие части станут более зрелые. Чрезмерное планирование, может оказаться пустой тратой времени, т.к. зачастую проекты редко соответствуют первоначальным планам. Важно давать себе отчет сколько времени, потраченного на планирование деталей, “достаточно” (т.е. когда нужно остановиться и приступать к кодированию). А это, к сожалению, приходит только с опытом.

Не бойтесь отладчиков. GDB может пугать начинающих. Но это чудесная вещь, экономящая время. Основы использования выучить довольно просто. Можно отлаживать большое количество проблем, используя лишь комманды break, run, next и print.

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

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