На протяжении свой карьеры программиста, я неоднократно сталкивался с тем, что программисты не умеют писать код. Причем это может касаться как начинающих так уже и очень опытных людей. Честно говоря, по моему мнению существуют единицы, которые действительно умеют это делать. Я не претендую на полноту освещение проблемы и на то что мое мнение правильное, а рассмотрю ее со своей точки зрения.
На мой взгляд не существует и не может существовать единого стандарта и каждый человек волен выбирать и адаптировать свои собственные подходы к программированию. Но есть некоторый набор практик, который помогает в подавляющем большинстве случаев.
Прежде всего хочется обратится к первоистокам проблемы. Что вообще не так и зачем надо что-то менять. Я думаю, что мечтой каждого программиста, является писать код максимально быстро и максимально красиво, причем чтоб все четко работало с первого раза. Это позволит чаще читать фишки и пить кофе с тестировщицами, для особо ярых даст больше времени для для развития себя как специалиста.
Одно из основных отличий профессионального программиста от новичка является система приоритетов. Как правило сделать код работающим очень не сложно, сделать его понятным намного сложнее (желательно конечно чтоб при этом он остался работающим). Поэтому профессионал зачастую больше времени проводит за рефакторингом чем за дебагом, что само по себе уже хорошо, однако хотелось бы и момент рефакторинга сократить до минимума.
В любой вашей реализации должна быть идея, это как линия которая проходит через всю функциональность и связывает ее воедино. До того как сесть что-то писать, вы должны более менее представлять как это все будет работать, какие есть блоки, как они друг с другом взаимодействуют. Не садитесь писать просто так, придумайте концепцию, так и интереснее и зачастую результирующий код станет понятнее. Естественно уже придумав что-то стоит максимально оставаться в рамках этой концепции, не стоит менять все при первых проблемах, проблемы будут всегда. Также не стоит лениться и со словами, “да ладно и так затащит” втыкать какуюто затычку. Это к добру не приведет.
А хочется конечно, чтоб он был, но его в 99.(9)% нет. Не стоит пытаться сделать код идеальным, получится еще хуже потратится намного больше времени. Это просто борьба с ветряными мельницами, все же нам платят за то что наше приложение работает а на за то, как оно шикарно написано. Часто поиски идеала приводят к постоянным сменам концепций, бесконечным переписыванием одного и того же, в конечном итоге надоедает, человек все бросает, затыкает все затычкам и “да ладно и так затащит”. Должно быть хорошо и удобно, идеал это не удел инженеров это удел поэтов, а программисты все таки инженеры.
Одной из основных проблем особенно у новичков является копание в деталях. Надо фокусироваться на 1 задаче в единицу времени. Что я хочу сказать, вы пишете какую-то функцию, натыкаетесь на какой-то не простой момент с которым надо разобраться. В большинстве случаев вы знаете, что эта проблема решается 100%, но не знаете как. Если переключиться на ее решение, вы собьетесь с фокуса текущей проблемы, потом для того, чтоб вернуться придется потратить время, переключение контекста никогда не было бесплатной операцией. Эта идея так же распространяется на детали реализации. Предположим вам надо написать функцию которая читает какие-то данные из базы и записывает их в файл. Вот то и есть вашим контекстом. Решите эту проблему потом решайте остальные (тоесть чтение из базы и запись в файл). Изначально мы пишем следующее:
и генерируем 2 заглушки для Read и Write, благо вижуал студия имеет магическую комбинацию клавиш alt+shift+f10, которую я прожимаю чаще всего (перебиндить ее на f1, просто f1 вместо поиска, мешает только то что это надо делать у всех). Что нам дает такой подход. Во-первых, мы пишем быстрее ибо остаемся в контексте. Во вторых мы пишем лучше ибо в один момент решаем одну задачу, да, ошибок будет меньше. В третьих мы получаем лучше код, он изначально формируется правильно. Функции называются правильно и по контексту, они получаются маленькие и простые. На мой взгляд это самая важная практика из всех перечисленных здесь.
Как писал Фаулер в своем бессмертном произведении, у кода есть запах. Не буду сильно повторяться, скажу кратко. Если вы ощущаете, что с кодом что-то не так, подумайте как его улучшить. Такое чувство возникает как правило с опытом, однако если вы все время будете анализировать то, что пишете, после написания, оно у вас будет развиваться намного быстрее. Однако помните, идеала нет!
Выработайте свою систему именования переменных, функций и тп. старайтесь ее максимально придерживаться. Я вот например возвращаемое значение функции всегда называю result, может это не правильно и не отражает смысл, отсылка во времена делфи, но я так делаю и мне это нравится, мне так удобно. Также я всегда использую var никогда не использую явное типизирование (ну только когда выхода нет). Я так же стремлюсь всегда давать очень короткие имена переменным i,d,v,k для меня не проблема, ибо функции маленькие все понятно из контекста. Зачем писать currentNode если можно написать просто n и при это все равно все ясно? Более того, длинные имена переменных часто только усложняю изложение. Про стандарты кодирования я тут молчу это другая тема, их просто надо придерживаться.
Задавайте себе больше вопросов по тому коду который вы пишете. Обрабатываются ли исключения? Правильно ли сделано управление ресурсами? Очищаются ли у вас кеши в нужный момент? Все ли хорошо с потокобезопасностью? Правильно ли вы используете библиотеки? В том ли месте находится функция которую вы пишете? Существует очень много вопросов которые стоит рассмотреть даже после того как код уже работает. Надо задаваться этими вопросами постоянно, тогда это войдет в привычку и все это будет делаться уже автоматом.
Шаблоны проектирования, иерархии классов, элементы функционального программирования это все замечательные вещи. Однако стоит по возможности стараться все делать как можно проще. Чем проще код, тем он понятнее и тем легче его сопровождать. Глубокие иерархии классов очень сложно поддерживать и понимать. Зачастую наследования вообще стоит избегать, старайтесь заменять его реализацией интерфейсов. Шаблоны проектирования тоже дают великолепные решения, но подумайте, может стоит все сделать просто? Возможно оно так будет понятнее? Зачастую так оно и есть.
— Если вы дебажите свой код, который только что написали, что-то пошло не так.
— Стоит реже компилировать свой код, вообще стоит больше писать меньше собирать. Если вы конечно активно используете юнит тесты, то этот пункт в принципе отпадает, там и правда лучше чаще собирать и запускать тесты. Однако все равно не стоит это делать слишком уж часто.
— Изучите все возможности которые дает среда разработки, выучите горячие клавиши и используйте их, это очень сильно экономит время. Однако не советую сильно настраивать под себя среду, будет очень сложно если придется помогать коллеге за его компьютером.
Я здесь умышленно не привожу примеры кода, сейчас я пишу на C# (как пытливый читатель уже наверно догадался), но дело в том, что не существует принципиальных отличий в написании кода на PHP, C++, Delphi, C# и тп. даже на сильно отличающихся языках (например функциональных).
Хочу отметить, что простое прочтение каких-то правил и советов ничего не дает, надо отрабатывать. И вот это последняя мысль которую я хочу выразить. Не пишете просто код, всегда отрабатывайте и улучшайте свои навыки. “Сейчас просто напишу, а дома на кошках потренируюсь” ничего вам не даст совершенно. Можно было бы еще продолжить и расширить мой список, но я считаю изложенные моменты основными.
На мой взгляд не существует и не может существовать единого стандарта и каждый человек волен выбирать и адаптировать свои собственные подходы к программированию. Но есть некоторый набор практик, который помогает в подавляющем большинстве случаев.
Прежде всего хочется обратится к первоистокам проблемы. Что вообще не так и зачем надо что-то менять. Я думаю, что мечтой каждого программиста, является писать код максимально быстро и максимально красиво, причем чтоб все четко работало с первого раза. Это позволит чаще читать фишки и пить кофе с тестировщицами, для особо ярых даст больше времени для для развития себя как специалиста.
Одно из основных отличий профессионального программиста от новичка является система приоритетов. Как правило сделать код работающим очень не сложно, сделать его понятным намного сложнее (желательно конечно чтоб при этом он остался работающим). Поэтому профессионал зачастую больше времени проводит за рефакторингом чем за дебагом, что само по себе уже хорошо, однако хотелось бы и момент рефакторинга сократить до минимума.
Итак основные идеи, которые могут помочь писать код лучше
Имей идею
В любой вашей реализации должна быть идея, это как линия которая проходит через всю функциональность и связывает ее воедино. До того как сесть что-то писать, вы должны более менее представлять как это все будет работать, какие есть блоки, как они друг с другом взаимодействуют. Не садитесь писать просто так, придумайте концепцию, так и интереснее и зачастую результирующий код станет понятнее. Естественно уже придумав что-то стоит максимально оставаться в рамках этой концепции, не стоит менять все при первых проблемах, проблемы будут всегда. Также не стоит лениться и со словами, “да ладно и так затащит” втыкать какуюто затычку. Это к добру не приведет.
Идеала нет
А хочется конечно, чтоб он был, но его в 99.(9)% нет. Не стоит пытаться сделать код идеальным, получится еще хуже потратится намного больше времени. Это просто борьба с ветряными мельницами, все же нам платят за то что наше приложение работает а на за то, как оно шикарно написано. Часто поиски идеала приводят к постоянным сменам концепций, бесконечным переписыванием одного и того же, в конечном итоге надоедает, человек все бросает, затыкает все затычкам и “да ладно и так затащит”. Должно быть хорошо и удобно, идеал это не удел инженеров это удел поэтов, а программисты все таки инженеры.
Сохраняй фокус
Одной из основных проблем особенно у новичков является копание в деталях. Надо фокусироваться на 1 задаче в единицу времени. Что я хочу сказать, вы пишете какую-то функцию, натыкаетесь на какой-то не простой момент с которым надо разобраться. В большинстве случаев вы знаете, что эта проблема решается 100%, но не знаете как. Если переключиться на ее решение, вы собьетесь с фокуса текущей проблемы, потом для того, чтоб вернуться придется потратить время, переключение контекста никогда не было бесплатной операцией. Эта идея так же распространяется на детали реализации. Предположим вам надо написать функцию которая читает какие-то данные из базы и записывает их в файл. Вот то и есть вашим контекстом. Решите эту проблему потом решайте остальные (тоесть чтение из базы и запись в файл). Изначально мы пишем следующее:
var data = Read();
Write(data);
и генерируем 2 заглушки для Read и Write, благо вижуал студия имеет магическую комбинацию клавиш alt+shift+f10, которую я прожимаю чаще всего (перебиндить ее на f1, просто f1 вместо поиска, мешает только то что это надо делать у всех). Что нам дает такой подход. Во-первых, мы пишем быстрее ибо остаемся в контексте. Во вторых мы пишем лучше ибо в один момент решаем одну задачу, да, ошибок будет меньше. В третьих мы получаем лучше код, он изначально формируется правильно. Функции называются правильно и по контексту, они получаются маленькие и простые. На мой взгляд это самая важная практика из всех перечисленных здесь.
Чувствуй запах
Как писал Фаулер в своем бессмертном произведении, у кода есть запах. Не буду сильно повторяться, скажу кратко. Если вы ощущаете, что с кодом что-то не так, подумайте как его улучшить. Такое чувство возникает как правило с опытом, однако если вы все время будете анализировать то, что пишете, после написания, оно у вас будет развиваться намного быстрее. Однако помните, идеала нет!
Лучше безобразно но единообразно
Выработайте свою систему именования переменных, функций и тп. старайтесь ее максимально придерживаться. Я вот например возвращаемое значение функции всегда называю result, может это не правильно и не отражает смысл, отсылка во времена делфи, но я так делаю и мне это нравится, мне так удобно. Также я всегда использую var никогда не использую явное типизирование (ну только когда выхода нет). Я так же стремлюсь всегда давать очень короткие имена переменным i,d,v,k для меня не проблема, ибо функции маленькие все понятно из контекста. Зачем писать currentNode если можно написать просто n и при это все равно все ясно? Более того, длинные имена переменных часто только усложняю изложение. Про стандарты кодирования я тут молчу это другая тема, их просто надо придерживаться.
Что? Где? Когда?
Задавайте себе больше вопросов по тому коду который вы пишете. Обрабатываются ли исключения? Правильно ли сделано управление ресурсами? Очищаются ли у вас кеши в нужный момент? Все ли хорошо с потокобезопасностью? Правильно ли вы используете библиотеки? В том ли месте находится функция которую вы пишете? Существует очень много вопросов которые стоит рассмотреть даже после того как код уже работает. Надо задаваться этими вопросами постоянно, тогда это войдет в привычку и все это будет делаться уже автоматом.
Будьте проще и люди к вам потянутся
Шаблоны проектирования, иерархии классов, элементы функционального программирования это все замечательные вещи. Однако стоит по возможности стараться все делать как можно проще. Чем проще код, тем он понятнее и тем легче его сопровождать. Глубокие иерархии классов очень сложно поддерживать и понимать. Зачастую наследования вообще стоит избегать, старайтесь заменять его реализацией интерфейсов. Шаблоны проектирования тоже дают великолепные решения, но подумайте, может стоит все сделать просто? Возможно оно так будет понятнее? Зачастую так оно и есть.
И на последок еще несколько замечаний
— Если вы дебажите свой код, который только что написали, что-то пошло не так.
— Стоит реже компилировать свой код, вообще стоит больше писать меньше собирать. Если вы конечно активно используете юнит тесты, то этот пункт в принципе отпадает, там и правда лучше чаще собирать и запускать тесты. Однако все равно не стоит это делать слишком уж часто.
— Изучите все возможности которые дает среда разработки, выучите горячие клавиши и используйте их, это очень сильно экономит время. Однако не советую сильно настраивать под себя среду, будет очень сложно если придется помогать коллеге за его компьютером.
Я здесь умышленно не привожу примеры кода, сейчас я пишу на C# (как пытливый читатель уже наверно догадался), но дело в том, что не существует принципиальных отличий в написании кода на PHP, C++, Delphi, C# и тп. даже на сильно отличающихся языках (например функциональных).
Хочу отметить, что простое прочтение каких-то правил и советов ничего не дает, надо отрабатывать. И вот это последняя мысль которую я хочу выразить. Не пишете просто код, всегда отрабатывайте и улучшайте свои навыки. “Сейчас просто напишу, а дома на кошках потренируюсь” ничего вам не даст совершенно. Можно было бы еще продолжить и расширить мой список, но я считаю изложенные моменты основными.