Как стать автором
Обновить

Комментарии 40

Стандартизация хороша и плоха.


Она хороша, если вы решаете стандартные (однотипные) задачи. Применив стандартные решения вы получите ускорение разработки, уменьшение числа ошибок, взаимозаменяемость, деградацию персонала. Т.е. обычный конвейер.


Стандартизация плоха, если нужно решать нетрадиционные проблемы. Применив разнообразие форм подхода и методов решения, вы получите эксклюзивные решения, увеличение времени разработки и расходов, постоянное развитие персонала. Т.е. экспериментальное производство.


А что надо вам — только вам самим и решать.

Опять же, есть люди, которые как рыба в воде себя чувствуют в зоопарке технологий, а есть те, кто привык все делать по строгой схеме без экспериментов.

Ещё одно преимущество стандартизации Standard & Co обнаружила после выхода новой версии языка TypeScript. Она показалась разработчикам удобнее для разработки, чем Flow, который они уже давно использовали. Разработчики Standard & Co переписали шаблон приложения и библиотеку компонентов интерфейса на TypeScript, сделав разработку проще, а код лаконичнее.

Вот так вот у вас есть стандарты, но тут по решению перейти на тайпскрипт вся компания взяла и переписала ВСЮ библиотеку компонентов (включая календари и пр.) на тайпскрипт.


Вы сами-то в это верите?) Только вот честно.

Если честно, мы так и сделали, переписали ВСЮ библиотеку на хуки и TypeScript.
И сколько человеко-часов было потрачено, если не секрет?
Сейчас сложно сказать, переход занял около двух месяцев, переводом занимался один разработчик, ему иногда помогал второй, оба параллельно решали ещё и задачи других проектов. Чтобы перевести проекты с Flow на TS, не так много кода нужно изменить, а вот с хуками пришлось повозиться.

О, интересно! А вышел ли какой профит от переписывания всё на хуки? Рассчитывались ли какие-нибудь метрики, оценивался ли как-то результат переписывания? Или просто взяли и переписали?

Да! Кода стало примерно на треть меньше, он стал существенно проще. Стали тратить меньше времени на доработки, в часах не измеряли, но это отметили многие разработчики.

Ещё один эффект обнаружили, когда нужно было сделать большую сложную форму с валидацией. Форма на библиотеке до хуков заметно лагала в IE, после обновления на новую версию библиотеки всё заработало нормально.
> мы так и сделали, переписали ВСЮ библиотеку на хуки и TypeScript.
>> на хуки и TypeScript

Что равносильно признанию в собственном безумии.

Можете развернуть мысль?

Могу, но мне лень.

Если вкратце — использование как хуков реакта, так и TS — уже довольно сомнительное решение. Тем более решение переписать на это вот всё библиотеку, которая работает и без этого — это уже неадекватность в квадрате на грани с помешательством.
Могу, но мне лень.

странновато) лень объяснять, но не лень писать комментарии в таком стиле


Использование как хуков реакта, так и TS — уже довольно сомнительное решение

Почему? Хуки — это же по факту функции с замыканиями, функции вполне себе типизируются. Или речь про то, что вы в принципе против хуков, как таковых и проотив ts как такового, а уж вместе — так вообще точно против?


Тем более решение переписать на это вот всё библиотеку, которая работает и без этого — это уже неадекватность в квадрате на грани с помешательством.

Тут возможно соглашусь, если и так всё работало — странно это трогать, а вот если они попутно это переписывали при переделке каких-то других вещей — то почему нет? Ну или переписали потому, что сопровождать код на классах было почему-то сложно

Сперва я хотел написать, что автор вообще поехавший, но решил быть вежливым.

жаль, что конструктива не будет.
так хотелось услышать хоть что-то полезное в "оппозиции" к хукам, а тут только какашкомёты

Хуки в реакте.

1. Нарушают концепцию чистых функций, добавляя в функциональные компоненты внутреннее состояние. А функция с внутренним состоянием — это и есть объект в терминах ООП (свойство инкапсуляции). Классы-компоненты в реакте уже есть.

2. Не добавляют ничего нового по сравнению с классами-компонентами. Фактически, дают второе API, которое делает то же самое. Зачем нам два API для одного и того же — не понимаю.

TypeScript.

1. Не поддерживается нативно ни в браузере, ни в node.js. Перед исполнением вся наша информация о типах вырезается нафиг и в runtime не используется равно никак. Зачем было её вписывать — вопрос риторический.

2. Проверка типов на этапе сборки отлавливает относительно небольшой процент ошибок, и ошибки в бизнес- и просто логике программы (которых большинство) туда не попадают примерно никогда. Зачем нужны такие вериги, польза от которых исчезающе мала?

3. Менее значимая фигня, но её тоже напишу. Можно ли написать такую корректную программу на JS, типы для которой нельзя будет описать на TS без использования any? В production-коде я с таким пока столкнулся только один раз, но сама возможность такого напрягает.

P.S. Приятного аппетита.

Ура, наконец-то конструктив, спасибо! =)


А функция с внутренним состоянием — это и есть объект в терминах ООП (свойство инкапсуляции). Классы-компоненты в реакте уже есть.

Не добавляют ничего нового по сравнению с классами-компонентами. Фактически, дают второе API, которое делает то же самое. Зачем нам два API для одного и того же — не понимаю.

Ну, считайте, что это новая версия api, более лаконичная (на взгляд тех, кто это api продвигает).
Плюс добавляет возможности, которые были выпилены из старого реакта с миксинами (ну, знаете, вынести общую логику подписки/отписки на какие-нибудь события и всё в этом духе).


Вообще в документации про хуки есть аж отдельная секция, посвещённая теме "зачем?" https://ru.reactjs.org/docs/hooks-intro.html#motivation

Перед исполнением вся наша информация о типах вырезается нафиг и в runtime не используется равно никак. Зачем было её вписывать — вопрос риторический.

Звучит как "тесты не используются в runtime, так зачем их было писать вообще?". Очевидно, чтобы проверить какие-то вещи до того, как оно уйдёт на площадку / в прод


Проверка типов на этапе сборки отлавливает относительно небольшой процент ошибок, и ошибки в бизнес- и просто логике программы (которых большинство) туда не попадают примерно никогда. Зачем нужны такие вериги, польза от которых исчезающе мала?

У вас ничем не подтверждённая предпосылка о том, что ошибки типов — это маленький процент ошибок. А мне кажется, что количество шуток про фронтендеров, которые выводят NaN куда-либо или падают со словами "undefined is not a function", намекают на обратную ситуацию.


Можно ли написать такую корректную программу на JS, типы для которой нельзя будет описать на TS без использования any?

Я понимаю на что Вы намекаете (типа, если часто приходится писать any, то нафиг такие типы нужны)? Тут можно согласиться, но лишь в том случае, если такие ситуации действительно происходят часто и выразительность типов TS не дотягивает до нужного уровня (хотелось бы посмотреть, что же такого надо сделать)

Звучит как «тесты не используются в runtime, так зачем их было писать вообще?»

Тесты прогоняются как раз против запущенного приложения, будь то фронтэнд или бэкенд. То есть это тот самый runtime и есть. Или у вас только помодульные тесты?

У вас ничем не подтверждённая предпосылка о том, что ошибки типов — это маленький процент ошибок.

Это мой личный опыт. Если у вас большое количество ошибок, связанных именно с типами — что я могу сказать, фигово быть вами.

А мне кажется, что количество шуток про фронтендеров, которые выводят NaN куда-либо или падают со словами «undefined is not a function», намекают на обратную ситуацию.

1. NaN в JS является вполне допустимым значением для типа number, контроль типов его не поймает.

2. undefined is not a function — это как раз runtime-ошибка. Но в runtime у нас типов УЖЕ нет, потому что см. выше.

В целом, примеры подобраны крайне неудачно.

(хотелось бы посмотреть, что же такого надо сделать)

Минимального куска кода для воспроизведения я не составлял. У меня возникали непонятные ошибки при сочетании generic-типов из библиотек React и Apollo GraphQL. PureComponent<MyPropsType> и так далее.
Тесты прогоняются как раз против запущенного приложения, будь то фронтэнд или бэкенд. То есть это тот самый runtime и есть

Окей, согласен, тесты — это рантайм, я наверно не совсем корректно сформулировал свою мысль: в боевом приложении на проде модульных тестов нету, но это не повод их не писать, если от них есть польза


Это мой личный опыт. Если у вас большое количество ошибок, связанных именно с типами — что я могу сказать, фигово быть вами.

это как посмотреть) можно на это ответить "если вы часто ошибаетесь в логике, то фигово быть вами", но я не хочу делать подобного рода оценочных суждений


по моему опыту — как раз чаще ошибаются в типах (что-то забыли, что-то не проверили, поменяли публичное апи, но не везде адаптировали вызовы и т.п.)


NaN в JS является вполне допустимым значением для типа number,

Это вы пользователям объясните, им этот NaN не даёт никакой информации (кроме информации о наличии ошибки на сайте)


контроль типов его не поймает.

Зато поймает попытки скрещивания string с number (такое бывает) или undefined с number (такое бывает даже чаще)


undefined is not a function — это как раз runtime-ошибка. Но в runtime у нас типов УЖЕ нет, потому что см. выше.

Конечно это runtime ошибка, но которая может быть отловлена на этапе компиляции (точнее, отловлено попытка вызова optional-типа без её предварительной проверки)

Хоть и местами написано вполне разумно, но другими местами сильнейшее натягивание совы «ради статьи». Или же чистые заблуждения, я такие и на практике вполне себе видел.

Стандартизация стека

Популярное заблуждение: если у нас будет везде один стек, то код будет легко переиспользовать.
Реальность: код легко переиспользовать, когда люди могут, умеют, и пишут переиспользуемый код. От технологий и фреймворков это тоже зависит, потому что да, некоторые фреймворки и решения скрещивать довольно сложно — но не так уж и сильно, потому что множество других фреймворков и решений скрещиваются легко, и необязательно даже раздувают код.
Но самое главное тут — то, что общий техстек сам по себе ничего не даёт (кроме теоретической возможности) для переиспользования кода. Можно всем взять реакт и продолжать фигачить неразборные монолитные фронты. Более того, многие так и делают.

Шаблон приложения

Шаблон хорош, когда ваши проекты работают в некоторой общей инфраструктуре, имеют приблизительно один размер и одинаковую нагруженность, и решают задачи плюс-минус одного домена.
Если что-то из вышеперечисленного не выполняется — то шаблонность начинает порождать чудовищ.

Ротация проектов и людей

Популярное заблуждение: «переучивание» фронтэндера с реакта на вью требует неиллюзорного существенного времени.
Реальность: нормальный фронтэндер переходит с фреймворка на фреймворк в течении пары дней, если в команде есть опытный профильный спец по фреймворку, и в течении 2-4 недель (сочетая этот переход с работой, разумеется), если такового спеца нет.

Ну и в остальном там очень многое подходит только к ситуациям, когда у конторы есть только довольно типовые проекты. Если проекты не типовые — добрая половина пунктов будет мешать, а не помогать.
Реальность: нормальный фронтэндер переходит с фреймворка на фреймворк в течении пары дней

Это какая-то параллельная реальность ). Более похоже на фантастическую.
Ровно столько времени нужно, чтоб почитать доки и туториалы (1 день) и попрактиковаться «на кошках» (еще 1 день). Далее человек уже имеет общее понимание о том, как тут всё работает, благо фреймворки работают плюс-минус похоже, и может решать мелкие задачи или даже средние с учётом обязательного код ревью от спеца по фреймворку. Спустя несколько решенных задач — уже и крупные (разработка новых фич) будут вполне доступны.

Если спеца нет — то, конечно, всё проходит медленнее и осторожнее.
По моим наблюдениям, средний фронтенд программист осваивает тот же React не за один месяц, если у вас проект не уровня HelloWorld, конечно. Ну может у Вас есть какие-то знакомые гениальные кодеры, которые за 2 дня любой фреймворк освоят ).
«Средний» фронтэнд — это какой? Что там в бэкграунде? Курсы молодого бойца по ангуляру, или всё же что-то адекватное?
Средний — middle, иногда ближе уже к сеньору. В среднем, минимум 5 лет фронта за плечами.
В таком случае он будет знать базу (vanillaJS, DOM, вот это всё) и подходы реакта не будут представлять для него чего-то сильно диковинное.
Реальность: нормальный фронтэндер переходит с фреймворка на фреймворк в течении пары дней, если в команде есть опытный профильный спец по фреймворку, и в течении 2-4 недель (сочетая этот переход с работой, разумеется), если такового спеца нет.
Вот только счет пойдет на месяца, пока его эффективность (за счет использования своих наработанных решений, знания тонкостей, подводных камней и различных подходов, знания популярных библиотек для этого фреймворка и опыта работы с ними, изучения сторонних и выработки своих best practices) достигнет уровня, который был при работе с его основным фреймворком.
В статье речь идёт о переброске людей между проектами, а не о «сели как-то любители реакта и вдруг решили зафигачить следующий бизнес-критикал проект с чистого листа на вью».

Развивать существующий проект и писать новый — это две большие разницы, делать это с людьми, которые уже поработали над проектом и знают техстек и делать это без таковых людей — две еще более большие разницы.
Ок. Из вашего комментария было не понятно, что вы имели ввиду.
Статья соткана из кэпских очевидностей и каких-то собственных умозаключений, типа:
Отсюда мораль: единый стек — первый шаг к стандартизации разработки ПО.


В Toyota, как и в любой компании с тысячами сотрудников единого стека быть в принципе не может. Стандартизация — это не то, что все пишут на nodejs и React под Windows. Это набор принципов и подходов, как создается код, тестируется и идет в production. А принципам и подходам все равно, на чем вы программируете :).
К сожалению, не для всех эти вещи очевидны, иначе стандартизации уделялось бы больше внимания. Часто в разработке идут по модели Diversity, сваливают в кучу разные технологии и подходы, я постоянно это вижу. Давайте попробуем Ramda, а вот ещё есть Immutable. Это же крутые штуки. Давайте в этом приложении будем использовать стандартную архитектуру с Redux, а в этом не будем, тут можно обойтись контекстом.

Если такова политика компании, руководство намеренно выбрало такой путь, понимая, что хочет получить от такого разнообразия — тогда это ок. Но часто руководство не лезет в разработку и не понимает последствий таких решений.

Единый стек может быть, взять, например, Сбербанк или Альфу. Есть основной стек, есть стандартизированная разработка, веб пишется на одном, мобильные приложения на другом. Внутри веба тоже есть и Angular, и React, но в рамках одного направления всё довольно стандартно, большое количество команд пишет примерно одинаково.
Подход Toyota(и тема статьи) это не про то должен быть единый стэк, а все остальное это ересь и должно быть выжжено напалмом. Подход Toyota — это стандартизация. Перенося на разработку ПО это говорит, что неважно, на чем пишет условный Вася. Но его код должен быть протестирован, написана тех. документация и все исправления и сопровождение его должны быть по одному стандартному процессу, принятому в компании. Тогда будет счастье и процветание, как обещают Тойотовцы.
Вот на самом деле не важно, на чём этот Вася пишет, пока он пишет один, когда их становится 10, это уже другая история. И тут один стек даст и общие библиотеки, и общие темы для разговоров, и переходы разработчиков из проекта в проект, и другое, о чём было в статье. Всё остальное тоже важно, безусловно, я не предлагаю упираться в один стек, но он действительно даёт многое.
Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.


а откуда инфа? Данное утверждение, как минимум, противоречит моему опыту, и де-факто общепринятому подходу к разработке как исследовательской задаче.
Давайте на примерах: приведение дат к строкам в разных форматах, создание строки поиска с автодополнением, валидация ввода пользователя, шифрование данных, запросы к серверу и обработка ошибок — типичные задачи для фронтенда, в котором я работал. Вряд ли всё это вы будете писать с нуля, скорее всего вы будете использовать наработки вашей компании или найдёте решение в интернете, так быстрее. Если вы работаете в компании, в которой несколько команд уже не первый год делают проекты, новые задачи, которые до вас никто не решал, будут встречаться довольно редко. Отдельная история — это бизнес-логика, но и здесь значительный объём будет покрыт готовыми решениями.
Контр пример: альтернативная имплементация TCP/IP стека в обход ядра Linux, реализация fail-safe протокола UDP без нарушения существующих патентов, ускорение выполнения исходного кода для процессора определенной архитектуры…

Это я к чему — в определенных условиях задачи могут быть типовыми. Это не является доказательством того, что все задачи (или даже большинство) — типовые.

Я не нашел исследования «типичности» задач в среднем по индустрии. Скорее всего потому, что измерять среднее для крайне неоднородной индустрии — дело неблагодарное.

Но без обозначения границ применимости — доказать, что утверждение «Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.» ложное — дело одного case study.
  • Стандартизация повышает производительность.
  • Свобода и разнообразие повышает результативность.

Когда цель просматривается плохо, да еще и имеет тенденцию к перемещению (что характерно для многих проектов разработки ПО), высокая производительность работает как инерция, снижает результативность.


Получается, что работаем производительно, двигаемся быстро, но приходим не туда, куда нужно.


Поделюсь опытом работы в одной крупной компании. Стандартизация там была на высоте. Целые департаменты занимались созданием и контролем соблюдения стандартов. Заказчик что-то хотел, но его быстро ставили на место, подгоняли под стандарт. Называлось "инженерной культурой" (хотя, скорее, это был "синдром инженера"). Результативность была очень низкой. Некоторые проекты после нескольких лет разработки сворачивали, так и не запустив в эксплуатацию.


Стек был единый, шаблоны и стандартные решения отрабативались годами (если не дясятилетиями), и вот какие были в этом недостатки (помимо вышеупомянутой низкой результативности):


  • мы использовали технологии >10 летней давности; забудьте про модернизацию, даже версии не обновлялись (так как было слишком много зависимостей)
  • ошибок было много, так как стандартные решения были старыми и обросшими "костылями", заглядывать внутрь было страшно
  • планирование, и вообще, разгон проекта до плановой скорости занимал немало времени – не меньше полугода уходило на составление ТЗ, согласование архитектуры и прочие подготовительные работы, чтобы потом взять, и быстро всё сделать
  • общение было далеко не эффективным, так как сводилось к написанию и прочтению заданий, требований, регламентов и процедур, обвинениям в нарушении таковых и парировании этих обвинений

В статье говорится, что стандартизация помогает со всем этим бороться, но на мой взгляд, как раз наоборот, именно она это порождает.


Между стандартизацией и свободой необходим баланс. Перекос в любую сторону ведет к негативным последствиям.


К сожалению, перекос в сторону стандартизации царит в большинстве крупных российских ИТ компаний.


Допускаю, что в стартапах есть перекос в другую сторону, но для них производительность – вообще не цель, важна только результативность.

Спасибо за такой развёрнутый комментарий! Это отличное дополнение к разделу о негативных сторонах стандартизации.

К сожалению, Вы правы, стандартизация может закончиться плачевно. Но дело, как мне кажется, не в стандартизации, а в руководстве. Без стандартизации дела, скорее всего, шли бы ещё хуже. Если разработкой стандартов и контролем занимается целый департамент, что мешает ему постоянно следить за развитием и обновлением стандартов? Только менеджмент. Руководство либо не понимает, как с этим работать, либо его такая ситуация устраивает.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.