Поместила эту тему сюда, потому что нет общего раздела по программированию, в котором можно было бы создавать темы.
Опрос адресован разработчикам на любых языках.

Это сообщение отредактировал(а) ida - 24.1.2009, 14:16

Вот последнее время актуально. Соответственно переписывать приходится. 

Мдя... Никогда не задумывался над всеми проблемами сразу. Вот, задумался. Ужаснулся. Вот что ощутил...
         

и приходится копать в ширь а не в глубь а отсюда уже все остальные проблемы  

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

не было б этих проблем, то программисты перестали бы быть нужны.
нужны были б тупые кодеры, которые кодировали только то, что описано в подробных и неизменных ТЗ (проблемы №1 и №2)
и кодерам этим не приходилось бы бороться с копипастом (проблема №3), создавать флексибильный и гибкий дизайн, чтоб его легко можно было поменять (проблема №4).
и само собой, зная среднюю скорость кодирования кодера и обьем работ (ибо ТЗ есть), не было б проблемы №5 (время бы считалось по формуле "время = обьем работ / скорость кодирования")

а проблема №6 всегда существовала и будет существовать. для ее решения придуман прием XP "Заказчик всегда рядом", но кто ж его использует?

 Правило: не браться за заказы без ТЗ.
А написание ТЗ делаю отдельно, после него только и пишу.

 Так за это и платят дополнительно. Было такое несколько раз, ничего страшного, всегда вознаграждалось доп. суммами.

 Это то же, что и отсутствие ТЗ. Т.е. изначально надо просчитывать и думать, браться или нет.

 ТЗ есть? Совпадает? Остались вопросы?
Плюс предоплата как перестраховка.


 А вот эта проблема - всем проблемам проблема (

Вообще есть еще такая проблема, например в ТЗ может быть 2 фичи: мегакрутая фича А и никому не нужная фича Б, при этом из-за фичи Б проект становится значительно сложнее и дороже, но для менеджера проекта она по каким-то причинам может быть важна, но оценить сложность ее(фичи Б) реализации он не в состоянии.
В общем оценка сложности и объема работ проекта невозможна до того как он будет сделан  

Lazin, вот это кстати я забыла.
Что оценка трудоемкости перед началом разработки не проводится, или проводится на глаз, или проводится людьми, которые сами не разработчики.


Только она является прямым следствием всех предыдущих 


мы не жалуемся, мы ищем решения.

программисты как раз не для этого нужны... а для того, чтобы писать компактный, эффективный, гибкий, понятный, тестируемый код... и обрекать их на решение перечисленных проблем ИМХО означает забивать гвозди микроскопом.

Это сообщение отредактировал(а) ida - 24.1.2009, 16:53

вспоминается цитата с bash.org.ru: самое трудное в работе с компьютерами - работа с людьми

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

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

Это сообщение отредактировал(а) maxim1000 - 25.1.2009, 00:25

Аналогично. Но последние два года у меня возникает тоже чувство при просмотре собственнного кода  давностью более 4-6 месяцев. Правда к счастью в последние время только в "красоте реализации", года 1,5-2 назад еще пытался все все реализовать сам, без поиска уже готовых решений, отсюда и проблема:



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

 Нет, это просто я такой разгвоздяй)

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

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

Это сообщение отредактировал(а) ida - 25.1.2009, 19:22

каюсь, неправильно подобрал цитату
она (возможно, неявно) претендует на обобщение вроде "любая работа с людьми - самое трудное"

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

а рано или поздно его приходится чинить, потому что чем больше его используешь, тем больше он тормозит твою работу

Согласна.
Но это уже политическая проблема, ее быстро не решишь.

что самое интересное - 60% от отводимого времени пипл активно косит, оставшиеся 40 (как правило под конец)  активно работает - то бишь косячит. Менагер который за этим должен следить - вертится у всех на детородном органе против часовой стрелки, ибо разгильдяйство процветает. 

mrbrooks, ты об этом?

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

гы. что-то типа этого. 

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

Фигня какая-то. Этот малограмотный в вакууме что ли работает?  В маленьких фирмах как раз я соглашусь, что такое возможно. Сидел человек ад разработкой, развитием и поддержкой своего проекта годами. Ушел и выясняется, что код - сплошая "лапша", изменения  вносились методом "заплаток"  итд. 
В больших фирмах  над проектом обычно работает команда,в которую  входят несколько программистов. Что же все они малограмотные?  Или тим лид стесняется своего подчиненного подправить? Кроме того в нормальных фирмах в процессе работы над проектом сделанный код обычно отдают на ревью другой команде. И ревью делается не от балды, а в соответствии с документом по конкретному языку, где описаны  возможные ошибки с указаниям их рейтинга.  

зависит от методики работы, если в команде каждый работает над своей частью и code review проводить не принять, то всякое может быть =)

Vyacheslav, тебе видимо всегда везло, я видел полную противоположность. При обязательности ревью код просто ужасен,  и еле держится.

все перечисленные, кроме :

и

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

Это сообщение отредактировал(а) Torsten - 26.1.2009, 13:58

ага, и зависнуть на полгода, предугадывая все моменты которые могут поменяться в будущем =)

Добавлено через 4 минуты и 9 секунд
как правило у любого кода есть ограничения, они накладываются сроками и возможностями, какую-то одну вещь бывает иногда дороже сделать чем весь остальной проект целиком. 

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

Требования:
- умение предугадывать, что и где в коде может потребоваться изменить после его написания

Мне интересно, что вам будут отвечать 

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

Довелось мне работать с одним предугадывателем... после того, как его уволили, одному из наших лучших разработчиков пришлось переписывать ВЕСЬ функционал, написанный этим телепатом.

Давайте вспомним процесс разработки ПО для тех, кто его не помнит из институтского курса.

При любой модели жизненного цикла ПО у нас должны быть следующие процессы:
1. Анализ
2. Проектирование
3. Кодирование
4. Тестирование

Причем качество двух последних зависит от первых двух на от 50 до 80% (смотря насколько грамотные специалисты работают на всех участках - частично плохой процесс может спасти хороший специалист, но никогда не полностью).

Компании от 100 человек, производящие ПО, ВСЕГДА имеют штатных специалистов, которые занимаются первыми двумя.
Компании от 30 до 100 (в среднем), в зависимости от их зрелости и от того, с какими заказчиками они работают, иногда имеют штатных аналитиков, иногда их функции выполняют другие специалисты. Причем варианты совмещения с разработкой - это худшие варианты.
В мелких компаниях (под 30 понимаются только те, кто занят в индустрии ПО, а не работает к примеру на большом заводе, где 3 человека пишут софт) аналитиков нет никогда. А постановки задачи это не отменяет. Потому что прежде чем писать код, надо понять, что этот код должен делать.
Вот так и лечат зубы через анус.

Это сообщение отредактировал(а) ida - 26.1.2009, 17:21

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

отучит народ использовть глобальные переменные?  

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