Тест Джоэла: 12 шагов к лучшему коду

← →
Fredericco (2003-12-16 18:53) [40]

А вот развитие механизма самотестирования, то есть написания скриптов для тестирования своих же кодов, причем это развитие не только у себя самого, но и у подчиненных, резко сокращает время разработки отдельных модулей проекта и снижает время реакции руководителя проекта на заявление программиста: "Готово!".

← →
kull (2003-12-16 18:58) [41]

> Sandman25 © (16.12.03 18:50) [39]

Вот чтоб избежать этих "Если" и необходима ежедневная сборка.

P.S. Только есть одно обстоятельство. Все конфигурации нашего пакета собираются за 6 часов (12 штук каждая по ~30 мин.).

Ну там все *.exe, *.dll, база данных, help, инсталяция и т.д.

Так что за это время можно не только пообедать но еще и поужинать.

← →
Юрий Зотов (2003-12-16 19:08) [42]

> Sandman25 © (16.12.03 18:50) [39]

А еще это может означать, что каждый из этих ОЧЕНЬ опытных программистов СВОЙ кусок сделал действительно грамотно и без ошибок, но... но не учел того, что сделал другой.

И не мог учесть. Потому что когда он писал СВОЙ код, он еще не видел изменений, сделанных сосседом - они еще не были залиты.

← →
Suntechnic (2003-12-16 19:21) [43]

10 из 12.

Со спецификациями постоянный напряг и постоянная ругань с product менеджерами.

Коридорное тестирование... хм... вообще то есть такие специфические программы, с которыми первый встречный и поработать не сможет. Предметной областью владеть надо. Так что выхватить в коридоре 5 RF инженеров, наверное, всё-таки проблематично.

← →
Alex Konshin (2003-12-16 19:50) [44]

У нас в районе 11 или даже все 12.
Пункт второй - сборка за один шаг - у нас просто иногда не осуществим: продуктов много, каждый состоит из нескольких кусков, которые создаются разными командами частенько в разных странах. То есть, если имеется в виду, могу ли я собрать продукт из частей, который мне предоставляют другие со сборкой своего кода, тогда да, для большинства продуктов это будет так. Но я точно не могу собрать все отдельные части всех продуктов сам.
То есть, скорее всего, здесь ответ утвердительный, просто не совсем понятно, что имеется в виду.
И еще: я не писал ни строчки кода при приеме на работу потому, что человек, который меня принимал и рекомендовал знал меня лично.
По поводу коридорного тестирования: это не всегда осуществимо, так как не всегда ваш продукт имеет GUI или его применение посторонним человеком затруднено из-за сложности самих задач. Для этого есть тестеры, пусть они делают свою работу. Что касается дизайна, то он проектируется и утверждается задолго до написания самого кода и каждое его изменение тоже согласовывается со специальными группами "связи с пользователями" и менеджерами. Так что этот пункт, на мой взгляд, вообще не имеет смысла для программиста большой компании.
Сборка - это вообще отдельная история.
Еще автор ни словом не упоминул о regression testing. Если этого нет в Microsoft, то тогда понятно, почему у них столько ошибок привносимых с новыми версиями. Это ОЧЕНЬ важно. Суть в том, чтоб была автоматизорованная система тестирования, которая бы проверяла каждый новый билд на то, что в нем не испортилось то, что давно работает. Это не только позволяет экономить на тестерах, но и исключает человеческий фактор из тестирования. Естественно, тестерам все равно остается что делать. Собственно, именно созданием таких систем я и занимаюсь сейчас в этой компании.

← →
Игорь Шевченко (2003-12-16 20:20) [45]

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

Ты имеешь в виду набор unit-тестов или тесты всей системы целиком ?

← →
Alex Konshin (2003-12-16 20:25) [46]

Игорь Шевченко © (16.12.03 20:20) [45]
А всего. И unit-тесты, и и тесты GUI, и тесты отдельных подсистем, и тесты взаимодействия нескольких продуктов.
У нас для всего есть или пишутся тесты. Используются разные технологии. Собственно, я сам тесты не пишу и не гоняю, поэтому не могу рассказать про них много, но я учавствую в создании комплексов для их прогонки.

← →
Игорь Шевченко (2003-12-16 20:32) [47]

Alex Konshin © (16.12.03 20:25)

А тесты GUI по какому принципу у вас построены ? (Хотя бы принцип)

← →
OlegGashev (2003-12-16 21:27) [48]

1- Да
2- Нет
3- Да
4- Да
5- Да (если не учитывать todo, что еще нужно добавить в рабочий код)
6- Да
7- Нет
8- Да
9- Нет
10- Нет
11- Нет
12- Иногда

← →
OlegGashev (2003-12-16 21:33) [49]

Если учитывать тестирование во время написания кода и проверку его на двух ОС, то 10 пункт 2.

← →
Sergey_Masloff (2003-12-16 22:39) [50]

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

← →
dmk (2003-12-16 23:18) [51]

10 из 12
кроме пунктов 4 и 11.
4 - Если голову считать за базу данных =) тоже да.
11 - Сам на работу никого не принимал, начальство
устроило ранее написанное.

← →
Alex Konshin (2003-12-17 01:47) [52]

Игорь Шевченко © (16.12.03 20:32) [47]
Alex Konshin © (16.12.03 20:25)

А тесты GUI по какому принципу у вас построены ? (Хотя бы принцип)

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

← →
ДедушкаКо (2003-12-17 10:10) [53]

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

← →
Sandman25 (2003-12-17 10:22) [54]

[42] Юрий Зотов © (16.12.03 19:08)

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

← →
Style (2003-12-17 10:23) [55]

А фотку его видели
Чем то он мне Киркорова напомнил :)

← →
Юрий Зотов (2003-12-17 10:48) [56]

> Sandman25 © (17.12.03 10:22) [54]

> Не надо им было изменять декларации методов или использовать
> модульные переменные

Разве это единственные причины несовместимости двух кусков кода? Таких причин - сколько хочешь.

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

А на фига же тогда системы контроля версий? Не такие, как VSS (которые просто лочат файлы), а более гибкие, как CVS, например. Зачем ими морочить себе голову, если все равно идет стук по Аське: Вася, ты этот модуль не трожь, я его правлю.

Не дело все это.

← →
Игорь Шевченко (2003-12-17 10:55) [57]

ДедушкаКо © (17.12.03 10:10)

Почему же советами не пользуются ? Книжка очень хорошая :) Жаль, что теперь подобных очень немного...

Даже краткий дайджест есть: http://www.delphikingdom.ru/article/tassel.htm

← →
Vuk (2003-12-17 11:11) [58]

to Юрий Зотов:
По поводу CVS. Не факт, что гибкость эта на пользу идет. Эта система позволяет править один файл нескольким людям, что в результате ведет к тому, что потом требуется слияние изменений. Причем, для большого проекта это будет настолько большой объем работы, что нужен специальный человек, который будет только слиянием изменений и разрешением конфликтов заниматься. Что в результате получится - вообще неизвестно. Уж лучше блокировка файла на уровне сервера. Это гарантирует непротиворечивость изменений и отсутствие конфликтов.

← →
Sandman25 (2003-12-17 11:51) [59]

[56] Юрий Зотов © (17.12.03 10:48)

Разве это единственные причины несовместимости двух кусков кода? Таких причин - сколько хочешь.

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

А на фига же тогда системы контроля версий?

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

← →
Юрий Зотов (2003-12-17 12:34) [60]

> Vuk © (17.12.03 11:11) [58]

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

... которое в 99% случаев выполняется автоматически (и уж если CVS берется сводить автоматически, то всегда делает это правильно). В оставшемся 1% CVS честно говорит - заливать не буду, сначала сведи вручную (об этом см. ниже).

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

Наш проект - около 900 тыс. строк исходников. Думаю, это уже можно считать большим. Так вот - ручное сведение выполняется любым разработчиком (то есть, самим же автором изменений) за 5 минут (как правило, даже быстрее), любой тулзой типа Super-Puper Merge, прямо из клиента CVS (он может интегрировать любую тулзу). И никаких специальных человеков.

С VSS я тоже работал. Во-первых, неудобно - именно из-за блокировки и именно потому, что не дает двоим править один и тот же файл. Во-вторых, если такая необходимость все же возникает (что бывает нередко), а время не ждет, то программер просто обновляет локальную копию захваченного кем-то файла, потом просто снимает с нее атрибут RO и правит без захвата (вот это - уже ДЕЙСТВИТЕЛЬНО конфликт). А потом, перед заливкой делает то же самое сведение - но уже ТОЛЬКО вручную.

Еще ситуация. Вася захватил файл А, а Петя захватил файл Б. В процессе правки Васе потребовалось внести изменения еще и в файл Б, а Пете - в файл А (что есть нормальная и совсем не редкая рабочая ситуация). Возникает классический deadlock - Вася ждет Петю, а Петя ждет Васю. Хорошо еще, если они сидят в одной комнате, а если на разных материках?

На практике такой конфликт разрешается либо все тем же стуком по Аське (Отпусти файл, он мне позарез нужен! Не могу, он мне тоже позарез нужен, подожди полчаса (нетрудно догадаться, что полчаса запросто могут вылиться и в полдня), либо описанным выше "способом". В итоге - надежность только кажущаяся, зато неудобств - куча.

← →
Юрий Зотов (2003-12-17 12:54) [61]

> Sandman25 © (17.12.03 11:51) [59]

> Мне просто очень интересно, какие это могут быть причины.
> Никогда не сталкивался.

Пусть есть некий базовый механизм (назовем его БМ), зашитый в коде ядра проекта. Вася делает прикладной кусок A и чтобы сделать его ОБЩУЮ поддержку (мы же помним, что Вася - очень опытный и грамотный), добавляет к БМ некую новую функциональность (не затрагивая, конечно, уже имевшуюся). Петя делает прикладной кусок Б, но он тоже очень и опытный и грамотный - поэтому он тоже делает его в ОБЩЕМ виде, тоже добавляя что-то к БМ (и тоже не затрагивая предыдущего).

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

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

Можно, но вообще-то, для этого существует руководитель (группы, проекта...) и та самая база ошибок.

← →
vuk (2003-12-17 12:59) [62]

to Юрий Зотов:
>Возникает классический deadlock - Вася ждет Петю, а Петя ждет
>Васю.
А иначе не получим ли мы ситуацию, что оба "поправят" файл так, что работать оно после слияния не будет?

← →
Sandman25 (2003-12-17 12:59) [63]

[61] Юрий Зотов © (17.12.03 12:54)

Понятно, спасибо.

← →
Юрий Зотов (2003-12-17 13:15) [64]

> vuk © (17.12.03 12:59) [62]
> А иначе не получим ли мы ситуацию, что оба "поправят" файл
> так, что работать оно после слияния не будет?

Тот, кто будет заливать "конфликтный" файл последним, должен будет свести код вручную и при этом он УВИДИТ код, залитый до него. Дальше все зависит от него самого. Если он тупо нажмет на "Merge" - ну, что ж, от дураков защиты не существует. А если он сначала ПОСМОТРИТ, что же именно сводится - то сведет так, как положено это делать.

Реально, за несколько лет работы коллективом в 5-10 человек такого еще не было.

← →
vuk (2003-12-17 13:19) [65]

to Юрий Зотов:
>А если он сначала ПОСМОТРИТ, что же именно сводится - то сведет
>так, как положено это делать.
А влияние изменений Пети на свой код Вася будет делать "на глазок"?

← →
Юрий Зотов (2003-12-17 13:31) [66]

> vuk © (17.12.03 13:19) [65]
> А влияние изменений Пети на свой код Вася будет делать "на
> глазок"?

В процессе сведения - на глазок (плюс мозги и знание проекта). А СРАЗУ же после сведения - тестированием.

VSS от накладок такого рода тоже не защищает - конфликты в логике работы кода не в состоянии просечь ни одна система контроля версий. Поэтому конечное тестирование все равно нужно.

← →
kull (2003-12-17 15:16) [67]

Мне что-то не совсем понятно насчет слияния конфликтующих файлов.

Если 2 человека работают одновременно с одним файлом, то наверняка, не с одним куском кода, иначе говоря не с телом одной функции.

А при работе с разными функциями в одном файле, со слиянием обычно проблем нет.

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

← →
Alex Konshin (2003-12-17 21:47) [68]

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

← →
Игорь Шевченко (2003-12-17 22:01) [69]

← →
Vuk (2003-12-17 22:01) [70]

Будет.

← →
Юрий Зотов (2003-12-17 23:12) [71]

> Alex Konshin © (17.12.03 21:47) [68]

Блин, да это было бы одно из самых интересных сообщений за все время существования форума.

← →
Юрий Федоров (2003-12-17 23:15) [72]

← →
Fantasist (2003-12-18 00:08) [73]

> Alex Konshin © (17.12.03 21:47) [68]

И отдельной статьей!

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

← →
Игорь Шевченко (2003-12-18 00:23) [74]

Fantasist © (18.12.03 00:08)

Могу порекомендовать сайт www.xprogramming.ru и книжку Кента Бека: "Экстремальное программирование, разработка через тестирование". Несмотря на то, что книга написана языком "для деревянных чайников" (IMHO), методика там неплохая. У экстремалов кое-что можно позаимствовать, забыв про их экстремальность.

← →
Alex Konshin (2003-12-18 01:11) [75]

Хорошо, я попробую написать статью когда дойду до дома.

← →
Alex Konshin (2003-12-18 11:05) [76]

Я начал писать, можете посмотреть.
http://home.earthlink.net/~akonshin/Workflow_in_PTC.html
Завтра постараюсь продолжить. До самого интересного еще не дошел.

← →
Sandman25 (2003-12-18 11:11) [77]

← →
Alex Konshin (2003-12-18 11:14) [78]

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

← →
Ihor Osov'yak (2003-12-18 11:19) [79]

небыло, минут через три появилось, следовательно версия [78] правдоподобна..

← →
Sandman25 (2003-12-18 11:23) [80]

Теперь я и у меня появилась.

Тест Джоэла: 12 шагов к лучшему коду Найти похожие ветки