Comments 72
Заказчику нужно чтобы работник сделал работающую вещь. Что там под капотом его мало волнует.
Работнику нужно чтобы сделал и получил за это деньги. Что там под капотом его мало волнует.
Те, кого волнует — разберутся сами. Потом они поднимаются наверх и там парят в облаках чистой архитектуры, обсуждая преимущества хаскеля перед го. Это хорошо. Но кто в это время будет интернет-магазины для доставки пиццы писать?
Заказчику нужно чтобы работник сделал работающую вещь. Что там под капотом его мало волнует.Так. А когда вот это вот всё перестанет быть «работающией вещью» и рассыпется на кучу составляющих компонент — кто всё это будет чинить?
Работнику нужно чтобы сделал и получил за это деньги. Что там под капотом его мало волнует.
В принципе-то всё происходящее даже не так плохо для меня и топикстартера: люди, которым пофиг, что там «под капотом» — потеряют работу первыми, а те, кому нужно, чтобы их сайт, всё-таки, продолжал работать — заплатят за всю предшествующую экономию людям, которые таки понимают откуда что берётся… но да, ощущение странности всего происходящего — не покидает, да.
Так. А когда вот это вот всё перестанет быть «работающией вещью» и рассыпется на кучу составляющих компонент — кто всё это будет чинить?
Найдут, кому починить. Вот вас наймут, вы будете чинить. Потом напишете статью на хабр о том, как тупой работодатель потерял кучу денег на двойной переделке одного и того же.
А дальше в дело вступают кривые прибылей-убытков. Быстрый ввод в строй с помощью индусского кода работодателю — прибыль. Шанс того что всё рассыпется и расходы на вашу работу — убыток. Пока прибыль выше убытков — ну вы понимаете?
Ошибка у вас в «заплатят за всю предшествующую экономию». Может заплатят, а может останутся в прибыли, вы-то откуда знаете? Судя по тому, что они процветают и могут ещё и вам платить — у них как раз всё в порядке.
В «Бойцовском клубе» тоже эта схема хорошо отражена. Ничего странного, просто бизнес.
Судя по тому, что они процветают и могут ещё и вам платить — у них как раз всё в порядке.Судя по безуспешным попыткам кого-то найти и убедить это всё починить… у них как раз всё не в порядке — просто они про это ещё не знают. Или знают?
На практике я видел, в основном, совсем не ту схему, которую вы описываете: начинается всё так, как вы сказали, но в какой-то момент, когда всё готово развалиться — компанию «впаривают» какому-нибудь монстру. Инжинеры которого, увидев код, говорят «это лучше выбросить, чем переписать». И очередной «многообещающий стартап»… просто исчезает.
Но да, владельцы стартапа в прибыли… но это пока у крупных компаний есть «шальные деньги» на покупку этого… добра.
Но когда (не если!) «шальные деньги» кончатся — что будет? А всё просто будет: «перспективные стартапы» будут неожиданно закрываться без всяких продаж… И всё. Вся разница. Вот только она сделает и все эти стартапы и людей, на них работающих попросту ненужными.
И почему вы считаете, что встретив задачу, которая не решается базовыми средствами фреймворка, разработчик обязательно сдастся? Это как раз и будет поводом разобраться как всё устроено внутри и в конце концов выдать решение.
Т.е. неопытный разработчик, неважно с чего он начинает, с фреймворка или с (извините) Vanilla PHP всё равно будет делать ошибки, оставлять дыры в безопасности и т.д. А с набором опыта и первый и второй тип разработчика придут примерно к тому же самому. Просто первый начнёт обучение с азов, а второй — по мере того, как будет разбираться в устройстве фреймворка.
И уж как-то больше доверия к неопытному Laravel-разработчику, чем к неопытному велосипедисту.
Ну оно же работает!
Куча людей при прохождении пути из статьи застревает на стадии
class User {
public function changeUserProfile($userId, array $userData){
global $db; // ну вы поняли
или даже раньше
и так случится если человека не критиковал и не направлял более опытный и он не сталкивался с задачами которые потребовали бы решения средствами чуток сложнее.
Написание велосипедов полезно в комбинации с использованием грамотного проверенного кода, т.е. на простой работе человек пишет используя Laravel к примеру, а домашний проект — без использования библиотек и фреймворков. В итоге получится что то что написал неопытный будет обернуто в грамотную оболочку, но при этом человек будет постепенно все глубже понимать как это работает изнутри. И в идеале нужно давать на ревью свой велосипед более опытному человеку чтоб он указал на ошибки и почему что-то сделано неправильно.
Если оставить велосипедостроителя одного — в итоге родятся шедевры подобные этим:
habr.com/ru/post/311304
habr.com/ru/post/438762
habr.com/ru/post/283166
Просто подход — а начну ка я сразу с Laravel тоже так себе. Другой пример: я когда изучал Android разработку, несколько месяцев потратил на Java Core, чтобы понять, как оно работает. Но есть много книг: Android разработка с нуля. И вот этого мне не понять.
Но есть много книг: Android разработка с нуля.Такие книги, в общем-то были всегда. Чем Delphi Programming for Dummies отличается от вашего гипотетического «Android разработка с нуля»? Да ничем.
Но как-то мне как-то всегда казалось, что люди, читающие эти книги, понимают — что это всё способ «быстро впрыгнуть в разработку»… а фундаментальные вещи они, потом, всё равно как-нибудь изучат.
Но в последнее время я, действительно, всё чаще встречаю людей, которые изучают подобную литературу, устраиваются на работу… и всё — больше им, типа, ничего не интересно и не нужно…
И вот этого мне не понять.А мне как раз понять. У меня есть знакомый, который как раз сейчас пытается освоить премудрости программирования. При этом у него есть жёсткий срок: 3-6 месяцев. Если он не найдёт никакой программистской работы за этот строк — то ему придётся снова идти работать продавцом, чтобы его семья с голоду не подохла. А ушёл от оттуда потому, что если ты работаешь по 12 часов в день семь дней в неделю на двух работах — то ни о каком изучении программирования ни в каком режиме и речи идти не может.
То есть он либо читает книгу «Android разработка с нуля», начинает что-то такое программировать — и потом изучает всё остальное… либо он остаётся продавцом на всю жизнь.
Так что существование таких книг меня не удивляет. Они всегда были и будут. Удивляют люди, которые читают такие книги, куда-то там устраиваются… и всё. А потом жалуются, что и через 5 и через 10 лет получают меньше, чем «выскочки-олимпиадники».
Они что — реально думаю, что вот кроме того, что написано в этих книгах — им больше ничего не нужно? И что люди, серьёзно изучавшие программирование 4-6 «по большому счёту» от них ничем не отличаются?
Программировать вообще-то довольно сложно, можно с работы монтажником/эникейщиком начинать, если уж очень хочется вкатиться.
А вот от человека, знающего немного, как мастерить поделки для Андроида до полноценного разработчика — некоторое количество опыта и чтение курса про алгоритмы…
Ну почему же, вполне существует дорога через администрирование, где программировать таки надо, а требования к навыкам программирования на порядок ниже, заодно можно многое узнать про сети, ОС и всякий разный софт, а потом уже перейти в разработку.
У меня был как раз такой путь, он года 3 занял. Многие коллеги тоже пришли в разработку именно так.
Кривая архитектура — кончается всегда одинаково. Вопрос только в сроках.
потратил несколько часов, вышло 40 строк кода, зато теперь она умеет выводить в красивой форме не только массивы, но имя переданной переменной или со своим текстом, принимать на вход функции, да хоть вложенный массив без знака $.
Я даже удивлен почему никто нигде это раньше не делал, но мне надоело постоянно мучаться с нормальным выводом на экран.
Более того, заменил эту функцию в плагине console wrap для редактора sublime (который тоже не идеален), зато теперь достаточно нажать пару кнопок, чтобы выделенную переменную обернуть этой функцией и не надо каждый раз писать одно и тоже.
Конечно, можно было ее не писать, но в плагине не было учтено перенос символа $ переменной, надо было ее дописывать, но для этого надо было прицелиться после скобки ( и перед началом переменной и вставить символ.
Вот в этом случае велосипед лучше всего помогает оптимизировать.
Впрочем, наверное в фреймворках есть свои… но мне чужого барахла не надо.
(Сарказм)
Эта вечная проблема наслаивания абстракций…
Проводя вашу аналогию с водителями дальше можно кстати неплохо объяснить ситуацию.
Водитель-любитель, которому надо пару раз из точки А в точку Б сгонять в движок действительно вряд ли полезет, незачем.
А вот водитель профессионал, который ездит по плохого состояния дорогам (плохой код вокруг него), без доступа к оборудованию и сервисам для починки (слабая команда) как раз должен разбираться в движке и прочих компонентах на отлично, потому что кроме него у него никого в дороге нет и случись чего — сервис будет двое суток ехать.
Профессиональный водитель текущим ремонтом заниматься не будет без крайней необходимости или неуемного интереса (Фреймворк, то есть, разрабатывать и починять), но когда надо быстро привести систему в работоспособное состояние или что то в ней изменить под себя (думаю понятно о чем речь) — он готов и знает как.
<?
echo "Hello world"; // и в браузере у нас скачивается index.php :)
?>
Так надо было сделать index.phtml и всё бы заработало
PHP 4.2 был выпущен в 2002, 5.2 в 2006. Были в те годы модные фреймворки? Да нет, композер то в 2011-2012 вышел.
Сейчас же на условного школьника выливается огромное количество противоречивой информации и в первую очередь человеку нужно научиться отличать устаревшую информацию от актуальной.
Как раньше — открываешь блокнот, пишешь (копируешь) код, заливаешь на бесплатный хостинг без бд, видишь ошибку с кодировками, ищешь решение, находишь нотпад++, попутно узнаешь что такое денвер и вот уже ты локально имеешь свою дырявую форму авторизации, в которой логин и пароль видны в гет параметрах.
Сейчас же ты узнаешь не об условном нотпад++, а о куче различных IDE. И да, ты можешь написать тот-же код в блокноте, но везде ведь кричат о самом лучшем IDE (и везде о разных). Уже появляется желание пойти на курс или прочитать книгу «Выбери свое IDE за 24 часа». И вот этих наворотов — композеров, фреймворков, апи, лучших практик, ORM, аджакс и прочее прочее прочее, их стало слишком много. И все это нужно, чтобы написать СОВРЕМЕННЫЙ проект состоящий из формы авторизации. А кто хочет начинать не с современного?
И вроде все стало проще, берем фреймворк, подтягиваем зависимости, херак — херак и готово. А на деле порог вхождения увеличился, из-за возросшего объема информации и порой неактуальной выдачи в поисковиках. И вот тут то школьник и забивает болт на эту идею, а ему всего-то нужен проводник, план обучения современным технологиям, которые выросли вокруг PHP.
И да, ты можешь написать тот-же код в блокноте, но везде ведь кричат о самом лучшем IDE (и везде о разных)
Да ладно бы кричали, так ведь ещё и прямо в вакансиях пишут «Требуется знание Eclipse».
Тем, что тогда эти технологии считались «устаревшими», а вокруг PHP был хайп? Так и сейчас есть всякие Arduino и прочий rust/golang!
Мне кажется что всё банальнее: в 2002м ещё о 1998м/2000м люди не забывали и понимали, что наличие какого-то опыта использования фреймворка — не есть гарантия трудоустройства.
Так всё будет хорошо: один кризис (а следующий будет покрупнее и 2000го и 2008го) — и горе-разработчки всё поймут.
Жизнь штука такая… жестокая. Не хотите учиться «по хорошему» — заставит «по плохому»…
когда и IDE разных было полно (хошь — Visual Basic, хошь — Delphi, хошь — Visual Studio)С каких пор Visual Basic и Delphi стали IDE?
Или вы в настоящих шотландцев играть собираетесь или давайте сюда что-нибудь признаваемое хоть кем-нибудь, кроме вас, определение IDE как «интегрированные редактор кода и компилятор плюс возможность запуска программ».
Мне вообще смешно наблюдать споры (в которые я никогда не вмешиваюсь, так как не вижу смысла спорить с людьми, путающимися в терминах): IDE vs Vi/Emacs. Ребята, вы о чём вообще? GNU Emacs, an extensible editor that is commonly used as an IDE on Unix-like systems красуется прям посреди статьи об IDE в Википедии!
А Delphi и Visual Basic предоставляли куда больше, чем «редактор с возможностью запуска кода»… и, с точки зрения прикладного программиста, больше, чем многие современные IDE! Возможность рефакторинга кода — это прокрасно, но зачем она, если вы всё равно не можете кнопочки мышкой подвигать?
IDE — Visual Studio, notepad++ или любой другой на ваш выбор.С удовольствием почитаю статью про то, как вы будете «Visual Studio, notepad++ или любой другой на ваш выбор» среде будете писатьь программы на Visual Basic (не путать с Visual Basic .Net).
Напомню, что в Visual Basic программа не в текстовом файле хранится, так что будет интересно как вы её собрались перегонять в Notepad++ или Visual Studio.
Получается, что «Visual Basic .Net» это следующая версия языка Visual Basic, сразу после версии 6.0.С точки зрения маркетологов — да. С точки зрения программистов — нет.
Отличие между Visual Basic и Visual Basic .NET — больше, чем отличия между ранними версиями C# и Java! И в обоих случаях Microsoft предлагал очень корявые конверторы из одного языка в другой, кстати.
Возможно вы скажете, что Visual Basic 6.0 и Visual Basic NET абсолютно разные языки программирования, но я так не считаю.Что считаете вы — не так важно. Важно что считают разработчики… а считают они вот что: за последнее время Visual Basic перешёл в популярности с 20го места на 16е! Уже кстати, то, что TIOBE считает отдельно программистов на Visual Basic и Visual Basic .NET (и да, он тоже достаточно популярен) и в вакансиях они описываются отдельно… и что разработчики за 20 лет (sic!) так и не перешли с одного на другой (статьи на эту тему всё ещё появляются)… могли бы натолкнуть на мысли некоторые.
Приведите мне ещё один пример другого языка, где бы переходу с одной версии на другую так же яростно бы сопротивлялись? При том что даже фирма, выпустившая VB6 уже прекратила его поддержку давным-давно?
P.S. И да, про Perl6 я знаю, спасибо. Там даже разработчики уже согласились с тем, что это нифига не разные версии одного языка, речь даже о переименовании одного из них зашла. Так что Perl6 — это тоже скорее повод считать Visual Basic и Visual Basic .NET двумя разными языками, чем одним…
Начинал разработку еще с php 3.5, помню хайп вокруг register_globals on и множества любителей и только зарождение ООП в php, веселое время было и замечательное, мы с пачкой энтузиастов начинали изучать php как один из простых языков. Было желание узнать все, официальная дока irc каналы, php-nuke как лучшая система и почти уникальная на тот момент…
По теме…
К сожалению в данный момент есть все то, чего не было у нас тогда. «Бестпрактикс», коммерция в сообществах, почти мертвый опенсоурс который так же стал коммерческим, абстракция на множество «чихов» и в основы уже почти ни кто не вдается, зачем основы если есть абстракция и документация по популярному yii, laravel, а множество пакетов позволяет собрать свою «цмс» просто настроив зависимости композера.
По моему это всё очень сильно от человека зависит. Если человек хочет просто "нажимать кнопочки и получaть деньги", то вы можете сколько угодно обучать его основам, но он всё равно всё забудет и будет лепить свои "велоспеды". А если человеку интересно учиться и понимать как оно всё устроено, то дайте ему "велосипед" и он сам найдёт где выучить основы чтобы понять как его сделать правильно.
И проблема скорее в том что раньше в ИТ шли в основном те, кому ИТ было интересно само по себе. А теперь в ИТ идёт очень много людей, которым зарабатывать деньги гораздо интереснее чем сам процесс.
Если человек хочет просто «нажимать кнопочки и получaть деньги»
Вы так говорите, будто это что-то плохое.
Никто не осуждает электрика, токаря, пекаря
Пора уже привыкнуть к тому, что программист это сантехник XXI века, что любой человек может за полгода научиться нажимать кнопочки и получать за это денег на хлебушек.
Вы так говорите, будто это что-то плохое.
Так а я нигде и не говорил что это само по себе обязательно что-то плохое. Просто надо понимать что это тоже имеет свои последствия. Например в виде тестов и проверок на "профпригодность" на собеседованиях. И кучи разных других вещей.
Пора уже привыкнуть к тому, что программист это сантехник XXI века, что любой человек может за полгода научиться нажимать кнопочки и получать за это денег на хлебушек.Да ради бога! Если бы ещё эти «сантехники» не пытались устраиваться на нормальные вакансии, где требуются нормальные знания — совсем хорошо бы было…
Кажется, что раньше "учили PHP" так же, как и сейчас "учат фреймворками" — дают набор шаблонов для запоминания, из которых можно слепить некий каркас. Однако, сегодня обучение — это бизнес, который готовы попробовать многие, да и технологии обучения (онлайн, вебинары) дают волю любому попробовать это.
Можно сделать отличный курс, который подведет к фреймворкам через основы:
- от простых запросов в БД через осознание проблем, с которыми можно столкнуться, к DBAL;
- от
if ($_POST['user_id'] == 1)
до PSR-7 и примеров реализации в фреймворках; - от
include 'function.php'
черезspl_autoload
к PSR-4 - от
index.php?page=contacts
до роутера на конкретных примерах.
Но, такой курс получится дольше, сложнее, дороже. Какой спрос, такое и предложение.
На той же курсере вполне есть выбор из разных по сложности вариантов
Кажется, что все желающие идут сегодня примерно по такому же пути.
Как будто про меня написано. Спасибо добрым людям, рассказали про mysql_escape_string еще до первого деплоя.
Такой старт получился главным образом из-за того, что лучшие практики только зарождались. Сейчас, когда нужно разово вникнуть в новый стек активно прибегаю к руководствам по быстрому старту и стараюсь не отходить от рекомендаций. Желание копнуть глубже приходится на время подавлять, чтобы сроки не затянулись.
Пусть лучше неопытный человек пишет на хорошем поддерживаемом фреймворке, не допуская кучи нелепых ошибок и уязвимостей. Вообще немного освоится во всём этом, научится работать от постановки и продумывания задачи до деплоя.
А вот когда он поймёт, что его знаний просто не хватает для реализации чего-то с помощью фреймворка — спросит совета на форуме, и ему более опытные люди подскажут куда копать.
И ссылку на PHP Right Way дадут.
Но он уже в коммьюнити, он более-менее «вдупляет» и может сформировать правильные вопросы, потому что фреймворк провёл его уже через все буреломы — и уже не страшно, и можно уже самому залезть в терновый куст и немного там покопаться.
А то в былые годы ты прямо годами мог продираться к тому, чтобы понять, как сделать рабочий онлайн-магазин, а потом — боже святый — пароли то в плэйн-текст. А как «солить»? «А хз, солить что ли надо?» «А я никогда не солил, и всё работает, уже пять лет мой сайт пчеловодов-любителей нормально живёт.» «А я и строки не эскейплю и ничего».
Всего этого брожения умов, которые проторили себе путь с самого низа и ушли в разных направлениях — спасибо, уже наелись.
Лучше новичок, который готовыми блоками может построить дом через 3 месяца, чем доморощенный профи, который сам обжигает корявый кирпич и складывает кособоко. Первый научится правильно и сможет потом ухватить детали — второму придется переломать себя.
Пусть лучше неопытный человек пишет на хорошем поддерживаемом фреймворке, не допуская кучи нелепых ошибок и уязвимостей.Ваша вторая часть ну никак не следует из первой. Какие бы ни были великолепные у вас фреймворки — при незнании «матчасти» уязвимости у вас будут всё равно.
А вот когда он поймёт, что его знаний просто не хватает для реализации чего-то с помощью фреймворка — спросит совета на форуме, и ему более опытные люди подскажут куда копать.Так он не поймёт. Он пароль прямо в URL засунет — и у него всё заработает.
Лучше новичок, который готовыми блоками может построить дом через 3 месяца, чем доморощенный профи, который сам обжигает корявый кирпич и складывает кособоко.Вот только новичёк, не знающий как работать мастерком состряпает такой дом, что там во время дождя нужно будет с зонтиком сидеть. А если, не дай бог, чуток тряхнёт — то и не будет у вас дома.
Готовые блоки, увы, не отменяют головы.
А когда читаешь говно-код мастера «вам шашечки или ехать», то сразу возникают вопросы: а что это за валидация такая интересная, что это за бест-практики тестирования такие, почему нельзя было использовать стандартный логер? И самая главная головная боль: теперь надо будет учить (тратить время) других, чтобы они разбирались в этих выдающихся инженерных решениях, не имеющих ни документации, ни известных за многолетный опыт использования сообществом знаний о преимуществах и недостатках данных конкретных решений.
Намного выгоднее, используя в проекте конкретный фреймфорк, дать время новичку освоить его практики, а не позволять тащить бекграунд его предыдущих проектов сюда.
Опытный и так себе не позволит, работая в рамках фрейморка, изобретать велосипед для того, что итак уже в нём реализовано. Даже если он раньше с этим не сталкивался. В этом его ключевое отличие от новичка — не тащить за собой свои «достижения» из компании в компанию: я на прошлом месте работы так делал!
Мы вроде бы и обучились, а как оно работает изнутри так и не поняли.
Сам я всего пару лет назад практически случайно с околонулевыми знаниями попал в разработку, сразу в продуктовую команду с yii1/yii2.
На мой взгляд писать на фреймворке и не разбираться как он работает изнутри возможно только в одном случае — если верх сложности для ваших задач это вывести данные из БД на страничку.
Иначе варианта два:
1) Ты пишешь с большим количеством ошибок (ни одни фреймворк не компенсирует отсутствие опыта и профессиональных навыков), наступаешь на одни и те же грабли, начинаешь копаться почему ты на них наступаешь и неизбежно постепенно погружаешься в документацию и понимаешь как же это все там работает под капотом.
2) Ты пишешь с большим количеством ошибок, но процессы в твоя команда достаточно профессиональна и процессы в ней налажены достаточно хорошо и твой код не проходит ревью, а фидбеком ты получаешь ссылки на документацию/статьи/объяснение почему так делать не стоит. В итоге постепенно ты также становишься лучше даже невольно начинаешь понимать как оно там все работает.
Все же я надеюсь и почти уверен, что нельзя писать что-то хоть немного серьезное в нормальной команде и не иметь представления о том как работает то на чем ты пишешь.
Проблема тут в том, что любой другой язык изучают сначала отдельно, а потом прикладывают к фреймворку. Тот же Python — никак не получится (ну ладно, получится, но будет малоэффективно) сразу изучать Django, нужно понимать, как язык работает. А курсы по PHP, видимо, пытаются пропустить эту стадию — и преуспевают, потому что язык и фреймворк это поощряют.
Писал это и подумал, что тут ещё роль играет фактор поверхностности подхода. Не хочет клиент писать бэкенд и фронтенд, клиент хочет, чтобы был сайт, и чтобы сайт работал — поэтому ему вполне хватит человека, который не знает, как фреймворк под капотом работает. Сложных задач всё равно не будет, а когда будут, можно нанять более сложного разработчика прикручивать их к тому, что уже есть. Грустно, согласен, но закономерно.
потом Delphi, чтобы проникнуться ООП в полной мере…
а дальше переходить на PHP3 и дальше, дальше… эх, ностальгия!
Я начинал PHP ещё в школе, писал что-то похожее из статьи по книжке. В книге было и как написать простые счётчики и небольшой форум с необходимым функционалом. Также было написано про разные возможные уязвимости (XSS, SQL-inj) и как их избежать. После этого я написал свой сайт полностью с нуля (с файликами sys.php, logout.php и прочим), который до сих пор в таком состоянии и находится вот уже более 10 лет (смотреть в тот код довольно неприятно, но немного его поддерживаю, недавно перевёл на PHP 7 и фиксил основные ошибки).
Так вот, имея такой бэкграунд, я узнал о фреймворках и… они показались мне очень сложными. Я смотрел Yii, его основные концепции MVC, шаблонизации, ORM. Выглядело чересчур усложнённым и вместо того, чтобы взять и просто использовать, я написал свой MVC каркас (ну как же, я же знаю PHP, напишу лучше и проще, думал я тогда). Там были основные модули, подобие шаблонов, но в основном оно не ушло далеко от примеров из той самой книжки, с которой я начинал.
Понимание того, что надо использовать фреймворки для упрощения себе жизни, а не строить каждый раз свои велосипеды, пришло позднее. Да, тот каркас был очень прост и понятен, к нему можно написать расширения и мне повезло, что его архитектура позволяла реализовывать много нужных вещей. Но его сложно поддерживать, расширять и весь базовый функционал логина, работы с базой нужно писать самостоятельно каждый раз.
Но понимание этого пришло не сразу, а когда я уже сменил место работы. А мой MVC каркас так и продолжает жить в старых проектах и мне немного за это стыдно.
А мой MVC каркас так и продолжает жить в старых проектах и мне немного за это стыдно.Это нормально. Если вам не стыдно за то, что вы творили в коде 10 лет назад — то это значит, что за эти 10 лет вы ничего не узнали и ничему не научились.
Вот это — ужасно. А что вы когда-то писали плохой код… ну так лучше писать сначала плохой код, а потом научиться писать хороший, чем всю жизнь порождать дерьмо…
TL;DR Надо доверять абстракциям.
Дальше пойдёт в основном про front, но думаю справедливо и для PHP
Чем дальше углубляешься, тем больше радуешься, что за тебя уже всё продумали и реализовали, осталось только это соединить и решать бизнес задачи.
Конечно углубляешься, натыкаешься, иногда вдохновляешься что-то запилить, но представив себе весь объём, который вот так самому наклипав изучить, понимаешь что и десятка жизней не хватит. Сброщик, фреймворк, ui kit, и каждый состоит из модулей и к нему еще идут плагины, так еще же есть IDE, сам язык, его движок, погоди а браузеры, их особенности, погоди а REST, GraphQL, а WebSockets, Events и т.п. и т.д.
Хорошо — это ваша специализация, а ось, а микросхемы? Ну вы поняли.
Мой первый скрипт — это jQuery без js. Цепочка вызовов, перемещение по дум, навешивание событий и ни каких переменных и функций. Но по живой книге, дальше конечно изучил сам язык, подтянулись фреймворки.
Писать что-то своё — здорово, но нельзя быть оторванным от мира, пишите то, чего нет, а найти это на самом деле не сложно.
Да, надо углубляться и изучать, но фреймворки сейчас — это как ЯП тогда, вы же не строчите двоичный код?
Да и я не думаю что новичку надо прям разъяснять с самого начала всю разницу прототипных классов от классического их понимания.
Сейчас огромная потребность в руках и фреймворки позволяют заполнить некоторую брешь. А как глубоко вы погрузитесь уже зависит от человека.
Перемещение по дум обычно использует технологии IDDQS, и IDKFA
TL;DR Надо доверять абстракциям.Абстракции текут. Ваш КО.
Чем дальше углубляешься, тем больше радуешься, что за тебя уже всё продумали и реализовали, осталось только это соединить и решать бизнес задачи.А не могли бы вы привести пример этой бизнес-задачи, которую нельзя было бы легко решить на Delphi 2 лет так 20 назад? И рассказать — как часто вы с этой бизнес задачей сталькиваетесь?
Только не «хотелки от заказчика», которые ничем не ограничены, а что-то вот… «бизнесовое».
И в 2006м я удивился — как парень, который нифига не знает радиоэлектронику (к слову — никак) — чинит принтеры и компы. Как происходило: включает комп — не грузится. Начинает с малого — память вытащит — другой заменит и пошел по компонентам. Потом повзрослел и по сигналам биоса определял в чем дело. Напомню — радиоэлектронику он и не начал учить. Потом вижу пошел дальше — феном материнки восстанавливал, видеокарты грел — и блин — работал метод.
Второй пример — вместе в радиокружок ходили с челом. Потом он начал чинить телефоны, потом смартфоны. Но я видел что он застрял еще тогда на лампах и чуть позже на выдергивании конденсаторов «КМ» и прочего драгмета. И он чинит смартфоны. Свой небольшой бизнес у него. Как? Я без понятия.
Они пропустили все основы, все азы. И тупо ремонт блочным методом. Так вот и программирование для многих — черный ящик с «подай сюда, то — получишь на выходе это».
А как больно смотреть сейчас как люди сайты на вордпрессе с помощью Elementor «программируют». И это у них на потоке.
p.s. я тоже сейчас учусь на своих костылях и грабли на моем пути — их много. Если кто зайдет и из последних моих работ на гитхабе раскритикует в issue — буду признателен.
Ну не суть.
Для меня большая разница между тем, что тогда и тем, что сейчас — интернет, а именно легкость к получению большого кол-ва разностороннего материала.
Уже на старте, и сейчас и тогда, наверное, каждый понимал, что есть проблемы с защитой, с ресурсами, с универсальностью, с производительностью.
И если не брать случаи, когда хотят просто по быстрому срубить и свалить и больше не начинать, то каждый уже сам осознано принимает решение.
«Да, я понимаю, что в моём проекте много дырок, но кому он нужен», «Да, оптимизацией с точки зрения производительности не занимался, но он и так пойдёт, а дальше расти не будет», «Да, проект запуститься только у меня и на таких же кранах, как у меня, ну и больше никому не надо ...» и так далее.
Если же не так, то как минимум будет поиск —
Ddos атаки, как избежать
уязвимости сайтов
java/php/c#/…. best practice
UI/UX/адаптивный дизайн
Я больше администратор, чем программист. Несколько недель назад в телеграм-чате зацепился с человеком. По его сообщениям до, человек производил впечатление опытного системного администратора, программиста. Даже, как то стыдно рядом с таким умничать, но я как-то сумничал понеслось, поехало, стал ему писать в личку, а потом в разговоре о Cygwin, он и раскрылся. Этот пацан по верхам нахватался всех этих популярных терминов, покатал чуть docker, может посмотрел обучалки по нему, не знаю, как, но человек реально в базе, в истории развития сред, в операционных системах мало что шарит, но увидишь это не сразу, а по оговоркам. Нет, конечно, может очень крутой админ его сразу бы разобрал, но мне потребовалось время. И в индустрии сейчас очень много петухов такого плана, которые своими яркими перьями и дичайше скоростным результатом, хоть и плохим, вызывают большие симпатии у окружающих и работодателей. Сейчас настало время модных хипстеров. Как всю там работает на низах, все эти протоколы, работа с памятью, ввод-вывод — не нужно, когда есть верхняя надстройка всё это делающее, пусть и не эффективно, пусть и дырявая, пусть даже падучая. У нас есть утилиты, которые будут отслеживать её падение и будет запускать. Да, да и это в прод. Директор всё равно не разбирается. Мы же ему не машину постоянно глохнущую на нейтрали даём, тут он точно не поймёт, где его «набманули»(этот термин придумал мой брат ещё, когда мы были совсем малышами).
Грустно это всё.
А вред от великов именно в корпорациях плохо. Глупо писать свою систему задач, при наличие уже безчисленного множества. Как минимум, можно взять за основу готовую. Но, всречаются и такие велосипедостроители, которые берутся в организации разработывать свой велосипед, собирая для этих целей целый отдел. Да и в целом открытое ПО развивается как-то на месте. Появляются всё более новые изощрённые методы, программы выполняющие известны функции, однако существуют целые прослойки, которые стоят на месте, потому что велосипедить там, где просто — легко, а в сложные дебри лезть не охота, может вообще не получиться.
Только не говорите, что вы таким не были или мой взгляд на обучение