Комментарии 55
Грубо говоря, когда гром грянет, тогда и зашевелятся.
И про это народный программисткий юмор есть — «пиши код так, как будто его читает маньяк, который знает, где ты живёшь». И где-то на хабре читал недавно, автор жалуется — в компаниях обычно не разбираются, кто написал конкретный плохой код, кто автор бага. Даже не в том дело, что надо найти, чтобы наказать. Нет. Найти, чтобы сказать — «не пиши так больше, дорогой товарищ» (кажется, про нагрузочное тестирование тема была).
Никакое высшее образование этого не заменит и не изменит. Потому что эта обратная связь — лучший способ получить реальный, жизненный опыт, а не книжный.
Вы же не говорите: «Вот есть доктор, с детства увлекался :), но с институтом не срослось. Неужели ему нельзя делать операции?»
Это вы прям с языка сняли! Я именно так и хотел ответить.
Более того, сейчас в программировании, как и в медицине, очень много специализаций появилось. Т.е. врачи бывают разные, например: стоматолог, хирург, терапевт, окулист и т.п. Также и с программированием — например, специалисты по базам данных, по сетевым протоколам, по математическим алгоритмам обработки изображений, по языкам в смысле трансляторов/компиляторов и т.п.
И для каждой специальности нужно свое глубокое обучение уже после получения базового высшего образования.
А для того, чтобы «сляпать» сайтик для «магазинчика», много ума не надо. И владение многочислеными аббревиатурами систем и технологий не поднимает уровень математической культуры его владельца.
Сравнение с доктором, имхо, некорректное. Ты не можешь дома тренироваться резать людей, зато программировать ты можешь сколько угодно.
Я тут немного biased, потому что сам самоучка и бросил универ на втором курсе когда нашёл реальную работу программистом. Меня тогда настолько эта работа увлекла, что уже не до универа было. Но и других примеров пруд пруди, когда большие специалисты либо не заканчивали универ, либо вообще туда не шли. То есть корреляцию ещё доказать надо.
И вообще, я вижу, что многие пытаются через проблемы нашего российского образования доказать, что идея о специальном, сродни медицинскому, программерском образовании — плохая. Вообще не вижу логики :)
Ибо тратить 5 лет на обучение там, где ученикам и учителям плевать на сам процесс обучения — пустая трата времени.
Поэтому я бы еще говорил про проблемы контроля качества обучения.
P.s. это касается РФ, как ситуация в других странах — не имею понятия.
Представьте что эти носители высшего образования пишут на более серьезных задачах.
Так что высшее образование зачастую приводит к повышенному желанию наличие этого самого высшего образование продемонстрировать. То есть не гарантия.
абстрактная фэктори для сервиса с единственным публичным методом, который вычисляет факториал используя частичную LINQ-выборку из бесконечного генератора чисел (который на yield return построен)
Это не совсем верно. Система образования у нас в основном такая, что из этой фразы выпускники большинства ВУЗов, обучающих по разным направлениям IT, знают только факториал. Ну и кто-то может помнить, что "методы — это то же самое, что функции".
И это неудивительно, если учитывать, что курс по веб-программированию в одном из довольно известных профильных ВУЗов последние лет 15 или даже больше читает 90+-летний профессор, рассказывающий про то, что сайты надо делать на CGI или PHP3 в IE6, а все более современное — фигня для домохозяек, которая никому не нужна. И это не один особый случай, так дела обстоят во многих учебных заведениях. Есть, конечно, и отличные преподаватели с отличным курсами, но это скорее исключение.
С другой стороны, многим студентам тоже нафиг не надо напрягаться, мотивации никакой. Все думают, что их учат как надо и они потом после выпуска сразу будут работать программистами, хотя их уровня знаний в IT хватит только для того, чтобы в excel графики строить и по инструкции hello world написать. А еще они методички понятного качества для будущих поколений пишут вместо преподавателей за автомат.
Так что я более чем уверен, что озвученная вами проблема — это не от переизбытка образования, а от его отсутствия. Я как раз сейчас магистратуру заканчиваю (осталось только диплом на руки получить) и это все прямо на себе ощущал 6 лет. Если бы не занимался самообразованием, то сейчас бы, видимо, думал, в какую организацию идти гамбургеры продавать на кассе. Зато отчеты писать умеем по ГОСТам и на 20 страниц размазывать то, для чего хватило бы 3-4.
на более серьезных задачах
Как раз на серьёзных задачах образование очень пригождается, нормальное образование. Когда задачи не чисто програмистские(поэффективнее переслать побольше байт из а в Б), а завязанные с предметной областью. Тут уж без ВО никуда. Технологии приходят и уходят, база — остаётся. в том числе математика, физика, биология, сайтами дело не ограничивается (тем более сайты бывают разные и бек-энд вполне может решать одну из таких задач).
Поэтому проблемы плохого кода состоят не только и не столько в механизмах использования классов, контроллеров, интерфейсов и прочего, ныне очень популярных в основном при построении пользовательских интерфейсов (как веб, так и десктоп, а также мобильных). Кстати, модель ООП должна быть не в самом языке, а в первую очередь в голове. А проблемы кроются в неумении правильно построить внутреннюю модель программы, эффективно реализовать необходимые алгоритмы самостоятельно применительно к той модели данных, которая выбрана в конкретном проекте.
Образование образованию рознь, если бы я сейчас вернулся в прошлое то не стал бы заканчивать вуз в СНГ по возможности (а она была, но я об этом не знал) лучше бы смотался по программе обмена студентов в японию/чехию/США. Но все вышло иначе — в колледже нас учили pascal и структурам данных вполоть до деревьев, интересным алгоритмам вроде апроксимации, рекомендовали хорошие книги вроде того-же "Совершенного Кода". Однако делал это одинокий старик которому не было пофиг на наши знания, 5 остальных преподователей по профильным предметам давали какую-то непереваримую дичь, В институте остались как раз эти-же преподователи. В итоге только деньги потратил впустую.
Математическая культура и опыт не решат проблемму того что код напечатан неверно или сложно обслуживать. Даже на своем основном языке а это php я видел как здравый человек с 10-и летним опытом программирования для проверки mime вместо стандартной функции из ядра языка читал первые байты из файлов и проверял их на соответствие через заранее зашитые в коде шеснадцатиричные константы. Для C++ такой подход приемлем, для php уже нет.
Другой пример — у нас есть отдел java и в него наняли одного перспективного специалста с кучей сертификатов и чемпиона кучи олимпиад по программированию. Я почувствовал себя ушербным бесполезным пхпшником
когда разговаривал с ним в курилке — человек отлично понимал как работают нейронные сети и компьютерное зрение, знал кучу формул и сам доказывал на доске пару теорем по математике на образовательном часу.
Но в итоге он был уволен, как не странно задачи бизнеса он не решал. а код который он оставил за собой до сих пор вызывает ужас у java отдела потому что он не понятен и запутан и неработает от слова "совсем". После увольнения человек угрожал разглашением приватной информации по проектам конкурентам, благо все конкуренты состоят в ассоциации и мягко говоря отправили данного человека в default gateway.
Итог — одних математических знаний мало и далеко на одной математике не уехать, в разработке сущетвует еще огромное количество факторов которое нужно учитывать при создании софта, при том что технолигии не стоят на месте и постоянно меняються. Единственное на что можно полагаться это на свой опыт и понимать что у тебя хорошо получаться а что нет, да я знаю java/c++/js но прекрасно понимаю что знаю данные технолигии недостаточно для того чтобы требовать за них достойную оплату и писать на них production-ready проекты и желания двигаться в этом направлении нет, учу python а php меня кормит.
То добавляют абсолютно лишние слои абстракции так, что от этих абстракций потом не избавишься. А еще — самый смак — если у команды есть unit-тесты. Такие, знаете, выстраданные и политые кровью и потом unit-тесты. Они, конечно, не падают когда возникают ошибки логики. Все чаще, знаете ли, тестируют на живой базе как отработал EF-ный .SaveChanges (да да, интеграционные тесты у нас часто по ошибке называют unit-тестами). И вот когда ты начинаешь архитектурный рефакторинг — тесты в лучшем случае выкидываются. Но иногда менеджменту, рьяно отстаивавшему необходимость unit-тестов в проекте «ну чтобы типа все безопасно было, чтобы при каждой сборке вот мы проверяли что система работает, TDD» — становится жалко потраченное время и бабло. И в этом случае тесты при архитектурном рефакторинге на ровном месте создают вдвое больший объем работы, чем был бы без них. Все правильно: разгреб навоз в коде — разгреби и в тестах, которые к тому моменту обычно перестают собираться.
Да да да. Я полностью поддерживаю автора — урезаешь ненужный код — остается 3,5 метода логики и пара классов.
А самое что вымораживающее — так это то, что каждый проект люди начинают «с нуля». Ну то есть с нуля определяются конвенции для разбиения системы на слои, (пере)осмысляется политика использования транзакций, используемые фреймворки подбираются по принципу «о, я слышал о такой штуковине — давайте изучим!», опять говориться о unit-тестах — ну конечно же, изобретаются велосипеды и используется все, что попалось под руку по принципу «ну мы же непрерывно учимся — вот, фреймворк новый пробуем». Зато в полном соответствии с гибкими методологиями! «У нас нет системного архитектора — у нас же SCRUM» — сколько раз я уже такое слышал…
Словом, фуфуфу такими быть.
Але, уважаемые. Довожу оперативно до вашего сведения, что для того, чтобы писались unit-тесты, система должна на эти самые unit-ы легко разделяться! А не быть монолитным куском, который за собой тянет маленькую галактику и не отрезается от БД.
Практика тут показывает что если в решении не используется в каком-либо виде инверсия контроля и разрешение зависимостей — то такой системе надо
Сложно нормально научиться постоянно с таким работая.
До боли знакомо)
Где доктора наук будут рассказывать, что обязательно нужно комментировать каждую строчку кода на русском языке, чтобы другой программист понимал, что int c = a*b — это // с равно произведению a и b.
Имхо, девочек профессоров надо менять на программистов (админов/инженеров/...) с опытом практической работы, а не курсы вводить. Практика показала, что в образовании толку гораздо больше от аспирантов и молодых преподавателей, которые параллельно с универом работают и могут полезными знаниями и навыками поделиться. Но, к сожалению, таких мало и обычно они только лабы проверяют, а учат эти лабы выполнять такие вот профессора, которые примерно в начале 2000-х окончательно потеряли связь с тем, что происходит в индустрии.
Так-то я совершенно с вами согласен, но одно только это не поможет.
Доктора решают совершенно другие задачи, другого уровня, не какой то ваш код… Сравнивать эти две профессии совсем некорректно.
Так пусть они свои задачи решают, не проблема. Пусть занимаются исследованиями, руководят аспирантами и преподают фундаментальные предметы вроде матана или алгоритмов.
Но очень грустно смотреть, как такие вот уважаемые "д.т.н., профессор", которые всю жизнь занимаются теоретическими исследованиями и ни строчки кода для бизнеса не написали, преподают программирование на всяких современных языках, ООП и прочее. В итоге их студенты кое-как могут запилить простые лабораторки, но код пишут как получится — нарушая все возможные рекомендации, которые можно найти в книгах Макконелла, Фаулера, Мартина и т.п. По рукам им дать некому. Что такое git, юнит-тесты, паттерны проектирования, SOLID и т.п. — они тоже не знают.
Я ровно о том, что все эти доктора наук должны заниматься своим делом, а в обучении будущих программистов/админов должны быть задействованы те, кто занимается этим на практике и знает, какие навыки нужны сейчас, а не 20 лет назад. Но таких обычно 2-3 человека на 20 преподавателей на кафедре, и они обычно зайдействованы не в обучении, а в выдаче и проверке лабораторных.
Математики и программисты имеют общие темы, но, это достаточно разные профессии и учатся на них по разному.
Технологии технологиями, а главное — код
Звучит, как «не важно какое блюдо готовить, главное правильно мыть картошку».
Как это технологии могут быть не в приоритете я не понимаю. Зачем нам тонны правильного, качественного кода, если это не содержит новых технологий? Хоть запишись правильным кодом! Но в этом не будет никакого смысла, если это не будет полезно.
Проблемы сложной поддержки кода решаются созданием нового ПО и покупкой нового оборудования с выделением денежных средств на это. Рефакторинг хорош, только в редких случаях или когда надо переписать что-то относительно не большое.
Я думаю вы пытаетесь решить проблемы политико-экономического характера, правильным написанием кода. Боретесь со следствиями следствий следствий. И из-за этого длинного логического пути не понимаете этого. Не можете осознать настоящей проблемы.
И я не говорил что технологии это плохо, просто им своё место.
Звучит, как «не важно какое блюдо готовить,
Вам поесть или разобраться в готовке???
Результат имеет значение. Я не говорю про совсем начинающих кодеров. Просто если у человека есть идеи, то надо их воплощать и не важно какими паттернами и архитектурами. Главное результат! Пусть программа будет написана хоть на HTMLе главное — она должна приносить пользу и иметь смысл.
Красота кода имеет значение, лишь в больших корпоративных проектах. Когда одну программу разрабатывает сразу толпа разработчиков. И им надо иметь какой-то один стандарт… и то не факт, что самый современный. В остальных случаях приоритет должен быть в технологиях, а не качестве кода. Кроме этого качество кода слабо влияет на количество глюков в проекте.
Так что плюсов особо никаких, зато убиваем массу времени на изучение… и теряем время на создание результата — технологий.
Кроме этого качество кода слабо влияет на количество глюков в проекте.
Оно влияет и на количество багов, и, самое важное, на быстроту их выявления и исправления.
Исправленная версия, для тех кто слабо понимает о чём я пишу:
«Вы правда считаете, что лучше повар, который готовит безупречно, но просто картошку, чем повар, который готовит хорошо, но картошку с мясом?»
Угли — готовят начинающие разработчики, которые учатся основам основ.
И некоторые технологии, даже в виде углей лучше (т.е. написанные совсем не качественным кодом) чем обычные, но безупречные технологии.
Оно влияет и на количество багов, и, самое важное, на быстроту их выявления и исправления.
нет. Количество багов зависит от логической продуманности приложения, а не архитектуры и способа написания. ООП на не больших проектах не даёт существенных преимуществ в продумывании этой логики. Только на больших.
А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
А что вы вообще понимаете под технологиями?
Нет. Это не то что вы подумали. Под технологиями я имею ввиду — цель проекта. Например, человек придумал что-то новое в медицине (новую технологию) и пытается написать программу для этого.
Написал, работает. Люди выздоравливают и говорят спасибо. Но написал криво… без использования моделей в разных местах, с использованием не правильных паттернов. Мог бы библиотеки заюзать… было бы меньше багов, но люди выздоравливают… и технология работает…
А программист, о котором в статье — будет писать всё верно, качественно… со всеми современными средствами… но будет писать долго… и бросит на пол пути… так ни один человек и не вылечится… Зато он изучил много паттернов и использовал много библиотек! Он крут))), только он не сделал ничего.
А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
Нет. Хорошо написанный код — проще! Именно так. Все эти толстые контроллеры, которые не кидают эксепшены когда надо, в них ошибку найти крайне сложно. Мне есть с чем сравнивать. Искал ошибки и там и там.
Количество багов зависит от логической продуманности приложения, а не архитектуры и способа написания.
"Логическая продуманность приложения" вообще-то примерно то же самое, что и архитектура, не находите?
А скорость выявления багов вообще только замедляется с увеличением качества кода. Ведь, чем кода меньше, тем он сложней! И находить ошибки в коде, который сложнее написан — «сложнее».
Ну если оценивать качество по количеству логики на число строк, то да. Но только качество оценивают не по этому критерию. Увеличение качества — это когда код становится понятнее. Это не обязательно ведет к уменьшению размера, кстати.
но люди выздоравливают… и технология работает…
Пока не убъет кого-нибудь из-за бага, закравшегося в адовую простыню кода.
А что вы вообще понимаете под технологиями? Использование самого модного сегодня фреймворка? Как это влияет на результат? Продукт должен соответствовать требованиям заказчика. Какое качественное влияние оказывают на результат технологии? С кодом как-то понятнее, коряво напишешь — будут неочевидные баги и каждую мелкую проблему исправлять придется по 2 дня. А что изменится от того, что вместо современной технологии X я использую прошлогоднюю технологию Y?
В остальных случаях приоритет должен быть в технологиях, а не качестве кода.
Приоритет должен быть на соответствии требованиям. Накой все эти технологии, если код неподдерживаемый и любое изменение ломает пол-системы? Мы не технологии создаем, а продукты для бизнеса. Создание технологий — узкая ниша, в которой сидят компании вроде MS, Google, JetBrains и т.п. И то над созданием технологий там скорее всего трудятся небольшие группы экспертов, а подавляющее большинство программистов делает продукты.
Я пойду… он сразу после VueJS будет :-)
Потому что писать код и потом после прочтения аннотейтов тиммейтом отхватить по шапке — одно, а чувство, когда тебя буду ревьювать (тут параллель со словом «собеседовать») — другое.
Можно считать такой шаг «хот-фиксом» ситуации, хотя в основном вы правы, начинать учиться надо было раньше, до начала программирования
Тут есть свои сложности, я как тот самый человек которы смотрит чужой код говорю.
Держать одного спеца только для ревью, который еще и много кушать просит не каждая компания потянет.
Если же пускать такого человека в работу (как в моем случае) у него не хватит времени делать полноценное ревью и стучать по шапке новичкам. В итоге ревью иногда делается постфактум (особенно при горящих сроках) за одно и с рефакторингом и раздачей моральных звездюлей накосячившим месяц а то и год назад.
Помимо этого опытный человек скорее всего имеет высокую квалификацию всего в 1-2 языках/платформах что вынуждает собирать комманду ревьюверов. Да я могу разобрать почти любой php код и указать на его проблемы, но при этом в javascript я не в зуб ногой — что-то простое еще могу написать или проверить, но ES 6 транспайлеры и ваши модные SPA штучки я просто не успеваю изучть и от меня этого даже не требуют.
В компании где я работаю помимо js есть еще и python и java6 в которых я умею только hello world. Плюс один человек для postgres/mysql и уже требуеться 5 человек которые имеют опыт (их еще найти и нанять надо, а опытный целовек по оплате его труда болько кусается) и которые не будут писать код, а только контролировать его качество и стабильность. Если вы не Google Yandex или какойнибудь Банк, тогда вы просто не сможете позволить себе таких людей.
В итоге имеем что имеем, есть пара-тройка опытных в одной технологии людей которые в одиночку лепят очень важные и критичные вещи, от которых у среднечков кипят мозги, группа middle которые одинаково плохо работают в нескольких технологиях и терпимо в одной — их выполняют текучку и пара студентов которые на подхвате. В итоге критичные вещи проверены и перепроверены а не критичные сделаны абы как и туда даже лезть никто не хочет.
Технологии технологиями, а главное — код