Инсайты

Делитесь всем, что вас как-то зацепило. Это может быть новость, чей-то коммент, даже ваше собственное озарение на какую-то тему 🙂 Чтобы легче было искать инсайты по теме, предлагаю выделять их в блок цитаты.


Code is ultimately about communications with other people, not just with a machine.
[image] - DEV Community

1 лайк

I’ve seen a lot of “experienced developers” come and go. They build a monument to complexity and then leave their customers trapped in an expensive hole. What has been lost in engineering in the 21st century is the appreciation for simplicity. Unless you are writing Facebook, React and Redux are probably overkill. In fact, what will people do when React and Redux are abandoned? Hire consultants to rewrite it in the next overly complex framework for twice as much money as the first time? People need to remember that engineering is about delivering a simple, cost effective solution, not building something to gratify their ego at their customer’s expense.
React and Redux are a joke right?

Redux is just horrible! I am a programmer for more than 25 years now. For the past few months I studied web frameworks: Angular 5, React, Vue, Django, Java Spring, Rxjs and the horrible Redux. All frameworks/libraries are ok except Redux. I can’t believe how very popular is Redux since any experienced programer should immediately see that it is a stupid anti-pattern for noobs that don’t know what they are doing.

Business logic code is the core of our work! The presentation code including the fancy frameworks like React or Angular is subordinate and should never dictate the shape of business logic code. Redux is doing just that. It forces you to write stupid messages and then stupid reducers with stupid switch statements and it forces you to make immutable changes to a big state object because React wants it. It is just terrible.

Frameworks are competing for “market” share by messing with inexperienced programmers. They convinced you that their framework is the most important part in your project. This is completely false! The most important part of your project is your business logic and it must be totally separated from unimportant user interface code and its frameworks. You should build the presentation code around your business logic so that business logic doesn’t know anything about presentation. Then you can use any web or desktop or mobile framework or just simple console output as an interface to your program.
React and Redux are a joke right?

Я раньше думал что создавать нужно только концептуально новое и уникальное. А копирование - это плохая практика. А потом я посмотрел это видео https://www.youtube.com/watch?v=nJPERZDfyWc, почитал сайт https://www.everythingisaremix.info/ и теперь могу со спокойной совестью делать клоны.

1 лайк

Ни разу не задумывался о сути simple-complex, easy-hard в контексте программирования. Еще не знал концепции “привычное”. Теперь применяю понимание разницы между этими концепциями чтобы оценить на сколько говорящий о технологии честен с собой, сколько в его словах личного мнения, а сколько информации по сути.

О вышеописанных концептах узнал из этой презентации
https://www.infoq.com/presentations/Simple-Made-Easy

1 лайк

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

1 лайк

Документальный фильм о массовой слежке в интернете, манипуляции и продаже личных данных.

Тяжелые времена создают сильных людей,
Сильные люди создают хорошие времена,
Хорошие времена создают слабых людей,
Слабые люди создают тяжелые времена.

10: Чем ниже порог вхождения, тем больше говнокода
20: Чем больше говнокода — тем больше создается абстракций чтобы его писать не приходилось.
30: Чем больше абстракций — тем ниже порог вхождения.
40: GOTO 10

Не вижу в этой модели объяснение реальности. Больше похоже на рационализацию своих чувст/взглядов “от раньше надо было знать XYZ, а сейчас каждый прыщ мнит себя программистом”.

Чем ниже порог вхождения, тем больше говнокода

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

Сам по себе низкий порог входа не делает отрасль навожденной людьми.

И повысить порог мы не можем (если я верно понял ядро проблемы, которую описывает автор).

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

Мысли хаброидов на тему солида и децентрализацици веба https://habr.com/ru/post/436326/

https://css-tricks.com/the-great-divide/ О разбиении на 2 лагеря фронтенда: 1) Семантика, стили, UX и т.п. 2) В основном JavaScript-ориентированные. Об обесценивании HTML и CSS, о повсеместном использовании JS и фуллстек разработки.

Обсуждать будем в этой ветке или вынесем отдельно? Как ты хочешь это видеть?


Бизнес и рынок решают. Если бы семантическая верстка и accessability имело значение для бизнеса, то эти навыки ценились бы им. Если бы ценность этих качеств выростала из реальности, мы бы видели отражение этих ценностей в бизнесе (который работает с реальностью в первую очередь). Бизнесу нужны решенные задачи, дешевле и быстрее. Поэтому тенденция объединения ролей (дизайнер + верстальщик + клиентщик + серверщик + инфраструктурщик итд) будет продолжаться. До тех пор пока люди на новых ролях не перестанут справляться с задачами, которые важны для реальности (т.е. аспектами влияющими на бизнес).

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

Далее. Когда речь идет о массовости, говорить о росте качества сложно. Количество программистов растет, и растет очень быстро, в ряды вступают не просто фанатики, но и рядовые люди. Если 10 лет тому во фронте были единицы упоротых (перешедших обычно из дизайнеров или верстальщиков текстов), или случайных людей как я, то сегодня сюда стремятся специально. Тема программирования слишком сложная чтобы ей правильно научить, ее можно только понять через практику. Образование может только сократить процесс понимания с условных 4 до условных 2 лет. И каждый год мы будем иметь дело с результатами работы тех, кто только выходит в поле программистов. “старичкам”, которые обычно и имеют голос в интернете, стоит смириться с этой реальностью.

1 лайк

Можно тут обсуждать, но ты по сути высказал мои мысли вслух. Аксасебилити, семантика, архитектурные стили – для конкрктной задачи они могут иметь серьезный вес. Но в контексте потока проектов на современной технологическом стеке они мало решают, чтобы евангелисты последних справедливо провозглашали их незыблемой основой. Как бы это печально ни звучало. Если ты делаешь веб-сайт для записи на мед осмотр граждан, тут микродата, аксасебилити и семантика могут сильно решать. Но если мы делаем стартап с криптовалютой, лендинг или любое другое подобное нутро, то там всем начхать на весь этот регламент. Влияние слишком незначительное.

С другой стороны я смотрю, что в подобных статьях часто отписываются люди, которым кажется что их вытесняют с их профессиональной сферы. Простой верстальщик не умеющий JS сейчас никому не нужен на рынке, какую бы черную магию верстки он ни умел. Это ествественный отбор в самом строгом смысле. Если б это было не так, факты были бы другими.

1 лайк

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

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

Дизайн как упаковка продукта важна до определенной меры, но куда важнее UX. Если последний провальный, то краски ничего не изменят. Вон люди пользуются уродским амазоном и все счастливы. И одностраничника нет и дизайн неочень, но продукт работает и приносит хорошую прибыль.

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

А вот статья-дополнение к оригинальной. HTML, CSS and our vanishing industry entry points – Rachel Andrew . Тоже старичок переживает что в современной веб разработке нужно знать тонны вещей и эти знания не “переносимые” в большинстве из проекта в проект.

Забавно что автор приводит почти такую-же формулу что и я (типа смириться):

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

Упоминает про коммерциализацию процесса, но не считает этот процесс корнем проблемы.

Он прав, считаю, что порог входа повышается. Но это только то того что требования к страницам возрасли (анимашки, аяксики и иже с ними), а базовые инструменты остались теми же (html,css).

Когда я читаю все эти статьи, прямо очень чувствую эту боль. Видимо с годами мозг устает от запутанности и сложности. Не всегда удается выйти на уровень осмысления других проблем, когда башка постоянно забита этим невероятным круговоротом фрейморков, библиотек и прочих инструментов доставить текст на кнопочку. Смириться – это не просто формула, это единственный выход. Все попытки поднять на поверхность эту проблему в самом высоком смысле только гарантирует лишнее беспокойство и трату нервов. Но возможно смысл не в том, чтобы все перекроить опять, ведь раньше было лучше. А в том, чтобы стараться в своей текущей работе больше унифицировать и упрощать все что можно, не усугубляя ситуацию.

1 лайк

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


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


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

Итого, несмотря на правильность и чистоту цели функционального программирования, оно, как и полагается ему, остается уделом ограниченной ниши разработчиков независимо от прикладной области. И та сложность, которую мы создаем своей привычной методикой работы, – просто плата, которую мы платим за удобную и доступную цену написания кода. На чаше всегда будет лежать с одной стороны простота, ограниченность и проблемность, с другой – гибкость, сложность и универсальность. В целом в повседневности получается, что лучшее враг хорошего. Так что функциональное программирование это хорошо, но функционально программировать не будем.

1 лайк

Вспомнил. Есть. Это бизнес логика. Одна функция которая выражает одно действие.