Что, черт возьми, означает красивый код? Он существует в серверной части?
Заявление об отказе от ответственности: автор этого сообщения - предвзятый и упрямый внутренний разработчик. Есть много статей / книг о передовых методах работы и правилах кодирования, которые, я уверен, большинство из нас прочитали и следовали. Следующее не об этом.
Между разработчиками внешнего интерфейса (FE) и внутреннего интерфейса (BE) всегда идет битва из-за того, что последние пишут уродливый код, потому что никто не сможет его прочитать, а тем более понять его, кроме них (и давайте будем честными, иногда через несколько месяцев те, кто написал код, захотят его реорганизовать, но это жизнь).
Не могу не подчеркнуть, насколько я категорически не согласен с этим мнением. Если вы разделите то, что нужно разработчикам FE / UI, от их коллег BE, на самом деле это полезная нагрузка. Да, все сводится к объекту (независимо от языка), который они используют, они реструктурируют его в соответствии с потребностями функции, а затем, вуаля, красиво доставляют его (если им повезет с помощью хорошего дизайнера UX и CSS) на экране.
Однако я видел уродливый и столь же красивый код в сфере BE. Но что такое красивый код?
Обладает ли он знаниями и способностью использовать новейшие крутые возможности языка «А»? Реализует ли он наилучшие шаблоны проектирования, соответствующие задаче «X»? Это (ре) структурирование кодовой базы в компонентах / модулях в соответствии с архитектурой «Z»? Это добавление комментариев? Написание (модульных) тестов для ваших функций (методов) для того, чтобы ваши коллеги (и ваше будущее я) поняли, какого черта вы сделали? Пишет ли он читаемый код, часто за счет отказа от классных приемов программирования, которые могут уменьшить количество строк в вашем коде? Или дело в эффективном коде? А как насчет устаревшей кодовой базы? Как можно писать красивый код, будучи технологически несовершенными и неспособными использовать новейшие фреймворки и новые языковые функции?
Нет только одного ответа. Напротив, ответ - все вышеперечисленное. И, конечно же, это зависит от вашего опыта, зоны комфорта или даже понимания того, как их сверстники используют код.
Хотя я считаю, что эффективность - очень важный аспект, который побуждает нас, разработчиков, писать красивый код, у вас нет возможности реализовать одну функцию, написать то, что, по вашему мнению, является красивым кодом, если ваши коллеги не могут этого понять. Когда кто-то впервые смотрит на ваш код, он хочет увидеть что-то самоочевидное (из имени метода / класса / пакета), а затем вникнуть в основу логики и понять ее быстро, сначала интуитивно, а затем глубоко. Это все равно, что читать хорошую книгу, страницу за страницей, по порядку, не переворачивая их. То же и с кодом. Переход от точки A к точке B к точке Z должен иметь смысл, естественный поток. Если есть какие-то юнит-тесты, даже лучше. Они не только помогают укрепить ваш код с точки зрения ошибок, но также объясняют логику реализации функции и направляют вас, как читать код, как его тестировать, как отлаживать. , так далее.
Знание последних тенденций и интересных функций языка помогает с точки зрения эффективности, чистый код, но это не панацея. В большинстве случаев новый способ ведения дел - лучший способ, но, как и в случае со всеми новыми вещами, вы должны действительно знать, как их использовать и какой цели они действительно служат.
Напомним, красивый код - это не просто красивый код. Речь идет о понимании цели, которой служит каждый бит вашей кодовой базы. Наконец, как и в случае с UX-дизайнерами, которые заботятся о пользовательском опыте, я действительно считаю, что backend-разработчики должны заботиться об опыте разработчиков, будучи внимательными к своим коллегам и написав код, который они сами могут понять и улучшить или позволить другим сделать это, когда есть необходимость.
