Написание кода для людей | Кодементор
Проблема: Ваш мозг
Наш хилый мозг может обрабатывать очень ограниченное количество логики за раз. Хотя программисты провозглашают логику своей областью, они лишь иногда и немного лучше справляются со сложностью, чем остальные из нас, смертных. Чем больше логики в нашем приложении, тем сложнее его изменить или познакомить с ним новых людей.
Самая распространенная ошибка программистов состоит в том, что они предполагают, что пишут код для чтения машиной. Хотя технически это верно, такое мышление ведет к аду, который является кодом других людей.
Я работал в нескольких стартап-компаниях, некоторые из них даже считались «бережливыми». В каждом из них мне потребовалось от нескольких недель до нескольких месяцев, чтобы полностью понять их кодовую базу, и у меня около 6 лет опыта работы с JavaScript. Мне это вообще не кажется разумным.
Если код нелегко читать, его структура уже представляет собой памятник — вы можете изменить мелочи, но серьезные изменения — те, которые каждый стартап претерпевает чуть ли не ежемесячно, — так же интересны, как и корневой канал. Как только код достигает такого состояния, что для опытного программиста его труднее читать, чем эту статью, — вас ждут гибель и страдания.
Почему код становится нечитаемым? Давайте сравним код с обычным текстом: чем длиннее предложение, тем легче нашему разуму забыть его начало, а дойдя до конца, мы забываем, что было началом, и теряем смысл всего предложения. Вам пришлось прочитать предыдущее предложение дважды, потому что оно было слишком длинным, чтобы ухватиться за него? В яблочко! То же самое с кодом. Хуже того, на самом деле логика кода может быть намного сложнее, чем любое предложение из книги или сообщения в блоге, и у каждого программиста есть своя собственная логика, которая для другого может показаться полной тарабарщиной. Не говоря уже о том, что нам также нужно помнить о логике. Иногда мы возвращаемся к нему в тот же день, а иногда и через два месяца. Никто ничего не помнит о своем коде после того, как не смотрел на него два месяца.
Чтобы сделать код понятным для других людей, мы полагаемся на три вещи:
1. Соглашения
Условные обозначения хороши, но они очень ограничены: слишком мало их применять, и программист привязывается к коду — никто никогда не поймет, что они означали, как только они исчезнут. Применяйте слишком много, и у вас будут часовые дебаты о каждом пробеле и двоеточии (правдивая история). «Обитаемая зона» очень узкая, и ее легко пропустить.
Они, вероятно, самые полезные, если все сделано правильно. К сожалению, многие программисты пишут свои комментарии в том же духе, что и код, — очень своеобразно. Я не принадлежу к школе, утверждающей, что хороший код не нуждается в комментариях, но даже красиво прокомментированный код может быть чрезвычайно сложным.
3. «Другие люди знают этот язык программирования так же хорошо, как и я, поэтому они должны понимать, что я пишу».
Ну… Это JavaScript:
4. Тесты
Тесты — это замаскированный дьявол. «Как нам убедиться, что наш код хорош и удобочитаем? Пишем больше кода!» Я знаю, что многие из вас могли бы бросить этот пост прямо здесь, но потерпите еще несколько строк: независимо от их пользы, тесты — это еще один уровень логики. Это больше код, который нужно читать и понимать. Тесты пытаются решить именно эту проблему: ваш код слишком сложен, чтобы вычислить его результат в вашем мозгу? Итак, вы говорите: «Ну, вот что должно получиться в конце». А когда этого не происходит, вы начинаете копать проблему. Ваш код должен быть достаточно простым, чтобы прочитать функцию или строку и понять, что должно получиться в результате ее выполнения.
Ваша жизнь программиста может быть намного проще!
Я разобью этот подход на практические моменты, но основная идея такова: используйте МЕНЬШЕ логики.
— Сократите 80% функций вашего продукта
Да! Просто так. Простота, прежде всего, исходит от продукта. Сделайте его простым для понимания и использования. Заставьте его делать что-то одно хорошо, а уж потом складывайте (если еще есть необходимость.)
Используйте только то, что вам абсолютно необходимо
Не включайте ни одной строки кода (особенно из библиотек), в котором вы не уверены на 100%, что будете использовать, и что это самое простое и прямолинейное доступное решение. Вам нужно простое приложение для чата и используйте Angular.js, потому что он хорош с двусторонней привязкой? Вы заслуживаете тех часов и дней отладки и дебатов о сервисах и поставщиках.
Боковое примечание: API-интерфейс браузера JavaScript управляется событиями, он создан, чтобы реагировать, когда что-то (обычно пользовательский ввод) происходит. Это означает, что события изменяют данные. Многие новые фреймворки (Angular, Meteor) меняют это направление и заставляют изменения данных запускать события. Если ваше приложение простое, вы можете счастливо жить с новым таинственным слоем, но если нет — вы получаете совершенно новый слой сложности, который вам нужно понять, и ваша жизнь станет экспоненциально более несчастной. Если ваше приложение постоянно не управляет большими объемами данных, избегайте этих фреймворков.
— Используйте простейшую логику
Скажем, вам нужно показывать разные HTML в разных случаях. Вы можете использовать клиентскую часть
маршрутизация с помощью контроллеров и данных, передаваемых каждому контроллеру, который отображает HTML из шаблона. Или вы можете просто использовать статические HTML-страницы с обычной навигацией в браузере и вручную обновлять HTML. Используйте второй.
— Сделать короткие файлы Javascript
Ограничьте длину ваших JS-файлов одной страницей редактора и заставьте каждый файл выполнять одно действие. Не можете втиснуть всю свою великолепную логику в маленькие модули? Хорошо, это означает, что у вас должно быть меньше этого, чтобы другие люди могли понять ваш код в разумные сроки.
— Избегайте прекомпиляторов и таск-раннеров
Чем больше слоев между тем, что вы пишете, и тем, что видите, тем больше логики нужно помнить вашему разуму. Вы можете подумать, что grunt или gulp помогут вам упростить вещи, но тогда у вас есть 30 задач, которые вам нужно запомнить, что они делают с вашим кодом, как их использовать, обновлять и обучать им любого нового программиста. Не говоря уже о компиляции.
Примечание № 1: прекомпиляторы CSS хороши, потому что в них очень мало логики, но они очень помогают с точки зрения читаемой структуры по сравнению с простым CSS. Я почти не использовал предварительные компиляторы HTML, поэтому вам придется решать самостоятельно.
Примечание № 2: таск-раннеры могут сэкономить ваше время, поэтому, если вы их используете, делайте это с умом, сохраняя минималистский настрой.
— Используйте Javascript везде
Это довольно специфично, и я не совсем уверен в этом, но наличие одного и того же языка в клиенте и сервере может упростить управление данными между ними.
— Пишите более человеческий код
Дайте вашим нетривиальным переменным (и функциям) описательные имена. Делайте более короткие строки, но только если это не ставит под угрозу читабельность.
Относитесь к своему коду как к поэзии и сводите его к минимуму.
