Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 25   вперед  Ctrl
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
WebSharper
Member

Откуда:
Сообщений: 406
skyANA
Но Вы же с чего-то написали, что кто-то решит потратить кучу бабла на занятие этим самым мембершип менеджементом.
Видимо как-то обрисовали себе это. Может к примеру как инвестиции?


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

см. также
8 апр 18, 17:32    [21321719]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
WebSharper
Member

Откуда:
Сообщений: 406
skyANA
[
Надо отметить, что у нас нет как таковых отделов. У нас горизонтальная структура организации. Есть артели, гильдии
Все они работают, собирают метрики, обратную связь и вносят свою лепту в составление плана. В том числе и артель Growth (маркетинг).


Тогда эта артель играет роль внутреннего заказчика.

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


Тогда вы играете роль внутреннего заказчика или представителя внешнего оллективного кастомера. Или ваше дело предложить, а контроллировать чтобы получилось то, что вы имели ввиду не ваше а чье-то еше?
8 апр 18, 17:34    [21321726]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
WebSharper
Member

Откуда:
Сообщений: 406
skyANA
А ещё в качестве примера можно привести конечно же Spotify: Spotify Squad framework - Part I и Spotify Squad framework - Part II.


У автора (авторки) блога есть должность product manager. Или она член гильдии продакт менеджеров. Обычно, роль ПМ состоит в том, чтобы представлять интересы кастомера в разработке. Так что РОЛЬ там такая есть. Возможно эти роли меняются, но фичи кто-то заказывает а так же то-то должен оценивать получилось то, что задумано или надо подправить.

С общим тезисом, что многое может зависеть от конкретного софта я согласен. См. также пять миров
8 апр 18, 17:39    [21321731]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25821
Поиск чёрного заказчика в тёмной комнате
8 апр 18, 20:59    [21322039]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 165
Я несколько дней отсутствовал на форуме.
Ситуация складывает не очень хорошая.
Тему очень много читают и не задают ни одного вопроса.
Как говорил мой любимый преподаватель:"Если у Вас нет вопросов, то Вы меня не правильно поняли".
Для тех, кто приступил к использованию выделенных проектировщиков,
считаю важным дать список дополнительной литературы по обобщенному программированию, в котором я немного разбираюсь, ИМХО.

Помимо книг Александра Степанова и книг по теории групп хочу порекомендовать книги по функциональному анализу. Их важность поясню.

Все знают знаменитую теорему Пифагора про прямоугольный треугольник.
Так вот эта теорема рассматривается в теории гильбертовых пространств.
Вы мне возможно не поверите, что
1. Доказательство этой теоремы в теории гильбертовых пространств занимает одну строчку, в то время как ее доказательство в школьной программе - целый лист с выносом мозга. Это не шутка.
2. В теории гильбертовых пространств теорема формулируется сразу для двумерных, трехмерных и стомерных пространств, Более того теорема формулируется для пространств, у которых отсутствует понятие размерности.
В школе и в технических ВУЗах существует давняя устойчивая традиции рассматривать все доказательства и использование теоремы изолированно.
3. Эта традиция (изолированного доказательства теоремы Пифагора для разных случаев) плавно переходит в устойчивую традицию разрабатывать программную реализацию этой теоремы отдельно для двухмерного и отдельно для трехмерного случая.
4. Эта традиция порождает следующую традицию - по 1000 раз разрабатывать с нуля очень похожий код.
И это происходит не только в разных программных продуктах. Это часто происходит внутри одного программного продукта. Очень часто различия в реализации двух требований ПО - это различия в названии БИНов, таблиц и полей.
5. Обобщенное программирование это значительно более серьезный подход чем микросервисы, модульное программирование, функциональное программирование и экстремальное программирование, вместе взятые. Исключительно ИМХО.
6. Обобщенное программирование - это долговременный политический союз программирования и математики.
Это фундаментальный подход.
Это очень серьезно.

Всем удачи и успехов в использовании выделенных проектировщиков.
Если есть вопросы, то пишите. Я отвечу.
12 апр 18, 08:48    [21331852]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
Особняк
Я несколько дней отсутствовал на форуме.
Ситуация складывает не очень хорошая.
Тему очень много читают и не задают ни одного вопроса.
Как говорил мой любимый преподаватель:"Если у Вас нет вопросов, то Вы меня не правильно поняли".
Для тех, кто приступил к использованию выделенных проектировщиков,
считаю важным дать список дополнительной литературы по обобщенному программированию, в котором я немного разбираюсь, ИМХО.

Помимо книг Александра Степанова и книг по теории групп хочу порекомендовать книги по функциональному анализу. Их важность поясню.

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

2. В теории гильбертовых пространств теорема формулируется сразу для двумерных, трехмерных и стомерных пространств, Более того теорема формулируется для пространств, у которых отсутствует понятие размерности.
В школе и в технических ВУЗах существует давняя устойчивая традиции рассматривать все доказательства и использование теоремы изолированно.
3. Эта традиция (изолированного доказательства теоремы Пифагора для разных случаев) плавно переходит в устойчивую традицию разрабатывать программную реализацию этой теоремы отдельно для двухмерного и отдельно для трехмерного случая.
4. Эта традиция порождает следующую традицию - по 1000 раз разрабатывать с нуля очень похожий код.
И это происходит не только в разных программных продуктах. Это часто происходит внутри одного программного продукта. Очень часто различия в реализации двух требований ПО - это различия в названии БИНов, таблиц и полей.
5. Обобщенное программирование это значительно более серьезный подход чем микросервисы, модульное программирование, функциональное программирование и экстремальное программирование, вместе взятые. Исключительно ИМХО.
6. Обобщенное программирование - это долговременный политический союз программирования и математики.
Это фундаментальный подход.
Это очень серьезно.

Всем удачи и успехов в использовании выделенных проектировщиков.
Если есть вопросы, то пишите. Я отвечу.


Вы мне тоже, возможно, не поверите, но, доказательство этой теоремы вообще может занимать 0 строк: когда она выступает в качестве эквивалента 5-го постулата Евклида. Для гильбертовых пространств аналогию проведете. Кстате, доктрина Гильберта "аксиоматизация -> логический вывод" потерпела крах, логическое обоснование которого - теорема Геделя о неполноте. "За что боролись, на то и напоролись".

Про группы и функциональный анализ - вообще не в тему. Понятно, что Вы пытались потролить
12 апр 18, 19:32    [21334678]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
Особняк
В школе и в технических ВУЗах существует давняя устойчивая традиции рассматривать все доказательства и использование теоремы изолированно


И это обосновано (в книгах по методике преподавания математики можете найти). Если на пальцах: в математике много чего взаимосвязанного (проявление сути в разных обличиях), и это лучше всего показывать на простых примерах. Или Вы всерьез считаете, что все эти доказательства после Пифагора - это действительно "эврика, я доказал!"?
12 апр 18, 19:42    [21334700]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

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


Математика - это не программирование. Программирование - это не математика. Ваше "исключительное ИМХО", это "обобщенное программирование" - это просто набор слов.
12 апр 18, 19:45    [21334707]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
love_bach,

Или Вы так завуалированно пытаетесь поведать про абстракции в программировании? Ну чтож, поздравляю тогда Вас с открытием. Только Вы лет на ~60 опоздали с ним
12 апр 18, 19:48    [21334711]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 165
love_bach
Особняк
Я несколько дней отсутствовал на форуме.
Ситуация складывает не очень хорошая.
Тему очень много читают и не задают ни одного вопроса.
Как говорил мой любимый преподаватель:"Если у Вас нет вопросов, то Вы меня не правильно поняли".
Для тех, кто приступил к использованию выделенных проектировщиков,
считаю важным дать список дополнительной литературы по обобщенному программированию, в котором я немного разбираюсь, ИМХО.

Помимо книг Александра Степанова и книг по теории групп хочу порекомендовать книги по функциональному анализу. Их важность поясню.

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

2. В теории гильбертовых пространств теорема формулируется сразу для двумерных, трехмерных и стомерных пространств, Более того теорема формулируется для пространств, у которых отсутствует понятие размерности.
В школе и в технических ВУЗах существует давняя устойчивая традиции рассматривать все доказательства и использование теоремы изолированно.
3. Эта традиция (изолированного доказательства теоремы Пифагора для разных случаев) плавно переходит в устойчивую традицию разрабатывать программную реализацию этой теоремы отдельно для двухмерного и отдельно для трехмерного случая.
4. Эта традиция порождает следующую традицию - по 1000 раз разрабатывать с нуля очень похожий код.
И это происходит не только в разных программных продуктах. Это часто происходит внутри одного программного продукта. Очень часто различия в реализации двух требований ПО - это различия в названии БИНов, таблиц и полей.
5. Обобщенное программирование это значительно более серьезный подход чем микросервисы, модульное программирование, функциональное программирование и экстремальное программирование, вместе взятые. Исключительно ИМХО.
6. Обобщенное программирование - это долговременный политический союз программирования и математики.
Это фундаментальный подход.
Это очень серьезно.

Всем удачи и успехов в использовании выделенных проектировщиков.
Если есть вопросы, то пишите. Я отвечу.


Вы мне тоже, возможно, не поверите, но, доказательство этой теоремы вообще может занимать 0 строк: когда она выступает в качестве эквивалента 5-го постулата Евклида. Для гильбертовых пространств аналогию проведете. Кстате, доктрина Гильберта "аксиоматизация -> логический вывод" потерпела крах, логическое обоснование которого - теорема Геделя о неполноте. "За что боролись, на то и напоролись".

Про группы и функциональный анализ - вообще не в тему. Понятно, что Вы пытались потролить
1. Теорему Пифагора никогда не включали в аксиомы геометрии: ни Эвклид, ни Лобачевский, ни Гильберт. Эту теорему всегда доказывали на основании аксиом и дополнительных определений геометрических объектов.
2. Великий Гильберт много чем занимался.
Аксиоматика математики - это одно направление его работ.
Гильбертовы пространство - другое.
3. Рекомендую хотя бы пролистать книгу Александра Степанова "От математики к обобщённому программированию".
Степанов - очень крутой спец.
https://ru.wikipedia.org/wiki/Степанов,_Александр_Александрович_(учёный)
Он главный разработчик библиотеки С++ STL.
В своей книге он объясняет зачем нужна теория групп в обобщенном программировании и вообще показывает связь математики и обобщенного программирования.
Пример с теоремой Пифагора из функционального анализа добавил я как очень наглядный.
4. Если я - троль, то А. Степанов - тоже.
5. Доказательство теоремы Пифагора в гильбертовом пространстве в одну строчку
https://books.google.co.il/books?id=qV6ECwAAQBAJ&pg=PA8&dq=теорема пифагора гильбертово пространство&hl=ru&sa=X&ved=0ahUKEwjL2Ki7xLXaAhVLzaQKHTSpDtQQ6AEIJjAA#v=onepage&q=теорема пифагора гильбертово пространство&f=false
(в конце страницы)
6. Обобщенное программирование безусловно использует абстрактные классы.
Библиотека STL - это капля в море под названием "Обобщенное программирование".
Нужны сотни или тысячи подобных библиотек, из которых можно быстро строить надежное и качественное ПО.
Эти библиотеки должны хорошо стыковаться друг с другом.
Наличие таких библиотек - это революция в разработке ПО, а микросервисы - увы нет.

Зачем нужен функциональный анализ разработчику сейчас объясню на примере.
Предположим Ваш сын учится физмат школе с углубленным изучением программирования.
1. Сын учится в 7 классе, приходит и говорит:"Нужно запрограммировать теорему Пифагора".
Вы ему говорите:"Бери великий и могучий язык Java и пиши: Це в квадрате равно А в квадрате плюс Бе в квадрате". Сын приходит на следующий день:"Пять баллов"
2. Сын перешел в 9 класс приходит и говорит:"Дали три точки в трехмерном пространстве. Нужно запрограммировать теорему Пифагора".
Вы возможно ему скажете:"Через три точки можно провести единственную плоскость. Находим координаты этих точек на этой плоскости. Дальше находим А и Бе. Затем находим Це в квадрате. И не забудь оформить это в стиле модульного программирования. Первый модуль считает Це в квадрате. А второй модуль готовит для него А и Бе."
3. Сын закончил школу с золотой медалью, поступил на мехмат МГУ, приходит и говорит:
"Дали три точки в N-мерном линейном пространстве и сказали, что они задают прямоугольный треугольник.
Сказали запрограммировать теорему Пифагора.
Дали формулу: скалярное произведение первого вектора на себя плюс скалярное произведение второго вектора на себя равно скалярному произведению третьего вектора на себя.
Никаких Бе в квдрате и Це в квадрате. Только слово "плюс" повторяется."
Возможно Вы ему посоветуете:"У меня на работе заказчик называет разные требования одним словом. Мы его не слушаем и делаем микросервисы. Так легче поддерживать и устанавливать ПО. Выдели школьный вариант теоремы Пифагора в отдельный микросервис, а для института сделай -второй".
4. Начинается новый семестр, приходит сын и говорит: "Мне на матанализе дали запрограммировать теорему Пифагора для функций, интегрируемых на отрезке.
Они похоже называют любую формулу, где встречается слово "плюс" теоремой Пифагора, Я тебя даже спрашивать не стал. Сразу сделал микросервис и получил зачет."
5. Начинается следующий семестр, приходит сын и говорит:"Препод по обобщенному программирования посмотрел мои микросервисы и сказал: "Ты попал парень. Реализуй теорему Пифагора для всех твоих школьных и институтских случаев для углов 90, 89 и 91 градусов. Но если ты будешь дорабатывать все свои микросервисы в отдельности, то зачета не получишь."
Все. Занавес.

Но мы немного отвлеклись от главного тезиса обсуждение:
для разработки ПО нужны и даже необходимы выделенные проектировщики.
Для чего? Например, для обобщенного программирования.
13 апр 18, 14:55    [21337058]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
Особняк
Степанов - очень крутой спец.
Если я - троль, то А. Степанов - тоже.
Все. Занавес.

Не думаю, что Степанов - тоже. А вот Ваша честность впечатляет.
Особняк
Но мы немного отвлеклись от главного тезиса обсуждение:
для разработки ПО нужны и даже необходимы выделенные проектировщики.
Для чего? Например, для обобщенного программирования.

Главный тезис - другой. Какие последствия от того, что отсутствует этап проектирования. Не выделенные проектировщики, речь не о них. Речь об этапе.

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

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

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

Вот такая вот ситуация складывается в целом.
13 апр 18, 19:44    [21338047]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
darth
Member

Откуда:
Сообщений: 1740
Особняк
Для чего? Например, для обобщенного программирования.

Понимаешь, сегодня НЕ обобщенного программирования нет как такового. НЕ обобщенное программирование заканчивается на языке ассемблера.
Язык Си это уже обобщение, абстракция.
Java/C# это уже обобщение/абстракция гораздо более высокого уровня.
1С/SAP/SQL это еще более высокоуровневые абстракции/обобщения.
Казалось бы, если обобщенное программирование это так круто, то 1С/SAP... должны были давно захватить мир. Но такого не наблюдаем. Почему? А потому что вселенная не линейная, она "кривая".
Всегда работает диалектика - закон отрицания отрицания.
Мы можем увеличивать эффективность всей системы изменяя какой-то параметр системы в определенных пределах, а если начинаем выкручивать этот параметр за эти пределы, то эффективность всей системы падает.
Например, ДВС дает максимальный КПД на 3000 оборотах в минуту. Автомобиль едет на 2000 оборотах, хорошо, давим на газ, обороты 2500, КПД стал выше, хорошо, давим еще на газ, обороты 3000, КПД еще выше, просто замечательно! Казалось бы, поддадим еще газку и будет ваще ЗБС... а нет. Диалектика. Авто едет быстрее, но КПД стал падать.
Этот принцип работает везде, программирование не исключение.
Используя обобщения в программировании, мы можем увеличивать эффективность своей работы в определенных пределах. Если выйдем за эти пределы - эффективность упадет.
Да, сегодня это очень сложные задачи, и да, что бы их решать нужны глубокие знания в системном проектировании.

Расскажу одну историю. Лет 8 назад мне заказали переписать одну систему управления техпроцессом, которая крутилась под досом с начала 90-х и работала через СОМ порты с оборудованием. Ну и я весь такой ретивый, с шарпом головного мозга - да не вопрос! Сейчас все на шарпе вам забацаю, на эскуэль сервер все данные будут бросаться... будет ЗБС!
Посмотрел исходники старой софтины - сишный код с кучей вставок на ассме... Ну старперы тупые! И не лень же было такое полотно говнокодить? Хорошо что сейчас есть си-шарп!
Открыл вижуал-студию, ну сча...
Ага. Счаз!
Оказалось, что для того что бы техпроцесс нормально шел, софтина должна работать в режиме реального времени и обрабатывать все сигналы в определенных временных диапазонах с точностью плюс-минус миллисекунда! И как это сделать под виндой да на дотнете? А никак!

Вот и все обобщенное программирование. Ввели дополнительные уровни абстракции, получили возможность более эффективно писать говносайтики, но при этом отвалился целый класс других задач.
13 апр 18, 21:03    [21338152]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
Особняк
Теорему Пифагора никогда не включали в аксиомы геометрии: ни Эвклид, ни Лобачевский, ни Гильберт. Эту теорему всегда доказывали на основании аксиом и дополнительных определений геометрических объектов.


Плохо, что не знаете базовых, в общем-то вещей: аксиоматика (Евклидова, Гильбертова) довольно гибкая вещь, позволяет некоторые теоремы обозначить как аксиомы, за счет чего другие аксиомы становятся теоремами.

Вы мой намек не поняли. Поэтому, прямо (уже совсем по теме топика) - абстракции не фиксированы, зависят от субъекта. И судить об их правильности/оптимальности/непротиворечивости/полноте - это закопаться в бесконечном поиске серебрянной пули. Даже математика, которую Вы пытаетесь использовать как мерило "правильного проектирования" этим грешна. А что уж говорить про наш бренный мир программирования
13 апр 18, 21:40    [21338191]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
darth
Member

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

Вы правы, сегодня в большинстве случаев цель - тянуть процесс, сосать бабло. Программирование ради программирования.

Но есть и другой подход, как любил говорить Карл Фридрих Гаусс - что не доделано до конца, то не делалось вообще.
Ну или по народному: сделал дело - гуляй смело.

Мне лично такой подход больше импонирует. Я не переношу решать одну и ту же задачу дважды.
Или беремся за задачу и решаем ее до конца, желательно с первого подхода, или вообще не беремся ее решать!
Если работать в рамках такой идеологии, то без основательного системного проектирования никуда. Ибо только основательное системное проектирование способно свести риски эпикфейла к минимуму.
13 апр 18, 21:47    [21338198]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

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

Вы правы, сегодня в большинстве случаев цель - тянуть процесс, сосать бабло. Программирование ради программирования.

Но есть и другой подход, как любил говорить Карл Фридрих Гаусс - что не доделано до конца, то не делалось вообще.
Ну или по народному: сделал дело - гуляй смело.

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


Особняк вкладывает в "основательное системное проектирование" некоторые, назовем их "метафоры", из математики. А что Вы под этим понимаете?
13 апр 18, 22:10    [21338225]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
darth
Ибо только основательное системное проектирование способно свести риски эпикфейла к минимуму.


это звучит как "надо делать хорошо, и не делать плохо"
13 апр 18, 22:11    [21338226]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
WebSharper
Member

Откуда:
Сообщений: 406
darth
Вот и все обобщенное программирование. Ввели дополнительные уровни абстракции, получили возможность более эффективно писать говносайтики


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

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


Как это отвалился? Для них свои инструменты, которые пилят. Те же самые сишарпы и джавы используются для них, но уже в качестве инструментария разработки. А вот для самих абстракций тоже пилят новые языки - вон у rust девиз "абстракции с нулевой стоимостью".
13 апр 18, 22:12    [21338228]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
darth
Member

Откуда:
Сообщений: 1740
love_bach
Особняк вкладывает в "основательное системное проектирование" некоторые, назовем их "метафоры", из математики. А что Вы под этим понимаете?

На 14-16-й страницах мои посты гляньте.
13 апр 18, 22:23    [21338242]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
darth
Member

Откуда:
Сообщений: 1740
WebSharper
Почему обязятельно говно, что за негативизм и неблагодарность. Вы ж прям сейчас пользуетесь сайтиком.

К сожалению 99% сегодняшних сайтиков не несут никакой информационной нагрузки, просто информационный мусор/шум. Отсюда и негативизм. Да, есть еще полездые сайты с полезным функционалом, но это капля в море.
13 апр 18, 22:26    [21338247]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
darth
Member

Откуда:
Сообщений: 1740
WebSharper
Как это отвалился? Для них свои инструменты, которые пилят. Те же самые сишарпы и джавы используются для них, но уже в качестве инструментария разработки. А вот для самих абстракций тоже пилят новые языки - вон у rust девиз "абстракции с нулевой стоимостью".

Кабы здесь объяснить...
Ну вот все прекрасно знают, что есть плоская отвертка и есть крестообразная. Но при этом производители оборудования умуюдяются юзать например такие винты:

Картинка с другого сайта.

Или такие:

Картинка с другого сайта.

От того, что производитель заюзал такой "интерфейс", соединение стало лучше? Нет конечно. Но гемороя обслуживающему персоналу добавилось.
Тоже самое сегодя и в ИТ, с этими растами, свифтами и прочими оккамами.
13 апр 18, 22:43    [21338272]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

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

Вы правы, сегодня в большинстве случаев цель - тянуть процесс, сосать бабло. Программирование ради программирования.

Но есть и другой подход, как любил говорить Карл Фридрих Гаусс - что не доделано до конца, то не делалось вообще.
Ну или по народному: сделал дело - гуляй смело.

Мне лично такой подход больше импонирует. Я не переношу решать одну и ту же задачу дважды.
Или беремся за задачу и решаем ее до конца, желательно с первого подхода, или вообще не беремся ее решать!
Если работать в рамках такой идеологии, то без основательного системного проектирования никуда. Ибо только основательное системное проектирование способно свести риски эпикфейла к минимуму.
Не согласен с Вами обоими по поводу ведущей (драйверной) роли заказчика в разработке ПО.
Заказчик - это группа лиц, у которых есть проблемы и деньги.

1. По поводу денег. Разработка ПО давно пытается обойтись без потных денег заказчиков с помощью IPO, ICO, краудфандинга и других инструментов. Нужно разделять желание быть инвестором разработки ПО и быть потребителем ПО.
Одно мешает другому.

Очень не нравится Ваше постоянное напоминание о распиле бабла.
Даже если это так, мы все-таки творцы и с нас другой спрос в высоком смысле слова. Я о естественном стремление к совершенству.

2. По поводу роли заказчика как эксперта по требованиям к ПО для решения своих проблем.
Заказчик - самое слабое звено, самое не профессиональное. самое непосредственное, самое необязательное. Как правило. Никого не хочу обидеть.

Поэтому заказчик - точно не драйвер.
Драйвер - кто-то другой.
Надеюсь, что это проектировщик.
13 апр 18, 23:04    [21338298]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
darth
WebSharper
Как это отвалился? Для них свои инструменты, которые пилят. Те же самые сишарпы и джавы используются для них, но уже в качестве инструментария разработки. А вот для самих абстракций тоже пилят новые языки - вон у rust девиз "абстракции с нулевой стоимостью".

Кабы здесь объяснить...
Ну вот все прекрасно знают, что есть плоская отвертка и есть крестообразная. Но при этом производители оборудования умуюдяются юзать например такие винты:

Картинка с другого сайта.

Или такие:

Картинка с другого сайта.

От того, что производитель заюзал такой "интерфейс", соединение стало лучше? Нет конечно. Но гемороя обслуживающему персоналу добавилось.
Тоже самое сегодя и в ИТ, с этими растами, свифтами и прочими оккамами.


не удачный пример, особенно второй - это винты, которые нельзя отвинтить. у них изначально такое назначение
13 апр 18, 23:05    [21338302]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
Особняк
2. По поводу роли заказчика как эксперта по требованиям к ПО для решения своих проблем.
Заказчик - самое слабое звено, самое не профессиональное. самое непосредственное, самое необязательное. Как правило. Никого не хочу обидеть


А кто имеет экспертизу в предметке? Например, ПО для моделирования печатных плат, ПО для расчета всяких нефтяных скважин и т.п. Не заказчик, разве?
13 апр 18, 23:10    [21338309]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
love_bach
Member

Откуда:
Сообщений: 398
love_bach
Особняк
2. По поводу роли заказчика как эксперта по требованиям к ПО для решения своих проблем.
Заказчик - самое слабое звено, самое не профессиональное. самое непосредственное, самое необязательное. Как правило. Никого не хочу обидеть


А кто имеет экспертизу в предметке? Например, ПО для моделирования печатных плат, ПО для расчета всяких нефтяных скважин и т.п. Не заказчик, разве?


и вот кстате там, могу ошибаться, проектирование уже было. в результате которого были выдвинуты требования.
13 апр 18, 23:12    [21338312]     Ответить | Цитировать Сообщить модератору
 Re: Отсутствует этап проектирования при разработки ПО. Какие последствия?  [new]
Особняк
Member

Откуда:
Сообщений: 165
darth
Казалось бы, если обобщенное программирование это так круто, то 1С/SAP... должны были давно захватить мир. Но такого не наблюдаем. Почему? А потому что вселенная не линейная, она "кривая".
1. Рынок информационных сейчас делят именно ERP-системы, у которых есть обобщенное программирование. Это именно SAP. 1С, OEBS. Но это не Парус и другие подобные системы. А ведь когда-то Парус и 1С являлись прямыми конкурентами.
2. Я предположу, что они предпримут попытку расширить ореол своего обитания.
Это очень сильные игроки на рынке ПО.
3. Что касается технического совершенства обобщенного программирования в ERP-системах, то им есть над чем работать, f у всех нас есть возможность сделать лучше, чем у них. И это можно делать в относительно небольших коллективах. Было бы желание.
13 апр 18, 23:32    [21338336]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 25   вперед  Ctrl
Все форумы / Работа Ответить