of63
- не уверен, что современные технологии (которые суть ООП) позволят "облегчить сопровождение"

Потому что ты их не использовал Уже одно разделение на слои и написание юнит-тестов на порядок улучшит качество проекта и его сопровождения. В монолите без тестов любое, даже самое мелкое изменение способно сломать, или, что ещё хуже, незаметно начать плодить ошибки (вроде как всё работает, а по итогу где-то там накапливается неправильная "сумма на счёте", или "пропадают" со склада товары). На реально старых технологиях крайне редко применяют и разделение на слои и юнит-тестирование, не говоря уж про автоматизированное тестирование UI (когда не ты, и не юзер, а автомат "кнопки тычет" и проверяет что всё как надо происходит).
Разница тут как при строительстве "небоскрёба" где-нить в начале 20-го века и сегодня. Страховки нет, рации для связи нет, леса могут быть "подгнившие", землю надо "на тачках", в лучшем случае на лошадке с телегой вывозить.

of63
- не уверен, что "современные технологии" останутся также поддерживаемыми через 20 лет

И что же тут такого страшного? Из за того что ещё не изобретён какой "телепорт" надо отказаться от самолёта, поезда и автомобиля и по старинке пешком или в кибитках передвигаться? Будут новые лучшие технологии - будем их использовать Жизнь это движение.
А "на века" программу писать - ну мне кажется что это нерационально. Разве что это уж 100% неизменная предметная область - но ты ещё найди такую, я вот с ходу не могу представить. Даже тупой бухучёт - казалось бы, ну что может измениться в "приход/расход/остаток" даже за 200 лет - а и тот постоянно меняется, усложняется...

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

Можно - если написаны они "правильно", если имеется документация, если разработчик следовал "best practices" а не "лепил горбатого". И это уже вопрос к заказчику - требует ли он от разработчика адекватный продукт, или на коленке слепленное нечто. Тоже по сути вопрос денег - взять за 100р и выкинуть через год обплевавшись, или взять за 1000р и использовать 10 лет.

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

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

of63
- не уверен, что отдаться на аутсорсинг (конторе, занимающейся созданием и сопровождением) практичнее, чем местному разрабу.

Зависит от проекта. По разному бывает. Конкретно конторе занимающейся, к примеру, промышленным выращиванием перепёлок нафиг не нужен it отдел и "собственные" програмные продукты - хоть бухгалтерского, хоть производственного назначения. Аренда ПО (1с по сути оно и есть), заказ "на стороне" небольших доработок - куда как практичнее своего центра разработки. Тем более что хрен ты найдёшь в какой Костроме или там Урюпинске нормальных разработчиков - по крайней мере "свободных" на рынке. Да и платить нормальному специалисту его стоимость невыгодно. Одно дело когда 10 сходных контор отстёгивают "посреднику" по 100р, а этот посредник платит разрабу, ну скажем 800р. И совсем другое когда каждая из этих контор пытается найти "своего личного" разраба, даже за 200р (что уже в 2 раза дороже выходит).

of63
Риск одинаково велик, что сдохнет первым разраб, или аутсорс-контора.

Угу, крупная контора со штатом в 10-20 тыщ человек и парой сотен платящих денежку клиентов вот так вот раз, и "сдохнет" При том что обычно эти компании придерживаются сходной методологии разработки, и "передать" продукт от одного аутсорсера другому не так уж и сложно - ну точно проще чем передать продукт писанный гением-одиночкой другому такому же (или даже компании-аутсорсеру, хотя заметная часть их бизнеса таки связана с переписыванием legacy систем - по разному созданных, конечно).

of63
Есть подозрение, что аутсорс-контора также пользуется услугами времянщиков, таких же одиноких сопровождальщиков.

А какая тебе, как клиенту, разница как они там внутри решают проблемы? Это нанять и содержать СВОЙ штат разрабов - твоя головная боль, а так - это всё перекладывается на аутсорсера

of63
Они за местные копейки не работают, сразу идут на врага, работать

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

"Не согласен я", что тоталитаризм (монополизм крупных софт-контор) лучше, чем много частников, проживающих в Костроме/Урюпинске, чем одна большая в Нерезиновске. и что кроме 1С нет альтернатив для учета перепелок, и шарп - для всего остального... Слишком по "советски" застойно.

ПС. Фразу
"не уверен, что современные технологии (которые суть ООП) позволят "облегчить сопровождение"
надо было читать как
"не уверен, что современные технологии (которые все суть одно и тоже - ООП) позволят "облегчить сопровождение"

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

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



Исправлено 2 раз(а). Последнее : of63, 01.12.18 16:36

Дело ясное, что "дело темное". ИК вполне добротно излагает (и не только излагает) интересы мировой профессиональной IT-корпорации. Только вот интересы этой корпорации ну ни разу не совпадают с интересами их клиентов. А потому, когда ИК "по надобности" обратится к юристу, силовику, доктору, строителю и т.п., его попытаются столь же "культурно и грамотно" облапошишь до нитки, и при этом ему объяснят, что это 100 лет назад "было проще", а "сейчас всё не так и всё иначе", и "распишись вот тут, что все риски и вся ответственность на тебе и заплати вот по этому счету". И всем будет счастье. Но вот если эти "ребята" обратятся к IT-отрасли хоть и для учета "законно отнятого у клиентов бабла", вот тут-то они нешуточно "попадут на бабки".

Добро пожаловать в корпорацию!..



Исправлено 4 раз(а). Последнее : Simple777, 01.12.18 17:43

of63
"Не согласен я", что тоталитаризм (монополизм крупных софт-контор) лучше, чем много частников, проживающих в Костроме/Урюпинске

Лучше для кого? Для "частников" - конечно хуже. Для их клиентов - лучше. Как и любое другое крупное предприятие - за счёт масштаба сокращаются издержки. И о "монополизме" речи не идёт - крупных компаний досаточно много чтобы они могли между собой конкурировать.
Где находится штаб-квартира для IT компании сегодня совершенно непринципиально. У многих бизнес вообще построен так, что сотрудник работает сидя у себя дома в той же Костроме/Урюпинске. Технологии позволяют.

of63
кроме 1С нет альтернатив для учета перепелок, и шарп - для всего остального... Слишком по "советски" застойно.

Альтернативы есть - правда для РФ они либо гораздо хуже (ну кто там остался ещё из более-менее заметных, Парус?), либо сильно дороже (САПы да Навижны). В плане языков, опять же, альтернатив выше крыши www.tiobe.com И шарп далеко не самый популярный, если что.

of63
Что ж мы тогда (прогеры-одиночки) все что-то пишем и пишем, кто на чем?

Не знаю я чего, на чём и зачем пишут "прогеры-одиночки", т.к. никогда таковым не был

of63
Проще самому на коленке написать прогу учета перепелок, и сопровождать его до конца перепелиных жизней

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

Simple777
интересы этой корпорации ну ни разу не совпадают с интересами их клиентов.

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

ИК еще и отличный адвокат дьявола!..

Лирическое отступление. Игорь, ты прогером-одиночкой не был, а я корпорациях не работал (хотя в корпоративах участвовал ), ну, только в советское время, при СССР 5 лет. Из тех времен у меня и представление о "корпорациях", которое я изложил, возможно устаревшее. Сейчас в них наверное "ангелочки летают на цветочках"

> У многих бизнес вообще построен так, что сотрудник работает сидя у себя дома в той же Костроме/Урюпинске. Технологии позволяют
Это тухлое "сопровождение". Без прямой связи с юзером - эта "технология" суть "испорченый телефон" (юзер - манагер - Урюпинск - манагер - юзер. В итоге - временной лаг, необходимость "ТЗ", которое кто-то не так понял, или, "ой, оказывается тогда надо еще и вот это доделать"... а потом "ой, так еще хуже, верни взад" и т.п.). Может, франчайзер и посылает конкретного разраба в поле, к юзеру, "посмотреть как там колхозники е..утся", для внедрения, но Урюпицец же не поедет в каждый банк смотреть результат его работы... Поедет манагер, выпьет коньяку с диром и уедет с актом выполненных работ

Конечно, нужны корпорации, типа госкорпораций по военке, но скорее как отдел кадров, отдел приемки, контроль качества, инспекции, ... ну и по бухгалтерии тоже неплохо (она, типа, одна, налог. кодекс один на всю страну). А вот учет перепелок, или, например, tata здесь недавно озаботилась малой автоматизацией в ПФР - разве ей надо искать подходящего франчайзера?, или напрямую обратиться в корпорацию? Естественно, хорошо бы обратиться к разрабу ПО ПФРа, чтобы они сделали необходимую доработку. Но я знаю как устроено сопровождение ПО в ПФР, доработок там не дождешься годами, "ТЗ" пишут на верхах, типа "чтобы все было хорошо", кто-то где-то исполняет в соотв. с ТЗ, но получается рабочий продукт, но в тоже время х..ня какая-то ) Также и в "Почте России", пенсии они носят пенсам при помощи некоего "ПО", которое я наблюдаю с прошлого века. Как был некий формат обмена в виде DBF, так он и остался с тех пор.

Недавно посетил налоговую, вернуть ПН за лечение ребенка. Собрал все договоры с лечебками, лицухи ихние, свои 2НДФЛ напечатал (1С) (бумагомарательный документ), справки, копии, и написал заяву с № счета в банке куда прислать возвращенный ПН. Вроде все хор, но тут девушка в ГНИ, полистав 20 мин. мои бумаги (>50 листов, копии, копии... где "электронный документооборот" пля?) говорит, а заява-то с № счета в банке не по форме, и дает мне 6 листов (2 листа за каждый год) к заполнению "по форме", с клеточками для букв! 2 страницы, чтобы всего-лишь сказать № счета в СБ! Я говорю, этож нереально заполнить (заполнил конечно за ок. 30 мин., матерясь, и не ошибся ни разу, но я с подобными документами работаю, а нормальному колхознику запаса матерных слов не хватит), на что девушка мило улыбнулась и сказала что куй пиши сам, вон там полочка у стены, и образец (на высоте 2м оказался, для тренировки шеи, скорее всего там размещен). ...Кстати, в ГНИ набрали операторами инвалидов, молодые девушки, колясочницы, но не совсем ДЦП-шники... Наверняка ПО ГНИ обслуживает какой-то франчайзер, руки ему оторвать сцуке. Сидел бы прогер рядом, то его давно бы юзеры и посетители за что-нибудь подвесили. Вот это милое заявление pro-vychety.ru которое оказалось не может быть заполнено из этого милого ПО.

Ну тогда тоже суток лирики, а то вы тут перепеловодов поминаете.

Во времена когда связь была по модема.
Через межгород коннектился модемом из Кр-ка к компу диспетчера во Владике через pcAniwhere.
Там запуска rAdmin и шёл на ком главбуха. Качал дистрибутив 1с от себя и устанавливал.
Получалось быстрее нежели Владивостокского сопроыожденца подтянуть.
Подумаешь час-полтора за межгород заплатить.
Но бывало и летал. Прямо сходу. Утром ушёл на работу, а вечером звоню жене: на ужин не жди, я во Владике.

Ну это нормально.

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



Исправлено 1 раз(а). Последнее : Taran, 02.12.18 13:35

of63
ну, только в советское время, при СССР 5 лет.

В СССР никаких "корпораций" не было

of63
Это тухлое "сопровождение".

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

of63
В итоге - временной лаг, необходимость "ТЗ", которое кто-то не так понял, или, "ой, оказывается тогда надо еще и вот это доделать"... а потом "ой, так еще хуже, верни взад" и т.п.).

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

of63
Поедет манагер, выпьет коньяку с диром и уедет с актом выполненных работ

И так я работал - только это не офшорное программирование, а как раз самое что ни на есть "классическое советско-российское"

of63
Конечно, нужны корпорации, типа госкорпораций по военке, но скорее как отдел кадров, отдел приемки, контроль качества, инспекции,

Попил бабла, давай уж своими именами называть эти вещи

of63
А вот учет перепелок, или, например, tata здесь недавно озаботилась малой автоматизацией в ПФР - разве ей надо искать подходящего франчайзера?, или напрямую обратиться в корпорацию? Естественно, хорошо бы обратиться к разрабу ПО ПФРа, чтобы они сделали необходимую доработку.

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





Исправлено 1 раз(а). Последнее : Igor Korolyov, 02.12.18 13:59

of63
> У многих бизнес вообще построен так, что сотрудник работает сидя у себя дома в той же Костроме/Урюпинске. Технологии позволяют
Это тухлое "сопровождение". Без прямой связи с юзером - эта "технология" суть "испорченый телефон" (юзер - манагер - Урюпинск - манагер - юзер. В итоге - временной лаг, необходимость "ТЗ", которое кто-то не так понял, или, "ой, оказывается тогда надо еще и вот это доделать"... а потом "ой, так еще хуже, верни взад" и т.п.). Может, франчайзер и посылает конкретного разраба в поле, к юзеру, "посмотреть как там колхозники е..утся", для внедрения, но Урюпицец же не поедет в каждый банк смотреть результат его работы... Поедет манагер, выпьет коньяку с диром и уедет с актом выполненных работ

Не понятно, что плохого в ТЗ и в ЧТЗ. ЧТЗ - частное тех.задание для программера,применялось у нас в конторе. Любой прогер брал ЧТЗ и мог понять что его коллега там навоял в случае передачи на поддержку ему того или иного модуля (к примеру, после увольнения сотрудника).Документация на проекте - обязательна, иначе как потом сдавать продукт, как отчитываться перед Заказчиком, что ты выполнил всё что тот хотел? Даже если ты внутренний разраб в своей конторе, то не писать документацию или игнорировать её написание и приводит к не очень хорошим последствиям. Я не вижу ничего плохого в манагерах, аналитиках, продакт. менеджерах, архитекторах БД и прочих людей. Мне вот очень удобно работать с манагером.





Исправлено 1 раз(а). Последнее : Божья_коровка, 02.12.18 14:19

> Agile: ... Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков»
Т.е согнать всех разрабов в мск, туда же пригласить представителя заказчика что-ли? А как же работяги из Урюпинска. Опять мск...

> Попил бабла, давай уж своими именами называть эти вещи
Я и говорю, когда 2 разраба обьединяются в команду, начинается разделение труда, появляется командир и подчиненный (разница в дележке бабла). Когда много разрабов - появляется дир (дир. делит бабло по известной методе - себе по потребности, остальным остальное). Когда появляется вывеска команды (юр.лицо) то появляются налоги (гос. хочет бабла), но появляется и возможность "пилить" (госчиновники хотят еще и откат). Много минусов... Когда без большой команды деваться некуда, то без чиновников и коррупции не обойтись, но для мелких работ обращаться к корпорации излишне. Вобщем, если поддержание проги стоит 1-3 ЗП програмера, то надо брать на постоянку 1-3 прогамера. 1 лучше не брать, лучше 2 (один запасной, на случай если один сдохнет). Если больше 3 - тогда "добро пожаловать в корпорацию", там заплатишь вдвое, по мск-ценам, но а что делать. Если меньше 1 програмера - то есть фрилансеры, или своим пердячим паром (сотрудники должны уметь пару кнопок нажимать в экселях и пр.) Как-то так...

> ...Любой прогер брал ЧТЗ и мог понять что его коллега там навоял в случае передачи на поддержку ему того или иного модуля (к примеру, после увольнения сотрудника).Документация на проекте - обязательна...
Ага. ты тоже пишешь описание к твоим доработкам? И читаешь описание к проге от предыдущего писателя? Не верю. Формально, я тоже пишу, причем комменты в проге составляют сравнимо с кодом. Но толку мало...

> Я не вижу ничего плохого в манагерах, аналитиках, продакт. менеджерах, архитекторах БД и прочих людей. Мне вот очень удобно работать с манагером.
Да да, так раньше в СССР корпорация (или как там она называлась, у нас НИИ) и работала, дохрена инженеров, молодых специалистов, и прочих людей, последних особенно. Судя по отделу в 15 чел, работали над темой 2 чел, им в прямую помощь 2-3 девочки, чертить, документы носить, и остальные хз зачем (стенды всякие, и ПО кое-какое даже довелось написать). В принципе на выходе что-то работающее выходило, но настолько долго, что к появлению образца для изготовления оно устаревало и выбрасывалось разрабатывалось новое. В принципе это нормально, когда много людей, все получают одинаковую ЗП, кормят семьи, не слоняются в поисках работы, получают какой-никакой опыт от разрабов (как правило это уже ребята под 40, старички), кому это интересно. Опять же молодешь, корпоративы, Первомай, турслеты, на картошку/уборку урожая, Коллектив вобщем, обьединяет людей!



Исправлено 1 раз(а). Последнее : of63, 02.12.18 14:53

of63
Ага. ты тоже пишешь описание к твоим доработкам? И читаешь описание к проге от предыдущего писателя? Не верю. Формально, я тоже пишу, причем комменты в проге составляют сравнимо с кодом. Но толку мало...

В той конторе в которой требовали, обязательно писала. И читала в случае приёмки. В ЧТЗ входит описание всех объектов БД используемых в разработке, таблицы, связи, процедуры и прочее. Описывалась логика работы модуля. На проекте котором работаю сейчас,тоже есть документация, конечно не столь подробная и информативная, но есть. ТЗ мне предоставляют. Без ТЗ я б наверно уже запуталась, что когда и кому делала. А так поднимаешь ТЗ-шку и сразу видно, ага, вот этим тогда то сделали вот такую штучку. Я если честно, всегда прошу писать ТЗ, без этого документа ничего не беру на разработку\доработку, потому что потом концов не найдёшь. Да и отчитываться о проделанной работе по ТЗ легче. ИМХО

Даже когда работала непосредственно с юзерами в банке. Я со слов ничего не делала. Т.е. юзер звонит и просит, а вот сделай ка мне вот это. Хорошо, ТЗ подписанное начальством и сделаю. Когда юзер пишет ТЗ он еще раз продумывает то, что же ему надо, когда начальник его пописывает он еще раз проговаривает то, что необходимо.Часто получалось, что после такой работы, на самом деле и не нужно было этого делать или устная задача настолько видоизменялась, что от того, что юзер говорил словами ничего не оставалось.





Исправлено 1 раз(а). Последнее : Божья_коровка, 02.12.18 15:20

of63
> Agile: ... Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков»
Т.е согнать всех разрабов в мск, туда же пригласить представителя заказчика что-ли? А как же работяги из Урюпинска. Опять мск...

Команда это обычно 5-7, изредка до 15 человек. Представитель заказчика (и его программисты, если команда смешанная), естественно, не сидит в офисе с разработчиками, но постоянно находится "на связи". Есть и команды которые вообще полностью территориально распределённые - связь через скайп или что-то подобное.

of63
но для мелких работ обращаться к корпорации излишне.

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

of63
Вобщем, если поддержание проги стоит 1-3 ЗП програмера, то надо брать на постоянку 1-3 прогамера.

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

of63
причем комменты в проге составляют сравнимо с кодом. Но толку мало...

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





Исправлено 1 раз(а). Последнее : Igor Korolyov, 02.12.18 16:28

> вопрос менталитета. Обратиться в крупный автосервис, или поехать "в гаражи"
Нае..ть могут и там и там, это менталитет человека вообще, неважно где он работает, в гараже, или под крышей конторы. Под крышей и нае..т хитрее, в сговоре/с ведома диров обоих крыш, например. Я ж говорю, везде не ангелы Меркель )

> ПО настолько гениальное что его нужно ежедневно "поддерживать" - что зачастую и происходит с "самоделками", то тот кто его заказывал просто дурак
сам дурак такое слово

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



Исправлено 2 раз(а). Последнее : of63, 02.12.18 16:50

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

Ну, например:

- системное ПО
- прикладное ПО
- офисные продукты типа MS Office


Прикладное ПО в свою очередь можно разделить на:

- индивидуальное
- тиражируемое широко
- тиражируемое в рамках отрасли

и т.д.

В каждом сегменте ПО свои особенности, и "обсуждать вообще ПО" нет никакого смысла.

Симпле, в чем смысл вашего предложения? Вы считаете, что в зависимости от вида разрабатываемого ПО подход будет разным?





Исправлено 1 раз(а). Последнее : Божья_коровка, 02.12.18 20:57

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

Божья_коровка
Симпле, в чем смысл вашего предложения? Вы считаете, что в зависимости от вида разрабатываемого ПО подход будет разным?

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

Taran
Мне кажется что и люди будут разные. Системщик и учетчик это примерно как баянист и аккордеонист.
Огромная разница.

Согласна. Люди разные. И учетчик хорошо может разработать учет подсчёта "перепёлок" с помощью экселя (как писалось выше), но не разработать этот самый эксель.
Только для того чтобы написать учет "перепёлок", необходимо первичное обследование задачи, сбор данных, анализ, постановка, проверка на ошибки (тесты) и пр... Разве для того чтобы разработать самое приложение Эксель будут критически другие этапы работы?





Исправлено 2 раз(а). Последнее : Божья_коровка, 02.12.18 22:09

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

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

- прикладное ПО
- офисные продукты типа MS Office

В чем разница приоритетов в этих двух сегментах?





Исправлено 1 раз(а). Последнее : Божья_коровка, 02.12.18 22:08

Конечно. Для учёта перепелок нужно сложить цифры столбиком. Начертить некоторую схему связей корм-перепелки-(яйца+мясо).
Этих связей относительно мало.
Для разработки ехеля нужно смотреть через два ряда сидений вперёд и три побокам.
Творчества и фантазии нужно значительно больше.
Под пиво такое не напишешь. Вермут нужен качественный.
Поэтому и ценник на спецов разный. ;)
Я раньше новые проекты начинал в пивбаре.
Вглядывался в людей и думал, а какую хрень мог бы захотеть тот или иной посетитель.
И тут же писал что-то. Массу вопросов получал от посетителей.