Правильно разработанный код не только легко читается, но легко масштабируется …
Это очень полезно не только при командной работе, но и когда Вы пишите проект в одиночку, как заметил автор статьи “Порядок в коде – порядок в голове”. Но увы, дизайн кода не исправишь авто-форматированием в отличии от оформления.
По этому даже код в одном стиле может стать адом при добавлении нового функционала.
Каких принципов лучше придерживаться при написании кода?
На этот вопрос в интернете можно найти много информации, к примеру материалы Joshua Bloch-a ( линк1, линк2 ).
Но, учитывая специфику данного сайта, хотелось бы выделить несколько принципов которые забывают или избегают начинающие малваршики.
- Процедурный стиль в программировании. Я думаю не стоит объяснять какие преимущества дает ООП при написании кода.
- Называйте методы/классы явно. Например, если у вас есть метод с именем registerUser, то он должен регистрировать пользователя и ничего больше не делать. но если вдруг он помимо регистрации еще и логинит пользователя, тогда его следует назвать loginAndRegisterUser, либо вынести этот функционал в 2 разных метода.
- Разделяйте сервисы и данные. Почти во всех приложениях можно разделить код как минимум на 2 части, это Данные(Классы которые имеют состояние и не содержат в себе код с логикой) и Сервисы(Которые не имеют состояния, и содержат в себе код с логикой). Данное разделение полезно во первых из-за того что сервисы не имеющие состояния потоко-безопасны, во вторых это позволяет тестировать функционал сервисов независимо от всего приложения (Unit тестирование).
- Код должен быть само документируемым, смотря на код не должно быть вопросов, почему или зачем вы это написали. Писать комментарии нужно только в случае неявных действий в коде (которых как сказано во втором пункте нужно избегать, но увы, без этого иногда не обойтись).
- Избегайте магических чисел (сабж) , выносите их в константы, если это не достаточно явно, в комментариях поясняйте зачем нужны эти числа.
Когда Вы пишете код, Вы помните зачем нужно это число, но если вы посмотрите на код спустя год или это сделает другой человек, ему нужно будет потратить некоторое время, что бы понять почему там стоит именно это число.К примеру:
// Занесем полученные от сервера атрибуты экрана в буфер консоли WriteConsoleOutputAttribute (hConsoleOutput,(const WORD *) (&buffer.consoleBuffer.Attribute), 8000 , dwWriteCoord, &NumberOfcharsWriten);
Первый вопрос который хочется задать, что такое 8000 ? может быть это какой то флаг, может быть размер буффера ? Да и почему 8000, почему не 42 , или почему не 8003 ?
Разве не лучше выглядит код:
const DWORD CONSOLE_BUFFER_SIZE = 8000; // Занесем полученные от сервера атрибуты экрана в буфер консоли WriteConsoleOutputAttribute (hConsoleOutput,(const WORD *) (&buffer.consoleBuffer.Attribute), CONSOLE_BUFFER_SIZE , dwWriteCoord, &NumberOfcharsWriten);
- Используйте наследование только если вы можете сказать что класс наследник является классом родителя. И не забывайте называть классы осмысленно.
Например:
//java code
public class Network extends Service{
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
return Service.START_STICKY;
}
...
}
Здесь было бы верно назвать класс NetworkService.
- Используйте паттерны, но умеренно, достаточно часто начинающие девелоперы выучив новый паттерн мыслят не в стиле: “О, хороший случай что бы применить такой то паттерн” , а в стиле: “Я знаю крутой паттерн, где бы мне его применить” и во втором случае есть вероятность нарваться на design hell.
Про другую крайность, а именно – игнорирования дизайна кода можно почитать в этой статье.
P.S.
Если вас понравилась моя статья, Я напишу продолжение уже на примере малваки, мы рассмотрим весь цикл написания проекта, от юзкейсов, до готового приложения, затронув unit-тестирование и системы контроля версий.
С вами был C@t и до скорых встреч!
Запись О дизайне кода впервые появилась VxLab.
from VxLab http://ift.tt/24i32AJ
via IFTTT
