ShovgenyukКлиент достал своими претензиями что ИС слишком сложная. Кроме общих фраз почти ничего конкретного не говорит.
Клиент имеет право быть полным идиотом. Ты - профессионал, твоя задача - обслужить его так, чтобы тот остался доволен.

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

apapacy1) Контролировать уникальность номеров документа
- в течение года
Я бы отметил, что "текущий год" и "в течение года" - разные вещи. В формулировках стоит избегать подобных неоднозначностей.

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

Фраза же - из серии "что вижу, то пою". Я не очень удивлюсь, если окажется, что код и вправду бежит по всем документам, делая что-нибудь типа if (не в текущем году) continue;

ShovgenyukКстати, как контролировать качество кода если над проектом работает несколько человек? Неужели все время перечитывать и разбирать весь их код?
Есть много ответов и вариантов ответов. Лично я выделил бы следующее:

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

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

2. В проекте не должно быть "собственного" кода. Любой исходник проекта - subject of view & change для любого члена команды. Нужно всячески стимулировать и поощрять знакомство программистов с кодом друг друга - начиная от сквозной отладки, путешествия отладчиком сквозь чужой код для отлова своих ошибок - и вплоть до нарочитой выдачи заданий на модификацию чужих модулей. Тогда получится и эффективный перекрестный контроль качества. Любопытный, хотя и спорный вариант - ввести практику директивного рефакторинга чужого кода.

3. Код "ненадежных" членов команды надо таки смотреть. Регулярно, выделяя на это время. Желательно - как можно быстрее после его написания/изменения. Лично я для этого пользовался возможностями VCS - делая check out изменений себе на машину, просматривал сделанные изменения. Если знаешь, что человек пишет хорошо - соответственно, плотный контроль не нужен, хотя поглядывать все равно стоит. Уже по более тонким соображениям (бывает, что человек что-то не знал, что-то неудачно придумал, наоборот, придумал что-то такое, что следовало бы запомнить и использовать, да и вообще, стоит быть в курсе "как дышит проект"...)

ShovgenyukТолько етот клиент особенный, он деньги не платит и за ето он "подопытный кролик" для фирмы. На нем все тестируется, так как отдел тестирования не справляется )
Тем более. Итак, ваш тестер говорит, что у него проблемы с вашим софтом.
Ваша реакция: да он нас достал.

Красиво :)