Плохо ли создавать проекты с нуля? Что значит быть про?

Здравствуйте.

Никак не могу понять, зачем люди массово используют backend-фреймворки, ООП и тестировщики.

Зачем тратят тучу часов на создание классов для функций, которые легко понятны и описываются 1-2 строками. Зачем подключают к проекту мастодонтов не используя и половины их функций. Как и зачем используют движки для сайтов под уникальные сервисы, это же дикий геморрой когда нужно кроме написания приложения ещё и понять как его присоединить к чужому коду (аля сервисы на dle,wordpress и т.д).

Все эти вопросы я задаю себе по ночам, я пишу проекты просто на коленке, используя notepad++ для php под бекенд и знания html/css/js под фронт. Под фронт максимум использую связку jquery/bootstrap и может плагины. Недавно ещё сделал чат с NodeJs на сервере, кроме как для real-time больше смысла его использовать вообще не вижу. И я никак не могу понять зачем люди используют доп. инструменты для бекенда? И соц. сети писал, и форумы и сервисы, и ни разу не потребовалось использовать что-либо кроме notepad++/sublime, разве что однажды ещё юзал htmldom плагин для php, чтобы парсить элементы страницы.

Безопасность?
Ну фиг знает, использую вот эти функции на все входящие данные и проблем нету ни с инъекциями, ни с xss:
//Для обязательных данных
function clearinput($input_text){
if ($input_text == ""){
die();
exit;
}
$input_text = strip_tags($input_text);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);
return $input_text;
}

//Для опциональных
function clearinput2($input_text){
$input_text = strip_tags($input_text);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);
return $input_text;
}

Может что-то посложнее, типо csrf? Ну фиг знает, посылаю к каждому запросу с клиента сгенерированный хеш в $_SESSION и проверяю на сервере.
Может какой кликджекинг или ещё чего? Просто на всех страницах стоит header X-Frame-Options: DENY.

И вот никак не могу понять, зачем писать ООП классы для, например, изменения группы пользователя, когда это делается 1 строчкой?
//Вроде любому вменяемому разработчику понятно что делает, тут же даже в самом запросе чуть-ли не объяснение
mysqli_query($bd,"UPDATE `users` SET `group` = '1' WHERE `id`='$user' LIMIT 1");


Я нигде и никогда не учился на программирование, просто много гуглил и много пробовал, объясните мне дураку, зачем всё усложняется? Чем плох, тот же процедурный стиль кода, разве упаковка кода в функции не проще?
//Типо ООП
$user->delete;
//Типо функция процедурная
delete($user);
//Один хрен же, нет?

Неужели чтобы быть профессионалом нужно проводить тесты над кодом который ты и так знаешь? Обязательно изучать и использовать супер-фреймворки, вместо коротких, простых функций выполняющих только то, что нужно? Использовать вместо адекватно выстроенной mysql, какие-то другие модные БД, ничем не отличающиеся по работе и скорости?

Объясните, пожалуйста, а то я очень комплексую, что просто быстро пишу работающий код, а все вокруг говорят о чём-то мне совершенно чуждом..
  • Вопрос задан
  • 6290 просмотров
Решения вопроса 1
ТС, надеюсь никому никогда не придется работать с тобой в команде и поддерживать твой код. Одно дело не знать, спрашивать и прислушиваться, другое дело гнуть свою кривую линию.
Ответ написан
Пригласить эксперта
Ответы на вопрос 19
@Plus3x
c10c573f52694badb316d1aa222bc323.png
Ответ написан
Комментировать
zoonman
@zoonman
⋆⋆⋆⋆⋆
Я понимаю, о чем вы пишите и почему. Ваш код работает, т.к. решает поставленные задачи и удовлетворяет потребности ваших клиентов. Имеет ли он право на жизнь? Да, но только в вашем отдельно взятом случае.

Дело в том, что ваш код не гибок, в нем отсутствует масштабируемость, его невозможно поддерживать.

Что если вам потребуется сделать блог, в котором нужно иметь комментарии, которые обновляются в режиме реального времени? И комментарии могут содержать HTML, но такой, чтобы ваш сайт не могли взломать?
А еще комментарии короче 2000 символов по воскресеньям платные. Оплата через Яндекс.Деньги.
Вы все это делаете, все работает.
Затем заказчик вам говорит, я хочу запустить такую же систему другу, но с оплатой по понедельникам через WebMoney.
Вы копируете сайт, переписываете функцию оплаты.
Дальше ваш заказчик видит, что у друга больше денег, он просит добавить WebMoney к себе.
Вы опять переписываете код. Добавляете условия.
Потом к вам приходит друг заказчика и хочет другое оформление. Вы переписываете его функции.
Затем он просит добавить поиск по названиям записей к себе на сайт. Вы делаете. Буквально на следующий день к вам приходит заказчик и тоже просит поиск, но не только по названиями, но и по телу статей и по комментариям. Вы делаете.
Затем ваш заказчик видит, что дела у него идут в гору и он просит отменить платные комментарии и сделать просто платные аккаунты для всех. Вы переписываете.
Тем временем друг просит вас сделать все тоже самое, но с его оформлением.
Дела у заказчика идут в гору и сайт начинает тормозить. Вы делаете кэширование.
Внезапно сайт заказчика попадает в топ и нагрузка резко увеличиваете настолько, что один сервер уже не справляется. Вы переносите все на самый мощный, но он его тоже мало.
Нужно делать горизонтальное масштабирование.
Для этого нужно переписать все функции, которые работают с базой данных. А их уже больше двухсот. И просто замена не подходит.
Сайт открывается через раз, заказчик звонит вам каждые 2 часа и спрашивает, как там прогресс.
И тут вам присылает письмо друг заказчика и говорит, что хочет перейти с MySQL на PostgreSQL.
И вы понимаете, что вам надо будет переписать еще 300 функций, но на другом сайте. Вы его посылаете, поскольку вы и так в мыле.
Друг жалуется на вас заказчику. Заказчик, не ставя вас в известность, нанимает другого исполнителя, у которого отваливается челюсть от того, что творится в системе. Он объясняет, что ему нужно будет потратить полгода, чтобы вникнуть в то, чтобы понять ваш код, но он может сделать все тоже самое за 4 месяца, причем для заказчика и его друга так, что это будет расширяемо и поддерживаемо не только им.
Тем временем, спустя двое суток жизни на кофеине вы героически переписываете все функции заказчика и идете отсыпаться. После суток сна вы обнаруживаете на автоответчике сообщение, что вы уволены. А все потому, что забыли проверить функцию логина.

А теперь разберем эту историю по частям. Почему же вас уволили?

Незнание абстракций и шаблонов проектирования привело к тому, что вы вынуждены были поддерживать 2 разных проекта с практически одинаковой логикой.
Например ORM смог вам помочь поддерживать 2 разные базы данных без каких-либо усилий. Сменить одну базу на другую стоило бы исправления конфигурации, а не переписывания 300 функций.
Использование фреймворков позволило бы сократить время на реализацию подключений платежных систем. Многие из них имеют готовые реализации.
Опять же в современных фреймворках, например в той же Doctrine реализован шардинг. В большинстве случаев ваши проблемы свелись к изменению настроек.
Но даже если бы вы накосячили, то интеграционные тесты не позволили бы попасть говну в продакшен. А если бы оно и попало, ну накосячили вы с тестами тоже, то проблема была бы обнаружена на раннем этапе благодаря "сине-зеленому" развертыванию и она бы не затронула всех пользователей.
И да, ваш код не прошел внешний аудит.

Чтобы быть настоящим профессионалом, нужно не только знать, но и уметь применять на практике ООП, популярные фреймворки, шаблоны проектирования, тестирование и средства непрерывной интеграции, а еще пользоваться нормальными IDE и нести ответственность за сделанную работу.

Когда пишете свой код, почаще задавайте себе вопрос: А если бы это был код для моего кардиостимулятора? Это поможет.
Это вам для общего развития.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Веб-разработка
software engineer
"И соц. сети писал, и форумы и сервисы"

Где ваша соцсеть хотя бы на десяток тысяч абонентов?
Есть ваш форум, с ежедневным онлайном хотя бы 1000 человек?
Что за сервисы, насколько они востребованы?

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


Пишутся не классы. Пишутся объекты. И объект пишется не под изменение какого-либо свойства. Объект описывает пользователя всевозможными свойствами и методами. И в эту обёртку помещается метод изменения группы конкретного пользователя.


//Типо ООП
$user->delete;
//Типо функция процедурная
delete($user);
//Один хрен же, нет?


Так то оно один хрен, да только не один. Абстрактный пример.
У вас, кроме $user, есть еще $group, $catalogue, $order и еще с десяток объектов, с которые вам нужно будет работать. Теперь представим, что вам нужно будет удалить объекты. В ооп стиле вам нужно будет просто вызвать метод ->delete для каждого объекта. А в процедурном вы будете писать 10 функций delete с разными названиями? Или одна, но внутри вы будете писать 10 проверок, что бы понять, какие данные к вам пришли и как их правильно обработать. А если таких объектов будет 100?

В ооп есть свои + и -. И ни в коем случае ООП не является панацеей ото всех бед. Где-то процедурный стиль выиграет, где-то ооп. Как мне кажется, профессионал обязан понимать, когда и зачем использовать ту или иную технику или инструмент.

UPD
нужно проводить тесты над кодом

И вы, вероятно, путаете понятия "тестировщик" и TDD
Ответ написан
Про от остальных отличается тем, что максимально эффективно использует самый дорогой ресурс - собственное время.

Поэтому: максимально исключается написание с нуля, используются свои и чужие наработки, отлаженные куски кода, библиотеки классов, фреймворки, готовые движки, ошибки отлавливаются прогоном тестов (а не руками)... и т.д., и.т.д.
Ответ написан
devalone
@devalone
̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻
Потому что так выгодно бизнесу. Бизнес не будет платить вам за поддержку вашего велосипеда, когда можно сделать на фреймворке, который знают все. А ещё так тупо быстрее.
Ответ написан
@kgbplus
> //Вроде любому вменяемому разработчику понятно что делает, тут же даже в самом запросе чуть-ли не объяснение
> mysqli_query($bd,"UPDATE `users` SET `group` = '1' WHERE `id`='$user' LIMIT 1");

Про таких специалистов даже есть специальный комикс:
exploits_of_a_mom.png
Ответ написан
Комментировать
@huwesu
Зачем тратят тучу часов на создание классов для функций, которые легко понятны и описываются 1-2 строками. Зачем подключают к проекту мастодонтов не используя и половины их функций. Как и зачем используют движки для сайтов под уникальные сервисы, это же дикий геморрой когда нужно кроме написания приложения ещё и понять как его присоединить к чужому коду (аля сервисы на dle,wordpress и т.д).


1. Если ты этого не понимаешь - значит ты не имел дело с действительно серьезными системами. Так как "написать 1-2 строчки для замены мастодонта" - это что то уж совсем примитивное делать.

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

3. Быть ПРО это не значит НЕ ИСПОЛЬЗОВАТЬ или ИСПОЛЬЗОВАТЬ "мастодонтов". А быть ПРО - это значит правильно выбирать инструмент под конкретную задачу. Где то правильным будет выбор мастодонта. Где то - написать две строчки с нуля.

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


Пока вы пишете "одноразовые" вещи - это не страшно.
Как только перейдете к проектам сложным - там уже так делать будет неверным. Такой подход в сложных проектах затрудняет существенно и вам модификацию/развитие и работу коллегам.
Ответ написан
sim3x
@sim3x
В вопросе идет подмен понятий
В заголовек предлагается обсуждать: с 0 или используя фреймворк
А в теле фопроса: ООП противопоставляется функциональному стилю

Писать с 0 плохо потому, что время не бесконечно и переиспользование кода основной подход для ускорения разработки

И еще больше смущает, что автор приводит дырявый код как аргумент, что можно наклепать решение быстро - только ухудшает ситуацию
Ответ написан
@shaqster
Symfony3 Guru
Плохо ли создавать проекты с нуля?

За такое нужно прибивать достоинством к дереву и выставлять на публичный позор
Ответ написан
@awdemme
Если вас все устраивает - зачем вы паритесь?

Зачем я использую инструменты?
  • Избавляет от нудятины.
  • Уменьшает ошибки.
  • Позволяет работать быстрее, следовательно, зарабатывать больше.


Иногда, не очень часто, целесообразно писть и нуля.

Ну а выбор когда писать с нуля а когда использовать инструмент - это отдельный вопрос.
Умение делать правильный выбор в этом - приходит с опытом. И никак больше.
Ответ написан
Комментировать
lukoie
@lukoie
а то я очень комплексую, что просто быстро пишу работающий код, а все вокруг говорят о чём-то мне совершенно чуждом..

Тут надо бы как у анонимных алкоголиков, научиться комплексовать немного по другой причине.

ЗЫЖ к католикам с такими вопросами не обращайтесь только. у них такое смертный грех .
Ответ написан
@user_root
Fullstack-программист
Если этот проект лично для вас, то ваш собственный фреймворк/CMS/велосипед это здорово для self improvement. Но если проект командный и/или вы, как программист, на аутсорсе, то гораздо лучше будет использовать готовое решение с документацией, протестированное сотнями программистов и апробированном в реальных бизнес-задачах.
Ответ написан
Комментировать
@artem_music
Отвечу со своей колокольни - пока вы пишите проекты для себя, то никаких проблем и вопросов, но как только вы начинаете продавать подобное клиентам, то им с этим в будущем как-то жить, с вами на поддержке или без вас.

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

И после поддержки таких проектов достаточно посмотреть на проекты, например, на рельсах, которые развиваются на протяжении 2-3 лет, и становится очень приятно, что не нужно ломать голову.
Ответ написан
Комментировать
@Pafnutyi
Хуже ООП-а может быть только ООП < : o)
Самый главный недостаток такой методики, не в том что у него много кода, а в том что нутро такой программы вывернуто с ног наголову. Приходится привлекать специально обученных хУру чтобы они придумали особенный способ описания боли (архитектура/объектная модель/фреймворк/свой термин) и избавили обезьянок от черезмерных страданий.

Когда поймёте как запихнуть придумку своей программы в это прокурустово ложе, тогда может быть сможете худо бедно использовать методологию ООП. А лучше всего с ООП поможет разобраться ... функциональное программирование, именно разобраться, писать на нём вам не позволит костлявая рука рынка - сдохните с голоду ;) После "просветления" вы будете страдать и есть кактус дальше - добро пожаловать в чудесный мир :D почитать 1 почитать 2

//Типо ООП
$user->delete; // пользователь сам себя убивает - где здравый смысл ???

//Типо функция процедурная
delete($user); // функция убийства выполняет операцию над пользователем - уже логичнее

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

PS. В функциональном программировании, библиотеки и фреймворки народ в свои программки цепляет по каждому чиху легко и без сомнений, а причина одна - в них очень просто разобраться и использовать абсолютно не задумываясь как они устроенны, вопросов изучения сложности просто не возникает.
Ответ написан
@SV999Z
По религиозным причинам, так же, как и С++.
Считайте, что это пункты ТЗ, сформулированного не вами, а вы - тупой наёмник, инструмент. Спустят требования - будете использовать и материться через строчку, это да.
Ответ написан
Комментировать
poimtsev
@poimtsev
CEO / Founder в Progress Engine
Не слушай никого, кто рекомендует тебе пользоваться ООП и прочей странной и непонятной хренью. Пиши как ты пишешь, от этого выигрывают все:

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

PROFIT! :)

А по поводу технических деталей - все уже написали. И пойми одну простую вещь - не разработчик главный в проекте, а тот, кто даёт деньги - то есть бизнес. И если бизнесу надо, чтобы проект обходился дешевле - он выберет профессионала, который сразу напишет код, который легко будет поддерживать, масштабировать и развивать.

PS: покури Elixir и Phoenix Framework - там нет классов, которые тебя так напрягают :)
Ответ написан
Комментировать
@deadem
Да всё нормально, на самом деле. Только твой подход - он из прошлого века. Сейчас php движется в сторону ООП, а ты продолжаешь играть со штуками пятнадцатилетней давности. С точки зрения результата разницы никакой, но в этой профессии даже для того, чтобы оставаться на месте, нужно изо всех сил бежать вперёд. Иначе отстанешь, устареешь и станешь ненужным.
Ответ написан
sulla
@sulla
w_b_x
1 Какие и сколько новых проектов вы сделали за последний год?
2 Сколько проектов вы поддерживали (правили/дополняли) из ранее сделанных?
3 У вас есть свой "фреймворк" - наработанная типовая кодовая база ? или Вы каждый раз всё с нуля пишите ?

вот тут есть например описание существующих процедурных: https://toster.ru/q/55410, возможно Вам есть резон собрать свой, выложить github и порадоваться звёздам или закидыванию запросами на правки - тогда будет гораздо понятнее чего же именно в Вашем подходе не хватает )
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы