среда, 8 сентября 2010 г.

[prog] Неожиданное продолжение истории об 1K строк на C в день

Чуть меньше года назад я задал в своем блоге риторический (как оказалось) вопрос о том, как можно писать по 1K (тысяче строк) на языке C в день на продолжении длительного времени. Вчера герой моего вопроса – Лев Валкин – написал в своем ЖЖ большую заметку “RSI — как бороться с туннельным синдромом”, в которой раскрыл эту тему подробнее.

Выяснились две довольно очевидные вещи:

  1. Выдавать 1K отлаженных строк ежедневно в течении более-менее длительного времени невозможно. (См.комментарии номер раз и номер два: мало того, что число 1K получилось не как число результирующий строк, а является числом измененных (переписанных) строк, так еще и не отлаженных);
  2. Работать в таком темпе вредно для здоровья.

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

Посему остановлюсь вот на чем: “А что, 1K строк ежедневно – это доблесть?” Читая Льва Валкина у меня складывается впечатление, что да, доблесть. Человек с гордостью говорит о том, что он мог работать в таком темпе. Более того, в комментариях прозвучала фраза “Но я, конечно, не дорос ещё до 1К строчек в день.”, поэтому, боюсь, доблесть видит в этом далеко не один человек.

Я хочу, чтобы читатель задумался о том, что значит 1K строк в день.

Обычный рабочий день составляет 8 часов. Всего 480 минут. И 1000 строк. Больше, чем две строки в минуту. Только набирать нужно больше двух строк в минуту! А когда же думать над тем, что пишешь?

Пусть каждая строка после написания переписывается два раза. Т.е. выдача “на гора” составляет ~330 строк. Т.е. около 1.5 минут на строку. Из которых часть времени занимает ее набор и исправление (т.е. физические действия), поэтому на обдумывание остается меньше времени. Путь будет 1 минута. Т.е. на обдумывание кода уходит, вроде бы, ~5.5 часов. Кажется, что неплохо – больше пяти часов на обдумывание кода в день.

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

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

А вот если бы она присутствовала, фаза эта? Представьте себе, что сначала пять часов тратиться на обдумывание, на рисование каракулей на бумаге или доске, на написание отдельных фрагментов на бумаге. Вплоть до тех пор, пока разработчик не поймет, что у него перед глазами прошло все, что он хотел набрать на компьютере. Сколько в результате получится строк? Да, в худшем случае, те же самые триста с плюсиком. Хватит ли оставшихся трех часов, чтобы спокойно и не напрягаясь набрать их? Как два байта…

Почему я сказал, что триста строк получится в худшем случае? Просто потому, что в лучшем случае их будет гораздо меньше. Это будут уже почти готовые и отлаженные строки. Нормально отформатированные, хорошо закомментированные. С намного меньшим процентом ошибок. С намного меньшим процентом серьезных ошибок.

Цифры “валовой продукции”, конечно, будут намного меньше. Не 1K, и даже не 300. А около 100 строк в день (это я цифры для C++ привожу, для других языков может быть и того меньше).

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

Последствия “обдумывания кода во время написания” зачастую сказываются на мне. Два дня назад в библиотеке, разработанной полтора года назад думающим-в-процессе-программистом, внезапно всплыл злобный баг и мне предстоит убить еще день на окончательное преобразование говнокода во что-то более-менее нормальное.

В последнее время это, мягко говоря, задалбывает. Поэтому я поступлю цинично и вопрошу:

Любишь колбасить по тысяче строк в день, вместо того, чтобы потратить три-четыре-пять-шесть часов на предварительное обдумывание?
Думаешь, что это круто – работать в таком темпе?
Думаешь, что таким количеством говнокода ты двигаешь проект вперед?
Если да, то готов ли ты к встрече с туннельным синдромом?
A?

9 комментариев:

  1. Количество строк кода - это самоцель чтоль?

    Действительно - думать то когда?

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

    Но зато я в этих строчках уверен.

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

    ОтветитьУдалить
  2. Вообще говорят - чем опытнее программист, тем меньше кода он пишет. Краткость - сестра нашего брата. :)

    И так постепенно превращается в менеджера. :D

    ОтветитьУдалить
  3. >Но зато я в этих строчках уверен.

    Чем больше работаю, тем больше ценю вот эту уверенность. И тем больше понимаю, как же дорого она дается.

    >Правда бывают и более напряженные периоды, когда нужно какую-то фичу побыстрее реализовать.

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

    ОтветитьУдалить
  4. >Если опыт в программировании и есть, то он как раз должен позволять придерживаться размеренного и устоявшегося ритма даже в авральных условиях.

    Я еще учусь. Этот процесс никогда не закончится. :)

    ОтветитьУдалить
  5. Собственно, про напряженные моменты -- это не я додумался. Об этом сказал Роберт Мартин (http://eao197.blogspot.com/2010/05/progwork.html): "Они не отбрасывают свои принципы даже в условиях дедлайнов. Более того, именно под прессом сроков они еще строже следуют правилам, в правильности которых они уверены."

    ОтветитьУдалить
  6. Добрый день.

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

    По существу.

    Как вы относитесь к автоматическому тестированию, TDD и BDD?

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

    Основная часть моей работы связана с ruby, поэтому я говорю о подходах реализованных в таких продуктах как cucumber и rspec, а как обстоит дело с "классическими" языками Си/Си++?

    ОтветитьУдалить
  7. @madbox:

    >хотел бы сказать спасибо

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

    >Как вы относитесь к автоматическому тестированию, TDD и BDD?

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

    Далее, нужно различать статически- и динамически-типизированные языки. Когда я активно программировал на Ruby, я вообще не был уверен в своем коде, если только не обкладывал его большой кучей unit-тестов. В C++/Java (не в C) после успешной компиляции у меня гораздо больше уверенности в работоспособности программы. Поэтому и такой серьезной потребности в unit-тестах не испытываешь.

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

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

    Так что TDD/BDD -- это хорошая вещь для определенных языков (Ruby/Python/Smalltalk и пр.) и определенных ниш (библиотек в первую очередь). Но не более.

    А вообще это тема для отдельного большого разговора.

    ОтветитьУдалить
  8. Я категорически согласен с тем, что думать надо, и надо аккуратно писать именно то, что требуется, а не ради количества строк.

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

    ОтветитьУдалить
  9. @lionet.info

    Мне, да и не только мне, было бы очень интересно узнать, как вам удавалось такое.

    ОтветитьУдалить