В числе прочих есть задача сделать так, чтобы ПО работало, а внести в него изменения самостоятельно было весьма затруднительно. MaryRabinovich делает акцент на том, что важны данные, а не код, и это отчасти верно, код позволяет работать с данными, и, например, данные из 1С для ИП Иванова ценнее, чем сама 1С, однако для 1С как вендора важнее обеспечить невозможность запатчить 1С до состояния "работает и жрать не просит". Так что, если статью применять к реальным задачам - то только к такми.
А хранятся ли где-то эти знания кроме как в устном фольклоре (эдакий сломанный телефон с задержкой по времени). Если придёт новичок в команду — откуда ему почерпнуть знаний? Тем более если проект большой — каждый новый разработчик будет много временить тратить на понимание всех «особенностей», которые успели наворотить его новые коллеги.
У себя в качестве попытки решения данной проблемы поднял форум (банальный phpBB прикрученный к AD), чтобы можно было знаниями делиться, но… народ активности не проявляет, и как заставить — вообще непонятно.
Занимается развитием разработчиков и расширением их компетенций.
Можете рассказать как это организовано?
Любые дефекты, несоответствия полученной функциональности требованиям появляются, когда код не проходит достаточную проверку качества.
Дело-то наверное не совсем в коде. Код может быть написан отвратительно (с точки зрения, скажем, стандартов оформления), но тем не менее решать поставленную задачу (пусть не оптимально, но решать). А вот вносить в него изменения — то еще приключение. И наоборот — всё красиво, по region`ам разделено, а баги есть. Дело-то больше в тестировании, которое позволяет убедиться работает код или нет. А еще дело может быть в подходе к тестированию, когда тест не учитывает всех вариантов, а только «сделали как написано в инструкции». Также нужно отметить важность регрессионного тестирования, вы указали, что тестируете доработки, а остальной функционал? CI как-нибудь организовывается?
Буквально недавно поймали крайне любопытный кейс, какой-то «разработчик» засунул в проект библиотеку, имя сборки у которой которой совпадало с именем другой сборки. По итогу ловили странную (и фатальную) ошибку в функционале, который ну вообще не трогали даже близко, он раньше стабильно работал! И свидетели есть (правда нет нотариальной надписи, ну да ладно). Так вот о чём я — при наличии регрессионного тестирования этот баг был бы виден заранее, не нервировал бы заказчика, и «разработчик» был бы более-менее спокоен за свое моральное состояние.
Втрое уменьшилось количество дефектов, фиксируемых конечными пользователями.
— Я на вас жалобу напишу!
— Пишите, их там всё равно уже никто не читает.
(с) Анекдот
Парное программирование.
Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики?
Как-то скучно, право слово, нет в вашем предложении челленджа, кича, протеста, бунта, если хотите.
заключаем ГПХ и я делаю за посчитанную сумму
Ну нет, так не интересно, вы, по-хорошему, должны будете встать на место программиста из поста, взять на себя его обязанности, и сделать работу в срок, оговоренный с руководством, иначе это шляпа какая-то, а не пари. Предлагаете стреляться, только расстояние до мишени выбираете вы, нет уж.
Либо, если уж хотите с договором ГПХ, внесите в ваше предложение корректировку — если к сроку вы не сможете выдать результат, отвечающий всем требованиям, то уплачиваете неустойку в размере суммы договора.
PG безусловно очень мощный инструмент. Хоть я и со скепсисом отношусь к применяемым вами решениям (видел аналогичные решения, не впечатлило), всё же интересно, переживет ли этот подход ближайшие 2-3 года, и не будет ли статей на тему «Как мы возвращали блудный API в лоно монолита» :)
Так и я то же самое сказал. «Да я же тебе все равно заплачу», хотя днем ранее рассказывал что «Денег нет, 2 кредита, на фирме долг, карты пустые». Воистину лох не мамонт.
Вляпывались в похожую фигню… Когда наш «дирэктор» нашел крутой проект и полез в него с ногами, бросив свою фирму. А как ЗП платить — «Ну вы че, потерпеть не можете? Я готов рискнуть» и прочее бла-бла-бла. Проект так и не взлетел.
Программисты дурят бизнес (в лице менеджеров);
Бизнес (в лице менеджеров) дурит клиента;
Клиенты дурят бизнес (через программистов);
GOTO 1
Впрочем, ничего нового.
Мне не передать всю ту боль, которая пала нулями из накладной на мои плечи...
Видимо о том что 1С не приговор)
Это прям бесконечная тема))) уже 2 года жду обзор плюсов архитектуры. Деда мороза в детстве так не ждал.
В числе прочих есть задача сделать так, чтобы ПО работало, а внести в него изменения самостоятельно было весьма затруднительно. MaryRabinovich делает акцент на том, что важны данные, а не код, и это отчасти верно, код позволяет работать с данными, и, например, данные из 1С для ИП Иванова ценнее, чем сама 1С, однако для 1С как вендора важнее обеспечить невозможность запатчить 1С до состояния "работает и жрать не просит". Так что, если статью применять к реальным задачам - то только к такми.
Или статей о минусах такого подхода при кажущейся "хорошести"
Как веревочке не виться...а без планового действительно никуда. Поддерживаю!
Они прям весь функционал прогоняют?
На контрасте с предыдущим пунктом разница в цене должна быть ощутимой даже на небольших сроках.
Кстати, про рефакторинг что-то ничего и не написано...
А хранятся ли где-то эти знания кроме как в устном фольклоре (эдакий сломанный телефон с задержкой по времени). Если придёт новичок в команду — откуда ему почерпнуть знаний? Тем более если проект большой — каждый новый разработчик будет много временить тратить на понимание всех «особенностей», которые успели наворотить его новые коллеги.
У себя в качестве попытки решения данной проблемы поднял форум (банальный phpBB прикрученный к AD), чтобы можно было знаниями делиться, но… народ активности не проявляет, и как заставить — вообще непонятно.
Можете рассказать как это организовано?
Дело-то наверное не совсем в коде. Код может быть написан отвратительно (с точки зрения, скажем, стандартов оформления), но тем не менее решать поставленную задачу (пусть не оптимально, но решать). А вот вносить в него изменения — то еще приключение. И наоборот — всё красиво, по region`ам разделено, а баги есть. Дело-то больше в тестировании, которое позволяет убедиться работает код или нет. А еще дело может быть в подходе к тестированию, когда тест не учитывает всех вариантов, а только «сделали как написано в инструкции». Также нужно отметить важность регрессионного тестирования, вы указали, что тестируете доработки, а остальной функционал? CI как-нибудь организовывается?
Буквально недавно поймали крайне любопытный кейс, какой-то «разработчик» засунул в проект библиотеку, имя сборки у которой которой совпадало с именем другой сборки. По итогу ловили странную (и фатальную) ошибку в функционале, который ну вообще не трогали даже близко, он раньше стабильно работал! И свидетели есть (правда нет нотариальной надписи, ну да ладно). Так вот о чём я — при наличии регрессионного тестирования этот баг был бы виден заранее, не нервировал бы заказчика, и «разработчик» был бы более-менее спокоен за свое моральное состояние.
— Я на вас жалобу напишу!
— Пишите, их там всё равно уже никто не читает.
(с) Анекдот
Влечет за собой умножение трудоемкости, и, как следствие, стоимости, на 2. Как к этому относятся заказчики?
Ну нет, так не интересно, вы, по-хорошему, должны будете встать на место программиста из поста, взять на себя его обязанности, и сделать работу в срок, оговоренный с руководством, иначе это шляпа какая-то, а не пари. Предлагаете стреляться, только расстояние до мишени выбираете вы, нет уж.
Либо, если уж хотите с договором ГПХ, внесите в ваше предложение корректировку — если к сроку вы не сможете выдать результат, отвечающий всем требованиям, то уплачиваете неустойку в размере суммы договора.
А я, а я тогда это… Squared Double Long Senior Cyber Security Consultant DevSecOpsWithMoreCamelCasedWords!
А 80 порт занят вебсервером. Шах и мат!
Ждем статью, раскрывающую эту тему!