Я тут очень много думал ))) читал, в основном разные университетские курсы и конференции по computer science — как же продуктивнее всего научить(ся) писать ясный код без ошибок, и качественно

Я тут очень много думал ))) читал, в основном разные университетские курсы и конференции по computer science — как же продуктивнее всего научить(ся) писать ясный код без ошибок, и качественно проектировать систему, строить аккуратные и чистые архитектуры? Вроде бы очевидные и абсолютно нужные всем темки, и материалов по ним должно быть множество, ведь так? НО! Их практически ноль!

…Конечно, самый мощный метод – через математику и формальную логику: fp, cs/tcs, toc, mltt, hott… Но даже самая короткая тропинка тут — это годы занятий, и то если повезёт, что будет возможность учиться в фоновом режиме, найдётся внятный курс, хороший ментор…

Проблема, что в другой крайности — в программной инженерии, в чисто инженерных мэйнстримовских подходах, царит хаос, бессистемность и попса. Да и в целом, по темам даже прозаического code design, code quality, programming in small (про clean architectures я вообще молчу…) на уровне джуниора-миддла, относительно хороших инженерных книг (которые, невзирая на критику, изучить обязательно надо) — ну буквально может десяток, и все их вы наверняка знаете:

— "Совершенный код" Стив Макконнелл

— "Чистый код" Дядюшки Мартина, ну и другие его книжки ("Идеальный программист", "Чистая архитектура"…)

— "Прагматичный программист" Ханта и Томаса

— "Паттерны проектирования" от GoF и (лучше) от Фрименов

— "Тестирование программного обеспечения" Канера

— “Архитектура корпоративных программных приложений” + "Рефакторинг: улучшение существующего кода" Фаулера (про Мартина см ниже!)

— "Эффективная работа с унаследованным кодом" Физерса

— "Рефакторинг с использованием шаблонов" Кериевски

— "Страсть к программированию" https://habr.com/ru/post/206198/

Про вечный десяток книг с наилучшим КПД для опытных программистов я рассказывал тут:

https://vk.com/wall-152484379_2952

= = =

Я регулярно отслеживаю по теме code design все выходящие книги (ноль в 2020-м) и статьи на конференциях и в блогах (ну может десяток от силы наскрёб),в которых были бы научные исследования, которые можно взять и после небольшого допиливания и обучения сразу применить в своей программистской работе.

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

Думаю, что причина прозаична: действительно, гораздо проще написать статью о том, как запрограммировать АI для Доты в виде контейнерного микросервиса на Java, чем грамотно объяснить разработчикам,

а) как писать хороший код и

б) как правильно проектировать программу и

в) как это делать на основе хороших математических формализмов, чтобы код получался ясным и безошибочным.

Ну и, главное, что гораздо проще и гораздо выгоднее :) , клепать курсы «как быстро запилить свою мобильную игру на Godot» и «стань Java-программистом за 90 дней с гарантией трудоустройства», нежели учить, как правильно писать хороший код. С игрой и джавкой есть объективный результат, а вроде как тут не пойми что результатом получается.

Точнее, важность good code design, я уверен, понимает любой программист, постоянно мучающийся с запутанностью кода и бесконечными багами. Проблема, что этого не хотят понимать его начальники в том плане, что их вполне устраивает, что если человек предсказуемо гонит 10-20 строк кривого кода в час с разумным уровнем багов, ну и хорошо. Пусть так и сидит годами на своей тысяче евро в месяц :)

80-90% ребят, которые приходят ко мне на курсы не с полного нуля (в том числе и студенты, и кто уже работает после университетов), делают элементарные ошибки в стиле кода (потенциальные баги фактически), избеганию которых я настойчиво учу на курсе с нуля с первых же занятий. Кто только научился у меня программировать, таких детских ошибок стиля не допускают, как те, кто уже давно работает!

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

Так что это очень типичная ситуация.

= = =

В результате на таком пустынным поле и возникают разные мартины фаулеры, в книгах и курсах которых крупицы полезного намешаны с какими-то невообразимыми абстракциями, никогда не проверявшимися в серьёзных проектах. Но, зато продаются эти темы очень хорошо ))) Фаулер в своей нише фактически вообще один! Конечно, он какие-то сильные идеи постепенно прихватывает, так как годами варится в этой области, и корешится с некоторыми авторитетами, и конечно, я рекомендую его книги поизучать.

Попытаюсь объяснить на пальцах, в чём недостаток книг вроде всяких «Рефакторингов».

Например есть код

function foo(n) :

if n=0 then return 100 else

if n=1 then return 200

(что нету отдельного итогового return, сейчас не важно)

Вообще, if программисты интуитивно не любят, особенно вложенные, есть даже такое движение «программируй без if».

И вот вас учат, что рефакторинг – это сделать массив

a = [100, 200]

и затем

return a[n]

Но это никакое не удаление IF !!! Ну, с научной точки зрения :)

Правильное мышление, правильный code design — когда программист понимает, что никакой это не рефакторинг, потому что оба этих кода эквивалентны не только семантически, но и структурно!

Мы по сути вообще НЕ изменили этот код!

(есть тут большая теоретическая область — эквивалентные преобразования программ, где ещё в 1960-х гениальный Турчин написал свой Рефал, в чём-то непревзойдённый и по сей день)

= = =

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

Значения 100 и 200, индексы 0 и 1 обязательно несут в себе какой-то конкретный смысл в вашей программе!

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

Умение мыслить на уровне смысла вашего кода – это и есть ключ к хорошему code desing/quality!

Сейчас также в средах разработки предлагаются десятки метрик кода, которые оценивают его «хорошесть», и конечно снижать ту же запутанность, связанность всегда полезно. Однако косвенный эффект метрик в том, что программисты начинают механически подгонять свой код под них, и результат может получиться ещё хуже, потому что рефакторить, развивать, улучшать свой код надо на более высоком абстрактном уровне — на уровне его логического понимания!

Сермяга в том, что это логическое понимание напрямую, «физически» в коде воплотить невозможно. А как это делать правильно, этой весной я вас буду учить :)

= = =

На тему хорошего кода написано, как я говорил, немного — десятки книг, может сотни статей, но везде предлагается чисто инженерный подход, набор best practices, которые были нащупаны интуитивно.

Вдобавок везде, особенно в programming in large, предлагаются «оригинальные» конкретные методики или подходы, которым надо специально довольно долго обучаться (тот же набор паттернов проектирования например), но почему они именно такие? Довольно часто они — просто неформальное представление достаточно глубоких формальных описаний, случайное открытие их кусочков вслепую.

Короче говоря, я думаю о том, как научить(ся) good code design/quality,

programming in small/in large так, чтобы не надо было привязываться к конкретным методикам и долго их изучать.

Чтобы это был Jeet Kune-Do – стиль, свободный от стилей, по Брюсу Ли.

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

Чтобы, пройдя 10-часовое обучение, получить результат в плане понимания good code design на 80% такой, какой другие получают, тратя 10 лет на theoretical computer science.

(продолжение следует :)

Источник: vk.com

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