Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »
Страницы: 1 2 3 4 5 6

Существует ли доделанный софт?


SergP ©   (17.09.18 08:29[40]


> Существует ли доделанный софт?


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


sniknik ©   (17.09.18 10:11[41]

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


Германн ©   (18.09.18 03:10[42]


> sniknik ©   (17.09.18 10:11) [41]
>
> любой софт доделан... пока не покажешь заказчику, и тут
> начинается

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


Alex Konshin ©   (04.10.18 04:29[43]

Один из законов Мерфи:
Если программа работает, то она устарела и её нужно исправить.

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


asail ©   (04.10.18 13:45[44]


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

А тут мы, во-первых, опять упираемся в толкование термина "законченная" (или более верного изначального "доделанная").
А во-вторых, устаревание к понятию "доделанный" никоим образом не относится. Например, я купил новенький автомобиль, скажем мерседес... Он доделан? Думаю да, раз продается и соответствует всем заявленным ТХ. Но, рано или поздно, он устареет (сломается) и будет отправлен на свалку. Что никак не отменяет того факта, что на момент покупки он был таки "доделан".


KSergey ©   (04.10.18 13:49[45]

> Германн ©   (18.09.18 03:10) [42]
> > любой софт доделан... пока не покажешь заказчику, и тут начинается
>
> Как пофигист широкого профиля скажу лишь то, что этими вопросами
> не должен заниматься разработчик. Если это конечно не индивидуальный разработчик.

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


KSergey ©   (04.10.18 14:06[46]

> Alex Konshin ©   (04.10.18 04:29) [43]
> А если серьёзно, то законченой программы даже теоретически
> быть не может хотя бы с точки зрения безопасности. Любая
> программа содержит ошибки и со временем устаревает.

А вот такой подход видится мне довольно странным. И такой подход, на мой взгляд - это основная беда отрасли, основная её проблема.
В самом деле: есть ли "законченный мост"? есть ли "законченный автомобиль"?
Если есть - то чем таким внезапно особенным являются программы, как результат инженерной деятельности, что они не бывают законченными?

Хотя в смысле з/п - да, подход хорош. Лишь потому, считаю, он и имеет место повсеместно быть


Германн ©   (05.10.18 02:08[47]


> Alex Konshin ©   (04.10.18 04:29) [43]
>
> Один из законов Мерфи:
> Если программа работает, то она устарела и её нужно исправить.
>
>
> А если серьёзно, то законченой программы даже теоретически
> быть не может хотя бы с точки зрения безопасности. Любая
> программа содержит ошибки и со временем устаревает.
>

Насчёт некоего из законов Мерфи сказать нечего, ибо о таком законе не слышал. Но насчёт "Любая программа содержит ошибки и со временем устаревает" готов поспорить.


Alex Konshin ©   (06.10.18 00:48[48]

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

И не существует более-менее существенных программ, для которых доказано, что там нет ошибок. Я немного в курсе, что есть попытки доказательств программ. Но это нереально. Можно ли утверждать, что ошибок не найдено по какой-то из методик. И ошибки всегда будут, нужно смириться с этим и научиться работать с ними. Нужно оценивать риски и принимать соответствующие контрмеры. Ну, например, нельзя полагаться на то, что все сторонние компоненты, используемые в программе, не содержат ошибок или каких-то дыр в безопасности. Также как нельзя быть увереным в том, что позднее не будет найдена ошибка/уязвимость в компиляторе, библиотеке, OS, процессоре, алгоритме, и т.п.. Чтобы решить очередную проблему нужно вносить изменения в программу, и есть риск внести новые ошибки в вашу "идеальную" программу. Я уж не говорю про то, что требования к программе от пользователей/системы/окружения меняются со временем.

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


Германн ©   (06.10.18 01:32[49]


>  KSergey ©   (04.10.18 13:49) [45]
>
> > Германн ©   (18.09.18 03:10) [42]
> > > любой софт доделан... пока не покажешь заказчику, и
> тут начинается
> >
> > Как пофигист широкого профиля скажу лишь то, что этими
> вопросами
> > не должен заниматься разработчик. Если это конечно не
> индивидуальный разработчик.
>
> Вот не согласен я.
> Программист, как ремесленник - да, видимо не должен.

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


KSergey ©   (08.10.18 11:08[50]

> Германн ©   (06.10.18 01:32) [49]
> Во-первых что плохого в слове ремесленник?

Абсолютно ничего плохого, что вы! не, в самом деле, если человек умеет выпиливать детали по шестому разряду со стабильным качеством - это отменно.
Я не про "плохо/хорошо", "достойно/недостойно".
Я про то, какое место в проекте и его развитии занимает человек тех или иных компетенций, какие риски ему готовы доверять.
Лишь про это.


KSergey ©   (08.10.18 12:02[51]

> Alex Konshin ©   (06.10.18 00:48) [48]
> Разница между автомобилем и программой в том, что автомобиль
> изнашивается, а программа нет - её двоичный код не меняеться.
>  Но меняется её окружение. И потому она не может не устаревать.

Речь, напомню, о "законченности изделия".
Как это связано с необходимостью приобретения нового авто/программы - мне не очень понятно. Я не вижу здесь ответа на вопрос, связанный с "законченностью". Автомобили не редко тоже содержат ошибки конструкции, к слову (т.е. не связанные с внутренним ПО даже). (Часто та или иная модель имеет характерные проблемы эксплуатации, и/или характерный неоправданный износ некоторых комплектующих, или имеет характерную проблему в каких-то условиях эксплуатации)

Так что вопрос остаётся: можно ли сказать о законченности других инженерных изделий?


Alex Konshin ©   (09.10.18 04:15[52]

Сейчас тут начнутся беседы по диалектике.

Если вы считаете, что продукт закончен после его продажи/сдачи потребителю, то да так можно и программы писать. Но тенденция сейчас такая, что продаются сейчас не собственно программы, а их поддержка, и отношение цены продажи к цене поддержки сейчас может быть любым. Вплоть до того, что вам могут заплатить за то, что вы возьмёте именно их продукт. И это не только в программировании, если вы задумаетесь, то найдёте массу примеров в других областях. А из этого есть следствие - законченный продукт невыгоден производителю. Ему нужно, чтобы потребителю потребовалась платная поддержка. Продукты постоянно развиваются, чтобы потребитель захотел обновления. А зачастую используются и другие, менее честные приёмы. Потому никто не стремится делать законченый продукты, даже если бы это было возможно.

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


KSergey ©   (09.10.18 06:20[53]

> Alex Konshin ©   (09.10.18 04:15) [52]
> Сейчас тут начнутся беседы по диалектике.
>
> Если вы считаете, что продукт закончен после его продажи/сдачи
> потребителю, то да так можно и программы писать. Но тенденция сейчас такая,
...

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


Сергей Суровцев ©   (09.10.18 11:51[54]

>Alex Konshin ©   (04.10.18 04:29) [43]
>А если серьёзно, то законченой программы даже теоретически быть не может хотя бы с точки зрения безопасности. Любая программа содержит ошибки и со временем устаревает.

Ну это не совсем так.
Незаконченность можно разделить на три категории.
1) Незаконченность с точки зрения разработчика (весь требуемый функционал работает, но есть внутренние огрехи, которые хотелось бы исправить, как то - архитектура, оптимизация, чистота кода и т.д.).
2) Незаконченность с точки зрения пользователя (не весь требуемые функционал присутствует, есть ошибки в работе того, что реализовано).
3) Незаконченность с точки зрения задачи (все что заявлено к разработке реализовано и работает, но есть еще список того, что хотелось бы добавить)

Так вот эксплуатироваться без изменений программа может спокойно при наличии П1 и П3, и даже их вместе. А вот при наличии П2 незаконченность очевидна и требуется доработка.
По идее доработка П2, если она осуществляется сама по себе может привести к законченности. Но обычно П2 реализуется только совместно с П3 (и по возможности туда же втыкают П1). Это ведет к тому, что список П2 постоянно изменяется, устраняются старые ошибки, но добавляются новые. И в этом случае да, законченность невозможна.
Но если П3 исчерпан, а над П2 проведена хорошая работа, законченность таки наступит.

Это возможно для маленьких и части средних приложений. Для остальных процесс изменений бесконечен, т.к. П3 у них практически неисчерпаем.


KSergey ©   (09.10.18 12:36[55]

Я думал таки ответ на мой вопрос таки очевиден.
Но возможно нет.

> Сергей Суровцев ©   (09.10.18 11:51) [54]

Всё объясняется проще: модификация ПО не требует капитальных затрат, не требует затрат на материалы.
А переделка ПО - это "бесплатная" операция, не требующая затрат, только труд рабочих.
Лишь поэтому автомобили никто не доделывает и не переделывает (1..2 богатых и рукастых не в счёт) , устраняя выявленные недостатки конструкции или добавляя новые фичи типа "а еще бы по болоту аки по суху" или "а вот бы еще взлетать, хотя бы не высоко". Потому как экономически это не имеет смысла, проще в новой модели учесть имеющийся опыт о недоработках конструкции.

> 3) Незаконченность с точки зрения задачи (все что заявлено к разработке реализовано и работает, но есть еще список того, что хотелось бы добавить)

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

А переделать ПО - это ж "бесплатно", вот и прикручивают, рефакторят, масштабируют и проч. фигнёй страдают, вместо того, чтобы переделать с нуля с учётом новых требований по нагрузке, функциональности и т.д. (это уже из наболевшего, извините).

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


Сергей Суровцев ©   (09.10.18 13:51[56]

>KSergey ©   (09.10.18 12:36) [55]
>Всё объясняется проще: модификация ПО не требует капитальных затрат, не требует затрат на материалы.
Даже не это. А то что замена ПО у пользователя не требует затрат. Даже за чайником еще идти надо. А тут 2-3 кнопки нажал и установил. На любом расстоянии от производителя за секунды-минуты.

Основная проблема в IT это низкое качество менеджмента. У него нет четкого понимания что делать, как, в какие сроки, кто за что отвечает. Нет физических ограничений. Иллюзия, что все возможно и несложно, надо только придумать как... Нет понимания разработки как производственного процесса продуманного, зафиксированного, распланированного. Скорее как "бери больше, кидай дальше", "гурьбой навалимся и все быстренько сделаем".

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


Игорь Шевченко ©   (09.10.18 13:52[57]

Сергей Суровцев ©   (09.10.18 13:51) [56]

https://habr.com/company/yandex/blog/425265/


Сергей Суровцев ©   (09.10.18 14:24[58]

>Игорь Шевченко ©   (09.10.18 13:52) [57]

О чем я и говорю. Сначала метко стреляем, потом смотрим в кого.


KSergey ©   (09.10.18 15:32[59]

А я чета не въезжаю как как приведённая ссылка связана с обсуждением.
Если чуваки сознательно закладываются на то, что "мы быстро делаем как-то, чтобы посмотреть надо ли это вообще, а что надо - после доделываем" - почему нет? люди делают осознанно, и это нормально.
При этом приляпанное лишь бы как - это вполне доделанная программа на момент выкатывания.
При этом люди думают про то, как потом сделать нормально, если это вообще надо будет.

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


Страницы: 1 2 3 4 5 6 версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо