Абсолютно с вами согласен. Имхо дело в реализации, а закопать можно даже проект с идеальной архитектурой. Несколько лет назад я бы сам не поверил, что можно написать например браузерную игру с сервером на nodeJS.
Интересное мнение.
А думаете стоит вообще видеть эти абстракции и выносить все в модули на первом же этапе разработки? Например если разобрать абстракцию автомобиля до скелета, то, думаю, для многих, останется двигатель и шасси. А можно прикрутить спереди пропеллер и видоизменить кузов, и вот получается самолет. Или прикрепить снизу винт — получается лодка. Но это так себе самолет и фиговенькая лодка. Чтобы получить летающий аппарат помощнее нужно очень сильно отрефакторить и двигатель и шасси.
Очень интересная статья.
Только одна маленькая деталь, мужчины и женщины работаю по разному, а вы женщина. Несомненно некоторые идеи из предложенных вами подойдут всем, но в общем не каждый сможет работать по такой схеме. Хотя мне бы например это очень понравилось :)
В отличии от js, где реализация окружения зависит от клиентского браузера, при работе с sql не нужно каждый раз определять тип, версию и прочие тонкости.
Не так давно на работе перевел систему сборки front-end части на grunt, со steal js. На данный момент это примерно 230 js файлов с логикой приложения, 7 js файлов библиотек и около 40 файлов со стилями. В итоге все собирается в три файла: main.js, lib.js, style.css. Время сборки js и css файлов изменилось с 10 минут на 10 секунд, при том степень сжатия увеличилась примерно на 10%. Мой радости не было предела.
По дефолту grunt просто выводит список возможных команд. Можно отдельно запустить валидацию, по отдельности собрать модули, или же например перезапустить дополнительную оптимизацию статики. Плюс есть команда полной сборки всего и вся, запуская которую я просто сижу и наслаждаюсь, жаль все это происходит за примерно 10 секунд )
Такой что получается большой процент бесполезного когда, который висит в памяти и занимает процессорное время.
«dead code elimination»? Покормите своего единорога. Если всё было бы так безоблачно, то разработка более менее сложного приложения проходила в разы быстрее.
Генерировал TypeScript.
Т.е. мы вроде как для себя позаботились о том чтобы в Shapes что-то было, а то что там уже могли быть свойства и тот же Point ему пофиг.
Бюрократия получается )) Вроде что-то делаем: замыкаем, «инкупсулируем», что многие обычно делают, а нафига это — не знаем. А код всё разрастается.
Я это к тому, что очень много получается бесполезного мусора, КПД низкий.
И чего же в этом примере проинкапсулировалось? Point что ли? Который потом был вынесен в открытое свойство. Shapes тоже доступный в глобальной области?
И не надо рассказывать что там могло бы быть больше свойств — тогда бы и результат компиляции был бы более ужасающим.
В таком простом примере после компиляции оказалось 2 уровня замыканий Оо. и ещё адовая конструкция (Shapes || (Shapes = {})). Очень много мусора.
Боюсь думать что же там получится при хоть сколько нибудь сложной логике. И сколько потом ночей придется провести за отлавливанием багов, и над попытками оптимизации.
В самсунге кроме инженеров и программистов работает большое количество других специалистов.
А вообще считал что всегда и везде побеждает «мозг», т.е. управляющее звено.
Пруф pi-online.ru
А думаете стоит вообще видеть эти абстракции и выносить все в модули на первом же этапе разработки? Например если разобрать абстракцию автомобиля до скелета, то, думаю, для многих, останется двигатель и шасси. А можно прикрутить спереди пропеллер и видоизменить кузов, и вот получается самолет. Или прикрепить снизу винт — получается лодка. Но это так себе самолет и фиговенькая лодка. Чтобы получить летающий аппарат помощнее нужно очень сильно отрефакторить и двигатель и шасси.
Только одна маленькая деталь, мужчины и женщины работаю по разному, а вы женщина. Несомненно некоторые идеи из предложенных вами подойдут всем, но в общем не каждый сможет работать по такой схеме. Хотя мне бы например это очень понравилось :)
По дефолту grunt просто выводит список возможных команд. Можно отдельно запустить валидацию, по отдельности собрать модули, или же например перезапустить дополнительную оптимизацию статики. Плюс есть команда полной сборки всего и вся, запуская которую я просто сижу и наслаждаюсь, жаль все это происходит за примерно 10 секунд )
«dead code elimination»? Покормите своего единорога. Если всё было бы так безоблачно, то разработка более менее сложного приложения проходила в разы быстрее.
var Shapes;
(function(){
/* */
})( Shapes || (Shapes = {}) );
Генерировал TypeScript.
Т.е. мы вроде как для себя позаботились о том чтобы в Shapes что-то было, а то что там уже могли быть свойства и тот же Point ему пофиг.
Бюрократия получается )) Вроде что-то делаем: замыкаем, «инкупсулируем», что многие обычно делают, а нафига это — не знаем. А код всё разрастается.
Я это к тому, что очень много получается бесполезного мусора, КПД низкий.
И не надо рассказывать что там могло бы быть больше свойств — тогда бы и результат компиляции был бы более ужасающим.
Боюсь думать что же там получится при хоть сколько нибудь сложной логике. И сколько потом ночей придется провести за отлавливанием багов, и над попытками оптимизации.
А вообще считал что всегда и везде побеждает «мозг», т.е. управляющее звено.