Статья с множеством идей: как свести с ума тестировщика.

Сообщество - О жизни

Статья для начинающих программистов\разработчиков о стандартах разработки ПО

Над островом летали бабочки: большие, зеленые махаоны, огромные - больше воробья. Они летали медленно-медленно и нам говорили офицеры… громко:
- Не дай боже, какая падла этих бабочек…. Эти бабочки занесены в Красную книгу, они водятся только здесь, мы гордимся этими бабочками. Чтоб ни одна не дай бог что. Они тут миллионы лет, мля, живут, а вы тут за час все засрё….
Бабочки были очень красивые, они очень медленно двигали крыльями и летели. Вот так. (Тут необходимо снять обувь и показать, как летают большие бабочки, в смысле самому показать.)
Крылья их были изумрудно-зеленые….
Я задавил трех штук.


Евгений Гришковец
"Как я съел собаку"
Пишу статью первый раз – НАКИПЕЛО:)
Итак, ВСТУПЛЕНИЕ
Почему я ЭТО пишу? Да просто по роду деятельности приходится проверять чужую работу, окошки, кнопочки и отчеты. И хочется, чтоб меня уважали и работа моя была УМНАЯ. Не люблю я садится за тестирование в предвкушении, а тут бабах и не открывается ничего и проверить – не могу. Не люблю видеть в работе других откровенную глупость и растрындяйство. Потому этот список – не для умудренных сединами программистов разработчиков, а для тех, кто только начал, но все таки хочет работать с другими людьми. Хочет, чтобы его работа отвечала минимальным критериям качества. Хочет уважения от людей, которые немного в этом понимают и работают рядом.
Поскольку работаю в одном из 1 франчайзи, и опыт работы у меня связан прежде всего с конфигурациями славной фирмы 1С, потому эти много буков предназначены прежде всего стажеру одинеснику.

ОСНОВНАЯ ЧАСТЬ

Будет содержать в себе несколько списков.

ПЕРВЫЙ СПИСОК, без выполнения пунктов которого просто не подходи и не говори, что работа сделана.

Если ты подумал, что ты завершил писать код, сохранил все что наделал, и хочешь показать это кому-то (тестировщице, тете Маше с бухгалтерии), то перед этим будь добр – ПРОВЕРЬ. Что я понимаю под словом ПРОВЕРЬ? Посмотри на свой труд глазами тети Маши.
1. Если сделал документ – проверь, чтоб он ОТКРЫВАЛСЯ.
2. И ЗАКРЫВАЛСЯ (его можно было записать и/или провести).
3. Не поленись и заполни ОДИН документ. Простые действия по заполнению полей не должны попадать в категорию необрабатываемых событий (простыми словами - не должны ошибки появляться).
4. Если в документе есть табличная часть, то попытайся создать хотя бы одну строку. И заполнить её. И записать. И провести.
5. Посмотри в документации (или спроси у тети Маши), сколько ролей пользователей будет использовать этот документ. Узнай, что они будут с ним делать (создавать, редактировать или смотреть). Для всех тех ролей, которые будут создавать документ и повтори для каждой роли все пункты от 1 до 4 этого списка. С остальными ролями попробуй сделать все, что они должны иметь право делать (например, просмотреть).
6. Если создал отчет, то проверь, открывается ли он.
7. В справочнике нужно что? Правильно, создать элемент, заполнив все поля.
8. Если у тебя все получилось, то честь тебе и хвала. И тестировщику останется проверить логику работы, а не искать бракодела.
Читающий умник скажет, что это и так понятно всем. И будет не прав. Да есть толпа, кому не понятно. НАДОЕЛО. Толпа, исправляйтесь!

ВТОРОЙ СПИСОК, в котором есть перечень того, что пользователь ждет от системы, если он надеется что система будет дружелюбна к нему. Наивный пользователь конечно не догадывается про то, что система что то ДОЛЖНА, но мы то хотим, чтобы программа соответствовала каким то стандартам, была комфортна и т.д. и т.п. В принципе, всего этого можно не делать, объявив «что в ТЗ такого нету», но всем известно, чем отличается работа мастера от работы дилетанта. И куда стремиться надо. Так давайте прочтем и будем стремиться.

1. Первый и главный пункт. В системе должны быть использованы одни и те же методы и приемы при обработке одних и тех же событий в разных местах (формах различных метаданных). Если мы создаем новый документ, то нам (пользователям) привычно нажать определенную кнопочку. Не надо нам новый способ. Мы хотим, так как мы привыкли. Конечно, для того чтобы знать, как система обрабатывает разные события, нужно знать дорабатываемую конфигурацию. Надеюсь это не станет препятствием на пути к совершенству. В конце концов – можно спросить как делать. Остальные пункты списка будут только частными случаями этого пункта, а именно вопиющими случаями, которых лучше бы не было, но они были, есть и будут, а мне как вы помните, НАДОЕЛО.
2. Нельзя чтобы документы и элементы справочника удалялись непосредственно. Если только Ваш только что созданный документ можно удалить непосредственно, а все остальные документы конфигурации нельзя, то наверно в этом есть какой то скрытый смысл. Наверно такой что если тетя Маша с бухгалтерии случайно удалит локтем документ, а в этом документе учтено денег 100 тысяч и 50 строк в табличной части, то это будет не приятно. Так сделаем пользователю приятно и безопасно. Запретим непосредственное удаление, даже если права полные (права то полные, но люди с полными правами тоже люди, с локтями). В экономическом ПО, где учитывают ДЕНЬГИ, делать так, чтоб можно тихонько удалить что-то и никто не заметит – НЕЛЬЗЯ.
3. Если есть функция для табличной части, которая чистит эту самую табличную часть или перезаполняет, или массово заполняет какие то реквизиты, то перед тем как ЭТО сделать, надо бы спросить у пользователя, а надо ли ему чистить и не случайно ли он нажал куда ни будь, и что может очистить 50 строк его накладной.
4. Если есть функция, которая заполняет табличную часть (например, импорт откуда то), то надо бы подумать, может стоит предварительно очистить эту самую табличную часть.
5. Если для табличной части нужно считать итоги, то это не должно быть поле, куда нужно посчитать итог и ручками вбить. И такое было тоже. Вообще – не делайте мне забавно:)
6. Если создаете документ с различными статусами, стадиями обработки, то проверь, с каким статусом документ оказывается, если его скопировали.
7. Список будет расширяться и продолжаться. Обещаю.

ТРЕТИЙ СПИСОК, для продвинутых, для тех, кто можно сказать архитектор, кому поручили что-то сделать, но не разжевали как.
1. Если твой документ делает + или – в какой то регистр, узнай что это за регистр и какая логика у него. Постарайся не нарушить внутреннюю логику системы. Если ты со своим документом делаешь + то кто и почему делает – ? И может когда то должен быть ноль? В этом может быть скрыт важный смысл. ЗРИ В КОРЕНЬ, и попробуй понять, для чего работала толпа людей до тебя или прямо сейчас возле тебя.
2. Если ты проектируешь интерфейс, то постарайся не ставить отборы в табличных частях и не делать скрытыми реквизиты, из которых потом формируешь движения и проводки. Даже если ты уверен, что совершенно точно туда записываешь то, что надо. Все ошибаются, даже ты. А проверить тебя будет тяжело – спрятал все. А пользователь, он существо сомневающееся. Будет смотреть в документ, видеть, что там все как ему надо и счастливо проводить неизвестно что. Другой более ответственный пользователь увидит, что там в движении неизвестно что, но в документе то - нормально. Опять посмотрит в документ, и снова посмотрит движения. Скоро ему покажется, что он слишком много работает на этой безрадостной работе и что у него не все в порядке со зрением/головой. Но у него то все в порядке… Так что представь беднягу пользователя и будь осторожен со скрытыми реквизитами.
3. Попытайся использовать простые решения. Конечно, не всякая система проста. Бывают и действительно сложные решения, но если делаешь сложно, то это должно быть оправдано. Что я подразумеваю под СЛОЖНО?
• Большая гибкость в настройках (большая гибкость практически всегда обозначает большой бардак или большую работу по ограничению прав к доступу к настройкам и по работе над автоматизацией контроля над всеми кто гибко пользуется)
• Тысяча настроек, чтобы заполнить один документ
• Сложные формы для заполнения
• Узлы взаимосвязей не запроектированные как следует
• Еще получается сложно, когда толпа людей работает без общей идеи и направляющего документа. Вернее бардак получается. А бардак тяжело проверять, это я думаю и так понятно.
Статья получилась не очень длинной и не содержит исчерпывающего списка. Может, кому то еще накипело, буду благодарна за идеи.

Ну а тем, для кого предназначено сие письмо, могу сказать только одно: ДЕЛАЙ ТАК И ОТЧИЗНА БУДЕТ ТЕБЕ БЛАГОДАРНА.

См. также

Комментарии
1. Андрей (Свой) 165 11.09.08 23:56 Сейчас в теме
Автор, вы молодец, хорошую тему подняли, пишите еще
2. Андрей Скляров (coder1cv8) 3308 12.09.08 11:15 Сейчас в теме
Готов подписаться под всем списком! )
38. Василий Демидов (Душелов) 3812 15.09.08 12:59 Сейчас в теме
(2) а второй список пользователь должен писать.
3. VasilyKushnir (vasilykushnir) 12.09.08 11:27 Сейчас в теме
4. VasilyKushnir (vasilykushnir) 12.09.08 11:29 Сейчас в теме
Эх жаль, что нет чего-то типа книги знаний - с содержанием, с рубриками и с другими понтами. Через время эта статья затеряется в ворохе других. А жаль...
5. beigka (beigka) 216 12.09.08 11:43 Сейчас в теме
2VasilyKushnir обещаю продолжить, если людям понравится то что я написала. так что заходите на блог
6. Usc (Uscolegy) 12.09.08 15:34 Сейчас в теме
7. Михаил (mdzen) 237 12.09.08 17:23 Сейчас в теме
Все правильно. Молодец!
Особенно п.3.
Интересно 1С-овцы следуют этому принципу.
Судя по типовым конфигурациям - нет.
8. Евгений Мартыненков (JohnyDeath) 290 13.09.08 13:31 Сейчас в теме
Хорошо! Понравилось.
Когда читал про + и - регистров, вспомнил про конфигурацию, над которой мне приходится работать и которую мне поставляют "сверху" от франча. Так вот там есть один регистр НАКОПЛЕНИЯ, в который идут только движения "+". На мой вопрос "а какие документы делают расход по этому регистру? Может я их просто не заметил?" мне ответили: "никакие. Вы всё правильно подметили.". Далее я спрашиваю: " А почему тогда этот регистр не ОБОРОТНЫЙ?". Ответ: "Да, НАВЕРНОЕ, вы правы. Но это сейчас для нас не главное, и, ЕСЛИ буднт исправлено, то как минимум через гола полтора!"
Вот такие вот пироги... (а это конфигурация распространяется во все регионы России)
9. Саид Абушев (Абушев) 131 13.09.08 23:38 Сейчас в теме
Все правильно, есть в словах истина! За это плюс!
10. Олег (Punisher) 14.09.08 22:29 Сейчас в теме
Да. Повешу с офисе плакат с этим письмом. Самое обидное что сколько не тычь носом программеров в их код почему то не получается вдолбить все это в их голову.
П.С. Правда и гуру совершают тупые ошибки просто потому что слишком уверены в себе. И считают лишним проверить банальные операции (типа проверки документа на открытие или еще хуже не проверить на синтакс контроль)
11. Valentin57 (ValentinV) 15.09.08 01:50 Сейчас в теме
Про воробьев, бабочек и собак понятно.
Проверяете чужую работу - понятно.
Чем занимается тетя Маша - тоже ясно
А кем работаете, за что отвечаете?
Критиком что-ли.
12. Михаил (ILM) 232 15.09.08 09:11 Сейчас в теме
Распечатал, повесил плакат в офисе! Раздал копии разработчикам... Огромный респект автору...
13. Oygen (Oygen) 15.09.08 09:39 Сейчас в теме
Статья скорее ориентирована на безответственных программистов, нельзя всех грести под одну гребенку
14. beigka (beigka) 216 15.09.08 10:23 Сейчас в теме
2 Oygen да, статья орентирована на и безответственных. хочеться заранее предупредить людей что я считаю безответственностью и чтоб такого не было. не нравится что ругаю? ну что ж, не сахарные, не расстают.
2 Valentin57 отвечаю за проект. технический лидер, аналитик и тестировщик - пишу ТЗ, принимаю у программиста и сдаю работу заказчику. а вы кто и за что отвечаете?
15. Аркадий Кучер (Abadonna) 3687 15.09.08 10:37 Сейчас в теме
>статья орентирована на и безответственных.
А по мне - просто на придурков ;)
16. beigka (beigka) 216 15.09.08 10:47 Сейчас в теме
2 Abadonna искренне надеюсь что правильно люди поймут. если я нервничаю и объясняю, значит мне не все равно и я хочу научить.
17. Аркадий Кучер (Abadonna) 3687 15.09.08 10:52 Сейчас в теме
2 beigka Да я же не возражаю ;)
Просто мысли вслух :))))
18. Сергей Старовойтов (AVARY) 174 15.09.08 11:02 Сейчас в теме
2 beigka: Твоим разработчикам "Совершенный код" в зубы - все будет тип-топ!
19. Василий Демидов (Душелов) 3812 15.09.08 11:09 Сейчас в теме
Для студентов, которые только открыли первый раз конфигуратор.
20. Василий Демидов (Душелов) 3812 15.09.08 11:16 Сейчас в теме
Можно аналог написать - как свести с ума разработчика - про ТЗ, которые часто ставят перед ними. "Хочу, чтобы все!"
24. Сhe Burashka (CheBurator) 15.09.08 11:59 Сейчас в теме
(20) Такое уже есть - чтобы "хочу, чтобы все!" - см.http://www.infostart.ru/profile/174/projects/841/
(21) если буду писать "красиво" (я в принципе стараюсь не писать некрасиво) - с голоду помру...
21. Valentin57 (ValentinV) 15.09.08 11:41 Сейчас в теме
Проблема реально существует.
Но она - макроэкономическая.
Когда в целях быстрого развития страдает качество.
И 1с, головная, много делает глюков и нелепостей.
Но они выполняют свою КОНЦЕПЦИЮ РАЗВИТИЯ, а не создают сервис по конфорту для тети Маши.
Всем трудно. Но это и есть суть работы. А испытателям, спасателями т.д. - сам бог велел пострадать за Отчизну.
Есть такие профессии - Родину защищать.
------------------------------------------------------
Система "фрачайзи" предполагает, что все занимаются развитием и тестированием. Все участники одного дела.
При этом, либо ты вписываешься в процесс с осознанием дела и совершенствуешь,
либо являешься тормозом развития, и Отчизна не будет благодарна.
Так же есть ТО, ТЗ и экономическое обоснование проекта. Ну и конечно деньги и время на выпонение заказа.
То есть, оптимальность решения задачи - многокритериальна. Попросту - из многих зол выбирают меньшее.
И если стажер-программист будет изучать Ваши инструкции - он свихнется и дуба даст. Он же живой!!!
Как программисту работать - определяют непосредственные руководители.
А у Вас - назидания 5-летнему ребенку, который от Вашего воспитания скорее бестолковым станет.
------------------------------------------------------
По моим наблюдениям, качество 1с действительно падает. И мы все за это в ответе.
Мы все в ответе а решает - ЛПР, лицо принимающее решение, в 1с.
Ну сейчас так всем выгодно жить.
Но обсуждать надо профессионально и предметно.
А так... Ну жаль мне Вас, ну свечку в церви поставить можно.
А когда придет время - маятник сново качнется в сторону ГОСТ-ов.
22. Сергей (fsv_kanash) 15.09.08 11:58 Сейчас в теме
23. beigka (beigka) 216 15.09.08 11:59 Сейчас в теме
Valentin57 сейчас стажер слушает и делает, а через год или два сам будет проектировать системы. а если боится, что дуба даст, то пусть не программирует, а в менеджеры идет.
>Система "фрачайзи" предполагает, что все занимаются развитием и тестированием. Все участники одного дела.
я думаю, что наличие отдельного тестировщика на проекте - это отлично. только 1с никам нужно доказывать, что тестировщик нужен.
а вообще, я выложила свои требования к качеству. если с нуля проектировать, то должно быть хорошо. если у вас другое мнение и идеи как улучшить качество - с удовольствием предметные вещи б почитала. в статье я просила делиться идеями для пополнения списка, а пока не густо.
25. beigka (beigka) 216 15.09.08 12:00 Сейчас в теме
2 Душелов не все. а вот точно по пунктам хочу.
26. Сhe Burashka (CheBurator) 15.09.08 12:00 Сейчас в теме
потому что:
- непосредственно функциональный код занимает 10 строк, а обвеска защита от дурака - 40 строк.
27. Василий Демидов (Душелов) 3812 15.09.08 12:10 Сейчас в теме
Боян, конечно, но еще раз повторюсь - есть 3 пункта: время разработки, качество и цена.
Одновременно работают только 2. Любые. На ваш выбор. И все.
Чаще всего, заказчики выбирают - быстро (время) и дешево (цена), соответственно, качество падает.
Ну и т.д.
den_bat; KukA.5; +2 Ответить
29. Valentin57 (ValentinV) 15.09.08 12:25 Сейчас в теме
(27)На практике ранжируешь эти показатели.
На первом месте всегда время. Надо быстро.
Ну если по всем правилам - потом сопровождение.
И только потом спецификация и детализация устранение мелких и множественных шероховатостей,
которые (23)НЕ СОСТОВЛЯЮТ ТЕХНОЛОГИЧЕСКОЕ ЯДРО ПРОГРАММЫ.
Такова ЭВОЛЮЦИЯ развития.
А за Вашу бюрократию, волокиту и формализм - кто расплачиваться будет.
Тогда нужна нянка или психоаналитик.
28. beigka (beigka) 216 15.09.08 12:19 Сейчас в теме
2 Душелов как в анекдоте - быстро, дешево, качественно. выберайте 2!:) некоторые делают вообще только одно из 3х, так что 2 - это тоже гуд.
30. beigka (beigka) 216 15.09.08 12:33 Сейчас в теме
2 Valentin57 здоровое количество бюрократии - это порядок, планирование (работа стабильная и не сверхурочная), это хорошо регулируемый уровень качества, ну и возможность делать красивые приложения. но это ответственность перед командой. нянька не нужна. работаю я с мужчинами. психоаналитик - не знаю. иногда стоит обсудить что человеку мешало сделать как надо:)
32. Valentin57 (ValentinV) 15.09.08 12:41 Сейчас в теме
(30)ВСЕ РЕШАЕТ КОНЕЧНЫЙ ПОЛЬЗОВАТЕЛЬ!!!
И что красиво, и что хорошо. Заказчик всегда прав.
Так было и так будет. АМИНЬ;)))).
31. Valentin57 (ValentinV) 15.09.08 12:36 Сейчас в теме
(26 Сhe Burashka)Искренне поддерживаю.
Иногда такой интерфейс надо городить по просьбе юзера, что первичная цель забыта и похоронена.
И даже не оценена пользователем изюминка.
33. Valentin57 (ValentinV) 15.09.08 12:44 Сейчас в теме
Есть такая мудрость.
Если сделать программу, что и дураку будет понятно,
так только дурак и будет пользоваться.
34. beigka (beigka) 216 15.09.08 12:50 Сейчас в теме
неужели ни у кого нет идей чтоб добавить в список?
36. Василий Демидов (Душелов) 3812 15.09.08 12:52 Сейчас в теме
39. Valentin57 (ValentinV) 15.09.08 12:59 Сейчас в теме
(36) В СТУДИЮ МЕТОДОЛОГИЮ.
И ЭТО ОЧЕНЬ вразумительно.
"Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming) "
41. Василий Демидов (Душелов) 3812 15.09.08 13:00 Сейчас в теме
(39) Там ссылочки есть :)

Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или ее фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют ее разработкой. Является одной из основных практик экстремального программирования.

Разработка в стиле TDD состоит из коротких циклов (длительностью от 2 минут, в зависимости от опытности и стиля работы программиста). Каждый цикл состоит из следующих шагов:
Из репозитория извлекается программная система, находящаяся в согласованном состоянии, когда весь набор модульных тестов выполняется успешно.
Добавляется новый тест. Он может состоять в проверке, реализует ли система некоторое новое поведение или содержит ли некоторую ошибку, о которой недавно стало известно.
Успешно выполняется весь набор тестов, кроме нового теста, который выполняется неуспешно. Этот шаг необходим для проверки самого теста -- включен ли он в общую систему тестирования и правильно ли отражает новое требование к системе, которому она, естественно, еще не удовлетворяет.
Программа изменяется с тем, чтобы как можно скорее выполнялись все тесты. Нужно добавить самое простое решение, удовлетворяющее новому тесту, и одновременно с этим не испортить существующие тесты. Большая часть нежелательных побочных и отдаленных эффектов от вносимых в программу изменений отслеживается именно на этом этапе, с помощью достаточно полного набора тестов.
Весь набор тестов выполняется успешно.
Теперь, когда требуемая в этом цикле функциональность достигнута самым простым способом, программа перестраивается (см. рефакторинг) для улучшения структуры и устранения избыточного, дублированного кода.
Весь набор тестов выполняется успешно.
Комплект изменений, сделанных в этом цикле в тестах и программе заносится в репозиторий (операция commit), после чего программа снова находится в согласованном состоянии и содержит четко осязаемое улучшение по сравнению с предыдущим состоянием.

Этот цикл упрощенно описывается Кентом Беком в своей книге как "красный-зеленый-рефакторинг". Красный и зеленый - это цвета полоски в среде тестирования JUnit, которая показывает, все тесты сработали или нет. При этом на первом ("красном") этапе необходимо добиться того, чтобы программа просто компилировалась, без срабатывания добавленного теста.
35. beigka (beigka) 216 15.09.08 12:51 Сейчас в теме
Valentin57 Если сделать программу, что и дураку будет понятно то она будет называться программой с интуитивно понятным интерфейсом. и с УПП дураку тяжело будет...
43. Valentin57 (ValentinV) 15.09.08 13:10 Сейчас в теме
(35)Ну опять Вам трудно, тяжело, душевное потрясение.
Психологи отмечают бурный рост иждивенческого и потребительского подхода.
Отсутствие склонности к созидательному труду.
Учиться, учиться и учиться.
37. beigka (beigka) 216 15.09.08 12:57 Сейчас в теме
2 Душелов второй бы список расширить
40. Василий Демидов (Душелов) 3812 15.09.08 12:59 Сейчас в теме
77. vkr (vkr) 101 23.09.08 15:03 Сейчас в теме
Уважаемые коллеги beigka, Valentin57, Душелов и все-все-все... :)

Возьму на себя смелость посоветовать прочесть совершенно шикарную книгу :

Фредерик П. Брукс - Мифический человеко-месяц или как создаются программные системы.

Прочел в свое время первое издание - СУПЕР !!!
Для развития (само)дисциплины программирования очень помогает...
Например, вот отсюда:
http://lib.ru/CTOTOR/BRUKS/mithsoftware.txt

З.Ы. (37) Законы Мэрфи сегодня актуальны, как никогда !!! :)
42. Василий Демидов (Душелов) 3812 15.09.08 13:03 Сейчас в теме
А еще лучше скачайте и почитайте книгу Кента Бека "Экстремальное программирование": http://bookz.ru/authors/kent-bek/ekstrema_365.html
44. Valentin57 (ValentinV) 15.09.08 13:33 Сейчас в теме
Иногда сам в шоке пребываю.
Уровень развития такой, что программа становится протезом интеллекта для пользователей.
Стало трудно найти бухгалтера, чтобы он знал бухгалтерию.
К тому же тенденция к отчуждению и самоизоляции.
А многие даже хотят, чтобы программист читал мысли и желания, жил в их мозгу, заменял им мозг
и был бы одновременно их мозгом и "козлом отпущения".
45. Василий Демидов (Душелов) 3812 15.09.08 13:36 Сейчас в теме
Это все просто идет к уменьшению финансирования на работников (операторов), чем ниже интеллект, тем ниже зарплата, потому и требуют от разработчиков писать такой софт, с котором и обезбяна бы могла работать.
47. Valentin57 (ValentinV) 15.09.08 13:41 Сейчас в теме
(45) Но стаким софтом короткий анекдот -"Обезьяна с гранатой".
Вот и вылизываешь кнопочки, картинки.
Не дай бог не туда или не так нажмет и прога не спасет от беды дитятку.
46. beigka (beigka) 216 15.09.08 13:41 Сейчас в теме
2 Душелов я тут не спрашиваю как процесс организовывать. я спрашиваю про то, на что стоит обратить внимание начинающего программиста, контрольные моменты, где нужно было б чтоб четко работало. и желательно именно для 1с ника пишущего экономического ПО.
2 Valentin57 мне не трудно. я как раз и занимаюсь созидательным трудом. учу стажеров, статьи пишу, проекты идут. а клиента и пользователя созидательному труду учить не хочу.
48. Василий Демидов (Душелов) 3812 15.09.08 13:46 Сейчас в теме
(46) начинающему программисту лучше сначала конфигурации пообновлять, отчетики пописать для магазинов и небольших фирм, а не лезть в разработку экономического ПО :)
Экономит ваша фирма на спецах, раз стажеров на такие проекты берете, которые пишут так, как приведено в статье.
50. beigka (beigka) 216 15.09.08 13:54 Сейчас в теме
(48) Душелов не экономит а учит.
ладно, безпредметный разговор. скучно.
55. Василий Демидов (Душелов) 3812 15.09.08 14:19 Сейчас в теме
(50) Согласен. Скучно. Зато компания экономит деньги на спецах :)
Да и попробуйте http://ru.wikipedia.org/wiki/Парное_программирование, спеца и стажера посадить рядом.
57. beigka (beigka) 216 15.09.08 14:37 Сейчас в теме
(55) 2 Душелов. ну вы право, как в старом и не актуальном анекдоте. у иженера в ссср маленькая зарплата. а в америке негров не любят.
я не спрашиваю, кого мне возле стажера садить. и вообще, брать ли стажера на проект. и какой уровень должен быть у стажеров чтоб с ним можно было работать.
58. beigka (beigka) 216 15.09.08 14:39 Сейчас в теме
(57) Valentin57 парное программирование я со своими сотрудниками обсуждала.:) они гришковца вспоминают. как палубу мыть вдвоем - один моет а другой волнуется:)
59. Valentin57 (ValentinV) 15.09.08 14:49 Сейчас в теме
(58)Нахожу тоже полезным.
Помните, "Котенок по имени гав". На крыше вдвоем боялись.:))))
Ну может еще не время, а может не появился этот "новатор", не вызрела пока достойная уважения личность,
способная понимать и тех и других и управлять ситуацией.
62. Василий Демидов (Душелов) 3812 15.09.08 15:12 Сейчас в теме
(58) обсудите экстремальное программирование :)
60. Василий Демидов (Душелов) 3812 15.09.08 15:05 Сейчас в теме
(57) а что спрашиваете? хотите идей - я вам предлагаю.
56. Valentin57 (ValentinV) 15.09.08 14:33 Сейчас в теме
(50) Скучно?!
Душа хотела социальной мясорубки с песнями и танцами?
"Какой хороший день, какой хороший пень, какой хороший я и песенка моя".
А оказалось и здесь надо трудиться (от слова трудно).
А про парное программирование - так как раз и надо УЧИТЬ И ПРИУЧАТЬ. Ведь что посеешь ...
49. Valentin57 (ValentinV) 15.09.08 13:52 Сейчас в теме
Уровень развития 8.0 и 8.1, что кроме диплома, надо 1-2 года юзером побыть,
да в подмастерьях побывать.
Бывает лучше чтоб интерфейс загнулся у юзера, чем он все данные загробил.
vasilykushnir; +1 Ответить
52. VasilyKushnir (vasilykushnir) 15.09.08 14:02 Сейчас в теме
(49) >Бывает лучше чтоб интерфейс загнулся у юзера, чем он все данные загробил.

За эти слова готов +5 баллов поставить.
51. Valentin57 (ValentinV) 15.09.08 13:59 Сейчас в теме
Вот такое "парное катание".
53. Valentin57 (ValentinV) 15.09.08 14:06 Сейчас в теме
На практике приходиться иногда инсценировать глюк, чтобы думали.
54. Valentin57 (ValentinV) 15.09.08 14:09 Сейчас в теме
А был случай имитации аварийного завершения, по причине не перепроведения документов.
61. Valentin57 (ValentinV) 15.09.08 15:11 Сейчас в теме
Не хочет.
Низы все время не хотят, верхи всегда могут.:)))
63. Valentin57 (ValentinV) 15.09.08 15:22 Сейчас в теме
Не ужели и этот караван не пойдет быстрей из-за самого медленного верблюда.;)
64. Maljaev (maljaev) 15.09.08 23:43 Сейчас в теме
Бабочек жалко... :(
h00k; NastyMN; ILM; +3 Ответить
65. Аркадий Кучер (Abadonna) 3687 17.09.08 14:45 Сейчас в теме
Есть хороший способ проверить работоспособность программы. Если программа не упала под Чебурашкой - значит не упадет никогда :)))
Проверено ;)
66. map5 (MAP5) 18.09.08 10:31 Сейчас в теме
А зачем тогда тестировщик? Постановку задачи делает руководитель проекта. Или у тестировщика ума больше чем у руководителя, забавно- садись и пиши, а то на разрабртке умных людей меньше и меньше. (кто не умеет сам- тот учит, кто не умеет учить - тот руководит), а вообще все укладывается в 2 понятия, так можно делать, а так нельзя. Отделить можно от нельзя очень сложно, и тем кто это умеет платят большую зарплату.
67. beigka (beigka) 216 18.09.08 11:54 Сейчас в теме
2 map5 про то зачем нужен тестировщик в какой то другой статье написано...
68. artmicro (artmicro) 19.09.08 18:04 Сейчас в теме
Здравствуйте beigka. Ваша статья довольно интересная, но у меня к ней есть ряд замечий. Во-первых, название ".... о стандартах разработки ПО"... Честно говоря не встретил у Вас в статье ни единого слова о настоящих стандартах, вся статья построена только на Ваших эмоциях - это разочаровало. Мне кажется, что перед началом написания статьи Вам следовало заглянуть в стандарты ;) например SWEBOK, IEEE 830, ну или хотя бы в ГОСТ. (мысли о Гостах уже упоминали в комментариях). Во-вторых, Вы пишете о качестве, но у меня сложилось впечатление, что сами точно не представляете что это такое. Хотелось бы узнать что такое качество в Вашем понимании? В третьих, я с Вами не согласен в том что, программист должен думать комплексно, желательно конечно, но это не есть недостатком. Например Ваш пример с регистром... Представим что я конечный программист который реализует функционал документа что пишет регистр в "+". Скажи пожалуйста, зачем мне узнавать кто и как будет писать его в "-". Эту работу еще на этапе анализа должен проделать архитектор, который планирует систему и потом пишет ТЗ, программист как конечный исполнитель не обязан знать что происходит там дальше... Еще так же не согласен, о том что разработчик должен общаться с пользователями и узнавать как и что у них работает. Для этого есть аналитики которые собирают начальные требования и описывают бизнес-процесс при старте проекта на этапе детального обследования. Ваши мысли (хотя статья очень эмоциональная, так что скорее эмоции) не совсем соотносимы с реальностью, с нормальным проектным подходом к работе. Кстати, вопрос о четкой постановки задачи разработчику тема для отдельной статьи ... кстати было бы интересно прочитать ее от Вас. Так как Вы упоминали, что занимаетесь обучением, интересно узнать, Вы говорите своим ученикам, что бы они отказывались работать при не четкой постановке задачи или отсутствии ТЗ?... Жду Ваших мыслей... А вообщем, так как это Ваша первая статья, то довольно не плохо :)
75. beigka (beigka) 216 21.09.08 17:35 Сейчас в теме
2 artmicro (68) вам тоже не болеть.
это статья действительно не о настоящих стандартах. эта статья подписана мною, потому это статья о моих стандартах. и она не о обеспечении качества как процессе, а о некоторых параметрах работы прогрраммиста.
вам не нравится - у меня слишком высокие требования? ну, команда сильна своими игроками. я хочу сильной игры, а для этого нужен какой то начальный уровень. хочется делать красивые и сложные программы.
мое мнение о четкой постановке задачи... мне бы тоже было интересно почитать статью о постановке задач от 1Сника.
69. Valentin57 (ValentinV) 20.09.08 12:49 Сейчас в теме
Например, такой пример.
Написал отчет по многофирменному учету (УТ 8 ). Отчет очень сложный, здесь таких не видал.
Учет без головного контрагента, продажи внутри базы по вертикали и по горизотали.
В одной базе 17 фирм, список номенклатуры - 32 000, все виды деятельности.
Регистры вставлять для зеркальных документов поздно. База работает 3,5 года, размер - 5 Гб.
Море пользователей!!!
Анализ - требует участия опытных и знающих пользователей.
И кодинг и планирование анализа работы отчета - ПОГЛОТИЛО.
ПОБОЧНЫЙ РЕЗУЛЬТАТ - У НЕКОТОРЫХ ПОЛЬЗОВАТЕЛЕЙ НЕ ОТКРЫВАЕТСЯ, У ДРУГИХ ВИСНЕТ ПРИ ИСПОЛНЕНИИ.
Причина - права доступа пользователей (вылетело из головы).
Хорошо пользователи опытные и поняли, что это мелочь, это не суть, неизбежное упущение. Не это, так другое при заданном времени.
------------------------------------------------
ЖАЛЬ НЕ БЫЛО ТОЛКОВОГО ТЕСТЕРА !!!
ЕСЛИ НАЙДЕТСЯ - ПИШИТЕ t3731081@ya.ru, отнесусь с уважением.

70. Valentin57 (ValentinV) 20.09.08 15:10 Сейчас в теме
О стандартах. Личное наблюдение.
Отсутствие жестких стандартов - дает свободу творчеству для всех, возможность креативных решений.
Правда требует от людей более прочных связей в отношениях, гибкого и глубокого взимопонимания.
На деле же - люди отдаляются. Но слава богу не всегда.
Тем более ценен человечный человек.
Стандарт же дает гарантии, надежность, но замедляет развитие.
В системе общества все эти моменты всегда цикличны, и колеблются возле золотой середины.
И сама природа так действует в поисках лучшего, отсекая самые крайние формы.

71. artmicro (artmicro) 21.09.08 12:37 Сейчас в теме
to Valentin57. О стандартах. На самом деле все зависит от руководителя, всегда можно найти компромиссное решение, между стандартизированным подходом и местом для самореализации конечного разработчика. Как вариант, можно требовать придерживания стандартов при реализации особенно сложным задач, там где гарантировано нужно получить качественный результат и в срок, кроме того это не означает слепое следования стандарту, конечно возможен и приветствуется отклонение, применение новых подходов, но стандарты облегчат поддержку и подальшее развитие этой задачи. Но для этого при оценке задачи необходимо давать время на реализацию с коэффициентом хотя бы 1,5, для того что бы разработчик не боясь мог потратить некоторое время на осмысление задачи и возможно поиск более оптимального решения чем уже существует. А на счет того что стандарт замедляет развитие - не согласен. Главное не принимать все строго и четко как написано. Стандарт можно использовать как вектор направления с каким то допустимым отклонением и тогда не будет ущемления работников для развития, главное понимать, что нет ничего абсолютно правильного, так же как и нет ничего абсолютно не верного :) везде есть чему по учится и от чего отклонится :)
72. Valentin57 (ValentinV) 21.09.08 13:45 Сейчас в теме
(71)На самом деле вопрос философско-методологический.
1. Компримиссное решение - для кого, для чего ?
___Для хозяина - оптимум - ПРИБЫЛЬ ЗА ПЕРИОД. А потом хоть потоп, хоть гибель всего человечества.
___Для разработчиков - оптимум - часто, больше з/п, меньше работы.
На деле компромисс определяют руководители по приоритетам хозяина.
Остальные, не зная главных целей, занимаются пересудами и душещипательствами, выбивая у начальства,
каждый для себя выгодное положение в системе организации.
2. Стандарты.
Согласно продвинутым воззрениям, все в природе циклично.
Иначе, подчиняется сеобщим законам развития, законам диалектики.
Простая и наглядная модель - маятник, круг, цикл. В математике - два периода.
Проще, эволюционный (медленные) период накопления перспективных изменений и медленное угасание устаревших.
В этом периоде способны только самые сильные вживлять новое, которому сопротивляются - почти ВСЕ.
В следующем, революционном и быстром новое вытесняет старое.
Как раз в этот момент и нужны стандарты.
Но какой стандарт лучше - объективная истина понятная единицам и только им.
Остальные догоняют постепенно, с опозданием осознают, а некоторые (на деле оказывается большинство) - НИКОГДА.
Всегда же существует вопрос критерия качества стандарта - (1) Для кого и для чего, его субъективность.
И связь с глобальными процессами, историческими по масштабам.
Для сплоченного коллектива, если они на перспективном пути развития стандарты не нужны. Они у них в привычках, в сформированной нравственности.
Для такого коллектива нужен психологический климат и материальные условия.
В этот момент люди сами на себя берут управленческие функции, их самосознание находится на самом высоком уровне.
Введение же бюрократии - создаст напряженность и повысит конфликтность в коллективе и некоторым единицам это выгодно.
Главным же стержнем сплачивающем людей в данный период - система общечеловеческих ценностей.
Именно она выступают стабилизирующим фактором.
Но приходит время ... и опять, одни создают стандарты. От детских и бредовых до фантастических и грандиозных.
Другие обсуждают их и постепенно начиннают сплачиваться вокруг наиболее перспективных,
которые проверят практика экономическими, математическими и друми методами оценивания.
И так МАЯТНИК КАЧАЕТСЯ ВЕЧНО.
73. Valentin57 (ValentinV) 21.09.08 14:54 Сейчас в теме
(71) Еще добавлю.
К чему привела деятельность людей в области создания СТАНДАРТА пород... например, пород собак ( у людей же породы нет :)).
С одной стороны и есть красивые и сильные и выносливые и быстрые и...
С другой, болезненные, маложивущие, зависимые и от людей и от окружающей природы.
Многие на воле просто вымрут.
Вот и пример субъективности подхода и отсудствия абсолютной истины.
74. beigka (beigka) 216 21.09.08 17:23 Сейчас в теме
2 Valentin57 (73, 72, 70, 69, 61, 59, 56, 54, 53, 51, 49, 47, 44, 43, 39, 33, 32, 31, 29, 21, 11) спасибо за коментарии и то что вы так болеете за эту тему.
76. Valentin57 (ValentinV) 21.09.08 19:49 Сейчас в теме
Извините, увлеклись, про автора забыли.
78. beigka (beigka) 216 24.09.08 12:17 Сейчас в теме
2 vkr читали, читаем и будем читать. законы мерфи не люблю. вообще не люблю читать об отрицательном опыте. интересуюсь прежде всего положительным.
79. Малышко В.Н. (molot) 277 09.05.09 00:08 Сейчас в теме
Вы там с идиотами работаете, или в студсовете... Жаль Вас искренне...
80. beigka (beigka) 216 09.05.09 08:28 Сейчас в теме
2 molot. а вы один работаете? у каждого своя беда.
первую статью прочитали - не понравилась. вторую вот...
спасибо за мнение.
81. Lubov Filippova (laf) 07.11.14 03:09 Сейчас в теме
Завидую тем, кто работает в большом коллективе с постановщиками, программистами, отладчиками и пр.
У нас же решили, что и программисты уже не нужны. Посокращали всех. На аутсорсинг думают переходить. Результат аудиторской проверки вышестоящей организации. Да и раньше никаких постановщиков не было, программист во всем сам разбирался, безо всяких ТЗ, "с колес". Думаю, что только в Гос.компаниях остались в штате и постановщики, и программисты, и тестировщики. Кризис?
Оставьте свое сообщение