- Автор темы
- #1
Не допускает ошибок только тот, кто ничего не делает. Для программиста это выражение более чем справедливо. При разработке больших программных продуктов, тем более в команде разработчиков ошибки неизбежны. Но все равно допускать их хотелось бы как можно реже. Сегодня мы поговорим о том, как избегать ошибок при написании программного кода.
Используй TDD – разработку через тестирование. После того, как ты разработал план, в первую очередь приступай к написанию модульных тестов к своему будущему коду. Так ты точно не забудешь их сделать. Но это не главное. Основной плюс такого подхода в том, что ты сначала продумываешь будущий интерфейс своих классов, а только потом приступаешь к конкретной реализации. Это позволяет на первоначальном этапе сконцентрироваться на более общих моментах, не заботясь о частных случаях. Кроме того, для меня как для C#-разработчика среда разработки Visual Studio Enterprise предоставляет удобную возможность Live Testing. Это позволяет прямо в время написания кода (без компиляции) видеть успешность выполнения тестов, а также построчное отображение покрытия тестами и правильность работы. И это в режиме реального времени. Очень удобная фича, рекомендую тебе попробовать, если работаешь с C#.
Не изобретай собственные костыли. Большинство типичных задач уже решены за тебя и при желании можно найти готовые решения, которые уже проверены множеством других программистов. Вероятность наличия ошибки конечно же есть, но она ниже, по сравнению с тем, если бы ты разрабатывал что-то самостоятельно с нуля (особенно если это объемный кусок кода). Поэтому не стесняйся использовать чужой код, фреймворки и библиотеки. В конце концов, повторное использование кода сейчас относят к расширенному списку из шести парадигм объектно-ориентированного программирования.
Пиши чистый и понятный код. Вероятность допустить ошибку в говнокоде намного выше, по сравнению с хорошо структурированным листингом. Лаконично, но информативно именуй переменные, с умом используй комментарии, выделяй и правильно именуй методы, соблюдай принципы проектирования SOLID, KISS, YAGNI, DRY. Тогда просто взглянув на исходники, ты сможешь заметить, что что-то идет не так и сразу же исправиться.
Хорошо знай тонкости языка. О базовых ошибках синтаксиса я даже говорить не буду, современные IDE и статические анализаторы кода без проблем отлавливают такие баги. Но у каждого языка есть неявные особенности, которые могут повлиять на производительность приложения или даже совсем поломать нормальную логику. Ты обязан хорошо знать инструмент (язык программирования), с которым работаешь, тогда и ошибок будет значительно меньше.
Возьми за правило практику проведения Code Review. Когда долго работаешь над задачей, возможен так называемый эффект замыливания глаза. Ты просто не будешь замечать ошибки, которые лежат на поверхности. Так действительно бывает, и именно для этого, необходимо давать почитать свой код другим разработчикам, а также читать чужой. Это не только помогает защитится от таких ошибок, но и стимулирует обмен опытом.
К коду нужно относиться к своему творению, именно он является продуктом нашей трудовой деятельности (ну естественно плюс решение проблем заказчика, о чем я писал в другой своей статье). В качестве лайфхака могу посоветовать одну интересную практику, которую использовали на одном из моих предыдущих мест работы – «соревнование без багов». Каждый из разработчиков в команде скидывался в общую копилку N-рублей и начиналась работа над спринтом. По итогам, приз получал тот программист, который допускал наименьшее количество ошибок. Результаты подводили на ретроспективе спринта. Мелочь, а приятно. Плюс к этому дух соревнования давал дополнительный стимул. Надеюсь, тебе было интересно, и ты почерпнул что-то полезное для себя. Пиши код, с практикой приходит опыт, а за опытом и качество.
Как делать меньше ошибок в коде
Для начала, уделите достаточное время планированию. Для корабля, который не знает, куда плывет, ни один ветер не будет попутным. Составь подробный план с четкими критериями для сравнения с промежуточными и конечным результатами. Не ленись рисовать UML-диаграммы и блок-схемы. Любая ошибка, выявленная на этапе проектирования, обходится в разы дешевле (по времени и затратам ресурсов), чем обнаруженная на этапе разработки, а еще хуже внедрения или использования. Гораздо проще изменить схему, чем переписывать куски кода.Используй TDD – разработку через тестирование. После того, как ты разработал план, в первую очередь приступай к написанию модульных тестов к своему будущему коду. Так ты точно не забудешь их сделать. Но это не главное. Основной плюс такого подхода в том, что ты сначала продумываешь будущий интерфейс своих классов, а только потом приступаешь к конкретной реализации. Это позволяет на первоначальном этапе сконцентрироваться на более общих моментах, не заботясь о частных случаях. Кроме того, для меня как для C#-разработчика среда разработки Visual Studio Enterprise предоставляет удобную возможность Live Testing. Это позволяет прямо в время написания кода (без компиляции) видеть успешность выполнения тестов, а также построчное отображение покрытия тестами и правильность работы. И это в режиме реального времени. Очень удобная фича, рекомендую тебе попробовать, если работаешь с C#.
Не изобретай собственные костыли. Большинство типичных задач уже решены за тебя и при желании можно найти готовые решения, которые уже проверены множеством других программистов. Вероятность наличия ошибки конечно же есть, но она ниже, по сравнению с тем, если бы ты разрабатывал что-то самостоятельно с нуля (особенно если это объемный кусок кода). Поэтому не стесняйся использовать чужой код, фреймворки и библиотеки. В конце концов, повторное использование кода сейчас относят к расширенному списку из шести парадигм объектно-ориентированного программирования.
Пиши чистый и понятный код. Вероятность допустить ошибку в говнокоде намного выше, по сравнению с хорошо структурированным листингом. Лаконично, но информативно именуй переменные, с умом используй комментарии, выделяй и правильно именуй методы, соблюдай принципы проектирования SOLID, KISS, YAGNI, DRY. Тогда просто взглянув на исходники, ты сможешь заметить, что что-то идет не так и сразу же исправиться.
Всегда думай, перед тем как писать код
Не забывай про документацию и системы контроля версий. Имея на руках записки и историю изменений кода, намного проще разбираться в том, что и как должно работать. Особенно это пригодится, если к команде разработки будут присоединяться новые люди. Особенно хорошо то, что этот процесс можно автоматизировать, если использовать специальные комментарии к методам и классам, а также связывать задачи и коммиты (например, это можно легко делать с помощью TFS). Чем лучше разработчик понимает, что он делает, тем меньше он допускает ошибок.Хорошо знай тонкости языка. О базовых ошибках синтаксиса я даже говорить не буду, современные IDE и статические анализаторы кода без проблем отлавливают такие баги. Но у каждого языка есть неявные особенности, которые могут повлиять на производительность приложения или даже совсем поломать нормальную логику. Ты обязан хорошо знать инструмент (язык программирования), с которым работаешь, тогда и ошибок будет значительно меньше.
Возьми за правило практику проведения Code Review. Когда долго работаешь над задачей, возможен так называемый эффект замыливания глаза. Ты просто не будешь замечать ошибки, которые лежат на поверхности. Так действительно бывает, и именно для этого, необходимо давать почитать свой код другим разработчикам, а также читать чужой. Это не только помогает защитится от таких ошибок, но и стимулирует обмен опытом.
К коду нужно относиться к своему творению, именно он является продуктом нашей трудовой деятельности (ну естественно плюс решение проблем заказчика, о чем я писал в другой своей статье). В качестве лайфхака могу посоветовать одну интересную практику, которую использовали на одном из моих предыдущих мест работы – «соревнование без багов». Каждый из разработчиков в команде скидывался в общую копилку N-рублей и начиналась работа над спринтом. По итогам, приз получал тот программист, который допускал наименьшее количество ошибок. Результаты подводили на ретроспективе спринта. Мелочь, а приятно. Плюс к этому дух соревнования давал дополнительный стимул. Надеюсь, тебе было интересно, и ты почерпнул что-то полезное для себя. Пиши код, с практикой приходит опыт, а за опытом и качество.