theory

Почему рефакторинг приносит результаты [Кент Бек]

Ценность программы имеет две составляющие — то, что они могут делать для нас сегодня, и то, что они смогут делать завтра. В большинстве случаев мы сосредотачиваемся при программировании на том, что требуется от программы сегодня. Исправляя ошибку или добавляя новую функцию, мы повышаем ценность программы сегодняшнего дня путем расширения ее возможности.

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

Я знаю достаточно, чтобы выполнить сегодняшнюю задачу. Я знаю не достаточно чтобы выполнить завтрашнюю. Но если я буду работать только на сегодняшний день, завтра я не смогу работать вообще.

Рефакторинг — один из путей решения описанной проблемы. Обнаружив что вчерашнее решение сегодня потеряло смысл, мы его изменяем. Теперь мы можем выполнить сегодняшнюю задачу. Завтра наше сегодняшнее представление задачи покажется наивным, по этому мы и его изменим.

Из-за чего бывает трудно работать с программами? В данный момент мне приходят в голову 4 причини:
— программы трудные для чтения, трудно модифицировать;
— программы в логике которой есть дублирование, трудно модифицировать;
— программы, которым нужно дополнительные функции, что требует изменения в работающем коде, трудно модифицировать,
— программы, реализующие сложную логику условных операторов, трудно модифицировать.

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

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

1c-Битрикс, плохо или хорошо для разработчика?

Хочу высказать наболевшую мысль. С битриксом я работаю уже 4-ый год, и все бы хорошо, но, есть одна большая проблема, для меня по крайне мере. Так все время приходится работать именно с этой CMS, мало того что становится просто скучно, но и еще идет деградации как разработчика.

Я каждый раз радуюсь когда приходится решать какие-то не стандартные задачи, это подстегивает и пинает мозги. Надоел GetList и $arResult. Хочется чего-то новенького….

Архитектура кода

вот так надо сними...

Только так и никак иначе…

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

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

Допустим есть большой проект, я имею ввиду web проект. Так получается что над проектом работает сначала одна группа разработчиком, потом другая, потом третья. Что мы получаем в результате, а получаем мы абсолютный бардак. Горы кода, классов и методов, от js в глобальном пространстве просто тошнит всех браузеров, так как каждый писал свои мега-супер-мини библиотеки и пытался заставить всех использовать именно его. А фишка в том что каждый из разработчиков был примерно одинакового уровня за исключением просто пары халявщиков, или заумных бездарей. На счет последних, они самые опасные для проекта, так как могут натворить делов, их нужно быстро вычислить и дать волшебный пендаль сцуко. Как правило такие люди все знают и все умеют, и умеют убеждать заказчика, и подписывать его на всякую чушь.

Continue reading