Комментарии 40
В середине прошлого века Toyota применяла принципы...
История про Разработку ПО в Тойоте: https://m.habr.com/ru/company/pvs-studio/blog/310862/
Стандартизация хороша и плоха.
Она хороша, если вы решаете стандартные (однотипные) задачи. Применив стандартные решения вы получите ускорение разработки, уменьшение числа ошибок, взаимозаменяемость, деградацию персонала. Т.е. обычный конвейер.
Стандартизация плоха, если нужно решать нетрадиционные проблемы. Применив разнообразие форм подхода и методов решения, вы получите эксклюзивные решения, увеличение времени разработки и расходов, постоянное развитие персонала. Т.е. экспериментальное производство.
А что надо вам — только вам самим и решать.
Опять же, есть люди, которые как рыба в воде себя чувствуют в зоопарке технологий, а есть те, кто привык все делать по строгой схеме без экспериментов.
Ещё одно преимущество стандартизации Standard & Co обнаружила после выхода новой версии языка TypeScript. Она показалась разработчикам удобнее для разработки, чем Flow, который они уже давно использовали. Разработчики Standard & Co переписали шаблон приложения и библиотеку компонентов интерфейса на TypeScript, сделав разработку проще, а код лаконичнее.
Вот так вот у вас есть стандарты, но тут по решению перейти на тайпскрипт вся компания взяла и переписала ВСЮ библиотеку компонентов (включая календари и пр.) на тайпскрипт.
Вы сами-то в это верите?) Только вот честно.
О, интересно! А вышел ли какой профит от переписывания всё на хуки? Рассчитывались ли какие-нибудь метрики, оценивался ли как-то результат переписывания? Или просто взяли и переписали?
Ещё один эффект обнаружили, когда нужно было сделать большую сложную форму с валидацией. Форма на библиотеке до хуков заметно лагала в IE, после обновления на новую версию библиотеки всё заработало нормально.
>> на хуки и 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 недель (сочетая этот переход с работой, разумеется), если такового спеца нет.
Ну и в остальном там очень многое подходит только к ситуациям, когда у конторы есть только довольно типовые проекты. Если проекты не типовые — добрая половина пунктов будет мешать, а не помогать.
Реальность: нормальный фронтэндер переходит с фреймворка на фреймворк в течении пары дней
Это какая-то параллельная реальность ). Более похоже на фантастическую.
Если спеца нет — то, конечно, всё проходит медленнее и осторожнее.
Реальность: нормальный фронтэндер переходит с фреймворка на фреймворк в течении пары дней, если в команде есть опытный профильный спец по фреймворку, и в течении 2-4 недель (сочетая этот переход с работой, разумеется), если такового спеца нет.Вот только счет пойдет на месяца, пока его эффективность (за счет использования своих наработанных решений, знания тонкостей, подводных камней и различных подходов, знания популярных библиотек для этого фреймворка и опыта работы с ними, изучения сторонних и выработки своих best practices) достигнет уровня, который был при работе с его основным фреймворком.
Развивать существующий проект и писать новый — это две большие разницы, делать это с людьми, которые уже поработали над проектом и знают техстек и делать это без таковых людей — две еще более большие разницы.
Отсюда мораль: единый стек — первый шаг к стандартизации разработки ПО.
В Toyota, как и в любой компании с тысячами сотрудников единого стека быть в принципе не может. Стандартизация — это не то, что все пишут на nodejs и React под Windows. Это набор принципов и подходов, как создается код, тестируется и идет в production. А принципам и подходам все равно, на чем вы программируете :).
Если такова политика компании, руководство намеренно выбрало такой путь, понимая, что хочет получить от такого разнообразия — тогда это ок. Но часто руководство не лезет в разработку и не понимает последствий таких решений.
Единый стек может быть, взять, например, Сбербанк или Альфу. Есть основной стек, есть стандартизированная разработка, веб пишется на одном, мобильные приложения на другом. Внутри веба тоже есть и Angular, и React, но в рамках одного направления всё довольно стандартно, большое количество команд пишет примерно одинаково.
Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.
а откуда инфа? Данное утверждение, как минимум, противоречит моему опыту, и де-факто общепринятому подходу к разработке как исследовательской задаче.
Это я к чему — в определенных условиях задачи могут быть типовыми. Это не является доказательством того, что все задачи (или даже большинство) — типовые.
Я не нашел исследования «типичности» задач в среднем по индустрии. Скорее всего потому, что измерять среднее для крайне неоднородной индустрии — дело неблагодарное.
Но без обозначения границ применимости — доказать, что утверждение «Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.» ложное — дело одного case study.
- Стандартизация повышает производительность.
- Свобода и разнообразие повышает результативность.
Когда цель просматривается плохо, да еще и имеет тенденцию к перемещению (что характерно для многих проектов разработки ПО), высокая производительность работает как инерция, снижает результативность.
Получается, что работаем производительно, двигаемся быстро, но приходим не туда, куда нужно.
Поделюсь опытом работы в одной крупной компании. Стандартизация там была на высоте. Целые департаменты занимались созданием и контролем соблюдения стандартов. Заказчик что-то хотел, но его быстро ставили на место, подгоняли под стандарт. Называлось "инженерной культурой" (хотя, скорее, это был "синдром инженера"). Результативность была очень низкой. Некоторые проекты после нескольких лет разработки сворачивали, так и не запустив в эксплуатацию.
Стек был единый, шаблоны и стандартные решения отрабативались годами (если не дясятилетиями), и вот какие были в этом недостатки (помимо вышеупомянутой низкой результативности):
- мы использовали технологии >10 летней давности; забудьте про модернизацию, даже версии не обновлялись (так как было слишком много зависимостей)
- ошибок было много, так как стандартные решения были старыми и обросшими "костылями", заглядывать внутрь было страшно
- планирование, и вообще, разгон проекта до плановой скорости занимал немало времени – не меньше полугода уходило на составление ТЗ, согласование архитектуры и прочие подготовительные работы, чтобы потом взять, и быстро всё сделать
- общение было далеко не эффективным, так как сводилось к написанию и прочтению заданий, требований, регламентов и процедур, обвинениям в нарушении таковых и парировании этих обвинений
В статье говорится, что стандартизация помогает со всем этим бороться, но на мой взгляд, как раз наоборот, именно она это порождает.
Между стандартизацией и свободой необходим баланс. Перекос в любую сторону ведет к негативным последствиям.
К сожалению, перекос в сторону стандартизации царит в большинстве крупных российских ИТ компаний.
Допускаю, что в стартапах есть перекос в другую сторону, но для них производительность – вообще не цель, важна только результативность.
К сожалению, Вы правы, стандартизация может закончиться плачевно. Но дело, как мне кажется, не в стандартизации, а в руководстве. Без стандартизации дела, скорее всего, шли бы ещё хуже. Если разработкой стандартов и контролем занимается целый департамент, что мешает ему постоянно следить за развитием и обновлением стандартов? Только менеджмент. Руководство либо не понимает, как с этим работать, либо его такая ситуация устраивает.
www.fastcompany.com/28121/they-write-right-stuff
Стандартизация разработки ПО