Как стать автором
Обновить

Почему бухгалтеров мы можем обучать, а программистов — нет

Время на прочтение 11 мин
Количество просмотров 21K
Всего голосов 32: ↑27 и ↓5 +22
Комментарии 36

Комментарии 36

Хороший код, что это?

Вопрос можно расширить до "Хорошее <что-нибудь>, что это?" Понятие хорошести не подлежит точной оценке и субъективно.

Слишком большой акцент на "написании кода". Основная работа в том, чтобы вникать в задачу и решать её.

Решить задачу можно и плохим кодом. По вашему, этого достаточно?
Вникать в задачу — это не всегда достаточно, но как минимум, необходимо.
Если задача полностью решена (а в неё обычно входит то, что называют «хорошим кодом», либо без него решение невозможно), то да.
можно и плохим кодом

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

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


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


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

Это очень сильное утрирование ситуации — мы не можем просто взять — и решить бизнес-задачу. Бизнес-процессы в основном своём просты (не считая тех, что касаются инфобеза; но эта область полна готовыми фреймворками и традиций вплоть до социальных, которые работают достаточно хорошо почти всегда) — возьми некоторый факт от одного субъекта и поделись этим фактом с другим (или тем же) субъектом через пространство-время. То есть, может потребоваться передать его по сети, а может потребуется сохранить его в течении некоторого времени. Или комбинация. Также, часто требуется различная мета-информация (кто оставил факт, с кем факт был разделён, когда и всё подобная чехарда), которые по сути своей сопутствующие факты. Поэтому у нас есть СУБД, есть распределённые СУБД, есть СУБД реляционные, а есть остальные, которых тоже куча разных — от простейших key-value, до серьёзных распределённных решений с системами запросов, фильтров и защит от дурака.


Я к тому, что одним абзацем можно описать 99% задач бизнеса. Только вот бизнес не статичен, он постоянно меняется — вместе с ним меняются и требования. Если раньше можно было только мечтать о том, что на одном мониторе можно будет увидеть практически всю команду из ста человек в разных концах света почти в реальном времени, то сейчас это не просто реальность — были созданы системы, которые достаточно эффективно решают такие задачи. Но это крайне сложная задача, для решения в "одно жало" — ведь теперь факт — это мимолётное понятие, нам необходимо организовать поток фактов, которые распределены в пространстве времени, а сами они перестали быть несколькими десятками байтов, теперь это изображения, качество которых неумолимо растёт. Нам потребуются качественные кодеки, которые хорошо работают с постоянными фреймдропами не сваливаясь в мыло, кашу и артефакты, но при этом максимально эффективно устраняют энтропию, обладая при этом минимальным лагом (буфером). При этом работать это должно почти механически, иначе не хватит производительности CPU общего назначения — нужен ASIC. Это пример, когда названный запрос заставил договориться абсолютно разных людей — учёных всего мира, которые математически опишут алгоритм, позволяющий оптимально кодировать такой набор фактов, завод в Тайване, производящие кристаллы и британских инженеров, проектирующие эти самые кристалы, китайцев, упаковывающие эти кристаллы в красивые упаковочки, инженеров, которые напишут драйвера для этих самых ASIC, индийцев, которые нарисуют формочки для этих самых драйверов и это ещё лишь верхушка айсберга.


Ведь по факту, все требования, все SOLID, новомодные agile и древнейшие V-Model с водопадами, все эти ваши git-flow, git-ops и паттерны проектирования, О-нотации и merge/quick-сортировки, SQL и часовые пояса, UTF-8, DevOps, DevRel и прочие Dev*, SRE, ssh, http, gpg, attlassian/gitlab/kanban — всё это и многое, многое другое лишь для одного. Это способ договориться.


Но пока вас меньше некоторого k можно договориться хоть языком жестов.

Но пока вас меньше некоторого k можно договориться хоть языком жестов.

Вы так много написали, но наверное не поняли о чем я. Фейл проекта зависит не только от количества вовлеченных участников — можно сфейлить и в одного и в тысячу. Я о том, что не нужно возводить в «карго культ» все эти техники — серебряной пули увы нет. А вот некоторая доля скепсиса и критики никогда не помешает)

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


Насчёт серебрянных пуль — конечно, их нет. Зато есть такие вещи, как best/good practice, которые себя зарекомендовали как рабочии. Причём их количество достаточно велико, чтобы подобрать идеальную под каждый конкретный случай.


Сам по себе подход "пиши код, блджад!" ни разу не плох, хотя и до хорошего ему как до луны. Он работает, весьма хорошо работает на коротких дистанциях, но в какой-то момент поддерживать принятые ранее решении станет слишком дорого. Вот всё.


Но и гнаться за безупречным кодом далеко не всегда хорошая идея, так можно никогда не выпустить продукт. Поэтому "спорные" решения принимать придётся. Для этого есть отдельные фреймворки поведения и управления, они каким-то образом регламентируют принятия решения. Многие из них не только напрямую влияют на характер принимаемых решений, определяя баланс качество/стоимость и лиц, обладающих определёнными правами в этой области, но также позволяют максимально распространить информацию о всех рисках, чтобы принимаемое решение было максимально объективным. К тому же, в процессе распространения информации могут появится решения, находящиеся в совершенно другой плоскости, что так же может оказаться значительно полезнее, чем любое другое решение "в лоб".


Тот факт, что серебрянной пули нет ни разу не означает, что ничего нельзя сделать.

Если не вникнуть в задачу, то можно потратить время на написание ненужного кода.
Какой код хуже: плохой или ненужный?

Слишком большой акцент на "написании кода". Основная работа в том, чтобы вникать в задачу и решать её.

Решение задачи включает написание кода в виде необходимого элемента.


Тут просто есть некоторый парадокс — всем очевидно, что нельзя прочитать статью в интернетах и пожать сотку от груди. Чтобы пожать сотку от груди — надо регулярно ходить в зал. Или — нельзя прочитать мануал "как играть на гитаре" и начать фигачить соляки из dream theater — надо долго и упорно тренироваться.
Это в точности так же работает и в случае ментальных навыков — любых. Мозг адаптируется к нагрузкам, как и остальное тело (только медленнее). Но люди этого не понимают, им кажется, что "статьи достаточно". В итоге мы и получаем человека уровня "читал самоучитель", который думает что может играть (где-то там, в своих фантазиях) — но при этом не в состоянии даже струну нормально зажать, если дать ему реальную гитару.

Естественно что бы решить задачу, надо вникнуть в нее, но и немаловажная часть само решение. Если вы не знаете теорию, то вы не посчитаете площадь круга, хотя вам и ясно, что требуется. Ну и площадь круга можно посчитать интегрированием, а можно просто радиус возвести в квадрат и умножить на пи, надеюсь правильно :). Уверен найдется больше людей которые знают второй способ, чем тех, кто сможет проинтегрировать. А те кто не втеме будут чертить на бумажке окружности циркулем, вписывать квадраты или еще, каким то способом извращаться.

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

Причем возведение радиуса в квадрат это скорее антипаттерн, так как работает только для одного специфического случая, и если потом у вас окажется, что нужно не только круг, но и квадрат посчитать, и ещё неведомо какие фигуры, все равно придётся все переделывать на интегрирование.
По мне, так наоборот, это интегрирование — антипаттерн.

Сначала пишешь своё интегрирование, чтобы работало на любых теоретически возможных фигурах, хотя нужно только площадь круга находить. Радуешься, что соломки себе подстелил в случае изменения бизнес-требований. А после релиза оказывается, что какая еще площадь, на самом деле надо периметр вычислять. И сидишь ты с этим интегрированием, на которое убил пару месяцев, и думаешь — на кой черт я звездолёт проектировал, когда с тем же успехом можно было сделать тележку? Что так что так — на выброс.
НЛО прилетело и опубликовало эту надпись здесь

Достаточно давно пришёл к подобным взглядам, как у Григория. И по части важности автоматизмов в роли мышления и системе подкрепления-повторения. Бухгалтеров обучать "умеют", потому что профессия жестко стандартизована и столетиями не менялась, а был бы у них каждый год новый react/vue и взрывной рост числа требуемых специалистов, когда за полтора десятилетия толпы просто рванули вайти за длинным рублём. Так что в итоге Григорий пришёл к очевидному — мета-лёрнингу и нейрофизиологии, вполне вероятно, что через 30 лет эти же штуки будут применять к какой-нибудь другой профессии.

НЛО прилетело и опубликовало эту надпись здесь
Дизайн систем же. И там, и там.

Может и есть программирование без дизайна систем (то, что называют «хреначить тикеты»?), но я таким не занимаюсь, и не видел.
НЛО прилетело и опубликовало эту надпись здесь
Законотворчество и программирование, забыл уточнить.
Согласно современным гипотезам, если исключить болезни, с возрастом ломается не способность к обучению, а система подкрепления.
Согласно моей гипотезе, у многих людей с возрастом в голове образуется конструкция, примерно как на картинке справа , и если в неё добавлять новое с той же скоростью, то она рухнет. И так же, как и с кодом, правильный выход — рефакторинг.

А происходит это потому, что доминирующая парадигма обучения — тупое запоминание долблением, без понимания, что и предлагает Григорий.

Не знаю, у кого как, а важные и/или интересные, с моей собствественной точки зрения, вещи, я запоминаю с одного раза. Неважные — сколько не долби, забываю обязательно. Более того, если мне рассказывают неинтересное — через 15 минут у меня начинает кружиться голова, и я вообще перестаю воспринимать сказанное. Читал немало свидетельств подобного у других людей, приблизительно 10-15 минут ерунды, и начинается головокружение, тошнота, боль в голове и т.д. Пример.

Запомнить как бить теннисной ракеткой по мячу — 5 минут. Научиться это делать — 3 года. В программировании также.

НЛО прилетело и опубликовало эту надпись здесь
Статья написана хорошо, я бы написал хуже. Читается легко, узнаешь новое.

Кажется, мы делаем всё, чтобы писать хороший код: читаем книги, слушаем подкасты, ходим на конференции и изучаем лучшие практики. Почему же результат оставляет желать лучшего?


Ответ чуть ниже прямо в той же статье:

Конечно, есть разработчики, которые относятся к коду как к искусству, но в основном он нужен бизнесу, чтобы решать бизнес-задачи и позволять людям взаимодействовать друг с другом и с информацией


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

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


Ну и, если экстраполировать в будущее, то:

Пятнадцать лет назад обучали ООП, а сейчас Rust и Go считают наследование антипаттерном.


Вангую, что еще через 15 лет мы перестанем…

… говорить джуну: «Тебе надо давать читаемые имена идентификаторам»


… и муштровать его интервальными повторегиями, а вместо этого будем все-таки знакомить его с моделями мышления, подходящими для широкого спектра решаемых проблем: унификацией, зависимыми типами, замыканиями, рекурсией в конце концов.

За ссылки с «свежий взгляд» на онбординг — спасибо.

Внезапно осознал близость проблем обучения программистов и бухгалтеров: постоянно сменяются фреймворки, а то и языки / постоянно меняется отчётность, а то и законодательство.


Получается, для тех и для других есть два слоя обучения: фундаментальный (освоение основных концепций и выработка стиля мышления) и сиюминутный (освоить очередной язык и т.п.)

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

И вот тут и проблема. В бухгалтерии методика записи зачастую едина в стране, в мире.

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

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


И здесь вина не программиста (не, есть необучаемые, не отрицаю). Программист в разработке продукта — инструмент. Даже очень качественное сверло можно запороть неправильным использованием.

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


Как быть?

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


Ну ничего не поделаешь, это зависимые параметры, они в одной формуле стоят.

Чтобы написать хороший код — нужно хотеть этого. Больше практики, стремиться к саморазвитию, к изучению нового и критического переосмысления старого. Если разработчик пишет в стиле «и так сойдет!», то сколько его не учи, он даже с 10 годами опыта будет лепить костыли из говна и палок.

Есть зависимость от предметной области. Если разработка идет в недоисследованной предметной области (незнакомой программисту или вообще компании вместе с заказчиком), то какой бы качественный код ни был, архитектура может не позволить ему быстро адаптироваться под изменяющиеся условия. При наличии фактора ограниченного времени костыли неизбежны.
Я считаю, что идеальным может быть только Pet-Project. Остальное только приближается к нему.

Книга Выразительный JavaScript. Современное веб-программирование (Марейн Хавербеке) для программирования в общем, не только на JS.


Пожалуйста, не читайте в русском переводе, там проблемы с переводом (во 2м издании точно, в третьем может уже исправлено). По крайней мере, «переменная» там называется «привязкой» (что сбивает с толку, так как привязками называют «bindings»). Возьмите лучше бессмертного Фленагана

Подписываюсь под каждым словом

МИР един
Мозг («М») и разум («Р») должны быть описаныединой теорией, центральный вопрос которой -природа «И» -соотношение «М» и «Р


Открыл презентацию К.В.Антохина — и если честно такие слайды, с явно посконным маркетингом, вызывают сильную настороженность.
Не могу сформулировать почему — но мой мозг подсознательно (т.е. как обученная но не говорящая почему нейросетка) говорит, что именно в такой маркетинг обычно заворачивают самые бесполезные теории.
Именно НАУЧНАЯ работа по когнитому может быть найдена в журнале высшей нервной деятельности, 2021, том 71, No 1, с. 39–71. Но предупреждаю на берегу, что тексты в научных журналах и на пабмеде сильно отличаются от популярных лекций. Скидок там нет, термины не расшифровываются, и если читатель знаком только с бытовым значением какого-нибудь слова, то шансов понять о чем речь немного. Зато в них все максимально по делу)
Просто для информации. Книги на сайтах издательств почти всегда дешевле (кроме периодов акций у площадок-посредников).
Например тот же упомянутый Выразительный JavaScript на литресе 699р за электронку, против 550р от издательства.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий