Pull to refresh

Comments 6

> Разработчики боялись дотрагиваться до этого кода, чтобы починив одно не сломать другое
А юнит тестов нет?
Иногда юнит-тесты дают ложное чувство уверенности в коде. Да — они позволяют отлавливать ошибки и ситуации, на которые рассчитываешь, но то, на что не рассчитываешь, тесты не видят. Однако разработчик, глядя на зеленые кружочки расслабляется и не ищет «нюансы». Поэтому те, кто не теряет бдительности, боятся дотрагиваться до кода, даже при наличии юнит-тестов. Не спорю с тем, что качественные юнит-тесты должны быть, но при этом совершенно не стоит расслябляться. Доверяй, но проверяй и перепроверяй, как говорится…
>Если же ограничивать доработку только тем, что нужно конкретному заказчику, для других она будет бесполезной. А для серийного программного продукта это гарантированные убытки.

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

Получите массу плюсов, но это сложно сделать, потому что нужно не менее чем полностью изменять подход к разработке.
Совет 1 вступает в противоречие с Советом 2, а неразрешённость этого противоречия приводит к Совету 3. :)

По статье — имхо, слишком мало конкретики. Мало примеров, мало погружений в задачи.
Sign up to leave a comment.