Справка - Поиск - Участники - Войти - Регистрация
Полная версия: А вот которые - программисты?
Частный клуб Алекса Экслера > Землячества и клубы
Страницы: 1, 2, 3, 4, 5, 6, 7
Martin
4 апреля 2015, 00:34

Газонокосильщик написал: Коллеги, вы на землю спуститесь, а? Есть немерено прикладников, которым ваши глобальные проблемы по-барабану, но к которым приходят и говорят - Саня, есть проблемка...

Зависит от сложности задач и величины проектов. Кому-то эта теория не нужна, а где-то без нее не обойтись, может развалиться вся работа.
Газонокосильщик
4 апреля 2015, 08:59
Так и я - о том же!
Газонокосильщик
4 апреля 2015, 09:05

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

Ты у меня за спиной стоишь! biggrin.gif
Был как раз такой случай! Естественно сразу реализовал первый вариант. Вроде всё ОК, но шо-то смущало... Полез вглубь (лучше бы не лазил 3d.gif ).
Troubleshooter
4 апреля 2015, 11:58

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

Зависит не только от этого. Все эти техники позволяют организовать стандартный процесс разработки программ. Скажем, один разработчик долго работал с какими то конкретными пользователями и понимает их с полуслова, также как и они его. Теперь этот разработчик увольняется. У вновь пришедшего разработчика опыта работа с данными пользователями нету. Без налаженного процесса работы может пройти немало времени прежде чем новый разработчик станет продуктивным в данных условиях. Все это может привестм к стрессовой ситуации, и хороший разработчик может уйти в другую организацию. Чем сложней проект тем больше вероятность что это произрйдет. Тоже самое можно сказать о коде, как в примере с переполнением. Если применяется дефенсив программирование, есть юнит тесты которые проверяют граничные условия, то даже новый разработчик возможно сможе исправит подобные ошибки сравнительно легко. Если этого нет, то да, после того как уволился программист который хорошо знает приложение может возникнуть проблема.
Газонокосильщик
4 апреля 2015, 13:34

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

См. про вышеупомянутый федеральный ресурс.

Troubleshooter написал: Теперь этот разработчик увольняется

Он умер... RIP...
А пользователи наконец поняли, что 9 (ДЕВЯТЬ) лет он вешал им лапшу на уши. Кастрюлями!!!
Troubleshooter
4 апреля 2015, 13:53

Газонокосильщик написал:

А пользователи наконец поняли, что 9 (ДЕВЯТЬ) лет он вешал им лапшу на уши. Кастрюлями!!!

Да, поэтому должны быть способы контроля создания и поддержки приложени на уровне каких то стандартов. Я согласен что везде есть своя специфика, (например я работал над проектами в команде где многие разработчики менялись каждые 3 недели. В таких условиях Scrum в классическом варианте не очень работает). Но при этом надо конечно просччитывать варианты "что если...?" применимые к этой специфике.
Газонокосильщик
4 апреля 2015, 15:03

Troubleshooter написал:  поэтому должны быть способы контроля создания и поддержки приложени на уровне каких то стандартов

У них "стандарт" был один - раз Лёня сказал, что нельзя - значит нельзя.

Mx
4 апреля 2015, 17:01

Газонокосильщик написал: А пользователи наконец поняли, что 9 (ДЕВЯТЬ) лет он вешал им лапшу на уши. Кастрюлями!!!

Человек делал так как ему было удобнее, нельзя его за это слишком сильно винить. Подозреваю что в "федеральных ресурсах" способ отбора подрядчиком весьма специфический и отбор сотрудников, ответственных за контроль над выполнением работ - тоже.
Газонокосильщик
4 апреля 2015, 23:09

Mx написал: Человек делал так как ему было удобнее

Ага. Классический пример супербыдлокодера.

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

Никаких "сравнительно честных способов отъёма денег" © biggrin.gif . Всё - внутри одного отдела. Исполнитель - подчинённый заказчика. Про лапшу я уже постил.
Подозреваю, что во многих госконторах - аналогичная ситуация.
whitekiller
6 апреля 2015, 15:00

Troubleshooter написал:
Скажем, один разработчик долго работал с какими то конкретными пользователями и понимает их с полуслова, также как и они его. Теперь этот разработчик увольняется. У вновь пришедшего разработчика  опыта работа с данными пользователями нету. Без налаженного процесса работы может пройти немало времени прежде чем новый разработчик станет продуктивным в данных условиях.

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

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

Второй случай - еще хуже, там разработчик для ускорения проекта не зашифровал частную информацию. Пользователи тоже обожали этого гиганта мысли, который теперь имеет хороший шанс попасть под суд.
Martin
16 апреля 2015, 20:15
На Хабре в прошлом году опубликовали статью "Почему 1С это плохо и почему так не любят 1С программистов". Название говорит само за себя. smile.gif
Troubleshooter
18 апреля 2015, 14:34

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

Со вторым случаем, здесь не только вина программиста. Где я работал/работаю , дизайн и имплементация программного кода работающегт с сенситив информацией должны проходить определённую проверку с позиции секюрити и удовлетворять принятым критериям. Иначе код не выпускается в продакшн. Понятно что "особо умный" программист может намеренно попытаться обойти эти проверки, тогда все ясно. Но в общем случае это shared responsibility. Т.е. программист виноват, но и специалисты ответственные за организацию процесса выпуска такого кода в продакшн виноваты не меньше.
Troubleshooter
18 апреля 2015, 14:44

Martin написал: На Хабре в прошлом году опубликовали статью "Почему 1С это плохо и почему так не любят 1С программистов". Название говорит само за себя. smile.gif

Казалось бы, что определённые решения по дизайну программного обеспечения лежат на поверхности. Для этого не надо быть супер разработчиком, вполне достаточно немного здравого смысла и посмотреть на проблему с точки зрения тех кто будет пользоваться результатом труда (т.е. юзеры, сопровождение, саппорт). И всеже по разным причинам это бывает самым сложным.
whitekiller
20 апреля 2015, 14:26

Troubleshooter написал:
Со вторым случаем,  здесь не только вина программиста. Где я работал/работаю , дизайн и имплементация программного кода работающегт с сенситив информацией должны проходить определённую проверку с позиции секюрити и удовлетворять принятым критериям. Иначе код не выпускается в продакшн. Понятно что "особо умный" программист может намеренно попытаться обойти эти проверки, тогда все ясно. Но в общем случае это shared responsibility. Т.е. программист  виноват, но и специалисты ответственные за организацию процесса выпуска такого кода в продакшн виноваты не меньше.

Вот его код и не прошел такую проверку на стадии QA релиза. Теперь программист уволен, сроки пришлось немного перенести. Более интересный здесь вопрос, откуда у бизнеса был доступ до частной информации. Я даже честно рад, сейчас такое внимание безопасности уделяется, вскрываются совершенно вопиющие случаи как безответственности, так и очевидного маразма.
Martin
6 мая 2015, 00:03
Все-таки есть польза от искусственного интеллекта. У меня есть стойкое предубеждение, что фреймы Марвина Минского были предвестниками классов в ООП.
Mx
6 мая 2015, 23:47

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

Или наоборот, потому что статья Минского вышла в 1974 году. К тому времени уже существовали языки Simula, Smalltalk и объекты в LISPе.
Сруль
18 мая 2015, 12:51

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

Любовь в одни ворота.
Два, нет 3 раза брали "на добивание".
Жеванный листик со списком багов,
Неделькa на вникание, 3 недельки на исправление.
Сделал ? Катись !
Работорговец стучал по столу пальчиком:
"Баран, там работы было на пол-года, куда тебя девать дармоеда"?
Martin
24 июня 2015, 23:08
Сегодня занимался героическим делом - ковырялся в проекте, к которому никто не возвращался уже 10 лет. Исходники к нему тоже находились черти где. Раз 10 уже подумывал о том, чтобы поменять работу на что-то другое. smile.gif
Эта версия форума - с пониженной функциональностью. Для просмотра полной версии со всеми функциями, форматированием, картинками и т. п. нажмите сюда.
Invision Power Board © 2001-2017 Invision Power Services, Inc.
модификация - Яро & Серёга
Хостинг от «Зенон»Сервера компании «ETegro»