Пользователь
0,0
рейтинг
23 ноября 2012 в 19:27

Разработка → Грязный, чистый, устремлённый

Грязный


Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?


Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

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

Эта аналогия не вполне корректна (как и большинство аналогий), но примерно передаёт ощущения, возникающие при работе с кодом. Неважно – чужим ли, своим ли, написанном пару месяцев назад и уже прочно забытым. Код либо нравится, либо нет. Он либо красив, чист и приятен – либо волосат, уродлив и дурно пахнет.

И, конечно же, у каждого есть свои критерии «красоты кода». Свой, так сказать, вкус.

Но, тем не менее, есть какие-то общие точки, о которых если и спорят, то вяло и соглашательски. Не о сути, а об обрамлении.
Давайте попробуем их перечислить.

Легко читается и понимается Запутан, неочевиден, трудно понимаем
Легко поддаётся изменениям Закостенел в своих внутренних связях; изменить что-либо стоит неимоверных усилий и жертв
Может быть расширен, либо встроен куда-нибудь в виде отдельного модуля Для расширения требует переписывания, для встраивания – обёрток
Поддаётся автоматизированному тестированию Может быть протестирован, лишь как «чёрный ящик»

Конечно, можно начать спор о «читабельности» или «понимабельности» кода. Это совсем не формализованные термины.

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

А желательно – основательно поковырять ООП и стараться инкапсулировать логику в отдельных классах, чтобы не приходилось напрягать головной мозг ни разбором огромных «портянок» кода на десятки экранов, ни запутанными связями процедур и функций, которые к тому же (omg) оперируют кучей глобальных переменных.

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

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

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

Чистый


Теперь давайте всё-таки попробуем разобраться – зачем же он вообще нужен, этот чистый код? И так ли уж плох код грязный и волосатый?

Ну, для начала нужно сказать: it depends.
Бывают моменты, когда написать «быстро и грязно» куда важнее, чем «долго и чисто». Хотя нужно отметить, что «грязно» далеко не всегда означает «быстро». Бывает, что ровно наоборот.


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

Например

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

Такую задачу вполне можно написать как угодно грязно – лишь бы утилька работала, а написание не заняло много времени. Ведь мы решаем здесь одну сиюминутную задачу.
Решить же задачу долговременную куда как лучше, изменив систему регистрации ошибок (писать те же численные данные в базу, например).

То есть утилиту эту в идеале используют один-два раза, после чего выкинут. Чистота кода здесь совершенно не важна.

Другой пример

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

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

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

Это ненамного замедлит разработку утилиты «здесь и сейчас» — зато, когда вновь встанет вопрос о воспроизведении последовательности запросов на сервер – утилита будет тут как тут и потребует минимального допиливания; а главное – минимального времени на вспоминание, что там к чему.

Третий пример

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

Казалось бы – модуль изолирован, интерфейсы взаимодействия с другими модулями определены. «Кручу-верчу, говнокод писать хочу». Но тут возникает серьёзное «НО».

Что будет с этим модулем через полгода? Год? Потребует ли он поддержки? Изменения? Расширения функционала? Возможно, в итоге разовьётся в отдельный продукт?
Если хотя бы на один вопрос можно дать хотя бы ответ «вероятно» — то говнокодить, увы и ах, строго не рекомендуется.

Но это не весь список вопросов. А кто будет работать с этим модулем через два-три года? Тот, кто его писал, или кто-то другой?

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

Если же работать с этим кодом будет сам разработчик – то тем более. Да он через полгода уже не будет помнить: что, где и как работает! Ему придётся разбираться в этом коде так, как будто код совершенно чужой. Не враг же он самому себе?

Четвёртый пример

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

С одной стороны – code and forget, можно писать что угодно и как угодно, лишь бы работало.

С другой стороны – а что, если этот заказчик через месяц вернётся и попросит за дополнительные деньги что-то добавить или переделать? Будем плакать, колоться, но жевать кактус? Откажемся от заказа?

А что, если он обратится к другому разработчику (компании), получит негативный feedback о качестве исполнения проекта, и больше никогда не вернётся к «злым говнокодерам», да ещё своим друзьям отсоветует?

Я уже не говорю о таких вещах, как качество кармы и память потомков.

Пятый пример

Командная разработка.

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

Да что там говорить – один говнокодер способен принести вреда больше, чем вражеский агент в тылу врага!
Если команда не изолирует его, бросив на написание никому не вредящих, ни с чем не связанных, абсолютно левых утилит и мини-приложений – то его продуктивность в команде будет не то, что нулевой – она будет отрицательной!

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

А тестирование? Сопровождение? Расширение функционала??

Я мог бы написать ещё пару хулительных абзацев – но нет. Не могу.
Клавиатура выпадает из ослабевших пальцев при мысли о том, сколько вреда может принести говнокод в команде…
Это ужасно… ужасно…

Устремлённый


Итак, мы примерно понимаем, что такое грязный код и чем он плох. Мы всё ещё не вполне понимаем, что такое чистый код, но ощущаем его необходимость.
Почему же он всегда есть, этот грязный код, почему он всегда присутствует и портит жизнь всем – в том числе и своим авторам?

На мой взгляд, всё предельно просто: писать чистый код – это искусство, это сверхспособность, развить которую в себе может практически каждый; но далеко не каждый даже задумывается о необходимости её развития.

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

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

И при этом, в идеале, он всегда ощущает, что его код всё ещё недостаточно хорош, что ему ещё далеко до совершенства. И пусть его сегодняшний «говнокод» на голову выше самого лучшего, что он писал два-три года назад – всё равно есть куда расти.

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

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

1) Хорошо работающая голова (поэтому у нас всегда есть задачки на логику)
2) Высокий уровень самокритичности (поэтому всегда есть задачки на написание кода и поиск ошибок в нём)
3) Интерес к программированию (важен в меньшей степени, задачками не определяется в принципе)

То есть понятно, что если голова работает плохо – то разработчиком не станешь при всём желании и старании. Однако, если она даже золотая и светится от разумности – это ещё далеко не гарантия.

Частенько бывает, что молодой специалист, видя, как легко ему всё даётся (особенно – в сравнении с большинством своих одногруппников, сокурсников, просто ровесников) начинает искренне считать, что круче бывают только яйца.
И, хотя наверняка к этому есть некоторые основания, но ЧСВ зашкаливает настолько, что в итоге в один прекрасный момент он просто перестаёт развиваться, считая, что «я и так умный, а кто пытается это оспорить – тот дундук».

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

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

Начинает чаще выполнять задачи «строго по спецификации», желательно – уже знакомые задачи, из знакомых сфер. Меньше уделять внимания новым языкам, платформам, концепциям.

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

Но так и не достигает вершины своего изначального потенциала.

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

Ах, как прекрасна эта картина – так и хочется смахнуть несуществующую слезу! Как прекрасен он, этот устремлённый в бесконечность молодой человек, своим духовным порывом приподнимающий самые небеса, в которые нацелен его всепроникающий взгляд!

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

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

И остаться внизу, с щемящей радостью наблюдая, как пронизывают они пространство и время в своём стремлении.

И знать, что хотя бы немного, хотя бы чуть-чуть – помог, поддержал, а не стоял в стороне, застывший в своём упоении собственной важностью, не бросал презрительных взглядов – «пхе… молодёжь..»
@NickPasko
карма
4,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (71)

  • +25
    sleep() получает параметром миллисекунды, так что ещё на 1000 умножить надо.
    • –1
      спасибо за содержательный комментарий :)
    • +13
      NAME
      sleep — Sleep for the specified number of seconds

      SYNOPSIS
      #include <unistd.h>

      unsigned int sleep(unsigned int seconds);

      DESCRIPTION
      sleep() makes the calling thread sleep until seconds seconds have elapsed or a signal arrives which is not ignored.

      RETURN VALUE
      Zero if the requested time has elapsed, or the number of seconds left to sleep, if the call was interrupted by a signal handler.

      CONFORMING TO
      POSIX.1-2001.
    • +2
      Не хотелось бы быть занудами, но это спорное утверждение:) По разному бывает.
      Хотя msdn.microsoft.com/en-us/library/ms686298%28VS.85%29.aspx (с большой буквы), тем не менее www.delorie.com/gnu/docs/glibc/libc_445.html (с маленькой).

      Function: unsigned int sleep (unsigned int seconds)
      The sleep function waits for seconds or until a signal is delivered, whichever happens first.
      • +1
        Вспомнилась связанная с этим история как Oracle Reports на линукс спортировали: vnaum.livejournal.com/9731.html
    • +22
      Закину сюда, может кто еще не видел сонную сортировку.
      dis.4chan.org/read/prog/1295544154
      • +2
        «Ресурс по данному IP заблокирован по решению органов власти» Билайн.
        Что хоть там?
        • +16
          #!/bin/bash
          function f() {
              sleep "$1"
              echo "$1"
          }
          while [ -n "$1" ]
          do
              f "$1" &
              shift
          done
          wait
          

          ./sleepsort.bash 5 3 6 3 6 3 1 4 7
          • +2
            Спасибо, давно так не ржал.
          • –1
            Вообще непонятно :(
            • +1
              Как написал кто-то в комментариях:
              Это примерно как поразрядная или корзинная сортировка, но вместо «пространственного» массива используется «временной» массив
            • 0
              Если я правильно понял, программа получает число, спит это число секунд, потом сдвигает это число в конец массива.
              т.е. в данном случае первым будет сдвинуто число 1, потом — три раза 3, потом 4, 5, 6, 6, 7
              решение оригинальное, да. ))
              • +4
                Я так понял, что она запускает процесс, который спит это число секунд, потом печатает результат и останавливается. И проделывает это для всех чисел. В итоге каждое число будет напечатано в тот момент, которому оно равно.
                • +1
                  Да, это ещё лучше.
                  Кому нужен массив ))
                • 0
                  Получается она в нескольких экземплярах запускается? Или в никсах sleep не останавливает выполнение программы на N секунд?
                  • +1
                    Останавливает. Но после запуска f "$1" & она не ждёт завершения. Так что f запускается в нескольких экземплярах.
      • 0
        Круто!
    • +1
      Уж тогда Sleep(), а sleep вполне себе получает секунды.
  • +8
    + Поддаётся автоматизированному тестированию
    — Может быть протестирован, лишь как «чёрный ящик».

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

    Статья слобоватенькая, и не особо информативная.
    • 0
      Может, если состоит из огромного скрипта без единой функции или если весь код в одной огромной функции.
      • 0
        Ну в этом случае «Белый ящик» — затруднителен, а автоматизированному функциональному тестированию ничего не мешает. Или нет?
    • 0
      Я вам один умный вещь скажу, только вы не обижайтесь пожалуйста. Тестирование есть проверка на соответствие спецификации. Если есть спецификация, любой код может быть протестирован как черный ящик. Тестировал (сам писал тесты, в команде естессно) JVM от Sun'a, javac, java API и никогда в их код не заглядывал. Ну разве что в некоторые стандартные классы из любопытства. Но у явы спецификации классные. Как результат — классные тесты и качественная реализация.

      А вот когда спецификации нет, то тогда приходится лазить в код — именно за спецификацией. Только что там можно найти — говнофикацию разве что.
      • 0
        В случае отсутствия спецификаций, можно проявить телепатические свойства и на основе интуитивно понятного интерфейса программы, разработать спецификацию?

        А на что я должен обижаться? То, что вы сказали как-то опровергает то, что я сказал?
    • 0
      Тут дело в частице «лишь».
      Которая подразумевает, что юнит-тестирование не применимо.
      Пример: программа, которая делает что угодно, используя лишь одну функцию. Юнит-тестирование попросту невозможно.

      Да, пожалуй, надо было уточнить, что под автоматизированным подразумеваются прежде всего юнит-тесты.
      Если претензия к этому — то принимаю и посыпаю голову пеплом. :)
      • +2
        А проблемы с юнит-тестированием — не показатель качества кода. Достаточно сколь угодно серьезного сайд -эффекта чтобы юнит тестирование было проблемным. А сайд-эффект, сам по себе, не показатель плохого кода.

        Я знаю, что тестируемость — показатель качества кода, но формализовать это дело — не берусь.
        • 0
          Я тоже не берусь.
          Просто высказываю соображения, которые, в зависимости от ситуации, могут быть важны — а могут быть и НЕ важны.
          Об этом в посте говорится, но несколько вскользь.
  • 0
    И правда, зачем было выносить в комментарий то, что можно было написать буквально:
    sleep(60 * 60 * 24);
    
    • +5
      Индусская оптимизация.
    • +2
      Блин, ну понятное же дело — раз рантайм в этой функции слегка растянут во времени, значит надо бороться за сокращение времени компиляции хотя бы.
    • 0
      рефакторинг очевидно же.
    • 0
      Не знаю, не знаю. Лично я уже давно назубок помню, что 86400 — сутки, а 3600 — час.
      • +2
        Вы меня пугаете. ))
        • 0
          Оно просто запоминается — сначала восьмерка, потом две цифры, каждая из которых меньше предыдущей на 2. И два нуля.
          • +5
            Нет, я немного о другом.
            Числа-то запоминать — в принципе дело полезное.
            Телефоны там… адреса… явки, пароли… ))

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

            Очень надеюсь, что на самом деле (с) в виду имелось нечто иное ;)
            • 0
              Нет, серьезно. Более того, я бы сам так написал. Не считая конечно фееричность использования sleep в данном случае.

              86400 с комментарием 60*60*24 отвечает требованиям микрооптимизиторов, и при этом обладает достаточной читаемостью.

              Единственное исключение, пожалуй, что начиная с некоторого уровня абстракций, правильнее будет уже не 86400, а strtotime("+1 day").
              • 0
                Ну, понятно.
                То есть Вы ратуете за использование этого числа, как зафиксированной данности.
                А не за фееричное решение задачи с его помощью. :)
      • 0
        А что такое 768, помните?
        • +5
          — Петька, приборы!
          — Двадцать!
          — Что «двадцать»?!
          — А что «приборы»?
        • 0
          Десятичное число вестимо.
        • +5
          256*3. Обычно используется, когда 512 мало, а 1024 много, но хочется «покруглее» в двоичном виде ))
          • –1
            Это наиболее близкий к правильному ответ.
            Только 3 — еретическое число.

            Правильный ответ:
            768 это 512 + 256
            • 0
              Тогда, что такое 42?
              Правильный ответ
              32+8+2

              365?
              Правильный ответ
              256+64+32+8+4+1

        • 0
          Точек в ширину на экране айпада в портретной ориентации, например.
          • +1
            Не поминай имени Э-л всуе
        • +1
          Высота монитора. При факторе 4:3 и ширине 1024. Соответственно, 3*256
      • 0
        В файлы с DNS зонами часто залезаете? :)
      • 0
        Проще написать 648000/Math.PI, чем вспомнить, как называется эта константа и в каком классе она определена. А при очередном рефакторинге заменить её по всему коду.
        • 0
          … если он, конечно, будет.
  • 0
    Не понял насчет утилитки и говнокода. Вы имеете в виду не слишком общо? В чем грязнота. Обычный линейный прикладной код без всяких шаблонов можно написать чистенько, что будет понятно, где мы что делаем.
    • 0
      Можно.
      А можно написать грязно.
      В том и дело, что в данном конкретном случае говнокод в принципе допустим.
  • +3
    Да вы Гоголь! ;)
    • 0
      Спасибо, я старался передать дух своего любимого писателя.
      Насколько получилось — судить не мне. Сам я слишком самокритичен. ))
  • 0
    Отличная КДПВ! Даже в пост зашел. Но не осилил текст. Зато увидел сонную сортировку.
    • 0
      Спасибо — хотя Ваше третье предложение меня несколько расстраивает ))
  • 0
    Хочу обратить внимание, что одиночная разработка по сути не отличается от коммандной. Во-первых даже маленький скрипт бывает нужно доработать позже, придется вникать в свой же говнокод. Во-вторых любая более-менее крупная программа не умещается целиком в голове, все время нужно будет вовращаться к разным частям системы и анализировать. То есть тебя как бы много, если рассматривать разные моменты времени, так как ты каждый раз разный, с разным контекстом в голове.
    • 0
      Полностью согласен.
      Более того — именно об этом я пишу в третьем и четвёртом примерах.

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

      Если в команде говнокодят чуть менее, чем все и каждый — то никто ничего не заметит.
      Тоже вполне жизненная ситуация, к сожалению.
  • 0
    Очень хотелось бы дать почитать эту статью на английском своей команде.
    плакать и жевать кактус
    Как жизненно.
    • –1
      Спасибо, я очень старался, чтобы статья понравилась :)
      Можно, конечно, написать и на английском.
      Но получится несколько хуже.
      Притом, что трудозатрат будет больше.
      В общем — к сожалению, это для меня сейчас вряд ли возможно. :(
  • –3
    У меня есть такой эвристический критерий грязного/чистого кода:
    Если после стандартного форматирования кода текст программы выглядит как ровные гладкие волны — то код скорее всего «чистый». Если же получились рваные неровные строчки с выбросами и провалами, то 99% это говнокод.
    • 0
      Странный критерий, откровенно говоря.
      • 0
        Поэтому критерий и эвристический — я не могу объяснить, почему это работает. И тем не менее красивый код выглядит красиво. И наоборот.
        • 0
          Надо будет поприглядываться :)
          Хотя буквально сегодня довелось поразгребать вполне себе волнового говнеца )))
    • +1
      А «волны» определяются по левым или по правым краям строчек?
      • 0
        В основном по левым. Правый край гораздо менее показательный.
        • +1
          Тогда после стандартного форматирования левые края соседних строчек отличаются на 0 или 4 символа (язык C#, настройки — открывающаяся скобка на одной строчке с конструкцией, закрывающаяся — на отдельной строчке). И любая программа без goto выглядит, как те самые волны. Выбросам и провалам браться просто неоткуда.
      • +1
        Придя домой — не забудьте снять trollface ))
  • 0
    Спасибо, прочитал с большим удовольствием. Ваш текст напомнил мне о давнем, до сих пор не реализованном намереньи прочитать The Programmer's Stone. Правда, мне показалось, что последняя часть вашего рассмотрения («устремлённый») не вполне продолжает противопоставление «грязный-чистый»: например, неустремлённый программист (тот, который «не достигает вершины своего изначального потенциала» и работает строго по спецификациям в знакомой области) может производить очень чистый код. И наоборот, устремлённый супер-производительный «хакер» (в хорошем смысле :) ) может продвинуть сложный проект так, как никто другой, но при этом произведя не особо чистый код (например, натащив какого-нибудь «прогрессивного новья», интересного ему в данный момент, но не полезного проекту в долгосрочной перспективе); т.е. противопоставление неустремлённый / устремлённый не вполне коррелирует с противпоставлением производитель грязного / производитель чистого кода. Это неможко смазывает посыл сообщения, по-моему.
    • 0
      Спасибо за конструктивную критику. Действительно, этот момент у меня немного выбивается из общей канвы.
      С другой стороны, текст писался, как обрамление бесплатным курсам чистого кода, которые я собираюсь проводить в ближайшее время.
      И третья часть скорее объясняет — почему вообще я считаю, что такие курсы нужны. И почему я хочу вкладывать в это своё время и свой, пусть не самый богатый, опыт.
      Очень рад, что текст сам по себе тоже может приносить пользу. Пожалуйста, реализуйте-таки своё намерение — от этого будет только польза и Вам лично, и окружающим :)
      Ещё раз спасибо — за внимание, за понимание и за критику. :)
      • 0
        Спасибо, постараюсь — пишите, пожалуйста, ещё!

        И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.

        Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
        • 0
          Совершенно согласен.
          Поэтому в разных командах бывают свои, командные, гайдлайны.
          Которые стараются от проекта к проекту не менять, чтобы, например, легче было перебрасывать людей из проекта в проект.
          Вот при переходе из команды в команду (из компании в компанию) бывает, что приходится тратить некоторое время на подстраивание под принятый там стиль кодирования.

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.