Комментарии 21
Готов платить за то, что программист просто пишет свой код, до тек пор пока код работает.
Ведь на самом деле есть такие компании, готовые платить за просто работающий код. Работал в такой.
Проблемы возникали крайне редко и их с лихвой покрывала экономическая выгода от такого подхода к разработке. Действительно, кода было очень много. Люди работали сразу над несколькими проектами и держали всё это в голове. Главный (да что там, практически единственный) критерий качества — работает и покрыт тестами.
Лично для меня, как «творца», ненадобность красивых архитектурных решений была одной из причин заняться другими проектами. Но с точки зрения эффективности, думаю, это работало.
А иногда вообще дешевле и проще slap shit together and deploy силами неопытных разработчиков, которые просто не умеют делать сразу красиво, «проверить бизнес-модель» и потом всё заново переписать.
Проблемы возникали крайне редко и их с лихвой покрывала экономическая выгода от такого подхода к разработке. Действительно, кода было очень много. Люди работали сразу над несколькими проектами и держали всё это в голове. Главный (да что там, практически единственный) критерий качества — работает и покрыт тестами.
Лично для меня, как «творца», ненадобность красивых архитектурных решений была одной из причин заняться другими проектами. Но с точки зрения эффективности, думаю, это работало.
А иногда вообще дешевле и проще slap shit together and deploy силами неопытных разработчиков, которые просто не умеют делать сразу красиво, «проверить бизнес-модель» и потом всё заново переписать.
Очередная статья призыв писать хороший код. 90% процентов объяснения как это важно, что и само собой понятно, и несколько строк, как это может быть достигнуто.
Это можно делать, когда у вас куча времени. Если у программиста достаточно времени, чтобы перечитывать свой код по несколько раз, то проблемы удобства чтения кода никогда не возникнет, так как любой программист любит перерефакторивать свой код, как только это становится возможным. Только очень редко в реальных проектах достаточно времени на такие вещи. И в таком случае у программиста должен быть инстинкт написания хорошего кода без оглядки, без продумывания по десять минут названия функции.
Вы должны остановиться и оценить его читабельность и разборчивость. Читайте и перечитывайте его несколько раз. Постарайтесь отстраниться от понимания проблемы, представляя, что кто-то читает этот код без того полезного контекста, который уже есть у Вас в голове, потому что Вы пишите этот код.
Это можно делать, когда у вас куча времени. Если у программиста достаточно времени, чтобы перечитывать свой код по несколько раз, то проблемы удобства чтения кода никогда не возникнет, так как любой программист любит перерефакторивать свой код, как только это становится возможным. Только очень редко в реальных проектах достаточно времени на такие вещи. И в таком случае у программиста должен быть инстинкт написания хорошего кода без оглядки, без продумывания по десять минут названия функции.
Если у программиста нет времени перечитать свой код, то у проекта большие проблемы.
Мне вот тоже очень непонятно становится, когда я сталкиваюсь с образом программиста, вся работа которого в том, чтобы бешено стучать по клавиатуре. Для меня программист — это инженер. Представьте себе инженера, который говорит «мне некогда смотреть, что я тут начертил, мне надо дальше чертить». Да работа инженера вообще не чертить (писать код) — работа инженера в том, чтобы думать. Придумывать и проектировать технические решения. Код — как и чертеж, как техническая спецификация — это описание результата работы по проектированию, а не сама работа. Сама работа делается в тот момент, когда человек в полоток смотрит отрешенным взглядом.
Конечно, не все думают смотря в потолок. Кому-то (мне в том числе) удобнее думать уже в процессе написания «отчета о проделанной работе», вперемешку с его написанием — так, зачастую, проще фокусироваться. Но это не отменяет того факта, что бОльшая часть времени уходит на раздумья, и лишь меньшая — на сам процесс описания результата. Даже когда я был джуниором на первой своей работе, и задачи у меня были самые наипростейшие — даже тогда где-то треть-половина времени уходила на анализ/проектирование/планирование. А я ведь и язык еще знал фигово, да и слепым методом набора не владел, да и тогдашние IDE нынешним не чета — т.е. была куча чисто технических причин, почему написание кода требовало тогда больше времени. Со временем задачи становятся все сложнее — а код пишется все легче. Сейчас, думаю, процентов 80-90 времени моей работы это именно придумывание решения, увязывание его с контекстом. Мне кажется, это совершенно естественный процесс — за что человеку с опытом платят больше, за умение быстрее текст набирать или за умение глубже думать? Если за второе, то очевидно, что доля этого, второго, в работе должна повышаться — разумно больше делать то, за что больше платят ведь?
И вот теперь такой вопрос: если каждый час когда я пишу «отчет от проделанном проектировании» (==код) стоит 8-9 часов проектирования — так, может, имеет смысл потратить чуть больше времени на то, чтобы этот «отчет» был написан ясным и понятным языком и аккуратно оформлен, а? Как-никак стоимость-то у него немаленькая…
Конечно, не все думают смотря в потолок. Кому-то (мне в том числе) удобнее думать уже в процессе написания «отчета о проделанной работе», вперемешку с его написанием — так, зачастую, проще фокусироваться. Но это не отменяет того факта, что бОльшая часть времени уходит на раздумья, и лишь меньшая — на сам процесс описания результата. Даже когда я был джуниором на первой своей работе, и задачи у меня были самые наипростейшие — даже тогда где-то треть-половина времени уходила на анализ/проектирование/планирование. А я ведь и язык еще знал фигово, да и слепым методом набора не владел, да и тогдашние IDE нынешним не чета — т.е. была куча чисто технических причин, почему написание кода требовало тогда больше времени. Со временем задачи становятся все сложнее — а код пишется все легче. Сейчас, думаю, процентов 80-90 времени моей работы это именно придумывание решения, увязывание его с контекстом. Мне кажется, это совершенно естественный процесс — за что человеку с опытом платят больше, за умение быстрее текст набирать или за умение глубже думать? Если за второе, то очевидно, что доля этого, второго, в работе должна повышаться — разумно больше делать то, за что больше платят ведь?
И вот теперь такой вопрос: если каждый час когда я пишу «отчет от проделанном проектировании» (==код) стоит 8-9 часов проектирования — так, может, имеет смысл потратить чуть больше времени на то, чтобы этот «отчет» был написан ясным и понятным языком и аккуратно оформлен, а? Как-никак стоимость-то у него немаленькая…
Я только за, но я пока не встречал работодателей, которые бы давали на это время. Возможно, это проблема моего личного опыта, но пока мне везде приходилось в бешеном темпе стучать по клавишам.
Не бешено стучать по клавиатуре, а срочно выкатить результат. Бывает такое, что твой начальник мечется по офису и каждые две минуты спрашивает, когда будет готово. Ему всё равно что и как ты там напишешь — главное чтоб работало, хотя бы как нибудь. А если тебе это так важно, то переписывать и рефакторить будешь «потом», когда время появится. Во-первых, такая работа отбивает желание в этот код даже заглядывать, а во-вторых «потом» время так и не появляется, а потому в следующий раз ты, скорее всего, правишь этот код в аналогичной ситуации.
Примерно так, в таких ситуациях, может рождаться самый страшный вид говнокода — спагетти: в условиях постоянного цейнтнота некоторые люди выбирают самое простое быстрое из возможных решений. Именно так появляется SQL в GUI. Именно так появляется GUI посередине сетевого протокола.
Примерно так, в таких ситуациях, может рождаться самый страшный вид говнокода — спагетти: в условиях постоянного цейнтнота некоторые люди выбирают самое простое быстрое из возможных решений. Именно так появляется SQL в GUI. Именно так появляется GUI посередине сетевого протокола.
Согласен, но я тут поразмыслил и пришел к заключению, что от многих ошибок в таком случае спасает правильная архитектура. Если вначале проекта много времени потрачено на правильное планирование архитектуры, то потом вы все же будете ей следовать. Да, узкие места будут, кое-где будет дублирование, легкий говнокод и пр., но все же это спасет от таких вот фундаментальных ошибок. Так что, в проекте главное, чтобы был хороший тимлид для придумывания архитектуры и разруливания узких мест, и тогда график может быть сколько угодно сжатый, качество кода все-равно будет кое-как поддерживаться.
Мой серьезный опыт в области программирования уже около 15 лет… Я до сих пор легко могу понять код, который написал… двенадцать лет назад.
Ничего плохого про автора не хочу сказать, но, на мой взгляд, в контексте совокупного стажа 15 лет про понимание кода 12-летней давности он всё же загнул. Как минимум, ему должно быть противно его читать, и уж точно не должно хотеться использовать снова, если он только не остался на том же профессиональном уровне, что было бы совсем печально.
Позволю себе не согласиться.
1. Противно не значит непонятно
2. Совершенно не факт что должно быть противно.
Для пробы открыл код, который коммитил в 2007-м в личный архив а писал и того раньше. Никакой противности не испытываю — да, сейчас я что-то сделал бы уже по-другому но не более того.
Если какая-то задача уже хорошо была решена 10 лет назад — зачем решать её еще раз, когда можно использовать уже готовое решение? Особенно если она решена понятно и при необходимости это решение легко можно будет поправить под новые ньюансы.
Как минимум, ему должно быть противно его читать...
1. Противно не значит непонятно
2. Совершенно не факт что должно быть противно.
Для пробы открыл код, который коммитил в 2007-м в личный архив а писал и того раньше. Никакой противности не испытываю — да, сейчас я что-то сделал бы уже по-другому но не более того.
… уж точно не должно хотеться использовать снова
Если какая-то задача уже хорошо была решена 10 лет назад — зачем решать её еще раз, когда можно использовать уже готовое решение? Особенно если она решена понятно и при необходимости это решение легко можно будет поправить под новые ньюансы.
Мне всегда понятно, что я написал какое угодно количество времени назад, но не всегда, почему я написал именно так. Какие-то вещи, которые кажутся очевидными в контексте и не требующими комментариев, потом иногда совершенно забываются, к сожалению.
НЛО прилетело и опубликовало эту надпись здесь
Извините, но «перевод» ужасен, а тема посредственна.
Попробую встать на защиту и обосновать гордость программиста, которого знает Эли Бендерски.
Код, который мы читаем, можно классифицировать:
1) Чужой код.
2) Код, который я написал сейчас.
3) Код, который я написал давно.
Чужой код оценить легко. Либо все понятно и красиво, либо я написал бы лучше (чаще всего второе). Мы легко видим недостатки чужого кода: архитектурные оплошности, неудачные идентификаторы, непонятные комментарии, и т.д.
В нашем коде между 2 и 3 пунктом лежит временной интервал. Насколько он длинен? Должно пройти время, пока мы забудем то, что писали, и будем относиться к коду как к чужому. Выполнять рефакторинг можно будет тогда, и только тогда, когда произойдет отстранение от своего кода. До этого момента мы к своему коду относимся предвзято. Именно этим и гордится этот программист — тем, что он может беспристрастно анализировать свой код уже через неделю.
Код, который мы читаем, можно классифицировать:
1) Чужой код.
2) Код, который я написал сейчас.
3) Код, который я написал давно.
Чужой код оценить легко. Либо все понятно и красиво, либо я написал бы лучше (чаще всего второе). Мы легко видим недостатки чужого кода: архитектурные оплошности, неудачные идентификаторы, непонятные комментарии, и т.д.
В нашем коде между 2 и 3 пунктом лежит временной интервал. Насколько он длинен? Должно пройти время, пока мы забудем то, что писали, и будем относиться к коду как к чужому. Выполнять рефакторинг можно будет тогда, и только тогда, когда произойдет отстранение от своего кода. До этого момента мы к своему коду относимся предвзято. Именно этим и гордится этот программист — тем, что он может беспристрастно анализировать свой код уже через неделю.
Врядли вы сможете легко понять и прочитать код, который был написан вами 12 лет назад т.к. ваши умения, навыки, стиль и техника, которые вы используете значительно изменились за такой большой промежуток времени.
Если у вас, дорогой читатель, достаточно времени, можете попробовать метод Франклина (о котором вроде бы даже упоминали на хабре, вот только лень искать). Заключается метод в том, что предмет творческого труда — в данном случае код — оставляют в темном сухом месте на 3 дня. По прошествию этого времени, предмет извлекается из места хранения и внимательно, с критической точки зрения, изучается. При выявлении непотребщины — исправить и повторить итерацию.
Чем лучше простого самоконтроля сразу по написанию кода — «замыленый взгляд» успевает отдохнуть, а мозг — выработать на уровне подсознания альтернативный подход к решению проблемы.
Чем лучше простого самоконтроля сразу по написанию кода — «замыленый взгляд» успевает отдохнуть, а мозг — выработать на уровне подсознания альтернативный подход к решению проблемы.
Читать свой код десятилетней давности вредно. У меня в нём обнаружилась давно забытая игрушка, на которую в итоге убил весь вечер.
А про понимание кода — было одно место, в котором разобраться сразу не удалось. Программа, судя по всему. решала японские кроссворды нечёткой логикой — так центральной функции алгоритма по своему коду мне понять не удалось. То ли там ошибка, то ли я тогда был умнее. В остальном читается нормально…
А про понимание кода — было одно место, в котором разобраться сразу не удалось. Программа, судя по всему. решала японские кроссворды нечёткой логикой — так центральной функции алгоритма по своему коду мне понять не удалось. То ли там ошибка, то ли я тогда был умнее. В остальном читается нормально…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Понимание собственного кода