Все работают и развиваются, просто по разному. Поэтому я и привожу наглядный пример с тем, что видно мгновенно - как выглядит рабочее место. Вы конечно можете спорить, считая, что можно работать за одним монитором всю жизнь, или за ноутбуком. С яркой лампой накаливания над головой. Да, можно. Если хотите достичь среднестатистических результатов, а не впечатляющих для самого себя. Личный выбор каждого. И про порядок в коде - я уже в статье всё написал. Если после прочтения не стало понятно, и захотелось спорить, доказывать свою точку зрения сравнивая подход с которым есть опыт с подходом в котором нет опыта - тут я ничем не могу помочь. Спорьте. Действуйте только как раньше. Вы абсолютно правы во всём. Оставайтесь правыми дальше.
я-то могу сравнить оба подхода, т.к. писал и без пустых строк, и с пустыми строками. и я выбираю второй вариант, для меня после моего практического опыта, его преимущества очевидны. как и для коллег, которые прошли через сопротивление и адаптацию.
а кто не может себе позволить попробовать писать с пустыми строками - не могут и сравнивать, из за банального сопротивления непривычному
если ты считаешь, что много мониторов может быть только у охранника, можешь глянуть следующий видос, в котором кстати в том числе раскрывается тема мониторов
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Объясню для чего это нужно. Часто приходится работать над несколькими файлами одновременно, т.к. их логика связана друг с другом. Если у вас на дисплее открыт только один файл с кодом - значит лишь то, что вы не открыли для себя возможность открывать одновременно 2, 3 и более файлов с кодом одновременно, разделяя рабочее пространство редактора кода, экономя время и свой фокус внимания, вместо того, чтобы переключаться между вкладками или окнами.
Когда одновременно открыто несколько файлов, чем более сжатый код, тем больше его помещается в не таком уж и широком окне области одного файла. А код желательно видеть полностью (по ширине), чтобы опять же не тратить время на листание влево-вправо.
Насколько мы можем сжать код? Один пробел - это один символ. Пробелы нужны, на одном пробеле не построить табуляцию, т.к. будет путаница. Получается минимальное расстояние - два пробела. Его мы и используем. Можно хоть 10 поставить, но всегда нужно понимать - ради чего.
Про преттиер я написал в статье своё мнение. Опять же, оно субъективно, однако каждый может ознакомиться с разными точками зрения, и сделать свои выводы.
Чтобы понять что именно удобно, нужно пробовать разные подходы. Разные IDE. Постоянно развиваться, не стоять на месте. А когда человек попробовал единственный подход, а на все остальные ставит себе барьер, потому что ему не привычно, и новый подход не укладывается в его устоявшееся мировосприятие - это не значит, что ему не может быть удобнее. Это значит, что он сам ограничил себя от бОльшего удобства.
P.S.: Дока это хорошо 👍
P.P.S.: Ко мне обращаются и за доработкой проектов к-е я писал год или два года назад. Благодаря моей концепции организации файловой структуры проекта и кода проекта, мне не составляет труда восстановить понимание устройства проекта в быстрый срок, и внести доработки.
Я вообще без работы никогда не сижу, и даже сам в том числе предоставляю людям работу. Людям, готовым открываться положительным изменением, расти через сопротивление, и позволить себе попробовать вопреки своим устоявшимся привычкам, новый подход.
Обратите внимание - попробовать. Не принять как истину по вере на слово, а именно попробовать. Да, не критиковать, не ставить себе барьеры, а именно - попробовать.
И как ни удивительно - ещё никто из тех, кто написал проект с таким подходом, назад, к старому подходу уже не вернулся. При этом каждый (и я в том числе) проходил через сопротивление и отторжение этих пустых строк.
Я уже не раз писал здесь в комментах - "Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉". Но право каждого - сделать свой личный выбор. Этот выбор не обязательно "попробовать". Можно сразу уйти в отрицание, критику, минусить, и продолжить жить и работать по старому. Ну критикуйте, минусите, пока ваши коллеги учатся по этому гайду, и лично со мной зарабатывают деньги 😉
а как вы работаете, поделитесь, господа критики? :)
Что гадать, я ответ на этот вопрос ещё в начале статьи написал:
В процессе внедрения предложенных мной концепций, вы с высокой вероятностью можете столкнуться с тем, что код будет выглядеть непривычно для вас, и внутренняя консервативность будет подталкивать к тому, чтобы писать код "по старому".
И в комментариях выше дополнил:
Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉
Всё вышеописанное является моим личным субъективным мнением и видением ситуации. Оно не обязательно должно совпадать с вашим мнением и видением.
Как написал и то, что
После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте.
Есть множество подходов, причём некоторые из них не взаимоисключают друг друга. Я делюсь подходом который показал свою эффективность как лично для меня, так и коллеги позволившие себе попробовать такой подход, неоднократно отмечали его преимущества. К тому же, если что-то уже есть, и без разницы от кого, это не значит, что теперь лучше уже не может быть, и не значит, что не стоит стремиться к лучшему.
Опять же, это моё мнение, и я его никому не навязываю. Кто-то прочтёт и скажет "фи", пропустит "мимо ушей" так сказать. А кто-то попробует, и получит пользу, и плюсы данного подхода станут для него очевидны.
В процессе внедрения предложенных мной концепций, вы с высокой вероятностью можете столкнуться с тем, что код будет выглядеть непривычно для вас, и внутренняя консервативность будет подталкивать к тому, чтобы писать код "по старому".
Однако, можете мне поверить, если вы сможете позволить себе пройти через адаптацию, код не соответствующий данным концепциям оформления будет вызывать у вас отвращение, т.к. будет напоминать слипшуюся кашу трудную для восприятия. К тому же в статье я не просто описываю приёмы, но и рассказываю, для чего это нужно.
Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉
P.S.: После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте. На первый взгляд оформленный таким образом код выглядит дико, и я тоже через это проходил.
Да, и имею на это полное право - это моё личное дело. В то же время вы можете использовать саму идею, но называть папки и компоненты на своё усмотрение.
Почему каркас?
Каркас — несущая внутренняя или внешняя конструкция здания, механизма, сооружения, аппарата
Так и у меня в вёрстке, данный компонент содержит "скелет", общую концепцию страницы, которая используется на каждой странице проекта.
MVC в названии подразумевает архитектурное разделение на модель, вид и контроллер
Именно об этом и идёт речь в статье, а именно:
Модель - глобальный и локальный стейт а также хуки (хранят модель данных, отображаемых на странице). Глобальный стейт по статье хранится в папке store
Вид - компоненты React являются представлением, т.к. отвечают за отображение данных и реагирование на действия пользователей. По статье хранятся в папке React
Контроллер - JS-логика как данные получаются, обрабатываются и обновляются. По статье подобные функции находятся в папке scripts, так же контроллерами можно считать экшены, по статье хранящиеся в store/actions
Точно так же, как неправильно называть произвольный сервис хранения исходного кода "гитом"
Я вижу не одного вас это сильно задело, ну так то вы в данном случае правы, отредактировал статью
Да, но поскольку я использую для вёрстки adaptivepx.ru, я создаю кастомный файл tailwind.scss где размеры указаны в адаптивных пикселях, и есть только те атомарные стили, которые я использую в проекте. Т.е. я использую идею tailwind, но не саму библиотеку.
видит шире своего мнения лишь тот, кто пробует смотреть с разных точек зрения, а не с единственной 😃
я писал код и другими способами, а вы не писали код предложенным мной способом
и кто из нас видит шире своего мнения, сравнивая эти два подхода? (вопрос риторический 🤓)
Все работают и развиваются, просто по разному. Поэтому я и привожу наглядный пример с тем, что видно мгновенно - как выглядит рабочее место. Вы конечно можете спорить, считая, что можно работать за одним монитором всю жизнь, или за ноутбуком. С яркой лампой накаливания над головой. Да, можно. Если хотите достичь среднестатистических результатов, а не впечатляющих для самого себя. Личный выбор каждого. И про порядок в коде - я уже в статье всё написал. Если после прочтения не стало понятно, и захотелось спорить, доказывать свою точку зрения сравнивая подход с которым есть опыт с подходом в котором нет опыта - тут я ничем не могу помочь. Спорьте. Действуйте только как раньше. Вы абсолютно правы во всём. Оставайтесь правыми дальше.
но вряд-ли представляете как достичь результатов, которые я достиг даже не сейчас, а ещё года 4 назад 😀
я тут скорее про то, как выглядит ваше рабочее место, после 20 лет опыта в разработке
Вот вы петросяните, а я между прочим - нет
я-то могу сравнить оба подхода, т.к. писал и без пустых строк, и с пустыми строками. и я выбираю второй вариант, для меня после моего практического опыта, его преимущества очевидны. как и для коллег, которые прошли через сопротивление и адаптацию.
а кто не может себе позволить попробовать писать с пустыми строками - не могут и сравнивать, из за банального сопротивления непривычному
ну а ты как думаешь?))))
если ты считаешь, что много мониторов может быть только у охранника, можешь глянуть следующий видос, в котором кстати в том числе раскрывается тема мониторов
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Объясню для чего это нужно. Часто приходится работать над несколькими файлами одновременно, т.к. их логика связана друг с другом. Если у вас на дисплее открыт только один файл с кодом - значит лишь то, что вы не открыли для себя возможность открывать одновременно 2, 3 и более файлов с кодом одновременно, разделяя рабочее пространство редактора кода, экономя время и свой фокус внимания, вместо того, чтобы переключаться между вкладками или окнами.
Когда одновременно открыто несколько файлов, чем более сжатый код, тем больше его помещается в не таком уж и широком окне области одного файла. А код желательно видеть полностью (по ширине), чтобы опять же не тратить время на листание влево-вправо.
Насколько мы можем сжать код? Один пробел - это один символ. Пробелы нужны, на одном пробеле не построить табуляцию, т.к. будет путаница. Получается минимальное расстояние - два пробела. Его мы и используем. Можно хоть 10 поставить, но всегда нужно понимать - ради чего.
Напишите файл со сложной вёрсткой с кучей вложенностей и сделайте там табы в 8 символов.
Затем сделайте дубликат файла, и там сделайте табы в 2 символа
Сравните, сделайте выводы
Или вы больше верите другим, чем собственному восприятию?
Про преттиер я написал в статье своё мнение. Опять же, оно субъективно, однако каждый может ознакомиться с разными точками зрения, и сделать свои выводы.
Чтобы понять что именно удобно, нужно пробовать разные подходы. Разные IDE. Постоянно развиваться, не стоять на месте. А когда человек попробовал единственный подход, а на все остальные ставит себе барьер, потому что ему не привычно, и новый подход не укладывается в его устоявшееся мировосприятие - это не значит, что ему не может быть удобнее. Это значит, что он сам ограничил себя от бОльшего удобства.
P.S.: Дока это хорошо 👍
P.P.S.: Ко мне обращаются и за доработкой проектов к-е я писал год или два года назад. Благодаря моей концепции организации файловой структуры проекта и кода проекта, мне не составляет труда восстановить понимание устройства проекта в быстрый срок, и внести доработки.
Я вообще без работы никогда не сижу, и даже сам в том числе предоставляю людям работу. Людям, готовым открываться положительным изменением, расти через сопротивление, и позволить себе попробовать вопреки своим устоявшимся привычкам, новый подход.
Обратите внимание - попробовать. Не принять как истину по вере на слово, а именно попробовать. Да, не критиковать, не ставить себе барьеры, а именно - попробовать.
И как ни удивительно - ещё никто из тех, кто написал проект с таким подходом, назад, к старому подходу уже не вернулся. При этом каждый (и я в том числе) проходил через сопротивление и отторжение этих пустых строк.
Я уже не раз писал здесь в комментах - "Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉". Но право каждого - сделать свой личный выбор. Этот выбор не обязательно "попробовать". Можно сразу уйти в отрицание, критику, минусить, и продолжить жить и работать по старому. Ну критикуйте, минусите, пока ваши коллеги учатся по этому гайду, и лично со мной зарабатывают деньги 😉
Что гадать, я ответ на этот вопрос ещё в начале статьи написал:
И в комментариях выше дополнил:
Именно об этом я и написал в статье:
Как написал и то, что
Есть множество подходов, причём некоторые из них не взаимоисключают друг друга. Я делюсь подходом который показал свою эффективность как лично для меня, так и коллеги позволившие себе попробовать такой подход, неоднократно отмечали его преимущества. К тому же, если что-то уже есть, и без разницы от кого, это не значит, что теперь лучше уже не может быть, и не значит, что не стоит стремиться к лучшему.
Опять же, это моё мнение, и я его никому не навязываю. Кто-то прочтёт и скажет "фи", пропустит "мимо ушей" так сказать. А кто-то попробует, и получит пользу, и плюсы данного подхода станут для него очевидны.
Специально для вас в начале статьи:
Всегда проще отказаться, чем попробовать. Где сопротивление, там точка роста, коллега 😉
P.S.: После практики данного подхода, писать кашу из кода - это даунгрейд (откат назад), даже в существующих проектах. Это можно понять только проверив на личном опыте. На первый взгляд оформленный таким образом код выглядит дико, и я тоже через это проходил.
Да, и имею на это полное право - это моё личное дело. В то же время вы можете использовать саму идею, но называть папки и компоненты на своё усмотрение.
Почему каркас?
Каркас — несущая внутренняя или внешняя конструкция здания, механизма, сооружения, аппаратаТак и у меня в вёрстке, данный компонент содержит "скелет", общую концепцию страницы, которая используется на каждой странице проекта.
Я конкретно ответил каким образом реализуется MVC в моём примере. Аргументируйте, если не согласны.
Именно об этом и идёт речь в статье, а именно:
Модель - глобальный и локальный стейт а также хуки (хранят модель данных, отображаемых на странице). Глобальный стейт по статье хранится в папке store
Вид - компоненты React являются представлением, т.к. отвечают за отображение данных и реагирование на действия пользователей. По статье хранятся в папке React
Контроллер - JS-логика как данные получаются, обрабатываются и обновляются. По статье подобные функции находятся в папке scripts, так же контроллерами можно считать экшены, по статье хранящиеся в store/actions
Я вижу не одного вас это сильно задело, ну так то вы в данном случае правы, отредактировал статью
Да, но поскольку я использую для вёрстки adaptivepx.ru, я создаю кастомный файл tailwind.scss где размеры указаны в адаптивных пикселях, и есть только те атомарные стили, которые я использую в проекте. Т.е. я использую идею tailwind, но не саму библиотеку.