Почему программистов не учат «чистописанию»?

Мартин Фаулер сказал золотую фразу: «Any fool can write code that a computer can understand, good programmers write code that humans can understand». Прошли годы, а воз и ныне там. Большинство разработчиков забывают о том, что 80% времени они читают свой код и код своих коллег. Статья — попытка заставить подумать о проблеме качества кода.

Об авторе

Алексей Солнцев. Консультант по процессам в компании Infopulse Ukraine. Agile коач в тренинг-центре XP Injection. Координатор перевода на русский язык книг «Scrum and XP from the trenches» и «Kanban and Scrum — making the most of both». Профессиональный путь: разрабатывал флэш-память, писал модули для трассировки элементов в сверхбольших интегральных схемах, потом был «уволен в запас», не поехал учиться в аспирантуру в Германию, писал на скриптовом noname языке, спрыгнул на Java, спасибо Илье Цветкову, завязался с Agile, спасибо датчанам, и понеслась душа в рай ...

Мысли вслух

А вы помните свои первые дни на работе в роли программиста? Вы помните свои первые незаданные вопросы?

Я прекрасно помню. Это не были вопросы, посвящённые выбору фреймворка, принципам обработки ошибок и увеличению производительности базы данных. Самый главный вопрос, который меня постоянно заботил — как же правильно назвать класс, метод, переменную. Мне всегда было крайне сложно дать чёткое и однозначное название переменной: стоит или нет зашить тип в название (descriptionString), использовать или нет притяжательную форму (updateUsersList), чем removeItem отличается от deleteItem?

И никогда не понимал, почему переменную, которая будет отвечать за подсчёт количества попыток называют с, count, в лучшем случае, counter, вместо того чтобы дать простое и понятное имя triesCounter.

Я уже не говорю про те случаи, когда методы называют с использованием транслитерации:

void sortirovka(String klienty)
Сам я так никогда не писал, хотя, понимаю, откуда уши растут. К моему глубокому сожалению, я учил немецкий 12 лет и спрыгнуть с него было, ох, как нелегко.

Ещё больше вопросов возникало у меня при написании комментариев, о важности которых мне постоянно рассказывали преподаватели на занятиях по ООП. Но я хоть убей, не понимал, зачем нужен javadoc комментарий в таком куске кода:

/**
* Returns the day of the month.
* @return the day of the month.
*/
public int getDayOfMonth() {
    return dayOfMonth;
}

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

А сколько времени было убито мной на нажатие Tab и Ctrl+Tab для форматирования текста? Почему мне никто долгое время не говорил, что любая более-менее вменяемая IDE имеет встроенный code beautifier и по нажатию одной комбинации весь код будет сиять своей «отформатированостью».

Смешно? Но я бы на вашем месте не смеялся, а взял бы и посмотрел на код ваших junior-ов и на то, как они работают. Поверьте мне, они пишут точно также как и я когда-то. За 10 лет особо ничего не поменялось. Но им всё таки повезло больше. В 2008 году на свет появилась книга Clean Code, которую просто обязан прочитать каждый разработчик. Эта книга сделает вашу жизнь как разработчика намного красивее, гармоничнее и чище.

В тот момент, когда я прочёл шедевр Uncle Bob-а, меня уже заботили совершенно другие вопросы: как использование dependency injection поможет мне при разработке, как разрабатывать многопоточные приложения, как избежать влияния junior-ов на стабильность работы приложения, над которым трудится 20 человек. И так мой взор пал на статические анализаторы кода, которые помогают автоматически выполнить огромное количество проверок, уменьшают трудозатраты на ревью кода и повышают качество конечного продукта.

На сегодняшний день, благодаря таким инструментам, как Sonar, FindBugs, Checkstyle, Cobertura, FxCop, StyleCop, PHP_Depend, мы можем получить много полезной информации о нашем коде, и раз и навсегда избавиться от детских ошибок.

Мне, как говорится, за эту тему очень болит, и мне очень жаль, что «чистописанию кода» не учат с первых курсов в институтах, наряду с рефакторингом и юнит-тестированием и подходами в работе с системами контроля версий (я говорю не про checkout-update-commit). Поэтому я хочу, чтобы как можно больше людей узнало, что такое «чистый код» и приглашаю всех желающих выступить с докладом (20-30 минут) или поучаствовать в дискуссиях на тему качества кода на третьем собрании «Клуба анонимных разработчиков».

P.S. Особенно интересно узнать, как обстоят дела с качеством кода в динамических языках программирования — Ruby, Python, PHP.

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


84 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Можно было бы еще вам привести некоторые соображения, но зачем мне это делать, учить вас?! :))

Почему программистов не учат «чистописанию»?

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

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

Видите, как все иногда не так просто как учат в школе :))

Так человек написал уникальный код, сделал фирме еще лучше, так как защитил код от плагиата(а это очень сарьезная проблема для фирм), а ему коллеги «не, плохой код, давай исправляй, чтобы каждый мог прочитать и понять в чем тут дело» :)

код налуплен ужасный, но рабочий и оптимальный

— вы такой код читаете или пишете?

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

Защита от плагиата — это вообще смешно. Никакая компания никогда свои исходники никому не отдаст и не покажет. А если речь об open-source, то на то там код и открытый — чтобы все пользовались.

за «Clean Code» большое спасибо. прочитал, многое стало на свои места

«Почему программистов не учат „чистописанию“?»

Смотря о каком программировании идет речь. В «ширпотребном программировании» это нужно, а в научном нет.

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

Это как пьяный электрик, который в доме сделал разводку как попало, «зато работает же!», и живите дальше с этим как хотите...

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

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

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

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

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

уже представляю себе ситуацию, приходишь на новую работу поддерживать проект написанный вот такими программерами как Вы — открываешь код, смотришь на него и думаешь:
Научное программирование отличается от ширпотребовского, что научное основывается на физике и всем том, что сделано экспериментально, то есть, понимание принципа. Чего нет в ширпотребовском программировании, где каждый раз что-то свое непонятное(ну автор придумал такое) и задумываешься над кодом «что за г.. тут накодили».
В ширпотребовском программировании основная задача это бизнес требование, и значит, если все написать самым лучшим образом, то так могли бы выпустить 9 разновидностей ПО, а так придется только одну версию выпустить, НЕ ВЫГОДНО, поэтому объем кода больше, и пишется дольше со всеми НазваниямиФункцииКотораяВозаращетДату :)

Матрица «A» всегда проще, чем «getМатрицаA()», чтобы тратиться на «getМатрицаА()», когда речь идет о векторах, то буквами мыслишь быстрее и понятней. Вектор он и в Африке вектор и операции с ним. :)

Вы понимаете, что такое стандарты и рекомендации?

если есть требования — Вы либо переучиваетесь и соблюдаете их, либо уходите.

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

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

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

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

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

Вы понимаете, что такое стандарты и рекомендации?

Это когда нужно идти более долгим путем, когда есть более легкий и простой.

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

Хотите сказать, что если Вам дадут исходники Windows с правильным оформленным кодом, то Вы сможете один поддерживать весь этот проект «Windows»? :)

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

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

Да все о том же, научное программирование — это когда правила представлений силы, векторов, проекций и операций над ними не измены, поэтому вопрос о правильном оформлении кода находится не в избыточном понятном getБлаБлаМетодБлаБла(), а в лаконичном буквенном символьном отображении через операторы. В научном программировании важно чтобы код был минимален по лаконичности, так как там не слова читают в коде, а представляют то ЧТО делают те или иные действия. В ширпотребном программировании такого нет. Если бы было бы не так, то Delphi не отличался бы от C своими

procedure БлаБла()
begin
end;

(25 букв)

void БлаБла() {
}

(14 букв)

Разница в 25-14=11 букв.

Где код правильней, а где г0внокод? :))

ИМХО
1. Хороший код это гораздо дальше чем правильные именования. Мне например проектирование, именование помогает лучше понимать суть проблемы. а
2. Вы говорите решаете задачи по физике, где в принципе для смысловой нагрузки возможно определять переменные длинной в один символ,.. Это ведь прекрасно! Просто предметная область гораздо лучше структурирована, чем те же финансы)

3. Да и в «научном» программировании обычно вы сами и будете потом разбираться в том что вы написали. Нет понятия унаследованого кода. Или почти нет.

1. Хороший код это гораздо дальше чем правильные именования. Мне например проектирование, именование помогает лучше понимать суть проблемы. а

А вот ситуация такая, что:
1. Нужно изучить к примеру программирование под android с нуля.
2. Написать интерфейс под android, и учесть в коде особенности работы с нитями и событиями, и другого, которых может не быть под ту или иную платформу того же телефона.
3. Максимально быстро, потому что конкуренция и нужно быстро быстро, время — деньги

4. Баги в ПО разработки под тот же android к примеру (без багов в программировании никак) отладка написанного кода и т.п.

И вот что получается — что важнее «правильный» код или рабочий проект?

Получается, что гоbнокод это не всегда умышленно.

Столько комментариев))) Это все мне? Как вы добры)

Холиварить не хочу, времени нет. Отвечаю один раз.

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

1. Кто видет исходный код в пропоритарном ПО?

2. Так есть же и обфускаторы исходного кода, что мама родная не узнает.

Научное программирование на любом софте не пишется! :))

))) как можно писать программирование? пусть даже научное:) Ну а если попытаться понять смысл, то да, академические инструменты отличаются от промышленных. Ибо задачи разные. Да и коммент мой был не на статью, а на дискуссию. И на Java прекрасно решал весь универ задачи по статистике, оптимизации... Как там Макконел говорил? «Программирй не на языке, а с помощью языка.»

И по третьему. Пусть вы квалифицированный .NET программист. Пусть у вас появилась идея для мобильного ПО. Пусть вы ориентируетесь на рынок Андроид. И вы приступаете к задаче. Пусть приложенице маленькое. Да, в топку многие формальные этапы. НО! У вас есть опыт ООД(Объектно-ориентированного дизайна), понимание многопоточности и базовые паттерны. Понимание вообще работы ОС, планировщщика, ГУИ системы, пусть даже для той же Винды.

У вас скорее всего не будет плохого кода! Могут быть некоторые костыли, связанные с техническими деталями, но оставить в приложении точки роста, чтобы их перекрыть, вы оставите.

3. Да и в «научном» программировании обычно вы сами и будете потом разбираться в том что вы написали. Нет понятия унаследованого кода. Или почти нет.

А работа с векторами, библиотеки же можно будет использовать. Хотя если делать такие расчеты на Java, то конечно много и долго придется в мозге «выворачивать» извилин, чтобы читать коды таких задач. :))

1. Хороший код это гораздо дальше чем правильные именования.

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

C=A*B; // C++

C=multipleMatrix(A, B); // Java, Delphi

A,B,C — вектора, матрицы и т.п.

Научное программирование на любом софте не пишется! :))

Ширпотребовское бла-бла пишется на чем угодно, поэтому там и букOffКи требуется рисовать правильно.

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

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

Видите, как все иногда не так просто как учат в школе :))

Хотите сказать, что если Вам дадут исходники Windows с правильным оформленным кодом, то Вы сможете поддерживать этот проект «Windows»? :)

а Вы считали, что операционные системы поддерживаются всевышним? :)

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

procedure БлаБла()
begin
end;
(25 букв)
void БлаБла() {
}
(14 букв)
Разница в 25-14=11 букв.

Где код правильней, а где г0внокод? :))

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

В Python — единый стандарт оформления кода www.python.org/.../peps/pep-0008 . Его стараются придерживаться очень-очень многие. Я использую в своем редакторе автоматическую проверку кода на соответствие этому стандарту.

И никогда не понимал, почему переменную, которая будет отвечать за подсчёт количества попыток называют с, count, в лучшем случае, counter, вместо того чтобы дать простое и понятное имя triesCounter.

c — не в счет, counter — счетчик, ничего плохого в этом названии не вижу. другое дело если оно в конкретной ситуации не информативно и/или может ввести в заблуждение, но если никакого другого счетчика больше нет, то triesCounter ни чем не лучше простого counter. а если будет подсчет количества неудачных попыток? вы назовете переменную failTriesCounter? так не трудно дойти и до переменной с именем userSessionFailTriesCounter :)

void sortirovka(String klienty)

ну это просто быдло-код, четкие требования к коду легко устраняют такие привычки.

касательно

getDayOfMonth()

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

опять же, все что необходимо — предъявить разработчикам требования к их коду. а иначе — телепаты в отпуске и кто как хочет так и кодит.

ps — в целом, я с Вами согласен касательно «чистого кода». тем более сейчас, когда IDE поддерживают авто форматированием и все что нужно — настроить среду, тогда если ты совсем криворукий писака — можно просто периодически использовать хоткей авто форматирования.

Цитатка в тему, сказал Yukihiro Matsumoto:

Программы в некотором роде сродни очерку. Про очерк читатели в основном спрашивают: «Чему он посвящен?» А про программу: «Что она делает?» Фактически цель должна быть достаточно ясна, чтобы не вызвать никаких вопросов. Но и для очерка, и для компьютерного кода всегда играет роль то, как они написаны. Даже хороший замысел трудно донести до желаемой аудитории, если он понимается с трудом. Стиль написания не менее важен, чем вынашиваемая при этом цель. Прежде всего и очерк, и строки программного кода предназначены для прочтения и понимания человеком.

Вы не могли бы перевести ту фразу:

Any fool can write code that a computer can understand, good programmers write code that humans can understand

?

Любой дурак может написать код, который может понять компилятор/интерпретатор, но только хорошие программисты могут написать код, который понятен еще и людям.

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

как среда может влиять на то что написал программист?

вы написали

Если среда программирования допускает написание такого плохого кода, то виновата среда, а не программист.

Это полная простите фигня, и вы не привели достойный пример этому.

Впервые слышу, что бетон виноват в том, что строитель в дрель вставил сверло по дереву.

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

Так вы мои слова как раз и подтверждаете, спасибо. Ни разу не видел, что бы в редакторе Вижуал Васика писали на ассемблере.

Правда перфоратор дороговат и не всем по карману. И вообще, завод-робот дороговастенько стоит

то есть пришли к тому, что все-таки виноват человек, потому как нормальный программист не будет писать на ассемблере в Вижуал Басике. :) и вам спасибо)

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

Возьми правильный инструмент и будет код правильный.

ха-ха! как бы ни так. Инструмент важен, никто не спорит, но если нет в голове нет понимания, что такое «чистый код», то никакой инструмент не поможет.

извините, вы тролль и я вас баню.

Взял вилку, полено и случайно из полена вырезал орла вилкой =)

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

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

Более того если на то что пишет программист начнет влиять среда, то о каком творчестве мы говорим?

хвост виляет собакой.

Это в корне ошибочное утверждение!

Получается если писатель создал плохой роман, то виновата пишущая машинка, на которой он писал — нужно было писать в последнем Word-е?

И если инженер спроектировал плохой мост, то виноваты инструменты, которые он использовал?

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

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

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

Фигня почти на 100 процентов. Да и сравнение книг-романов с кодом — это нечто.

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

Какое именно утверждение вы считаете 100% фигнёй? Вы тоже думаете, что IDE а не программист виноваты в корявом коде?

Это —>

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

я лично знаком с парнем, который был такой же «религиозный» как и Вы. Писал все в FAR editor/Notepad. Потом покаялся )

В Far-e можно только лабы в институте писать :)

двачую )

20 лет назад в чем писали крупные коммерческие проекты?

Знаете каких размеров были раньше крупные коммерческие проекты?
Windows 3.11 — 11.25MB!
И эту систему писали 30-40 супер-нинзя-программистов.

А теперь библиотека одна столько весит.

Это не библиотека, а bloatware, скорее всего. Но это не относится к вопросу обязательности IDE. Тут дело в привычке и удобстве, а не можно писать / нельзя писать.

я же не сказал, что хороший программист «должен» писать код в notepad или в far’e. Я только сказал что он «может» — т.е. у нормального разработчика не должно быть проблем открыть код вне IDE в vim/emacs/far/notepad... (на выбор) и быть способным поправить и собрать проект. Т.е. если программер без IDE не может написать и скомпилить простенькую программку — это не очень хороших признак.

Ну як сказати. Я довший час провів з Екліпсою. Багато фіч але тормоза мене вбивали. Тому я перейшов на Нотпад++. Зара тільки задоволений. Це той самий блокноп, просто продвинутий.

Ребята, как можно такое говорить? Голый редактор — это 1/100 всех фич современных IDE.

Получается если писатель создал плохой роман, то виновата пишущая машинка, на которой он писал — нужно было писать в последнем Word-е?

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

сомнительно — даже если человек работает с текстовым редактором он отвлекается на разные вещи... т.е. лимитом здесь есть не возможности инструмента (которые в целом достаточны) а лимит воображения — т.е. лимит наложенный самим автором.

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

P.S. Уильям Гибсон, один из основоположников киберпанка, писал свой известный Нейромант на пишушей машинке (чем я был очень удивлён — учитывая, что роман о всеобщей компьютеризации и влиянии технологий на социум).

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

Для документирования — yard и rdoc.

«чистописанию кода» не учат с первых курсов в институтах, наряду с рефакторингом и юнит-тестированием

Это из области фантастики. Примерно так, что завтра все чиновники, не знающие украинские языка будут расстреляны публично. В университетах ТОЛКОМ не учат ничему, кроме вышки и философии.

Но согласись, что этому научить не так сложно. Намного легче чем программировать контролеры :)

программировать контролеры
как сговорились эту фразу использовать)) И в рассылке — и здесь

Чистоту коду важко тримати, особливо коли щодня міняються рекваременти, при цьому треба клієнту пояснити, чому добавити ще одну кнопку займає стільки ж часу. Навіть якщо розбити все на модулі, притримуватись MVC чи іншої парадигми...всерівно буде замовник, який скаже, що вот йому треба вже і зараз, зробити щось, тому що він вже пообіцяв юзерам.

Как раз в книге Clean Code приводится хорошее сравнение. «Вы же не говорите хирургу перед операцией чтобы он не мыл руки, а как можно быстрее приступал к операции?».

Тоді я говорю польові умови (впав сервер, неправельно рахуються ключові дані, клієнту не подобається хвостик в букви j)

Отвечаю, даже не смотря на то что это откровенно притянутое за уши сравнение: чините сервер, а потом меняете переменную j на iterator.

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

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

а через какое время рефакторинг? у нас каждые полгода новые фичи. если я начну рефакторить после, то 1 — большие затраты QA ресурсов. 2 — «40 часов программисту на вот эту хрень, о которой нет упоминания в спеках» — менеджеры не понимают.

а что такого страшного в рефакторинге? Это занимает в день не больше, чем разработчик тратит на покурить.

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

А если разработчик не курит?

значит сидит и комментит всякую фигню на девелоперсах

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

и принятие такого решения может занять не «на покурить», имхо :)

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

півроку, круто, в нас що 2х тижнів + гарячі підкидування по кілька в тиждень

у вас standalone app? какая предметная область? направление?

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

консультанты тоже делают ошибки :) quick-fix-ы — зло.

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

code beatifier = code beaUtifier — мне обычно помогает несколько раз прочесть статью до того как нажать кнопку «publish» и несколько раз сразу после того

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

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

Да... вопрос серьезный...

т.к. в ruby(и python?)-фреймворках в основном используется принцип convention over configuration, там все еще более менее читабельно.

В мире пхп полная задница. Тема очень актуальна.

6 років з РНР, вчу пітон. Покіщо в РНР чистота, а в Пітоні задниця. Вам не здається, що це не залежить від технології, а тільки від людини?

Согласен, разруха не в технологиях, разруха — в головах.

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

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

Изучая хранимые процедуры в продуктах компании Iflex solutions (на данный момент куплены Oracle’ом), я частенько вспоминал тихим словом таких вот горе-программеров-индусов. Если мы как страна, хотим продолжать конкурировать на рынке Outsourcinga, то необходимо, как правильно заметил Алексей, внедрять культуру и навыки «чистописания» уже из-за школьной скамьи.

Подписаться на комментарии