stikriz писал(а):Над чем Вы будете думать, если заказчик не совсем понимает что ему нужно? Как результат - все, что Вы писали в первой итерации- сплошная бага. А потом переделывание.
Это ключевой момент. Но все решаемо, только вначале нужно думать, а потом кодить. Первоначально нужно в целом понять, что за заказчик, какова его квалификация и т.п. Второе, от заказчика нужно получать требования только в той терминалогии, в которой компетентен заказчик. То есть ТЗ, про которые обычно все говорят, лучше вообще не требовать от заказчика, т.к. он его не может написать. ТЗ должно быть не программно, а проблемно ориентированным. Например, ТЗ от торговой фирмы может быть таким: уменьшить пересортицу, уменьшить складские запасы неликвидных товаров и все. Не нужно никаких рассуждений заказчика про БД, формы, документы и прочее. Дальше, прежде чем запускать среду программирования, нужно глубоко понять, что и как происходит у заказчика и т.п. Естественно, что такой подход требует специализации, один человек обычно не может автоматизировать и нефте-химию и торговлю. Я бы сказал больше, что программировать не будучи специалистом в предметной области - это банально глупо. Как минимум не сможешь заработать нормальных денег, и будешь всю жизнь нищим так, что даже на лицензию не хватит. Практикуя проблемно-ориентированный подход можно зарабатывать раз в 5-10 больше, чем обычно. Об этом не часто пишут, но тут все просто, на этом зарабатывают крупные компании, которые разделяют специалистов в предметной области и программеров, экономя на зарплате каждого.
Добавлено спустя 19 минут 9 секунд:stikriz писал(а):И еще, в больших командах есть возможность выделить способного человека, который ищет баги - это большая удача иметь такого/таких специалиста/ов. И есть люди-генераторы Кодят, кодят, кодят... А потом половину кода в мусорку, а вторую половину на оптимизацию, зато оставшаяся часть после оптимизации - на вес золота, потому, что у них есть абстрактное мышление, творческая жилка, могут видеть всю систему целиком, но нет женской натуры делать все абсолютно аккуратно.
Беда софта в том, что большинство изначально не ценит код, считая, что бесплатно можно все переписать заново, итог имеем говнокод. А Вы попробуйте практиковать подходы из харда. Представте для самого себя, что за одну опечатку (исправление одной строки) нужно заплатить 10 т.р. Зарплата 100 т.р., сделал 10 ошибок в месяц, и получил 0, сделал 100 ошибок, продал квартиру и стал бомжом. Я и по своему опыту, и по реальному опыту многих людей знаю, что как только люди начинают считать исправление великим грехом (мотивы будут разные), то количество багов без всяких тестеров падает на несколько порядков, а скорость разработки вырастает в разы. Я практикую для себя, что на 1000 строк кода можно допускать не более 2-3 ошибок, а желательно их вообще не делать. И это же реально удается. Если пишешь код в хорошем настроении, когда нет отвлекающих факторов, то обычно пишешь так, что вообще нет ни одной ошибки.
Другое дело, есть исследовательская сфера. И тут не нужно совмещать промышленное программирование и исследования. Есть непонятная тема - пробуй, тут может быть и баг на баге. Точно также, когда непонятно что-то в задаче, делайте прототипы, только изначально понимайте, что прототип и промышленное ПО - это разные вещи. Например, пока нет 100% ясности с постановкой задачи, то не нужно даже думать об иерархии классов, все равно не угадаешь. Поэтому делая прототип и не нужно замарачиваться со структурой, нужно делать прообраз некого функционала. А на практике видим что, немного обсудили задачу (понимание не более 50%), а самые "шустрые" уже бегут и строчат структуру классов, на эйфории новой задачи они в миг набивают несколько тысяч строк кода. Естественно, что все оказывается не так, но им уже код жалко, они пытаются его приспособить, вот и получаем баг на баге.
Впрочем, которого ноги кормят. Хотя...наверное именно ввиду отсутствия индустрии, у нас индививидуалы вынуждены волчком крутиться, портить себе нервы, заниматься несвойвенными профессии коммрческими [жлобскими] вопросами 
