Качество - это спекулятивная мера оценки чего либо. Вот какой код качественный? Скажем код который хорошо выполняет бизнес задачу? Он достаточно качественный, а если это либа, которую мы скачали из интернета, подключили и вызвали одной функции, скажем код 4-е строчки со скобочками ?
Как к примеру оценить качество iPhone в сравнении с Android? Тут огромное поле для спекуляций.
Если попытаться дать определение качественному коду - то это код, который хорошо выполняет свою функцию легко читаем и понятен другому разработчику. И смотрите, мы получили качественный код, который не обязательно должен быть строготипизирован. Который безусловно должен быть покрыт тестами. Просто некий код который понятен, легко читаем и выполняет свою функцию. И вродебы сложно не согласиться.
Тут еще можно порассуждать на эту тему, но зачем. Написана целая книжка Чистый код, есть принципы SOLID. Проводилось масса дескуссий. И всеровно нету такого кода, который я бы распечатал, повесил на стену, и смотрел бы как на эталон качества.
Я могу вот всего в пару слов разделить, все задачи на две большие группы. Фичи которые - безусловно надо запилить и эксперементальные. Смотрите, ребята из бизнеса, продукты, и прочие они толком то и не знают как должно приложение работать в точности. Зачастую у них есть примерный вижен, как это должно работать. А дальше все опытным путем. Запилил - выкатил - протестировал - удалил. Запилил - выкатил - протестировал - оставил. Давайте назовем это итеративная разработка.
Просто пара слов в доказательство. Если бы все точно знали что вот именно такая функциональность востребованна и нужна именно в таком виде. То риски на создание проекта были бы ничтожны. Такое бывает. Особенно когда происходят сливы или ктото получает инсайдерскую информацию о готовящемся релизе такогото продукта с такой вот функциональностью.
Тогда да бац и без ошибок сразу в релиз. Хороший пример это выпуск нового iPhone, когда китайцы могут за пару месяцев раньше релизнуть либо такой же, либо не хуже. Да и посмотрите на фичи iPhone & Android на презентациях. Ну они явно шпионят друг за другом.
В общем я к чему - для решения безусловных задач, конечно нам бы хотелось иметь код мегакачетвенным, так как это ключевые фичи. Мы хотим, что бы они работали хорошо. И мы написав этот код один раз, неменяли его никогда, только максимально дешего саппортили.
Ок, допустим. Скажем это займет Х времени. Но внедрение эсперементальных фичей должно быть просто молниеносным, что бы бизнес был конкурентноспособным, надо постоянно эксперементировать, на основании результатов экспериментов строить новые гипотезы... Это не менее важно чем безусловные фичи. Так вот скажем внедрение такой фичи должно занимать 0.1X. Как этого добиться этого при том же качестве.
Скажем если это одна и таже задача. Просто в одном случае она безусловная, во втором эксперементальная.
Практика показывает, что никак.
Во втором случае нам выгоднее всего говнокодить. Но таким образом, что бы какашку было легко выкинуть при необходимости. И так же легко доработать до нужного состояния.
В частном случае, это может быть фича вне проекта, просто демо возможностей. Типо поиграться посмотреть как оно ведет себя. Или какой либо драфтовый прототип, показывающий какойто кейс. Который можно потом доработать в отдельный проект, или использовать как некую спеку для реализации фичи в проекте.
Я веду к тому, чтобы мы не сильно заостряли свое внимание на качестве, намного больше важен порядок в коде и архитекутра. Как в конце концов написанна конечная функция, это уже дело десятое, если ее леко выпилить или заменить.
Если задуматься над вопросом насколько сложно делать качественно. Мы вернемся к размышлениям о комьюнити и всем предыдущим разделам.
Смотрите, если вы задали тон, решили архитектурные вопросы. А так же смогли найти общий язык с братьями по коду. То писать качественно не составит труда. Скажем так, вы будете довольны качеством вашего проекта.
Если мы говорим о продукте вцелом, то сделать продукт качественным, а значит ценным для его пользователей очень сложно. Потому что это вцелом вопрос работы компании, маркетинг, сервисы поддержки, программисты. А так же перформанс приложения, accessability и тп.
Если подменить слово качество, на ценность. То смотрите, чем больше у вас клинетов тем тяжелее. Для привлечения большой аудитории вы будете жертвовать качеством / ценностью для одних пользователей в угоду другим. Так как для каждого вашего клиента или пользователя в продукте развные фичи буду ценны.
Особенно если вы не продвигаете свои ценности наружу. Тоесть в случае если клиенты разделяют ваши ценности можно снизить цену на качество. Так как вы сами будете лидером мнений, и будете решать что ценно для пользователей а что нет.
По сути вы перестанете распыляться на миллион фичей и обещаний. А сфокусируетесь на том что вам и вашим пользователям ценно. У вас будет единое мнение о ценности продукта. Вместе с разработчиками которые его делают.
Вот ряд простых правил которые я разработал для себя. Которые вписываются в общую картину предыдущих рассуждений.
Пишите код максимально нативно, старайтесь не злоупотреблять, или не пользоваться code sugger. Любой сахар может сойти на нет, при развитии синтаксиса, а в JS последние пару лет прям очень горяче с этим.
Как пример люди подсевшие на jquery или lodash не могут его не использовать. Просто инклудают его везде, используют его методы когда давно есть нативные методы, делающие тоже самое стандартным способом. Почему это плохо? Потому что человек который будет читать этот код, возможно не вы, должен будет знать jquery / lodash или им придется с ним разбираться. Это зачастую неоправданное усложнение.
У вас есть возможность написать, нативный код, пишите нативный. Тоже самое касается CSS / HTML. Я это писал раньше но еще раз повторю. Да можно подключить Less / Sass / Stylus, шаблонизаторы. Если разница, профит не велик, то возможно они нам не нужны. Возможно мы лишь повышаем сложность входа в проект таким образом. Сейчас самое время опомниться. И начать писать нативнее, ванильней.
Сдругой стороны крайне протеворичивое правило.
Писать на последних стандартах, внедрять их, и адаптировать. Я не смог дропнуть babel из своей жизни, мне он нравиться. Но я стараюсь использовать только те фичи что идут в стандарт, без всяких сахорочков аля: Это бы было слишком удобно, но повысило бы порог входа в проект.
К примеру, появились промисы, используйте их, дропните нафиг колбэки. Выделите время пройдитесь почистите проект. Потом - появились async / await. Снова пройдитесь, обновите код.
Таким образом, код всегда будет достаточно хорош и мало кто посмеет сказать: "Что за говно у вас тут - сэр?".
И последнее правило, декомпозиция, используй ее всягда когда можно. Файлы размером в 2-3 экрана это дичь, такого не должно быть в принципе если мы говорим о JS.
Само собой SOLID, само собой все что мы обсуждали про архитектуру и прочее.
Ну только так, а как иначе то.
Если мы постоянно ищим и выносим типичный код в декораторы, делаем декомпозицию и у нас простой флоу данных. То безусловно код будет писать легче. Больше всего замедляют написание код весчи которые должны как бы упростить нам жизнь. Это линтеры, всякие тайпскрипыты, и прочее.
Мы уже обсужадли это в разделе технологии. Немного дополню.
Мне как то оч давно, учитель по программированию сказал: "Make it works, Make it done". И вот, все, что блокирует мне написание грязного тестового кода, который я безусловно приведу в порядок позже, когда соберусь его показывать всему миру. Мешает невероятно.
Это не только я такой поломанный, опросы ребят показал, что большинство сначало пишит простой код, как привыкли. Потом начинаю пробелы расставлять, типы дописывать. И это самый последний этап.
Так что все таки чекеры максимум могут на прекомите висеть, что бы не раздражать во время работы.
Ладно к этому мы еще вернемся.
Вообще в IT мы можем все. Самый главный вопрос, а что мы с этого поимеем.
Отвечайте так на провокационные вопросы, когда вам пытаются навязать какую либо работу, или внедрение какого либо говна. "Ребята а мы можем переписать это все на typescript?" - само собой ответ да, поэтому нас и спрашивают. Что бы мы решили, что это было типо наше решение. Дешовые трюки...