Comments on: Что общего у программиста и писателя http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/ Alexander Lebedev writes about software development and outsourcing Tue, 16 Feb 2010 17:27:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Лучший способ найти время на юнит-тесты » Outsourcing stories http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/comment-page-1/#comment-36 Лучший способ найти время на юнит-тесты » Outsourcing stories Thu, 31 Aug 2006 03:34:03 +0000 http://alexlebedev.com/blog/?p=6#comment-36 <p>[...] В одном из недавних комментариев Андрей написал о наболевшем: И, наверное, документирование надо рассматривать как еще одну <em>невключаемую</em>обычно_ в план работ задачу. [...]</p> [...] В одном из недавних комментариев Андрей написал о наболевшем: И, наверное, документирование надо рассматривать как еще одну невключаемуюобычно_ в план работ задачу. [...]

]]> By: Alex Lebedev http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/comment-page-1/#comment-34 Alex Lebedev Thu, 31 Aug 2006 02:02:20 +0000 http://alexlebedev.com/blog/?p=6#comment-34 <p>Проекты бывают разными и я уверен, что тот же sqlite - весьма интересный пример. Однако один проект сам по себе ничто - важно видеть код разных проектов, чтобы иметь базу для сравнения.</p> <p>Андрей, вы пишете на C более-менее серьезно? Если нет, то читать код будет примерно так же сложно как книгу на иностранном языке, которым с трудом владеешь.</p> <p>По поводу примера с присваиванием 0 указателю - мне кажется, что в хорошем коде из имени переменной должно быть ясно, что она содержит указатель. В этом случае мы просто имеем дело с разной семантикой одного и того же действия, что весьма несложно распознать опытным взглядом. Например, в приведенном ниже коде не нужно думать над тем, где вычисляется длинна строки, а где - длинна массива. <code> width = len(name) height = len(event_list) </code></p> <p>С отступами и стилями тоже достаточно странно. ИМХО, большинство уважающих себя open source проектов весьма аккуратно поддерживают согласованность стиля. Если у sqlite с этим все так плохо, найдите другой проект.</p> Проекты бывают разными и я уверен, что тот же sqlite – весьма интересный пример. Однако один проект сам по себе ничто – важно видеть код разных проектов, чтобы иметь базу для сравнения.

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

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

width = len(name)
height = len(event_list)

С отступами и стилями тоже достаточно странно. ИМХО, большинство уважающих себя open source проектов весьма аккуратно поддерживают согласованность стиля. Если у sqlite с этим все так плохо, найдите другой проект.

]]> By: Андрей http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/comment-page-1/#comment-33 Андрей Wed, 30 Aug 2006 17:00:15 +0000 http://alexlebedev.com/blog/?p=6#comment-33 <p>Ага, щаз. Пробовали. Берешь какой-нибудь интересный проект с исходным кодом, начинаешь разбирать {может в этом проблема, может надо просто читать, а как?} и ничего не понимаешь. Нет, языковые конструкции это все понятно, просто либо модули слишком большие, либо классы сильно перегружены функциями, либо нужных комментариев недостает. Вот просто идет программный код и все. Я уж не говорю про стилистику, отступы. Приходится доставать code стайлеры. Пример, sqlite, раздобыл исходники на C, решил посмотреть как работает. Где-нибудь в середине кода переменной присваивается 0 (ноль), а переменная по своей сути является указателем, так чтобы не запутаться приходится по ходу чтения заменять 0 на NULL - одно дело когда какой-нибудь счетчик и другое дело когда адресная арифметика. Но отсутствие <em>нужных</em> комментариев это наверное самый сильный бич. Когда разбираешь текст, оставляешь в нем свои вопросы, так хотя бы формулируешь для себя, что искать. Находишь ответы - туда же, в код. По-хорошему документировать программу должен не тот, кто ее писал, а тот кто будет ее читать. Например в процессе code review, ведь именно в этом случае будут задаваться правильные вопросы (если я этого не понял, значит и после меня этого не поймут и не поймут тоже самое). И наверное документирование надо рассматривать как еще одну <em>невключаемую</em>обычно_ в план работ задачу. P.S. А еще бывает полезно перечитывать творения рук собственных.</p> Ага, щаз. Пробовали.
Берешь какой-нибудь интересный проект с исходным кодом, начинаешь разбирать {может в этом проблема, может надо просто читать, а как?} и ничего не понимаешь. Нет, языковые конструкции это все понятно, просто либо модули слишком большие, либо классы сильно перегружены функциями, либо нужных комментариев недостает. Вот просто идет программный код и все. Я уж не говорю про стилистику, отступы. Приходится доставать code стайлеры.
Пример, sqlite, раздобыл исходники на C, решил посмотреть как работает. Где-нибудь в середине кода переменной присваивается 0 (ноль), а переменная по своей сути является указателем, так чтобы не запутаться приходится по ходу чтения заменять 0 на NULL – одно дело когда какой-нибудь счетчик и другое дело когда адресная арифметика. Но отсутствие нужных комментариев это наверное самый сильный бич. Когда разбираешь текст, оставляешь в нем свои вопросы, так хотя бы формулируешь для себя, что искать. Находишь ответы – туда же, в код. По-хорошему документировать программу должен не тот, кто ее писал, а тот кто будет ее читать. Например в процессе code review, ведь именно в этом случае будут задаваться правильные вопросы (если я этого не понял, значит и после меня этого не поймут и не поймут тоже самое). И наверное документирование надо рассматривать как еще одну невключаемуюобычно_ в план работ задачу.
P.S. А еще бывает полезно перечитывать творения рук собственных.

]]> By: Alex Lebedev http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/comment-page-1/#comment-12 Alex Lebedev Thu, 10 Aug 2006 03:01:01 +0000 http://alexlebedev.com/blog/?p=6#comment-12 <p>Согласен, языки программирования намного строже естественного языка. Читать для приобретения хорошего вкуса и чувства стиля нужно заметно меньше. Однако, не советую успокаиваться, прочитав небольшое количество текста. Стили и решения, как правило, имеют ограниченную область естественного применения, которую можно понять только ознакомившись с объемом кода намного большим, чем два-три проекта.</p> <p>Предлагаю рассмотреть вот какой пример. Вы отлично знаете английского язык, но из текстов читали только учебник и сонеты Шекспира - зачем что-то еще, у вас же есть пример отличного стиля. Внимание, вопрос - в каком стиле будут написаны ваши письма заказчику в США? Подходит ли этот стиль для данной задачи?</p> <p>Еще один момент - чтобы легко отличать хороший код от плохого нужно, чтобы вы во множества видели примеры и того и другого. Тут тоже не хватит чтения малого количества хороших исходников.</p> <p>Сколько кода нужно прочитать, чтобы развить в себе чувство стиля? Попробуем провести аналогию с литературой. Предположим, что для разумного развития литературного вкуса нужно прочитать книги из школьной программы плюс еще столько же (ИМХО, этого абсолютно недостаточно). Речь идет об объеме в 100-150 книг, что составляет примерно 30 000 страниц или 1 000 000 строк текста. Цифры взяты с потолка, но дают представление о порядке величин. Даже если кода нужно читать в 20 раз меньше, речь все равно идет о десятках проектов и десятках тысяч строк.</p> Согласен, языки программирования намного строже естественного языка. Читать для приобретения хорошего вкуса и чувства стиля нужно заметно меньше. Однако, не советую успокаиваться, прочитав небольшое количество текста. Стили и решения, как правило, имеют ограниченную область естественного применения, которую можно понять только ознакомившись с объемом кода намного большим, чем два-три проекта.

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

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

Сколько кода нужно прочитать, чтобы развить в себе чувство стиля? Попробуем провести аналогию с литературой. Предположим, что для разумного развития литературного вкуса нужно прочитать книги из школьной программы плюс еще столько же (ИМХО, этого абсолютно недостаточно). Речь идет об объеме в 100-150 книг, что составляет примерно 30 000 страниц или 1 000 000 строк текста. Цифры взяты с потолка, но дают представление о порядке величин. Даже если кода нужно читать в 20 раз меньше, речь все равно идет о десятках проектов и десятках тысяч строк.

]]> By: Foror http://alexlebedev.com/blog/%d1%87%d1%82%d0%be-%d0%be%d0%b1%d1%89%d0%b5%d0%b3%d0%be-%d1%83-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%b0-%d0%b8-%d0%bf%d0%b8%d1%81%d0%b0%d1%82%d0%b5%d0%bb%d1%8f/comment-page-1/#comment-10 Foror Thu, 10 Aug 2006 02:19:39 +0000 http://alexlebedev.com/blog/?p=6#comment-10 <p>Полностью согласен. В наше время, в большинстве проектов(особоено в веб), математика отходит на второй план. Почти в каждой области уже созданы свои фреймворки, позволяющие особо не заморачиваться на математику. Конечно, это не означает, что математика теперь не нужна, есть проекты где она просто необходима...</p> <p>Сейчас изучаю Java, и если бы не чтение хороших исходников Java проектов, я бы остался без знаний (возможно через какое-то время дошёл бы сам) о некоторых особенностях этой платформы. Но я думаю языки программирования намного ограничение человеческих языков, а значит существует намного меньше приемов(шаблонов) для создания "красивых фраз". Поэтому, здесь не нужно много читать, здесь нужно просто познакомиться с малым количеством хороших исходников... а дальше изучать новые особого смысла нет. Со стилями тоже самое :) есть стандарты оформления кода, и просто нужно писать с пониманием, что пишешь для человека, который будет в будущем это всё читать.</p> Полностью согласен. В наше время, в большинстве проектов(особоено в веб), математика отходит на второй план. Почти в каждой области уже созданы свои фреймворки, позволяющие особо не заморачиваться на математику. Конечно, это не означает, что математика теперь не нужна, есть проекты где она просто необходима…

Сейчас изучаю Java, и если бы не чтение хороших исходников Java проектов, я бы остался без знаний (возможно через какое-то время дошёл бы сам) о некоторых особенностях этой платформы. Но я думаю языки программирования намного ограничение человеческих языков, а значит существует намного меньше приемов(шаблонов) для создания “красивых фраз”. Поэтому, здесь не нужно много читать, здесь нужно просто познакомиться с малым количеством хороших исходников… а дальше изучать новые особого смысла нет. Со стилями тоже самое :) есть стандарты оформления кода, и просто нужно писать с пониманием, что пишешь для человека, который будет в будущем это всё читать.

]]>