TECH · 29 августа 2017, 18:02 · Отдел информации dev.by
Разработчик: «чистый код» должен выглядеть неопрятно

Full-stack разработчик Стивен Дегути раскритиковал общепринятый подход к идее «чистого кода» в своём блоге. dev.by перевёл наиболее интересные фрагменты его рассуждений.

Фото: TheTechNews

Чистый код — это незаконченный код

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

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

«Чистый» не значит «идеальный»

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

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

Фото: The Cheat Sheet

Чистый код может выглядеть неопрятно

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

Автоматические тесты не так важны

В целом они важны, но для всего нужно подходящее время и место. Для некоторых проектов лучшим вариантом будет вручную протестировать скрипт или приложение. Основанная на тестах разработка полезна. Кроме этого, 20, 50 или 300 тестов, результаты которых отображаются зелёным цветом, дают важное чувство удовлетворения в конце рабочего дня.

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

Даже эксперты сталкиваются с трудностями

Наблюдая за тем, как признанные профессионалы борются со сложными задачами, Дегути перестал беспокоиться об идеальности собственного кода. Если нет очевидных проблем, все тесты (ручные или автоматические) выполняются без ошибок, то с кодом всё в порядке.

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

Источник: dev.by
Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
Вакансии
Новые комментарии

Обсуждение

Missing-male
+3

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

Missing
+2

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

Missing
+2

SE не про какое-то там ООП, оно про здарвый смысл, про то как выстраивать взаимодействующие абстракции, строить системы, про то какие могут быть трейдофы. Про взаимодействие подсистем, про то как справляться с нагрузкой и про самое главное надежность и предсказуемость. В данной же статье чувак очень сильно задел вот этой фразой: "Если нет очевидных проблем, все тесты (ручные или автоматические) выполняются без ошибок, то с кодом всё в порядке." Ну опупительно теперь, давай полагаться на чувства. Тесты проходят, збс, раскатываем. Нахрен вообще все формальные методики, давайте просто херачить и гребсти бабло, бизнес велью есть - ну значит хорошая система. Надежность, предсказуемость, устойчивость к ошибкам - вот это всё не будет работать на чувствах. Хотя кому я это говорю, 23 летним синьер ангулар девелоперам, которые может к 40 и станут инженерами. Ах да в реалиях белайти и галер ни к чему такие разговоры. Тут другая идеалогия: как же так ты уже 10 лет инженер и не хочешь быть менеджером, ну значит что-то не так с твоим миропониманием. Я лично устал от инфантильных сеньеров на гироскутерах, которые и программировать не умеют.

Missing
+2

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

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

Missing
+1

Ну у меня просто бомбануло. У вас была похоже другая крайность. Такое чувство что вы столкнулись с Ivory architects. Вы работали в банке или в телекомах? Там действительно крайняя противоположность, чуваки которые, называют себя архитекторами, не лезут в код и городят хер пойми что на диаграммах и UML и на практиках из девяностых. Там действительно не борются со сложностью, там её создают. А любую проблему заваливают оверинженирингом и кодерами. И действительно у них получаются мозгодробительные дженериковые и крайне хрупкие конструкции.

Missing
+3

Я не работал в компаниях с описанным вами подходом, и в банках конкретно. Но данная проблема которая простым языком описывается - over engineering, существовала практически в любой компании где я работал и особенно если разработка велась на ОО языке или другом языке с богатыми возможностями для созданиям собственных типов. Разработчики тратили кучу времени я продумывание бессмысленных абстракций.

Missing
+1

А в каких конторах остались еще "проектировщики", которые не открывают код? Везде уже полный аджайл и нет уже устрашающих жестких иерархий. И никто уже себя не называет "проектировщик" и "старший инженер". А так да тут везде трейдофы и нужно наиболее адекватное решение под ситуацию.

B22cf3b2327970a0352447b567a4841a?1531959657
+1

>> Я лично устал от инфантильных сеньеров на гироскутерах, которые и программировать не умеют

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

Missing-male

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

Я не про то, что он неправ, а про то, что такие откровения это нормально в 20 лет, а потом надо переставать заниматься ерундой. Про все это написано умными людьми полвека назад, что надо не спасать мир, а подумать головой, написать требования (не по стандарту DO-178A, а просто на бумажке написать, что мы делаем, для кого и зачем), и в свете этих требований проектировать и писать проект. No magic.

Missing
+1

Как по мне о пишет о зацикленности на практиках "чистого кода" описанных во многих книгах.

Как по мне в начале - "В постоянной погоне за идеальным кодом, защищённым от всех вероятных проблем, большинство разработчиков приходит к «перепрограммированию»..." и далее о тексту об этом и пишется. Людей которые пишут код не пытаются нагромоздить кучу абстракций и стремятся к простоте намного меньше тем любителей перемудрить.

Хотя понятно что некоторые практики чистого кода хороши - например понятные имея переменных и методов ("самодокументированность кода") но даже с ними можно впасть в крайности и писать километровые названия которые ничего не дают. Как мо мне статья о разумном подходе и мотивирует не зацикливаться или другими словами не впадать в крайности.

Ddae2167deeb3ae25982e4bba8b81456?1531959825
+1

А можно я распечатаю Ваше сообщение на принтере, сверну в трубочку и буду бить по лицу " 20 летних инфантильных сеньеров на гироскутерах" ?

B22cf3b2327970a0352447b567a4841a?1531959657

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

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

F66e33f1b11b0312e10c2ed1a9e39188?1531959774
Sergey Bodrov
– инженер-программист в Новатех

+1

Обычный принцип "слабого звена" имени Голдратта. Алгоритм такой:

1. Находим самое слабое звено в цепочке разработки (или в самой программе) - это может быть и методика, и код, и железо, и человек.

2. Исправляем слабое звено или оптимизируем остальное под него.

3. goto 1.

Главная проблема - это правильно определить это самое слабое звено в цепочке. Многие не могут даже саму цепочку определить.

Missing

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

Missing
+1

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

Picture_8925?1356410063

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

Picture_8925?1356410063

Если кто читал классиков, уже в 1980-х они описывали процесс рекурсивного создания ПО. Вот как это примерно выглядит, с продолжением в наше время. Сначала вбиваем команды ЦП цифрами с консоли, делаем интерпретатор символьных команд. На них пишем что-то типа Бэйсика. На нём пишем DOS. В нём пишем компилятор Си. Далее из него делаем Си++. Время написать UNIX/Windows. Пора написать базы данных и серверы. Придумываем Интернет. А теперь подключаем ИИ и озадачиваем его идеями и текущими проблемами. Идем пить пиво, так как самому уже ничего писать не надо. :)

F66e33f1b11b0312e10c2ed1a9e39188?1531959774
Sergey Bodrov
– инженер-программист в Новатех

Такое уже не раз проходили во всех отраслях. И всегда есть деление на пользователей (которые умеют только использовать готовую технологию, но не умеют ее воссоздавать и развивать) и разработчиков. Порог вхождения в разработчики на порядок выше, чем в пользователи. И если современных кодеров/дизайнеров заменят роботами, то разработчиков этих роботов заменить будет некому. Если разработчики не будут постоянно поддерживать и развивать технологию, то она деградирует и все начнется по-новой.

Missing-male

Не побоялся сказать правду. Де-факто так и есть. Тесты впереди кода - полный бред.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси