Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > проблемы разработчиков

Автор: ida 24.1.2009, 14:14

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

Автор: W4FhLF 24.1.2009, 14:26

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

Автор: andrew_121 24.1.2009, 14:34

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

Автор: Lazin 24.1.2009, 14:42

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

Автор: Alek86 24.1.2009, 14:59

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

Автор: nerezus 24.1.2009, 15:31

Цитата  нет технического задания, задача описана только на словах  Правило: не браться за заказы без ТЗ. А написание ТЗ делаю отдельно, после него только и пишу. Цитата Вот последнее время актуально. Соответственно переписывать приходится.   Так за это и платят дополнительно. Было такое несколько раз, ничего страшного, всегда вознаграждалось доп. суммами. Цитата двусмысленность или нечеткость задачи, при кодировании приходится делать предположения  Это то же, что и отсутствие ТЗ. Т.е. изначально надо просчитывать и думать, браться или нет. Цитата получив продукт, заказчики говорят, что это не то, что им нужно  ТЗ есть? Совпадает? Остались вопросы? Плюс предоплата как перестраховка. Цитата в запланированные сроки не удается реализовать то, что требуется  А вот эта проблема - всем проблемам проблема (

Автор: Lazin 24.1.2009, 15:59

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

Автор: ida 24.1.2009, 16:48

Lazin, вот это кстати я забыла. Что оценка трудоемкости перед началом разработки не проводится, или проводится на глаз, или проводится людьми, которые сами не разработчики. Цитата(nerezus @ 24.1.2009,  16:31) Цитата в запланированные сроки не удается реализовать то, что требуется  А вот эта проблема - всем проблемам проблема ( Только она является прямым следствием всех предыдущих  Цитата(Alek86 @ 24.1.2009,  15:59) программисты, в основном, и нужны для того, чтобы справляться с этими "проблемами". зачем тогда на них жаловаться? мы не жалуемся, мы ищем решения. программисты как раз не для этого нужны... а для того, чтобы писать компактный, эффективный, гибкий, понятный, тестируемый код... и обрекать их на решение перечисленных проблем ИМХО означает забивать гвозди микроскопом.

Автор: maxim1000 25.1.2009, 00:25

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

Автор: Gwendolen 25.1.2009, 10:53

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

Автор: nerezus 25.1.2009, 11:03

Цитата Только она является прямым следствием всех предыдущих  Нет, это просто я такой разгвоздяй)

Автор: ida 25.1.2009, 11:17

Цитата(maxim1000 @ 25.1.2009,  01:25) вспоминается цитата с bash.org.ru: самое трудное в работе с компьютерами - работа с людьми Если послушать программистов, то они бы рады вообще избегать общения с другими людьми. И ладно бы, это их личное дело - но когда в результате страдает проект, совсем другой разговор. Хорошо, что аналитиков уже придумали. Работать с людьми не трудно - это интересно и увлекательно, гораздо интереснее, чем ковыряться в коде. Просто к этому нужна склонность. А если у человека нет такой склонности - не надо его насиловать, надо просто найти человека, у которого такая склонность есть, и все он сделает в лучшем виде.

Автор: maxim1000 25.1.2009, 17:04

Цитата(ida @  25.1.2009,  11:17 ) Если послушать программистов, то они бы рады вообще избегать общения с другими людьми. И ладно бы, это их личное дело - но когда в результате страдает проект, совсем другой разговор. Хорошо, что аналитиков уже придумали. Работать с людьми не трудно - это интересно и увлекательно, гораздо интереснее, чем ковыряться в коде. каюсь, неправильно подобрал цитату она (возможно, неявно) претендует на обобщение вроде "любая работа с людьми - самое трудное" на самом деле, хотел сказать о несколько другой проблеме: в больших компаниях при наборе малограмотных людей эффекты от их деятельности начинают приносить всё больше вреда в маленьких организациях это, наверное, лучше заметно, а в больших гнилой код иногда обнаруживается уже через некоторое время после того, как человек ушёл а рано или поздно его приходится чинить, потому что чем больше его используешь, тем больше он тормозит твою работу

Автор: ida 25.1.2009, 19:24

Цитата(maxim1000 @ 25.1.2009,  18:04) в больших компаниях при наборе малограмотных людей эффекты от их деятельности начинают приносить всё больше вреда Согласна. Но это уже политическая проблема, ее быстро не решишь.

Автор: mrbrooks 26.1.2009, 09:17

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

Автор: Alek86 26.1.2009, 09:49

mrbrooks, ты об http://russian.joelonsoftware.com/Articles/FireAndMotion.html?

Автор: nerezus 26.1.2009, 10:05

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

Автор: mrbrooks 26.1.2009, 10:10

Цитата(Alek86 @  26.1.2009,  09:49 ) mrbrooks, ты об этом?  гы. что-то типа этого.

Автор: ida 26.1.2009, 11:49

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

Автор: Vyacheslav 26.1.2009, 11:51

Цитата(maxim1000 @  25.1.2009,  17:04 ) на самом деле, хотел сказать о несколько другой проблеме: в больших компаниях при наборе малограмотных людей эффекты от их деятельности начинают приносить всё больше вреда в маленьких организациях это, наверное, лучше заметно, а в больших гнилой код иногда обнаруживается уже через некоторое время после того, как человек ушёл Фигня какая-то. Этот малограмотный в вакууме что ли работает?  В маленьких фирмах как раз я соглашусь, что такое возможно. Сидел человек ад разработкой, развитием и поддержкой своего проекта годами. Ушел и выясняется, что код - сплошая "лапша", изменения  вносились методом "заплаток"  итд.  В больших фирмах  над проектом обычно работает команда,в которую  входят несколько программистов. Что же все они малограмотные?  Или тим лид стесняется своего подчиненного подправить? Кроме того в нормальных фирмах в процессе работы над проектом сделанный код обычно отдают на ревью другой команде. И ревью делается не от балды, а в соответствии с документом по конкретному языку, где описаны  возможные ошибки с указаниям их рейтинга.

Автор: Lazin 26.1.2009, 12:23

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

Автор: vinter 26.1.2009, 12:30

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

Автор: Torsten 26.1.2009, 13:55

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

Автор: Lazin 26.1.2009, 14:27

Цитата(Torsten @  26.1.2009,  13:55 ) ну вот как раз последнее говорит о низкой квалификации программиста,  он должен заранее предугадывать, что и где возможно будет изменено/добавлено/удалено и сделать так, чтобы измнения были мелкими и легкими в будующем. ага, и зависнуть на полгода, предугадывая все моменты которые могут поменяться в будущем =) Добавлено через 4 минуты и 9 секунд как правило у любого кода есть ограничения, они накладываются сроками и возможностями, какую-то одну вещь бывает иногда дороже сделать чем весь остальной проект целиком.

Автор: ida 26.1.2009, 17:11

Цитата(Torsten @ 26.1.2009,  14:55) ну вот как раз последнее говорит о низкой квалификации программиста, он должен заранее предугадывать, что и где возможно будет изменено/добавлено/удалено и сделать так, чтобы измнения были мелкими и легкими в будующем. Вы попробуйте разместить вакансию программиста, где в числе прочего укажите Требования: - умение предугадывать, что и где в коде может потребоваться изменить после его написания Мне интересно, что вам будут отвечать  Нет, последнее чаще говорит об отсутствии аналитика или его низкой квалификации. Программист ничего предугадывать не обязан - он должен четко соблюдать требования поставленной задачи. Довелось мне работать с одним предугадывателем... после того, как его уволили, одному из наших лучших разработчиков пришлось переписывать ВЕСЬ функционал, написанный этим телепатом. Давайте вспомним процесс разработки ПО для тех, кто его не помнит из институтского курса. При любой модели жизненного цикла ПО у нас должны быть следующие процессы: 1. Анализ 2. Проектирование 3. Кодирование 4. Тестирование Причем качество двух последних зависит от первых двух на от 50 до 80% (смотря насколько грамотные специалисты работают на всех участках - частично плохой процесс может спасти хороший специалист, но никогда не полностью). Компании от 100 человек, производящие ПО, ВСЕГДА имеют штатных специалистов, которые занимаются первыми двумя. Компании от 30 до 100 (в среднем), в зависимости от их зрелости и от того, с какими заказчиками они работают, иногда имеют штатных аналитиков, иногда их функции выполняют другие специалисты. Причем варианты совмещения с разработкой - это худшие варианты. В мелких компаниях (под 30 понимаются только те, кто занят в индустрии ПО, а не работает к примеру на большом заводе, где 3 человека пишут софт) аналитиков нет никогда. А постановки задачи это не отменяет. Потому что прежде чем писать код, надо понять, что этот код должен делать. Вот так и лечат зубы через анус.

Автор: ida 13.4.2009, 22:11

http://forum.vingrad.ru/forum/topic-255408/kw-%D1%81%D0%B5%D0%BC%D0%B8%D0%BD%D0%B0%D1%80-%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D0%B5%D1%82%D0%B5%D1%80%D0%B1%D1%83%D1%80%D0%B3.html, который научит решать самую актуальную проблему из перечисленных и существенно снизит влияние следующих двух. Пока только в С-Петербурге.

Автор: Lazin 13.4.2009, 22:22

Цитата(ida @  13.4.2009,  22:11 ) Семинар, который научит решать самую актуальную проблему из перечисленных и существенно снизит влияние следующих двух. Пока только в С-Петербурге. отучит народ использовть глобальные переменные?

Автор: ida 13.4.2009, 22:25

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)