Хороший программист - это не просто техническая профессия и набор некоторых навыков. В большей степени, это стиль жизни, и специфический взгляд на мир и природу вещей. С одной стороны, это мудрость - наработанный жизненный опыт, и какое-то количество боли от прошлых неудач. С другой стороны, это наличие внутреннего морального стержня и сформированных личных убеждений. И пожалуй в третьих, это сохранившаяся вера в светлое начало - наличие голоса надежды где-то внутри.
Из личной практики, хорошими программистами не рождаются - ими становятся. В ходе развития, любой специалист проходит длинный путь романтики, идеализации, последующей разидеализации, и наконец принятия реальности как она есть. Но я всё-таки считаю, что этот путь можно сократить, и уменьшить количество болезненного опыта. В том числе об этом первая часть нашей философской трилогии.
Предлагаю на обозрение небольшой список положительных метрик качества программных продуктов. Конечно, это только один из множества углов обзора, но надеюсь что кому-то он сможет оказать пользу. В целом, это достаточно простые и естественные принципы, которые можно применять как в программировании, так и в других профессиях. Можно даже сказать, принципы естественного права!
Краткость 📝
Любой код тем лучше, чем он меньше в размере и проще в логике своей работы. Идеальный программный код - это код, который вообще не написан. Идеальная кнопка - это кнопка, которой не существует. Идеальный интерфейс - это отсутствие интерфейса, и решение задачи в фоновом режиме.
В окружающей нас реальности, любая стабильная система стремится к максимальной простоте. Любое устоявшееся взаимодействие стремится к минимальному энергопотреблению. Так же точно происходит и внутри программных продуктов.
Чем проще написан программный код, чем меньшее количество библиотек в нём использовано, чем меньшее количество велосипедов изобретено в процессе работы над задачей - тем лучше. Краткие решения всегда сочетают в себе лаконичность и изящество, и как следствие - минимальное потребления внимания (от программистов и пользователей), и соответствующее низкое потребление энергоресурсов.
Предсказуемость 🔮
Программирование, при всех его творческих началах - это достаточно строгая наука. Любые создаваемые программы, функции внутри них, библиотеки и модули - всегда решают конкретные задачи и проблемы. От любого программного продукта мы ожидаем предсказуемого поведения. Это правило распространяется как с точки зрения внешнего наблюдателя, так и с точки зрения внутреннего качества программ.
Независимо от решаемой задачи, поведение программного кода должно быть предсказуемым. Логика любого участка кода должна создаваться таким образом, чтобы понятным и надежным образом выполнять заявленную функцию, без каких-либо неожиданностей. Приводить пользователя или поток данных кратчайшим путём из пункта А в пункт Б.
Программист - это не волшебник, а компьютеры - это не магические шары предсказаний. Пиши программу так, чтобы другим не пришлось ломать голову над её структурой. Создавай интерфейсы так, чтобы пользователи не зависали в попытках понять, какую же кнопку им нужно нажать. Делай предсказуемые вещи, поведение которых можно угадать и на которые можно положиться.
Читабельность 📖
Хороший программный код должен быть легко читаем, и понятен другим специалистам. Фокус программных продуктов в том, что как правило с ними работают команды программистов. Это справедливо даже для тех случаев, когда некоторый программист в конкретный момент времени работает над каким-то кодом в полном одиночестве. Не сегодня - так завтра, не он - так другие продолжат развитие создаваемой программы.
Фокус здесь в том, что любой код нужно хорошо документировать и упрощать (см. пункт "Краткость"). Твои коллеги не обязаны угадывать твои мысли или копаться в запутанных недрах логики. Код должен быть оформлен и структурирован таким образом, чтобы он был читаем и очевиден для любого нового участника.
Для себя я уже много лет использую простое правило читабельности. Оно звучит следующим образом: "Программируй так, чтобы твой код был понятен даже идиоту". Забавно - но правило выручает и своего автора, когда спустя много лет я заглядываю в свои же исходники, уже совершенно не помня как устроен тот или иной модуль.
Сюда же относится документирование кода. Любой класс, метод, функция - абсолютно все части программы должны быть покрыты качественной документацией. Опять же, из личного опыта - создаваемые и проектируемые мной программы это 60% кода и 40% документации.
Сопровождаемость 🛠
Программы должны иметь адекватную сопровождаемость. Если код написан таким образом, что любая доработка напрочь роняет всю архитектуру - грош цена такому коду. Опять же, программы это не что-то фиксированное на веки вечные. Это срез решения какой-то конкретной задачи на какой-то момент времени, глазами конкретного программиста.
Наивно полагать, что условный программный код станет эдаким монолитом-гегемоном, навеки запечатлевшим безупречное видение некоторого автора. Отнюдь - развитие любого программного кода это неизбежность - в простом виде это доработка, а в сложном - переписывание кода с нуля. И дальнейшая судьба любого созданного кода, во многом зависит от его потенциальной сопровождаемости.
Пиши код, имея в виду неотвратимые последующие доработки в нем, или тобой самим, или другими людьми. Изначально закладывай в свой код возможности по дальнейшему развитию продукта. Не старайся создать программу подобно хрупкой скульптуре - не делай так, чтобы для небольшого изменения формы, приходилось выкидывать старую скульптуру, и ваять её целиком заново.
Масштабируемость 📈
Хороший код должен быть масштабируемым. Что значит это красивое слово? Буквально - хорошие программные продукты склонны развиваться и расти. Удачно сделанный сайт сегодня будет иметь посещаемость 300 человек, а завтра 5000 человек. Полезное приложение соберет аудиторию сначала в 100 человек, а далее возможно и в 100 тысяч человек.
Разумно создавать программы, изначально закладывая возможности по их дальнейшему росту. Не всегда это удается, но лучше иметь в виду дальнейшее развитие любого из создаваемых модулей - и желательно не через радикальный метод его полного перепиливания.
Высокая скорость 🚀
При прочих равных условиях, мы всегда ожидаем от компьютера высокой скорости отклика. Никому не нравятся веб-страницы, которые загружаются больше 2-3 секунд. Никто не любит приложения, которым надо внезапно скачать обновление размером в несколько гигабайт. Не встречал я ещё человека, который был бы в восторге от внепланового вечернего апдейта Windows перед выключением ноутбука.
Создавай программы таким образом, чтобы они работали максимально быстро при имеющихся условиях. Старайся выбирать такие алгоритмы и подходы к проектированию, которые решают поставленную задачу прямым образом - чем проще, тем лучше. Экономь своё время как разработчика, экономь время своих пользователей, экономь ресурсы оборудования.
Если твой проект может обойтись без jQuery - это просто прекрасно. Если для разработки программы тебе не нужно тащить туда Symfony / Doctrine / Yii / любые другие огромные фреймворки или библиотеки - ты просто волшебник. Если тебе нужна одна-единственная иконка, пожалуйста постарайся обойтись без FontAwesome.
Тестируемость 🔨
В продолжении к пункту о предсказуемости. Хороший программный код - это хорошо оттестированный программный код. Даже если в какой-то момент в голову закрадывается лукавая мысль о том, что созданный код "ну никак не может содержать ошибок". Всегда, абсолютно всегда находятся уникальные, неожиданные, невероятные обстоятельства - при которых предсказуемый программный код начинает вести себя неожиданным образом. Чем лучше будет протестирован твой код - тем меньше последующих капиталовложений в его обслуживание нужно будет совершить. Не пренебрегай тестированием.
Extra - бонус: правило "уточки" 🦆
Есть такой прекрасный анекдот на тему качества (а хотя, это часто не анекдот, а правда жизни) - "Если среди Ваших знакомых нет чудаков, у меня есть для Вас некоторые новости". И выводимый из этого анекдота следующий принцип: "Если ты считаешь, что все вокруг не правы в каком-то вопросе, хорошенько подумай об этом ещё раз".
С точки зрения программирования (да пожалуй и в любом другом деле) важно искать некую точку баланса. Это точка равновесия между личными взглядами, и представлениями окружающих. Конечно, не нужно прогибаться под первое пришедшее извне мнение, но так же не следует игнорировать советы коллег и старших специалистов. Ищи золотую середину, друг мой. Будь в балансе! Не будь уточкой!
На днях - вторая часть. Кто такой "Плохой" и каковы его принципы.
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Для тех, кто хочет не просто читать о программировании, а начать свой путь джедая прямо сейчас, приглашаю на Boosty! Там эксклюзивный обучающий материал по программированию для любого уровня подготовки. А ещё там можно посмотреть, как автор выглядит в жизни. Жми сюда и полетели!🚀
P.S.2 Ещё у меня есть Telegram-канал. Там посты чуть проще и веселее. Ссылка
P.S.3 Предлагаю делиться в комментариях личным взглядом на наилучшие подходы к программированию. Случаи из жизни и поучительные истории из IT приветствуются!
