Так зачем же мы пишем этот плохой код, который изо дня в день замедляет нашу работу?
Потому, что мы тогда вынуждены были сделать что-то быстрее!
Я оставлю вас наедине с это логической несостыковкой…
На одной из лекций Роберта Мартина
У нас на DevConf будет не самый обычный мастер-класс. Там не будут рассказывать о новых технологиях или хайлоаде. Будут говорить о коде. Хорошем, плохом. Называется он Принципы хорошего кода на реальных примерах. Расспросим немного автора.
Кто ты и чем занимаешься?
Меня зовут Адель. Я фрилансер. Обычно занимаюсь backend-разработкой. Еще иногда пишу и дописываю плагины для PhpStorm. Из популярных Laravel plugin и .env files support.
Что тебя побудило на такой мастер-класс?
Удрученность текущей ситуации в отрасли. Все одержимы технологиями. В последнее время облачными. Читаешь вакансию, перечисляют используемые технологии, необходимый опыт (который почти никогда, на самом деле, не нужен). Очень круто звучит на собеседованиях. Приходишь на проект. Смотришь на код… и он печально говорит тебе: «Пристрели меня». Смотришь глубже и понимаешь всю его печаль. Он смертельно болен. Как раковые опухоли разрослись классы, которые кто-то, словно в шутку, назвал контроллерами. Как метастазы везде расползлись копипасты. На психологию кода давит то, что он лишь жалкая обвязка для крутых облачных технологий. Но пристрелить дорого.
Мы тут прерывались на хабракат, но ты продолжай
Приходится засучить рукава и убирать копипасты, уменьшать контроллеры до пары-тройки методов с 3-4 строками. Раскидывать логику, инфраструктуру по нужным классам. Хорошо хоть менеджмент проектов всегда одобрял такие правки. Но приходишь на новый проект и там опять тоже самое. Я боюсь, что эта проблема становится все глубже. Я работал 6 лет в большой компании (>1000 сотрудников), которая много вкладывала в обучение своих сотрудников. И это совсем не то обучение, которое нужно! Все эти курсы опять-таки про технологии. Правильно писать код там не учат, даже наоборот. Смотришь примеры кода, которые там показывают и это тот самый, зараженный код, который грозит превратиться в вышеописанный.
Что видит человек, только собирающийся стать программистом? Видит список технологий, которые необходимо изучить. И все! Изредка кто-то поумнее все-таки посоветует прочесть Рефакторинг или Совершенный код. Но этого недостаточно.
Что же ты предлагаешь?
Предложить мне пока особо нечего. Я поделюсь тем, с чем мне приходилось сталкиваться на проектах. Что побудило так написать. Как это исправить и самое важное — как так не писать. Примерный план: для чего и как отделять логику от инфраструктуры, валидация где и когда, неиспользуемая мощь эксепшенов, паттерны, юнит-тесты, etc. Я, если честно, пока не представляю сколько материала я смогу уместить, поэтому этот план весьма примерный.
Есть ли у нас какой-то шанс на светлое будущее?
Я надеюсь. Отрасль потихоньку выходит из хаоса. Создаются специальные обучающие IT-институты. Когда-нибудь сформируется стандарт обучения, где подобно шаблонам проектирования, но гораздо шире и глубже охватят стандартные задачи и пути их решения. Я был бы чрезвычайно рад, если бы были созданы и стали популярны сервисы, подобно Codility, но проверяющие не способность быстро решать задачи олимпиадного типа, а способность грамотно написать код для обычной задачи, автоматически проверив правильность разделки задачи по частям (классам). Чуть более интеллектуально, чем параметры типа cyclomatic complexity.
Если есть желание, приходите послушать. DevConf в этом году проводится совместно с YiiConf.
16 июня пройдет YiiConf.
17 июня — DevConf.
18 июня — день мастер-классов для обеих конференций.
Программа YiiConf уже сформирована. По докладам DevConf пока идет голосование. Успейте приобрести билеты по майским ценам.
Комментарии (55)
pnovikov
30.05.2017 14:48+6От себя (дотнетчик) добавлю, что люди не знают и не умеют оперировать готовыми стеками. Вот для .NET/MVC он например есть. ORM, сервисы, IoC, автомаппер. Просто, как три копейки. Нет жешь блин! Приходишь в каждый проект и там то статика сплошная, то on-demand люди создают себе инстансы чего-то отдаленно похожего на сервисы, то просто подключение к БД пробрасывают в контроллеры (хорошо если одно на запрос!) и фигачат прямым SQL-ем. Воистину понимаешь, что те, кто запилил свой IoC-фреймворк — с теми хотя бы работать можно.
То добавляют абсолютно лишние слои абстракции так, что от этих абстракций потом не избавишься. А еще — самый смак — если у команды есть unit-тесты. Такие, знаете, выстраданные и политые кровью и потом unit-тесты. Они, конечно, не падают когда возникают ошибки логики. Все чаще, знаете ли, тестируют на живой базе как отработал EF-ный .SaveChanges (да да, интеграционные тесты у нас часто по ошибке называют unit-тестами). И вот когда ты начинаешь архитектурный рефакторинг — тесты в лучшем случае выкидываются. Но иногда менеджменту, рьяно отстаивавшему необходимость unit-тестов в проекте «ну чтобы типа все безопасно было, чтобы при каждой сборке вот мы проверяли что система работает, TDD» — становится жалко потраченное время и бабло. И в этом случае тесты при архитектурном рефакторинге на ровном месте создают вдвое больший объем работы, чем был бы без них. Все правильно: разгреб навоз в коде — разгреби и в тестах, которые к тому моменту обычно перестают собираться.
Да да да. Я полностью поддерживаю автора — урезаешь ненужный код — остается 3,5 метода логики и пара классов.
А самое что вымораживающее — так это то, что каждый проект люди начинают «с нуля». Ну то есть с нуля определяются конвенции для разбиения системы на слои, (пере)осмысляется политика использования транзакций, используемые фреймворки подбираются по принципу «о, я слышал о такой штуковине — давайте изучим!», опять говориться о unit-тестах — ну конечно же, изобретаются велосипеды и используется все, что попалось под руку по принципу «ну мы же непрерывно учимся — вот, фреймворк новый пробуем». Зато в полном соответствии с гибкими методологиями! «У нас нет системного архитектора — у нас же SCRUM» — сколько раз я уже такое слышал…
Словом, фуфуфу такими быть.
Adelf
30.05.2017 14:52О да. Под многим подпишусь. Я тоже и дотнетчик и php. Дело не в языках. Дело в людях. некоторые фразочки из этого коммента надо добавить себе в репертуар. «выстраданные и политые кровью и потом unit-тесты» — именно! :)
pnovikov
30.05.2017 14:57Раз уж речь о unit-тестах, то я еще 5 копеек добавлю: подобные конторы/команды любят на собеседованиях спрашивать «а вы умеете писать unit-тесты?» и в вакансиях утверждать «мы используем TDD и без него никуда!».
Але, уважаемые. Довожу оперативно до вашего сведения, что для того, чтобы писались unit-тесты, система должна на эти самые unit-ы легко разделяться! А не быть монолитным куском, который за собой тянет маленькую галактику и не отрезается от БД.
Практика тут показывает что если в решении не используется в каком-либо виде инверсия контроля и разрешение зависимостей — то такой системе надотитьку сосатьархитектурный рефакторинг провести. А не unit-тесты писать.Adelf
30.05.2017 15:03+1Однажды первым заданием на проекте у меня было — «Создать юнит-тесты для этого вот контроллера». У контроллера было 3 тысячи строк :)
pnovikov
30.05.2017 15:07Во во. Держу пари, что когда вы это задание выполнили — где-то в мире заплакал один разработчик, которому придется этот тест в итоге заигнорить или удалить, потому что окружает его такое дерьмо, что непонятно как это все еще работает :)
Adelf
30.05.2017 15:19Все хорошо. Я сделал рефакторинг :)
pnovikov
30.05.2017 15:21Вы при этом плакали? :)
Adelf
30.05.2017 15:28+2Не. Все было хорошо. С одной стороны это как убираться в заваленной мусором квартире. Но конечный результат то приятен! По пути были пофикшены пара багов. Но самое приятное, что автор кода был благодарен. Он же не враг самому себе. Не специально писал так, чтобы было все плохо. Он просто не умел по-другому. Не понимал зачем создавать новый класс, когда все можно написать в этом. Использовать IoC. Не понимал как сделать так, чтобы не копипастить код. В частности, такая вот попытка мастер-класса обусловлена именно этим. Я уверен, что большинство программистов не хочет писать неправильно. Просто знаний и опыта не хватает. Хочу попробовать поделиться тем, что умею.
pnovikov
30.05.2017 15:34Смотрите, тут дело еще может быть в том, что люди (а заказчики — особливо) реально не видят профитов от правильного написания. И с ними очень сложно спорить по этому вопросу, ибо как технически — да, можно запихать всю логику в один контроллер. И таки да — это будет работать. К сожалению, даже в нашей индустрии людей, просчитывающих свои действия на 2-3 шага вперед довольно немного. И зачастую, для того чтобы человек осознал что надо писать правильно — ему требуется «доказательство от противного» — e.g. пронаблюдать хотя бы один проект, у которого maintainability cost превысила net income, что привело к банкротству стартапа/заказчика/watever. Я не говорю что все такие, но по моим наблюдениям в России таких довольно-таки много.
Adelf
30.05.2017 15:40Так везде. Изредка бывает наоборот, огромное внимание качеству кода в ущерб business value. Ну это обычно когда менеджер-технарь :) Необходима некоторая золотая середина. По моему глубоко личному опыту лучшие менеджеры, которые чувствуют эту золотую середину — бывшие QA.
pnovikov
30.05.2017 15:45+1Абсолютно верно — важна середина между качеством и business value. Чтобы одно не уничтожало другое. У меня (Паша скромный, да) это чувство например развито — я могу сделать немного в ущерб качеству, а местами занять технического долга, если это даст существенный прирост в скорости. Но я не знаю как обрел этот скилл и уж тем паче не ведаю как его можно передать, например, подрастающему поколению. На словах-то оно просто звучит, а на деле далеко не всегда понимаешь где кончается реальная польза для бизнеса и начинается качественная выдрочка (НЛО, здесь имеется в виду маленькая выдра!).
a4k
31.05.2017 12:30+1Эх… у меня на проекте почти все контроллеры такие… :(
Сложно нормально научиться постоянно с таким работая.
jetcar
31.05.2017 12:02хуже только когда все эти библиотеки и фреймворки используются не правильно, позволяет автомаппер из огромного запроса создать огромную модельку со связями, а орм это всё записать в базу то никого не интересует как он это сделает а ещё ангуляр который может заменить логику бякенда, вот и получается что из хороших инструментов сделали огромного неповоротливого монстра который делает кучу лишней работы и пересылает туда обратно кучу неиспользуемых данных, и все плюсы крутых технологий сразу пропадают, разве что технического кода меньше
farwayer
31.05.2017 04:20+1Уже давно думаю, что пора в универах и на курсах вводить дисциплиину «Философия кода». И я не шучу. Чуть-чуть перефразирую посыл из этой гениальной статьи: «теперь у нас все в курсе про deep learning и облака, но х*р его знает, как писать хороший код».
INC_R
31.05.2017 05:11Где доктора наук будут рассказывать, что обязательно нужно комментировать каждую строчку кода на русском языке, чтобы другой программист понимал, что int c = a*b — это // с равно произведению a и b.
Имхо,
девочекпрофессоров надо менять на программистов (админов/инженеров/...) с опытом практической работы, а не курсы вводить. Практика показала, что в образовании толку гораздо больше от аспирантов и молодых преподавателей, которые параллельно с универом работают и могут полезными знаниями и навыками поделиться. Но, к сожалению, таких мало и обычно они только лабы проверяют, а учат эти лабы выполнять такие вот профессора, которые примерно в начале 2000-х окончательно потеряли связь с тем, что происходит в индустрии.
Так-то я совершенно с вами согласен, но одно только это не поможет.
EmotionTigran
31.05.2017 10:34Доктора решают совершенно другие задачи, другого уровня, не какой то ваш код… Сравнивать эти две профессии совсем некорректно.
INC_R
31.05.2017 11:32Так пусть они свои задачи решают, не проблема. Пусть занимаются исследованиями, руководят аспирантами и преподают фундаментальные предметы вроде матана или алгоритмов.
Но очень грустно смотреть, как такие вот уважаемые "д.т.н., профессор", которые всю жизнь занимаются теоретическими исследованиями и ни строчки кода для бизнеса не написали, преподают программирование на всяких современных языках, ООП и прочее. В итоге их студенты кое-как могут запилить простые лабораторки, но код пишут как получится — нарушая все возможные рекомендации, которые можно найти в книгах Макконелла, Фаулера, Мартина и т.п. По рукам им дать некому. Что такое git, юнит-тесты, паттерны проектирования, SOLID и т.п. — они тоже не знают.
Я ровно о том, что все эти доктора наук должны заниматься своим делом, а в обучении будущих программистов/админов должны быть задействованы те, кто занимается этим на практике и знает, какие навыки нужны сейчас, а не 20 лет назад. Но таких обычно 2-3 человека на 20 преподавателей на кафедре, и они обычно зайдействованы не в обучении, а в выдаче и проверке лабораторных.
iit
01.06.2017 09:02Если ты доктор наук по it специализации, то думаю такие вещи ты не просто должен знать, а еще и сам разрабатывать новые практики, иначе как-то все печально получается...
EmotionTigran
31.05.2017 10:09Математики и программисты имеют общие темы, но, это достаточно разные профессии и учатся на них по разному.
Master255
31.05.2017 12:51Технологии технологиями, а главное — код
Звучит, как «не важно какое блюдо готовить, главное правильно мыть картошку».
Как это технологии могут быть не в приоритете я не понимаю. Зачем нам тонны правильного, качественного кода, если это не содержит новых технологий? Хоть запишись правильным кодом! Но в этом не будет никакого смысла, если это не будет полезно.
Проблемы сложной поддержки кода решаются созданием нового ПО и покупкой нового оборудования с выделением денежных средств на это. Рефакторинг хорош, только в редких случаях или когда надо переписать что-то относительно не большое.
Я думаю вы пытаетесь решить проблемы политико-экономического характера, правильным написанием кода. Боретесь со следствиями следствий следствий. И из-за этого длинного логического пути не понимаете этого. Не можете осознать настоящей проблемы.Adelf
31.05.2017 13:48+1В любом более-мене сложном приложении главное — это домен. Именно ради поддержки его и строится вся инфраструктура. Выбирается как можно более подходящая и т.д.
И я не говорил что технологии это плохо, просто им своё место.
vyatsek
31.05.2017 14:13Я вам открою секрет. Парвильные пчелы — делают правильный мед. Если человек говнодел, то он г-но сделает на любых технологиях потому, что так или иначе придется решать какие-то уникальные задачи, свойственные данному проекту и данной бизнес области.
Звучит, как «не важно какое блюдо готовить,главное правильно мыть картошку».Неверно, должно звучать так, «не важно какое блюдо готовить, главное чтобы бы повар умел готовил хорошо».Master255
31.05.2017 15:59Вы правда считаете, что лучше повар, который готовит хорошо, но просто картошку, чем повар, который готовит средне, но картошку с мясом?
Вам поесть или разобраться в готовке???
Результат имеет значение. Я не говорю про совсем начинающих кодеров. Просто если у человека есть идеи, то надо их воплощать и не важно какими паттернами и архитектурами. Главное результат! Пусть программа будет написана хоть на HTMLе главное — она должна приносить пользу и иметь смысл.
Красота кода имеет значение, лишь в больших корпоративных проектах. Когда одну программу разрабатывает сразу толпа разработчиков. И им надо иметь какой-то один стандарт… и то не факт, что самый современный. В остальных случаях приоритет должен быть в технологиях, а не качестве кода. Кроме этого качество кода слабо влияет на количество глюков в проекте.
Так что плюсов особо никаких, зато убиваем массу времени на изучение… и теряем время на создание результата — технологий.Adelf
31.05.2017 16:01Кроме этого качество кода слабо влияет на количество глюков в проекте.
Оно влияет и на количество багов, и, самое важное, на быстроту их выявления и исправления.
farwayer
31.05.2017 16:38+2Я предпочту повара, который хорошо готовит только картошку, а не того, который из картошки и мяса делает угли. Даже, если мне нужна картошка с мясом. Почему? Первого можно научить готовить новое блюдо, второго научить готовить будет сложно — он не знает основ.
Master255
31.05.2017 18:08Так про угли никто речи не ведёт! Мы обсуждаем разные методы реализации, а не сравниваем провал и успех.
Исправленная версия, для тех кто слабо понимает о чём я пишу:
«Вы правда считаете, что лучше повар, который готовит безупречно, но просто картошку, чем повар, который готовит хорошо, но картошку с мясом?»
Угли — готовят начинающие разработчики, которые учатся основам основ.
И некоторые технологии, даже в виде углей лучше (т.е. написанные совсем не качественным кодом) чем обычные, но безупречные технологии.
Оно влияет и на количество багов, и, самое важное, на быстроту их выявления и исправления.
нет. Количество багов зависит от логической продуманности приложения, а не архитектуры и способа написания. ООП на не больших проектах не даёт существенных преимуществ в продумывании этой логики. Только на больших.
А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
А что вы вообще понимаете под технологиями?
Нет. Это не то что вы подумали. Под технологиями я имею ввиду — цель проекта. Например, человек придумал что-то новое в медицине (новую технологию) и пытается написать программу для этого.
Написал, работает. Люди выздоравливают и говорят спасибо. Но написал криво… без использования моделей в разных местах, с использованием не правильных паттернов. Мог бы библиотеки заюзать… было бы меньше багов, но люди выздоравливают… и технология работает…
А программист, о котором в статье — будет писать всё верно, качественно… со всеми современными средствами… но будет писать долго… и бросит на пол пути… так ни один человек и не вылечится… Зато он изучил много паттернов и использовал много библиотек! Он крут))), только он не сделал ничего.Adelf
31.05.2017 18:17А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
Нет. Хорошо написанный код — проще! Именно так. Все эти толстые контроллеры, которые не кидают эксепшены когда надо, в них ошибку найти крайне сложно. Мне есть с чем сравнивать. Искал ошибки и там и там.
INC_R
31.05.2017 18:24Количество багов зависит от логической продуманности приложения, а не архитектуры и способа написания.
"Логическая продуманность приложения" вообще-то примерно то же самое, что и архитектура, не находите?
А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
Ну если оценивать качество по количеству логики на число строк, то да. Но только качество оценивают не по этому критерию. Увеличение качества — это когда код становится понятнее. Это не обязательно ведет к уменьшению размера, кстати.
но люди выздоравливают… и технология работает…
Пока не убъет кого-нибудь из-за бага, закравшегося в адовую простыню кода.
INC_R
31.05.2017 16:39+1А что вы вообще понимаете под технологиями? Использование самого модного сегодня фреймворка? Как это влияет на результат? Продукт должен соответствовать требованиям заказчика. Какое качественное влияние оказывают на результат технологии? С кодом как-то понятнее, коряво напишешь — будут неочевидные баги и каждую мелкую проблему исправлять придется по 2 дня. А что изменится от того, что вместо современной технологии X я использую прошлогоднюю технологию Y?
В остальных случаях приоритет должен быть в технологиях, а не качестве кода.
Приоритет должен быть на соответствии требованиям. Накой все эти технологии, если код неподдерживаемый и любое изменение ломает пол-системы? Мы не технологии создаем, а продукты для бизнеса. Создание технологий — узкая ниша, в которой сидят компании вроде MS, Google, JetBrains и т.п. И то над созданием технологий там скорее всего трудятся небольшие группы экспертов, а подавляющее большинство программистов делает продукты.
vyatsek
02.06.2017 15:31Мне нужен тот человек, который умеет делать что-то хорошо и может разобраться в чем-то новом. Прогресс не стоит на месте. Чем умнее человек, тем ему проще осовить новый инструмент и понять каким образом его необходимо использовать.
Zo0m3R
31.05.2017 16:49Есть хорошая практика — пользоваться git-flow с обязательными 2-я аппрувамми и один из этих аппруверов должен быть человек с нужным «чувством кода», то есть с большим опытом программирования за плечами.
Потому что писать код и потом после прочтения аннотейтов тиммейтом отхватить по шапке — одно, а чувство, когда тебя буду ревьювать (тут параллель со словом «собеседовать») — другое.
Можно считать такой шаг «хот-фиксом» ситуации, хотя в основном вы правы, начинать учиться надо было раньше, до начала программированияiit
01.06.2017 09:31Тут есть свои сложности, я как тот самый человек которы смотрит чужой код говорю.
Держать одного спеца только для ревью, который еще и много кушать просит не каждая компания потянет.
Если же пускать такого человека в работу (как в моем случае) у него не хватит времени делать полноценное ревью и стучать по шапке новичкам. В итоге ревью иногда делается постфактум (особенно при горящих сроках) за одно и с рефакторингом и раздачей моральных звездюлей накосячившим месяц а то и год назад.
Помимо этого опытный человек скорее всего имеет высокую квалификацию всего в 1-2 языках/платформах что вынуждает собирать комманду ревьюверов. Да я могу разобрать почти любой php код и указать на его проблемы, но при этом в javascript я не в зуб ногой — что-то простое еще могу написать или проверить, но ES 6 транспайлеры и ваши модные SPA штучки я просто не успеваю изучть и от меня этого даже не требуют.
В компании где я работаю помимо js есть еще и python и java6 в которых я умею только hello world. Плюс один человек для postgres/mysql и уже требуеться 5 человек которые имеют опыт (их еще найти и нанять надо, а опытный целовек по оплате его труда болько кусается) и которые не будут писать код, а только контролировать его качество и стабильность. Если вы не Google Yandex или какойнибудь Банк, тогда вы просто не сможете позволить себе таких людей.
В итоге имеем что имеем, есть пара-тройка опытных в одной технологии людей которые в одиночку лепят очень важные и критичные вещи, от которых у среднечков кипят мозги, группа middle которые одинаково плохо работают в нескольких технологиях и терпимо в одной — их выполняют текучку и пара студентов которые на подхвате. В итоге критичные вещи проверены и перепроверены а не критичные сделаны абы как и туда даже лезть никто не хочет.
OpenMan
Мне кажется, что проблема отрасли программирования в том, что сюда попадают люди, которые еще не получили высшего образования и не обладают достаточной математической культурой, которая развивается как раз в высших учебных заведениях. Ведь ни у кого не вызывает сомнений, что нужно получить высшее образование, чтобы стать врачом или инженером. А для программистов — пожалуйста! Отсюда и все беды.
Adelf
Да. Я примерно о том же. Сформировать в будущем некую систему образования, с довольно жесткими критериями, которая получит всеобщее признание. Это даст огромный толчок отрасли. Но чую я, это пока лишь мечты :)
OpenMan
Я думаю, что по мере проникновения информационных технологий во многие критические области народного хозяйства будут всё чаще возникать случаи «очень нештатных» ситуаций, в результате которых будут приниматься более строгие требования (дипломы, аттестации и т.п.) к профессии программиста.
Грубо говоря, когда гром грянет, тогда и зашевелятся.
beetleinweb
Гораздо важнее образования — обратная связь. Когда программист пишет плохой код, ему, как правило, потом не больно. Потом мучительно больно другому программисту, которому приходится в этом коде ковыряться. И когда пишет хороший код — слой масла на бутерброде редко становится толще вот прям таки сразу. Корреляцию сложно оценить. Она есть обычно, никто не спорит — но зависимость эта слабая, сложная, неоднозначная — много всяких факторов, задержка по времени очень существенная.
И про это народный программисткий юмор есть — «пиши код так, как будто его читает маньяк, который знает, где ты живёшь». И где-то на хабре читал недавно, автор жалуется — в компаниях обычно не разбираются, кто написал конкретный плохой код, кто автор бага. Даже не в том дело, что надо найти, чтобы наказать. Нет. Найти, чтобы сказать — «не пиши так больше, дорогой товарищ» (кажется, про нагрузочное тестирование тема была).
Никакое высшее образование этого не заменит и не изменит. Потому что эта обратная связь — лучший способ получить реальный, жизненный опыт, а не книжный.
Dale
А как же те люди, которые с детства увлекаются программированием, но с «вышкой» как-то не срослось?
Adelf
Мы сейчас говорим не о текущем высшем образовании, которое ооочень слабо коррелирует с будущим скиллом программирования, а о будущей вышке для программистов. Вы же не говорите: «Вот есть доктор, с детства увлекался :), но с институтом не срослось. Неужели ему нельзя делать операции?»
OpenMan
Это вы прям с языка сняли! Я именно так и хотел ответить.
Более того, сейчас в программировании, как и в медицине, очень много специализаций появилось. Т.е. врачи бывают разные, например: стоматолог, хирург, терапевт, окулист и т.п. Также и с программированием — например, специалисты по базам данных, по сетевым протоколам, по математическим алгоритмам обработки изображений, по языкам в смысле трансляторов/компиляторов и т.п.
И для каждой специальности нужно свое глубокое обучение уже после получения базового высшего образования.
А для того, чтобы «сляпать» сайтик для «магазинчика», много ума не надо. И владение многочислеными аббревиатурами систем и технологий не поднимает уровень математической культуры его владельца.
Dale
В современной реальности я не вижу корреляции между наличием высшего образования и качеством написания/понимания кода. Возможно, когда темп развития технологий в программировании снизится, тогда мы сможем говорить о качественной подготовке специалистов в ВУЗах.
Сравнение с доктором, имхо, некорректное. Ты не можешь дома тренироваться резать людей, зато программировать ты можешь сколько угодно.
Я тут немного biased, потому что сам самоучка и бросил универ на втором курсе когда нашёл реальную работу программистом. Меня тогда настолько эта работа увлекла, что уже не до универа было. Но и других примеров пруд пруди, когда большие специалисты либо не заканчивали универ, либо вообще туда не шли. То есть корреляцию ещё доказать надо.
Adelf
Ну даже если бы было возможно резать трупы дома, то одному, без наставника, это делать почти бесполезно. Даже с помощью хороших учебников.
И вообще, я вижу, что многие пытаются через проблемы нашего российского образования доказать, что идея о специальном, сродни медицинскому, программерском образовании — плохая. Вообще не вижу логики :)
vbad
Проблема (отсутствия «вышки») не в том, что «неоконченное высшее» не позволит качественно заниматься каким-то ремеслом (в данном конкретном случае-написанием кода), поскольку ремесло — оно и есть ремесло: чем больше посвящаешь себя ему, тем качественнее результат, а в том, что (отсутствие «вышки») накладывает некоторые ограничения на «индивидума» в широте возможностей само-реализации в различных проектах. Нужно постоянно доказывать своим портфолио, что ты из себя представляешь. Все вышесказанное применимо только на уровне «исполнителя». Движение вверх по служебной лестнице — однозначно навсегда закрыто. И вот тут возникает сожаление об упущенных возможностях. Только исправить, как правило, уже ничего не возможно.
SparkleMan
Но с другой стороны, если у тебя в городе нет хорошего высшего учебного заведения, то у тебя нет выхода.
Ибо тратить 5 лет на обучение там, где ученикам и учителям плевать на сам процесс обучения — пустая трата времени.
Поэтому я бы еще говорил про проблемы контроля качества обучения.
P.s. это касается РФ, как ситуация в других странах — не имею понятия.
pnovikov
Чушь! Я видел очень много людей с высшим образованием, пишущих дурного качества код. Знаете к чему приводит переизбыток образования при неумении писать простой и эффективный код? Правильно — к «русскому коду». Русский код — это когда у тебя есть абстрактная фэктори для сервиса с единственным публичным методом, который вычисляет факториал используя частичную LINQ-выборку из бесконечного генератора чисел (который на yield return построен).
Представьте что эти носители высшего образования пишут на более серьезных задачах.
Так что высшее образование зачастую приводит к повышенному желанию наличие этого самого высшего образование продемонстрировать. То есть не гарантия.
INC_R
Это не совсем верно. Система образования у нас в основном такая, что из этой фразы выпускники большинства ВУЗов, обучающих по разным направлениям IT, знают только факториал. Ну и кто-то может помнить, что "методы — это то же самое, что функции".
И это неудивительно, если учитывать, что курс по веб-программированию в одном из довольно известных профильных ВУЗов последние лет 15 или даже больше читает 90+-летний профессор, рассказывающий про то, что сайты надо делать на CGI или PHP3 в IE6, а все более современное — фигня для домохозяек, которая никому не нужна. И это не один особый случай, так дела обстоят во многих учебных заведениях. Есть, конечно, и отличные преподаватели с отличным курсами, но это скорее исключение.
С другой стороны, многим студентам тоже нафиг не надо напрягаться, мотивации никакой. Все думают, что их учат как надо и они потом после выпуска сразу будут работать программистами, хотя их уровня знаний в IT хватит только для того, чтобы в excel графики строить и по инструкции hello world написать. А еще они методички понятного качества для будущих поколений пишут вместо преподавателей за автомат.
Так что я более чем уверен, что озвученная вами проблема — это не от переизбытка образования, а от его отсутствия. Я как раз сейчас магистратуру заканчиваю (осталось только диплом на руки получить) и это все прямо на себе ощущал 6 лет. Если бы не занимался самообразованием, то сейчас бы, видимо, думал, в какую организацию идти гамбургеры продавать на кассе. Зато отчеты писать умеем по ГОСТам и на 20 страниц размазывать то, для чего хватило бы 3-4.
vbad
согласен на все 100%, особенно порадовала фраза про самообразование.
Pakos
Как раз на серьёзных задачах образование очень пригождается, нормальное образование. Когда задачи не чисто програмистские(поэффективнее переслать побольше байт из а в Б), а завязанные с предметной областью. Тут уж без ВО никуда. Технологии приходят и уходят, база — остаётся. в том числе математика, физика, биология, сайтами дело не ограничивается (тем более сайты бывают разные и бек-энд вполне может решать одну из таких задач).
OpenMan
Мир программирования состоит не только из задач веб-фабрики, в которых многие программисты используют пару фреймворков и каких-нибудь технологий, склеивают это между собой и готов продукт. А есть еще совсем другие задачи, которые такие программисты-самоучки не решают в принципе, потому что не умеют. К таким задачам можно отнести обход графа, реализация алгоритма балансировки двоичных деревьев в сетевой базе данных, рекурсивный спуск по дереву для различных задач, даже банальные способы сортировки не все эти программисты способны реализовать применительно именно к своей текущей конкретной задаче. Как правило они ищут какой-то готовый продукт, в котором это реализовано. Этот продукт втягивается целиком ради одной задачи и в результате собственный проект пухнет, как тесто на дрожжах. А если кто-то пытается всё-таки сам реализовать какой-то алгоритм или решение, то его обвиняют в изобретении велосипеда.
Поэтому проблемы плохого кода состоят не только и не столько в механизмах использования классов, контроллеров, интерфейсов и прочего, ныне очень популярных в основном при построении пользовательских интерфейсов (как веб, так и десктоп, а также мобильных). Кстати, модель ООП должна быть не в самом языке, а в первую очередь в голове. А проблемы кроются в неумении правильно построить внутреннюю модель программы, эффективно реализовать необходимые алгоритмы самостоятельно применительно к той модели данных, которая выбрана в конкретном проекте.
raidhon
Полная чушь!
Где в математической культуре учат стандартам PSR в PHP?
Или что PEP 8 это хорошо, что код нужно тестировать, комментировать и документировать?
Что не нужно пихать весь код в контроллеры, что 50 вложенных callback это плохо?
Что интерфейс к каждому классу делает только имбецил?
Что библиотеки можно и нужно ставить через Composer, а RubuCop упрощает жизнь?
Список можно продолжать очень долго.
А я вот за свою пятнадцатилетнюю карьеру таких умников встречал, выпускников бауманки и таганрогского технологического.
Математическая культура имеет очень отдаленное отношение к стандартам программирования.
Так как предназначена она для самих математиков и формируется у них и для них.
У программистов есть своя культура программирования.
В учебных заведениях из нее прививают только если шаблоны проектирования.
А вот стандарты как то пропускают или выдают очень устаревшую и бесполезную версию.
Университет в принципе не делает из тебя программиста, он дает тебе 5% процентов нужных знаний.
Остальное ты или учишь сам или меняешь профессию, что что многие и делают.
Программисту же нужно постоянно обучаться и совершенствоваться, а главное практиковаться.
Только интересные и сложные задачи сделают из тебя программиста.
Поэтому такое количество самоучек, которые ничем не хуже а часто и лучше людей с образованием.
Сам работаю с напарником который за пару лет выучил front end программирование на профессиональном уровне.
Причем на таком что сам стал у него спрашивать непонятные мне вещи в разработке на Vue.js и React.
В этом и отличие программистов.
Врачем и инженером ты не станешь без института, а программистом запросто.
Все нужные знания доступны, практика да пожалуйста практикуй на домашнем компьютере.
jetcar
полагаю всё-таки дело не в этом, самые умные девелоперы которых я встречал, вовсе не оканчивали программирование, а в универах как минимум у нас в эстонии в основном учат решать типа олимпиадные задачи, тоесть не так важно качество кода и архитектурное решение, главное что задача сделана, ну и всётаки только 10% из всего выпуска можно назвать хорошими програмистами, а остальные так себе и особо лучше не станут даже с опытом, но не давать им диплом глупо ведь много и таких работ где не надо писать на века, нужно чтоб хоть как-то работало и не дорого, вообщем как и в остальных профессиях, не все хирурги будут делать операцию на мозге, а только единицы хотя у обоих есть высшее образование
Adelf
С этими 10% все понятно. Я за них рад. Но есть 90% вероятность, что нам с вами придется работать с кодом других товарищей. Именно с этим надо что-то сделать :)
jetcar
так тут проблема не в программистах, а в бизнесе и желании сьекономить, если я захочу слепить кастомную машину я не пойду в представительство мерседеса чтоб они для меня нарисовали и собрали, дешевле и быстрее будет пойти к местным механикам в гаражах и они мне соберут намного дешевле, и скорее всего ею можно будет пользоваться без проблем, но краш тест она не пройдёт и обслуживание будет сложным если отдавать другим, но это уже моя проблема, так же и с кодом, а запретить всем говнокодерам писать это убить весь малый бизнес
iit
Образование образованию рознь, если бы я сейчас вернулся в прошлое то не стал бы заканчивать вуз в СНГ по возможности (а она была, но я об этом не знал) лучше бы смотался по программе обмена студентов в японию/чехию/США. Но все вышло иначе — в колледже нас учили pascal и структурам данных вполоть до деревьев, интересным алгоритмам вроде апроксимации, рекомендовали хорошие книги вроде того-же "Совершенного Кода". Однако делал это одинокий старик которому не было пофиг на наши знания, 5 остальных преподователей по профильным предметам давали какую-то непереваримую дичь, В институте остались как раз эти-же преподователи. В итоге только деньги потратил впустую.
Математическая культура и опыт не решат проблемму того что код напечатан неверно или сложно обслуживать. Даже на своем основном языке а это php я видел как здравый человек с 10-и летним опытом программирования для проверки mime вместо стандартной функции из ядра языка читал первые байты из файлов и проверял их на соответствие через заранее зашитые в коде шеснадцатиричные константы. Для C++ такой подход приемлем, для php уже нет.
Другой пример — у нас есть отдел java и в него наняли одного перспективного специалста с кучей сертификатов и чемпиона кучи олимпиад по программированию. Я почувствовал себя ушербным бесполезным пхпшником
когда разговаривал с ним в курилке — человек отлично понимал как работают нейронные сети и компьютерное зрение, знал кучу формул и сам доказывал на доске пару теорем по математике на образовательном часу.
Но в итоге он был уволен, как не странно задачи бизнеса он не решал. а код который он оставил за собой до сих пор вызывает ужас у java отдела потому что он не понятен и запутан и неработает от слова "совсем". После увольнения человек угрожал разглашением приватной информации по проектам конкурентам, благо все конкуренты состоят в ассоциации и мягко говоря отправили данного человека в default gateway.
Итог — одних математических знаний мало и далеко на одной математике не уехать, в разработке сущетвует еще огромное количество факторов которое нужно учитывать при создании софта, при том что технолигии не стоят на месте и постоянно меняються. Единственное на что можно полагаться это на свой опыт и понимать что у тебя хорошо получаться а что нет, да я знаю java/c++/js но прекрасно понимаю что знаю данные технолигии недостаточно для того чтобы требовать за них достойную оплату и писать на них production-ready проекты и желания двигаться в этом направлении нет, учу python а php меня кормит.