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

← →
kull (2003-12-16 12:55) [0]

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

Я подсчитал баллы для своей компании. Получилась мрачная картина - 5 баллов, а должно быть - 12. :(

Тест Джоэла: 12 шагов к лучшему коду - см. здесь:
http://www.joelonsoftware.com/global/Russian/Articles/TheJoelTest.html

Народ! Страшно интересно сколько у вас получится...

← →
panov (2003-12-16 13:10) [1]

Статейка - супер!

← →
Rouse_ (2003-12-16 13:36) [2]

Классс !!! Сенькс за линк...

PS: 8 баллов... тоже не дотягиваем...

← →
Юрий Зотов (2003-12-16 13:48) [3]

Да... есть о чем подумать.

Вот ТАК работают те самые, которые "масдай".

← →
Ditrix (2003-12-16 13:59) [4]

там все статьи - супер!
а вот балы... не буду я это озвучивать -:)

← →
Vuk (2003-12-16 14:05) [5]

Везет тем, у кого 8 баллов. :o(

← →
panov (2003-12-16 14:13) [6]

>Vuk © (16.12.03 14:05) [5]
Точно!

← →
Rouse_ (2003-12-16 14:27) [7]

> [5] Vuk © (16.12.03 14:05)
У нас просто еще до моего прихода было все так поставлено... и ничего не изменилось, хотя могло бы и измениться ...

PS: Кстати пункт о спокойном рабочем месте под эти баллы не подходит... :(
Что не может не огорчать... домой еду, голова как колокол...

← →
Lola (2003-12-16 14:31) [8]

"Команда головорезов" - это я :)))) Хорошо, что голова только одна - моя, и "мы её режем".
Термин "коридорное тестирование" вообще услышала впервые, хотя периодически пытаюсь такой опыт провести над своим мужем ;)

← →
Palladin (2003-12-16 14:44) [9]

Распечатал 10ый пункт и повесил в офисе, предварительно зачитав шефу...

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

У меня 10 баллов ;)

← →
kull (2003-12-16 15:02) [11]

10 баллов! Да... Счастливые люди.

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

Пункты 8 и 12 отсутствуют :)

← →
Sandman25 (2003-12-16 15:52) [13]

Я не понимаю, в чем смысл 3 Выполняете ли вы ежедневные билды для улучшения кода...
1) Зачем билдить, если в этот день не было изменений? В большинстве компаний есть несколько проектов. Неужели над каждым из них работают каждый день?
2) Если я собрался сделать настолько большие изменения, что они займут несколько дней?

← →
Юрий Зотов (2003-12-16 15:54) [14]

> Sandman25 © (16.12.03 15:52) [13]

Ну не буквально же надо понимать.

← →
Карелин Артем (2003-12-16 15:56) [15]

Твердая двойка ))

← →
Reindeer Moss Eater (2003-12-16 15:57) [16]

Зачем билдить, если в этот день не было изменений?

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

← →
Fredericco (2003-12-16 15:58) [17]

А у нас отсутствует 8 и 9.
А 3 просто не нужно, так как у нас много маленьких проектов, которые делаются раз и на всегда (тестим ё-моё как:-)) и сборка работающей системы состоит из выбора набора программ.

← →
Юрий Федоров (2003-12-16 16:12) [18]

4 балла.
в целом картина не очень, вот что обидно. Я думал, только у нас...

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

Вот что у меня вышло:

1 - да (CVS)
2 - да (Finalbuilder)
3 - нет (хотя ничто не мешает)
4 - да (Mantis)
5 - да
6 - да
7 - нет (то что у нас есть спецификацией можно назвать с трудом)8 - нет (хотя может быть и грех жаловаться)?
9 - нет (не уверен что оно новейшее, а тем более дорогое.)
10 - нет (Мы сами себе тестеры)
11 - Точно не знаю, но кажется - нет
12 - Нет

итого = 5

← →
Sandman25 (2003-12-16 16:36) [20]

[14] Юрий Зотов © (16.12.03 15:54)

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

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

Sandman25 © (16.12.03 16:36)

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

Это называется TDD (Test-driven development) разработка через тестирование, когда после любого исправления в программе прогоняется набор функциональных тестов.

← →
Sandman25 (2003-12-16 17:36) [22]

[21] Игорь Шевченко © (16.12.03 16:42)

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

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

Sandman25 © (16.12.03 17:36)

Ссылка на сайт - www.xprogramming.ru

> Кто-то еще сказал, что для этих программистов главное не
> результат, а сам процесс.

Вообще-то неверно. Использование тестов сокращает время на сопровождение и исправление ошибок, особенно в больших проектах.

← →
Sandman25 (2003-12-16 17:43) [24]

[23] Игорь Шевченко © (16.12.03 17:39)

>Ссылка на сайт - www.xprogramming.ru

Точно!

>Вообще-то неверно. Использование тестов сокращает время на сопровождение и исправление ошибок, особенно в больших проектах.

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

← →
VAleksey (2003-12-16 17:44) [25]

> Игорь Шевченко © (16.12.03 14:59) [10]

У меня вышло 9-ть.
Мышку мне не дали :-(...
Исключительно из-за мышки. Нервничал много :-)).

PS
А вообще в одиночестве работать... Так я пожалуй и курить бы начал.
Для потока надо наушники одевать. IMHO.

← →
Юрий Зотов (2003-12-16 17:44) [26]

> Игорь Шевченко © (16.12.03 17:39) [23]

> Использование тестов сокращает время на сопровождение и
> исправление ошибок, особенно в больших проектах.

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

← →
blackman (2003-12-16 17:46) [27]

1."Если вы хотите устроиться программистом в компанию, спросите у вашего предполагаемого работадателя, сколько баллов набирает его компания. Если балл слишком низок, убедитесь, будут ли у вас достаточные полномочия, чтобы всё наладить и изменить ситуацию."
Попробуйте...
2."Иначе вы мало чего добьётесь и вряд ли будете довольны"
Лучше конечно иначе :)
Если попробуете 1, то точно ничего не добьетесь и будете очень недовольны :)

← →
Passlight (2003-12-16 17:48) [28]

VAleksey © (16.12.03 17:44) [25]
Мы с начальником насчитали около 2х баллов :)))

← →
Юрий Зотов (2003-12-16 17:50) [29]

> Sandman25 © (16.12.03 17:43) [24]

> Зачастую навыки программиста столь велики, что он гарантирует,
> что его изменения ничего нового не привнесли.

Вот тут-то и кроется одна из самых больших опасностей. Даже если его гарантии и верны, то ведь рядом правит код не менее опытный программист, который тоже гарантирует. Но когда два неоттестированных куска начинают работать ВМЕСТЕ... оп-ля, вот тут-то и выясняется.

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

Юрий Зотов © (16.12.03 17:44)

Полностью согласен.
Одного начального проектирования недостаточно.

← →
DiamondShark (2003-12-16 18:02) [31]

> Sandman25 © (16.12.03 15:52) [13]
> Я не понимаю, в чем смысл 3 Выполняете ли вы ежедневные
> билды для улучшения кода...

Артефакт Си-программизма ;-)
Программист на Си не ищет синтаксическую ошибку, нажимая кнопку "Build" ;-)
Нам это не грозит.

_______________

5 баллов, при учёте, что:
- п.3 явно артефактный -- проигнорирован
- п.9 ответ "НЕТ", а нафига?
- п.11 не было уже года два как, ответ "НЕТ"
- п.12 чиво-чиво?

← →
blackman (2003-12-16 18:06) [32]

>Одного начального проектирования недостаточно
И вот пример настоящей работы (Огонь и движение):
http://russian.joelonsoftware.com/Articles/FireAndMotion.html

← →
kull (2003-12-16 18:11) [33]

Насчет гарантий опытного программиста...
Какие могут быть гарантии, человеку свойственно ошибаться.
Или программист - не человек?
Может просто залипнуть клавиша, и полетит в CVS кривой файл. :)

← →
ДедушкаКо (2003-12-16 18:22) [34]

почему-то вспоминается:
а кто не умееет программировать-тот учит других
(не о мастерах-о джоеле)
и похоже на хлеб с икрой имеет

← →
ДедушкаКо (2003-12-16 18:25) [35]

и еще вспоминаются ксерокопии книжек по каратэ

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

ДедушкаКо © (16.12.03 18:22)

> а кто не умееет программировать-тот учит других
> (не о мастерах-о джоеле)

А там вроде он и о своих программках рассказывает...

← →
kull (2003-12-16 18:34) [37]

> ДедушкаКо
> почему-то вспоминается:
> а кто не умееет программировать-тот учит других

Ну почему-же? Это не так.
Я на себе почувствовал, как упростилась моя програмистская жизнь, когда начали выполнятся некоторые пункты из теста.
И я с ужасом вспоминаю те времена, когда этого не было. Даже не представляю, как я тогда мог нормально работать.

← →
DiamondShark (2003-12-16 18:34) [38]

Да чё там!
Выперли из Мелкософт, вот и бесится.

← →
Sandman25 (2003-12-16 18:50) [39]

[29] Юрий Зотов © (16.12.03 17:50)

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

← →
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]

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

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

← →
Ihor Osov'yak (2003-12-18 13:18) [82]

да, очень интересно..
присоединяюсь к [81]..

← →
Alex Konshin (2003-12-19 10:47) [83]

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

← →
Sandman25 (2003-12-19 11:07) [84]

← →
Sandman25 (2003-12-19 15:36) [85]

Утром было Page not found. Сейчас тоже. Так и не получилось прочитать продолжение... Ждем-с :)

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

← →
Ann (2003-12-19 16:09) [87]

у меня тоже не получается прочитать..

← →
Alex Konshin (2003-12-23 10:42) [88]

Дописал еще кусочек.

← →
Юрий Зотов (2003-12-23 22:00) [89]

> Alex Konshin © (23.12.03 10:42) [88]

Алекс, огромное спасибо. Читаю - и получаю удовольствие.

Материал ОЧЕНЬ интересен, есть ОЧЕНЬ много вещей, над которыми действительно СТОИТ задуматься. По крайней мере, мне, как team leader"у (и конечно, исходя из ситуации в нашей команде и с нашим продуктом - увы, на сегодня не самых радужных).

Кроме того, Вы еще и прекрасно пишете. Не комплимент - действительно так. Спасибо еще раз.

← →
panov (2003-12-23 22:13) [90]

Вот увидите, ЭТО будет бестселлер-)

← →
Игорь Шевченко (2003-12-23 22:47) [91]

Отлично написано, очень хорошая статья!
Алекс, большое спасибо. Надеюсь на продолжение :)

← →
Alex Konshin (2003-12-24 11:08) [92]

Подумаешь! Я еще и вышивать могу, и на машинке... тоже. (с) Кот Матроскин.

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

← →
Sandman25 (2003-12-24 11:35) [93]

А у меня все Page Not Found :(

Может кто-нибудь из добрых людей послать мне статью на e-mail Sandman25@hotmail.com? Дочитать охота, а не получается... Заранее спасибо.

← →
Sandman25 (2003-12-25 16:53) [94]

Очень интересное продолжение. Спасибо!
Особенно понравился раздел про сборку и тестирование.
Я начинал подумывать о написании тестов UI, но после прочтения статьи стали яснее все возможные проблемы и трудности. Цитата: Зачастую создание системы тестирования - задача, сравнимая по сложности с написанием самого проекта. конец цитаты. :(

← →
Alex Konshin (2003-12-25 22:02) [95]

???
Про сборку в самом деле интересно - он еще не написан.

← →
Alex Konshin (2003-12-26 02:35) [96]

> Зачастую создание системы тестирования - задача, сравнимая по сложности с написанием самого проекта. конец цитаты. :(
Ну, не пугайтесь! Видимо, у меня талант страшилки писать. В нашей ситуации явный пример перехода количества в качество. При наших объемах приходиться задумываться о том, что, возможно, вам и не нужно. Не думаю, что у вас сотни программистов и тестеров, а если нет, то и проблемы у вас все-таки иные. Хотя, конечно, согласен, что любой чужой опыт интересен. Я где-то читал про тестирование в Oracle. Конечно, там не было деталей, но были цифры. Например, они очень гордятся тем, что собирают и тестируют (regression testing) очередной билд за ночь. Если найду первоисточник - сообщу.

Еще немного дописал про тестирование.

← →
Игорь Шевченко (2003-12-26 02:52) [97]

Чем дальше, тем интереснее. Завидно :)

← →
Sandman25 (2003-12-26 12:16) [98]

[95] Alex Konshin © (25.12.03 22:02)

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

[96] Alex Konshin © (26.12.03 02:35)

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

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