Я должен подготовить свой код к будущим изменениям? [закрытый]
Улучшена производительность со статической ссылкой на компоненты:
TYPES: BEGIN OF ty_structure,
fieldk TYPE i,
fieldt TYPE i,
fieldh TYPE i,
END OF ty_structure.
DATA: itab TYPE TABLE OF ty_structure,
mystructure TYPE ty_structure,
currency TYPE c LENGTH 1.
LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs>).
CASE currency.
WHEN 'K'. ADD <fs>-fieldk TO mystructure-fieldk.
WHEN 'T'. ADD <fs>-fieldt TO mystructure-fieldt.
WHEN 'H'. ADD <fs>-fieldh TO mystructure-fieldh.
ENDCASE.
ENDLOOP.
Если вы хотите упростить код, вы можете использовать макрос (встроенный код):
LOOP AT itab ASSIGNING FIELD-SYMBOL(<fs>).
DEFINE m_add.
IF currency = 'K'.
ADD <fs>-field&1 TO mystructure-field&1.
ENDIF.
END-OF-DEFINITION.
m_add : K, T, H.
ENDLOOP.
22 ответа
Меня, вероятно, будут линчевать для моего мнения об этом, но здесь я иду.
В то время как я имел, это стучало в меня за годы чтения идеалистических статей и нахождения через слишком многие семинары и лекции, категорически указывая нирвану как преимущества этого, у меня также были подобные вопросы в моем уме. Этот ход мыслей может привести к крупной сверхразработке кода, добавив много человеко-часов или больше разработать, разработка и тестируя оценки, увеличив стоимость и издержки, когда в действительности это не часто имеет место. Сколько раз имеет, Вы на самом деле снова использовали свой код или библиотеку. Если это будет используемым во многих местах через многочисленные проекты, то да Вы должны.
Однако большую часть времени дело обстоит не так. Вы будете часто находить это более экономичным (вовремя и деньги), чтобы только осуществить рефакторинг Ваш код для повторного использования и конфигурируемости, когда Вы на самом деле будете знать, что собираетесь использовать его снова. Остальная часть времени реальная выгода потеряна.
Это не, я повторяюсь НЕ, оправдание записать неаккуратный, плохо разработанный, плохо зарегистрированный код. Это должно быть фундаментальным, которое так полностью внушено в Вас, что Вы не могли повредить его, но запись, что класс для повторного использования является отходами большую часть времени, поскольку это никогда не будет снова использоваться.
Существуют очевидные исключения к этому. Если Вы пишете сторонние библиотеки затем, очевидно, дело обстоит не так и повторное использование, и расширение должно быть ключевым для Вашего дизайна. Определенные другие типы кода должны быть очевидными для повторного использования (Вход, Конфигурация и т.д.)
Я задал подобному вопросу здесь Возможность многократного использования Кода: действительно ли это стоит того, Это могло бы помочь.
Да, всегда думайте, где Ваш код, возможно, должен развиться в будущем. В текущем проекте я продолжаю работать существуют тысячи файлов, и каждые из них имеет по крайней мере один пересмотр его. Даже не принимая во внимание исправления ошибок много тех изменений должно освободить дорогу для дополнительных программных функций.
Сбалансировать усилие с преимуществ - навык дизайна.
Не весь наш код должен быть гибким. Некоторые вещи не будут изменяться.
Никакое потраченное впустую усилие. Нахождение, что правильные части уделяют наше внимание.
Хитрый.
Я не изменился бы, мой мог для подготовки к неизвестной будущей функции.
Но я осуществил бы рефакторинг для получения лучшего решения текущей проблемы.
Это действительно важно. Это должно преуспеться, но берет опыт.
Если я подсчитываю количество редактирований (через "разность") после реализации типичного изменения требований, числа как 10-50 распространены.
Если я делаю ошибку на каком-либо из них, я вставил ошибку.
Так лично я всегда пытаюсь разработать для подавления того числа.
Я также пытаюсь оставить инструкции в коде для того, как внести ожидаемые изменения. Если я поддерживаю код, я действительно ценю его, если предшествующий автор также сделал это.
Да, но только путем написания удобный в сопровождении, легко пересмотренный код.
Вы не должны определенно пытаться предположить то, что могло бы требоваться в будущем. Такие усилия не только бессмысленны и бесполезная трата времени для Ваших текущих целей, но и как правило контрпродуктивны, когда любые будущие изменения становятся очевидными.
Два простых принципа для следования:
- KISS
- Всегда избегайте зависимостей
Это - хорошее начало
Я нахожу, что существует параллель здесь к чему-то, что я недавно услышал на разработке через тестирование. Человек, говорящий об этом, заметил, что, в то время как сначала это могло быть немного раздражения, чтобы всегда записать модульные тесты и думать о том, как Ваш код может быть написан, чтобы быть тестируемым, оказалось, что в какой-то момент это только начинает приходить естественно к тесту записи дружественный код.
Дело в том, что, если Вы всегда пишете с модифицируемостью в памяти, Вы могли бы закончить тем, что делали ее более или менее отражением, таким образом, делая издержки из написания дополнительного кода очень маленькими. Если можно достигнуть состояния, где высококачественный, растяжимый код - то, что прибывает естественно к Вам, я думаю, что это определенно стоило бы начальной стоимости. Я действительно все еще полагаю, тем не менее, что Вы должны к нему умеренно и что иногда это - просто не правильный поступок для данного клиента.
То, что Вы описываете, является неотъемлемой частью того, чтобы быть хорошим разработчиком.
Посмотрите при написании удобного в сопровождении кода
Очевидный ответ - ДА. Но более важный вопрос состоит в том как!
Ортогональность, Обратимость, Гибкая архитектура, Отделение и Метапрограммирование являются некоторыми ключевыми словами, которые решают эту проблему. Главы 2 и 5 выезда "Прагматически настроенного Программиста"
Я нахожу, что это обычно - лучшая стратегия разработать "размещающую изменение" архитектуру, чем попытка указать определенные изменения, которые могли бы (или не мог бы) происходить. Это - хорошее осуществление, тем не менее, для выяснения, "Что может измениться в будущем?", и затем сопротивляйтесь искушению преждевременно реализовать потенциально ненужные опции, а скорее иметь такие возможности в виду при создании архитектуры приложения.
Одним словом, да.
Еще в нескольких словах необходимо всегда делать код максимально читаемым, включать комментарии и всегда предполагать, что в некоторое время в будущем, Вы будете призваны, или кто-то еще будет, для изменения кода.
Если это, кто-то в будущем сталкивается с блоком кода, непрокомментированным, восстановленным после форматирования, без признака того, что это делает или должно сделать, то они проклянут Вас навсегда :)
Помните, что большинство из Вас код будет изменено/осуществлено рефакторинг. Если Вы знаете, что необходимо будет изменить код в течение следующей недели, подготовить его. Но не начинайте делать все сменным и модульным по умолчанию. Просто, потому что, "возможно, в будущем" Вы не должны создавать платформу, если три строки кода делают задание на данный момент.
Но думайте дважды, если система позади делает осуществляющим рефакторинг трудный (базы данных).
Одна вещь я узнал в своем простом году кодирования для компании, что работаю на, все, которое Вы делаете, неважно, как прекрасный Вы думаете, что это, возвратится, преследуя Вас для обновления или должна быть изменена, потому что клиент X внезапно решил не любить его.
Теперь я делаю свой код высоконастраиваемым поэтому, когда в тот день прибывает, чтобы сделать некоторые корректировки, это было бы готово в мгновение ока, и я могу продолжить свою работу.
Предсказанные или вероятные изменения - да, обычно хорошо иметь их в виду.
"Возьмите что-либо, что могло бы когда-либо происходить во вселенной во внимание" - нет. Вы не знаете то, что могло произойти, пытаться покрыть для всего неизвестного только по разработке.
Да - путем выполнения меньше.
Вы не будете знать что будущие требования для Вашего кода. Лучшая подготовка к будущему не должна реализовывать ничего, что это не нужно сразу же, и имейте хорошее покрытие модульного теста все, что Вы действительно реализуете.
Если бы Вы работаете в благоприятном для рефакторинга lanuguage, я сказал бы "нет". (На других языках я не уверен),
Необходимо сделать код максимально свободно связанным и сохранить вещи максимально простыми. Останьтесь конкретными и не делайте вывод к неизвестным вариантам использования.
Это сделает Вашу кодовую базу подготовленной к вещам, которые принесет будущее.
(И откровенно говоря, большинство ожиданий будущего имеет тенденцию быть достаточно вне метки для не гарантирования кодирования для него сегодня),
Править: Это также зависит от того, что Вы делаете. Разработка пчелы для внешних пользователей не является тем же как разработкой веб-приложения для Вашей компании
Масштабируемость в Вашем коде является одной вещью, которую необходимо всегда рассматривать.
Чем больше времени Вы провели сегодня в питании для масштабируемых решений, тем меньше времени Вы проведете в будущем при фактическом расширении
yagni.
http://en.wikipedia.org/wiki/YAGNI (*inserted дружелюбным редактором :-) *)
исправьте ошибки в этом код horrenous, который Вы пишете сегодня.
осуществите рефакторинг, когда время настанет.
В причине и конечно если не много усилия.
Я не думаю, что можно всегда применять это, поскольку это может заставить Вас сверхспроектировать все, и затем это занимает слишком много времени, и Вы не делаете много денег. Рассмотрите, как, вероятно, клиент должен реализовать что-то, сколько дополнительный потребуется для подготовки к нему теперь и сколько времени это сэкономит позже.
Если это требует большой работы, но имеет смысл экономить деньги, Вы могли бы повысить его с клиентом.
Я, кажется, нахожусь в разногласии с большим количеством людей здесь, которые всегда говорят - но я видел много вещей, где усилия были приложены к, делают будущие функции легкими реализовать..., но они никогда не реализовывались. Если клиент не заплатил в течение времени, проведенного, делая функцию легкой реализовать, это - деньги непосредственно Ваша нижняя строка.
Править: Я думаю, что ее соответствующее указывает, что я происхожу из среды агентства. Если Вы работаете над кодом для себя, можно, вероятно, предсказать будущую разработку с большим уровнем уверенности, и таким образом, ее, вероятно, выполнимый сделать это в большем количестве случаев.
Нет, никогда. Напишите хороший код, к которому легко снова использовать/осуществить рефакторинг, но подготовка наполовину продумала улучшения, imo, брат преждевременной оптимизации; Вы, вероятно, закончите тем, что делали вещи, в которых Вы не нуждаетесь или то нажатие Вы вниз, определенное (возможно неоптимальный) разрабатывает путь в будущем. Как mfx говорит, сделайте минимум, требуемый теперь и модульный тест все; это делает расширяющийся код пустяком.
Вы не можете проектировать вопреки неизвестному (будущему), и, как говорили другие люди, попытка создать гибкий дизайн может легко привести к чрезмерному проектированию, поэтому я думаю, что лучший прагматический подход - думайте о том, чтобы избегать вещей, которые, как вы знаете, усложнят вам поддержку кода в будущем. Каждый раз, когда вы принимаете дизайнерское решение, просто спрашивайте себя, усложняете ли вы что-то изменить в будущем, и если да, то что вы собираетесь делать, чтобы ограничить проблему.
Очевидные вещи, которые всегда будут вызывать проблемы:
- Разрозненная информация о конфигурации - у вас должна быть возможность легко проверять и изменять это.
- Непроверенный код - вам нужны тесты, чтобы вносить изменения с уверенностью
- Объединение проблем хранения и вывода с основной логикой - вы переключитесь экземпляры базы данных и форматы вывода, если только для тестирования
- Сложная архитектура - у вас должна быть четкая ментальная модель системы
- Устройства, требующие ручного вмешательства или обновлений, чтобы поддерживать их работу