В техническом сообществе мы часто видим блоггеров, пропагандирующих различные [расширенные функции] и [расширенные режимы] языков программирования и дающих некоторый [элегантный] код, использующий эти функции. Так хорошо или плохо учиться и использовать эти вещи, и каковы плюсы и минусы? Эта статья призвана помочь вам составить собственное мнение.
Сообразительность и великая мудрость навыков
Многие люди гордятся тем, что используют непопулярные особенности языков и фреймворков, и показывают свое знакомство с фреймворками, используя различные нераспространенные API, а потом думают, что их программные способности и технический уровень выше, чем у студентов, которые пишут простую логику. Разумно ли это мнение? Ниже мы используем несколько примеров, чтобы сделать вывод:
Во-первых, при наборе и развитии студентов наблюдается очень интересное явление, то есть для кандидатов более высокого уровня проверка конкретных навыков кодирования меньше, а проверка архитектурных способностей, понимания бизнеса и инженерного качества больше. . Обратите внимание, что понимание архитектуры, бизнеса и инженерии — это отнюдь не обобщенные коммуникативные, управленческие и прочие [мягкие качества], а твердая профессиональная способность инженера.
С другой стороны, наиболее популярным контентом в техническом сообществе часто является [Руководство по началу работы] различных фреймворков и библиотек классов. От различных популярных моделей [XXX от входа до мастера] до [Научим вас изучать XXX вручную], самым популярным контентом по-прежнему являются технические знания о том, как настроить эти API и как установить режим.
Объединив эти явления и немного здравого смысла, мы можем получить следующие три условия:
- Чем продвинутее программист, тем меньше доля технических знаний в дереве способностей.
- Доля старших программистов намного меньше доли младших программистов.
- Большую часть сообщества программистов больше всего интересуют технические знания.
По этим условиям можно сделать неточный вывод: **Наиболее озабочены и одержимы навыками программирования, пожалуй, большинство программистов младшего звена. ** Таким образом, акт демонстрации навыков не сможет продемонстрировать превосходный технический уровень.
Чтобы уточнить, здесь мыОпределенно не то, чтобы навыки программирования были неважными. И наоборот, продвинутые программисты явно лучше знакомы с методами, чем студенты младших курсов, и многие технические коды на порядки лучше оптимизируют и решают проблемы. Итак, как мы должны оценивать такой код?
Учащиеся, которые могут использовать различные расширенные функции, несомненно [сообразительны]. Однако, когда и как его использовать, требуется так называемое «мудрое» суждение. Время от времени эта фраза звучит в спецификациях кода Facebook и Google:
Use your best judgement.
Хотя это звучит хорошо, на самом деле это очень метафизическая концепция. Ниже мы проведем более конкретные обсуждения, извлекая некоторые общие приемы и приемы.
общие приемы
Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.
- Толстой
Хороший код похож, плохой код плох по-своему.
Если мы оцениваем определенный фрагмент кода с помощью «умелых навыков», то качество этого кода, вероятно, не намного лучше. Для кода, использующего различные приемы, мы также можем найти довольно много плохо используемых приемов, которые указывают на соответствующие проблемы.
Используйте опасную семантику
После прочтения некоторых книг, таких как [XX Advanced Programming], многие люди будут применять их в реальных проектах, чтобы продемонстрировать свое понимание [Advanced Features]. В категории внешнего интерфейса эти действия включают, но не ограничиваются:
- учиться
==и===После различия используйте разные символы в разных случаях, чтобы понять логику суждения. - учиться
变量提升, используйте его для реализации особого порядка выполнения кода. - учиться
prototypeиconstructorВпоследствии используйте их для реализации различных отношений наследования. - учиться
thisПосле различных правил указания используйте специальные правила для привязки контекста. - ...
Код, который использует эти функции, конечно, будет работать, но проблема здесь в том, что эта семантика либо опасна, либо отбросы проблемы дизайна в языке. **Зачем использовать их, чтобы продемонстрировать свое мастерство, если вы знаете, что их сложно использовать, и есть зрелые альтернативы? **В сообществе фронтенда такое поведение идет одно за другим. Например, просто понимание различныхthisуказать на правила достаточно, чтобы написать длинную статью (это уже скучная статья в Nikkei во многих технических сообществах). и==Есть много людей, которые читают блог [глубокое мастерство] и используют его [разумно]. Что касается变量提升Такие совершенно нелогичные недостатки дизайна часто используются людьми для составления всевозможных причудливых вопросов для интервью.
Конечно, это никоим образом не противоречит пониманию того, как работают эти так называемые [расширенные функции] и почему они приводят к запутанному поведению. Для каждого надежного ученика, который хочет вырасти, очень важно их выучить. Совет, данный здесь:
- выучить их хотя бы разбыть в состоянии указать, где проблемаСтепень.
- Изучите альтернативы этим функциям и узнайте, как избежать ловушек.
- Никогда не используйте их в своем коде, если вы не поддерживаете базовую библиотеку.
Каждый язык программирования неизбежно оставит унаследованные проблемы в своем собственном процессе разработки. Эта проблема еще более серьезна для такого языка, как JS, который родился в выходные и требует очень высокой прямой совместимости. Но с развитием разработки программного обеспечения опасная семантика этих конструктивных недостатков постепенно ушла из истории, и теперь их глубокое изучение, освоение и использование так же устарели, как погружение в проблемы совместимости с IE6. И если кто-то использует эти вопросы, чтобы усложнить вам задачу, вы можете вернуться следующим образом:
Да, я знаю
thisЕсть четыре метода привязки, и я также знаю, что есть четыре способа написать Huizi.
Применение шаблонов проектирования
В общем, какие-то "паттерны" в программе действительно есть, хотя бы буквально. Потому что вы всегда можете опираться на предыдущий опыт и использовать его для построения новых программ. Вы можете назвать этот опыт «образцом». Но с тех пор, как в 1994 году была опубликована книга «Шаблоны проектирования» (часто называемая GoF, «Банда четырех», «Банда четырех»), слово «шаблоны проектирования» приобрело новый, искаженный смысл. Это стало догмой, что привело к серьезным осложнениям и неэффективности процедур компании.
Шаблоны проектирования также являются очень популярной темой технических статей. Например, есть много статей, в которых более дюжины паттернов из раздела «Шаблоны проектирования» перенесены в JS, а затем используются различные [расширенные возможности], упомянутые выше, для имитации этого и реализации того, и, наконец, возвышенное, что все эти паттерны [ Отличные программисты должны владеть мастерством], поэтому добавление строки [Освоение различных шаблонов проектирования] в вашем резюме просто ошеломляет!
Первоначальная цель шаблонов проектирования — восполнить недостатки статических языков, таких как Java. Многие [классические] шаблоны проектирования уже давно являются частью языковой механики в эволюции языков программирования. Например,exportВстроенная поддержка шаблона singleton, используйте содержимоеfunctionУпаковочный слой является фабричным рисунком,yieldТакже реализует шаблон итератора и многое другое. Другой пример: динамическая природа JS делает JSON намного более гибким, чем отражение, а дизайн функций первого класса граждан также делает функцию обратного вызова JS намного более гибкой, чем интерфейс обратного вызова или посетитель Java и другие режимы.
Многие статьи, пропагандирующие шаблоны проектирования, ядовиты не потому, что они искусственно создают ненужную сложность, а вместо этого создают иллюзию, что вы недостаточно хороши, если не используете шаблоны XX. По крайней мере, в исходниках отличных опенсорсных проектов, которые я читал, я не нашел места для копирования паттерна, а для описания решаемой кодом задачи, а потом давал легко читаемую абстракция. Вы, конечно, можете задним числом заключить, что они реализуют определенные шаблоны, но я предпочитаю верить, что авторы не кодировали образ мышления [шаблон XX здесь]. Однако многие начинающие студенты, не обладающие способностью различать, если у них нет опыта чтения качественного кода, могут также встать на восьминогий путь установленной модели под [потворством] старому кодексу исторический проект компании. Я подумал, что это жалко.
Сжатые строки кода
Все мы знаем, что копирование и вставка длинного повторяющегося кода — это плохо. Однако копирование и вставка чаще всего происходит в сценариях, когда период строительства сжат и уже слишком поздно для оптимизации. Судя по интенсивности работы учеников Небесной Династии, это тоже понятно. А наоборот, это другой вид перебора, то есть для того, чтобы добиться "самого простого" кода, использовать разные невообразимые средства для "упрощения" кода.
Например, студенты, которые только начали заниматься функциональным программированием, могутa(b(c(d, e(f, g))))Я питаю слабость к такого рода коду. Я думаю, что за счет глубоко вложенных функций промежуточные переменные можно сильно сократить, тем самым сэкономив объем кода. Другой пример: некоторые студенты любят связывать различную логику суждений с логическими операторами и строковыми их вместе за один раз.a || b && c && dТакая логика суждения записывается в одну строку, также для служебных функций также принято писать больше параметров, а затем [передавать все параметры в одну строку].
Давайте еще раз подумаем, действительно ли этот код более читабелен? Глубоко вложенные вызовы функций могут привести к большому количеству ошибок.))))))Правильная скобка , которая долгое время подвергалась критике в Лиспе; однострочная логика оценки не способствует отладке; поведение функций, которые передают большое количество параметров, имеет тенденцию быть сложным и трудным для отладки (подумайте о часовом поясе вступительных экзаменов в колледж).f(x, y)Сколько трюков вы можете сыграть?f(a, b, c, d, e)насколько сложными могут быть перестановки и комбинации переменных).
Все эти методы кодирования легко и безболезненно заменяются более читаемыми формами, и это не имеет большого значения. но,Намеренно создать такой кодСколько будет стыдно с сопровождающими за спиной. Для конкретных методов переноса строк и отступов используйте формуJavaScript Standard StyleТакой инструмент может автоматически обрабатывать подавляющее большинство случаев.
Неявно переписывая здравый смысл
Explicit is better than implicit.
Современные инженерные фреймворки обычно предоставляют множество настраиваемых интерфейсов, с помощью которых разработчики могут легко переопределить поведение фреймворка. Например, React открывает контекст, а такие библиотеки, как Redux и MobX, используют этот интерфейс для значительной оптимизации.propsГлубокий опыт. Тем не менее, существует множество неявных [консенсусных] соглашений о структуре, которые вызовут большие проблемы, если они необоснованно настраиваются в общем бизнес-коде. Этот тип переписывания обычно происходит в незаметных местах, но его влияние часто очень велико.
Например, в проекте, который мы поддерживали, былоReact.ComponentБазовый класс [незаметно] переписан и заменен своим собственнымXXX.BaseComponentповедение. Кастомизированный компонент не имеет никаких изменений, связанных с бизнес-логикой, но добавляет какой-то необъяснимый код инициализации. Таким образом, [общий здравый смысл], изначально подразумеваемый базовым классом компонентов React, недействителен. Когда дело доходит до технического обслуживания, замененный компонент может показаться на первый взгляд ничем особенным, но при замене может вызвать проблемы. Более того, эти черные технологические коды не имеют ни комментариев, ни документации, не говоря уже о том, что их первоначальное намерение решить. Для таких практик кодирования, я боюсь, что в дополнение кбыть умнымНет более разумной оценки.
В качестве другого примера, в этом проекте есть еще одна [гениальная] практика, котораяwindow.fetchЗамените тремя или четырьмя различными пользовательскими версиями в зависимости от запрошенного пути (не волнуйтесь, я не скажу вам, почему!). Таким образом, когда сопровождающий пишет новыйfetch, вы не можете использовать ни один из предыдущихfetchНеявное существующее знание, но его необходимо проследить до настроенной версии предшественника для отладки, разве это не удивительно?
Есть и неявные практики, проблема с [побочными эффектами]. Например, когда вы видите предложениеuser = getUser(id), вы, вероятно, не хотите этогоgetUserФункция не только помогает вам опрашивать пользователей, но также беззвучно воспроизводит подсказку, отправляет запрос и очищает текущие данные? Конечно, в области интерфейса часть сложности заключается в управлении большим количеством побочных эффектов, таких как пользовательский интерфейс и сеть. Однако, если вызов функции имеет много последствий, многие сопровождающие могут отказаться от перезаписи, что еще больше усложнит задачу.
Конечно, я считаю, что многим производителям по-прежнему понравится код с неявными побочными эффектами. Например,Неявная установка 360 для Family Bucket.
заново изобретать колесо
Коллекции в виде [наиболее распространенных функций интерфейсных инструментов] часто можно увидеть в техническом сообществе, и их лайки часто очень высоки. Однако действительно ли игровая карта Bully 500-в-1 веселее, чем Super Mario?
Автору посчастливилось прочитать несколько таких статей, и он обнаружил, что эти упакованные функции часто даже не имеют фиксированной темы: леваяgetCookie, правыйdeepClone,ПредыдущийisEmail,СледующийscrollTop. Каждая из этих реализаций имеет всего несколько строк комментариев уровня [перевести названия функций с английского на китайский] без тестовых примеров, конфигураций зависимостей и документации.
Стоит ли копировать такой код в свой проект для повторного использования? Проще говоря, они просто продукт удовлетворения сексуального влечения [я могу строить колеса]. Лично я, конечно, полностью верю, что у автора есть возможность написать элегантную глубокую копию, но проект — это не интервью. нужный. Согласно опыту «Мифа о человеко-месяце», фактическое время кодирования в программном проекте составляет только 1/6, а оставшееся время требует большего тестирования, документации и коммуникации. Для более качественного библиотечного кода действительно ли работает написанный от руки или скопированный (о нет, встроенный, мягко говоря) код?
При использовании библиотеки классов в формальном проекте, если существующая стабильная зависимость может соответствовать требованиям, очевидно, что это первый выбор. Если вы столкнулись с местом, где вам нужно построить свои собственные колеса, то постарайтесь сделать оставшиеся 5/6 надежного проекта в дополнение к коду, и не повторяйте изобретение некачественных колес.
Стремление к абстракции высокого уровня
Последний пункт, вероятно, относительно небольшой, потому что для многих людей, которые могут достичь своих потребностей только путем копирования и вставки, это явно противоречит их привычке. Однако из-за этого это более продвинутый [Искусный навык].
[Дополнительно] Звучит как святой Грааль. [Функции высшего порядка] и [Компоненты высшего порядка] кажутся идеальным выбором для [программистов высокого уровня]. Однако что вы думаете, если вам нужно поддерживать такие функции более высокого порядка?
() => () => () => () => 123
Один返回返回返回返回 123 的函数的函数的函数的函数, действительно очень высокого класса, но не будет ли это вас смущать...
Суммировать
Если многие студенты дочитают до конца (терпят), чтобы попасть сюда, они могут пожаловаться [Эти навыки очень важны в сложных, продвинутых и других сценариях, бла-бла], поэтому я уточню несколько моментов в конце:
- Большинство навыков, влияющих на ремонтопригодность, не только не должны появляться в повседневной бизнес-логике, но их также следует по возможности избегать. Особенно в отношении таких мотивов, как [API, который я изучил вчера], мне нужно дважды подумать.
- В серьезных крупных проектах с открытым исходным кодом неизбежно много технических хаков. В это время вы, вероятно, обнаружите, что в соответствующих местах будет много комментариев, чтобы рассказать вам, почему вы написали это.ОченьУ него стоит поучиться.
- Это не против овладения передовыми навыками программирования, а в надежде не опрометчиво внедрить какие-то «умные» коды в формальные проекты, которые принесут неудобства в последующем сопровождении.
- Если вы хотите избавиться от тяжелого бремени бизнес-проектов и научиться [правильно использовать приемы и приемы], участие в проектах с открытым исходным кодом может быть коротким путем. В связи с этим следует надеяться, что предшественник этой статьиРуководство по вкладу сообщества с открытым исходным кодом с нуляможет помочь.
Наконец, для возможных сомнений, личноеGithubВ нем есть несколько простых игрушечных колес, пожалуйста, не стесняйтесь жаловаться... 😅