Насколько расширяемым должен быть код на самом деле?

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

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

Но у меня никогда не было четкого представления о том, как далеко в будущем это должно быть.

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

Сначала я был ошеломлен и думал, что он был неудачной работой, но чем дольше я думаю об этом, тем больше я согреваюсь до этой концепции.

Есть ли у кого-нибудь еще мнение о том, как далеко в будущем вы должны кодоваться?

Ответ 1

Вы должны код в соответствии со спецификациями, ни больше, ни меньше. Если спецификации предусматривают 30 лет, вы кодируете 30 лет. Если в спецификации содержатся положения на 3 месяца, применяется то же самое.

Просто помните, что вы также должны кодировать для своего здравомыслия. Весь код, который вы создаете, должен достичь 3 вещей:

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

Ответ 2

Один из трудных суждений, которые нужно достичь, - насколько это возможно. Как босс, я действительно раздражен, когда назначаю кому-то 2-часовую задачу, и три дня спустя они все еще работают над этим, потому что они решили, что это должно быть более расширяемым, поэтому они добавили записи в файл конфигурации и столбцы в таблицы и изменить 4 или 5 других объектов, чтобы разместить это, а теперь устаревший документ устарел, а развертывание script должно измениться, и тестер должен положить через день или два попытку всех комбинаций и перестановок, чтобы мы могли знать, что код даже работает. Но я также очень раздражен, когда кто-то другой задал эту двухчасовую задачу, превратив ее в полчаса, жестко кодируя все, даже адрес электронной почты, который он отправляет, и не понимает, когда остальная часть команды жалуется.

Если бы существовало простое жесткое правило, каждый мог бы стать старшим программистом в день, когда они сначала скомпилируют какой-то код. Это требует опыта и суждений, и это, вероятно, самое важное решение, которое вы приобретете. И вы знаете, как вы получаете хорошее суждение? Опыт. И вы знаете, как вы получаете опыт? Плохое суждение.

Ответ 3

Если вы действительно хотите долговременную программу, стремитесь убедиться, что ваши даты могут обрабатывать прошлое 2038 (что следующая "Y2K" ).

Даты в сторону, как точно кодировать в течение года, а не через десять лет? Вы либо пишете код поддерживаемого кода, либо нет; вы не можете точно указать, как долго пока ваше изменение "истечет".

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

Ответ 4

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

Ответ 5

Если вы следуете методологии Agile для письма, тогда вы должны просто кодировать текущую проблему. Это также известно как принцип YAGNI (вам не нужен).

Идея состоит в том, что вы не знаете, что происходит за углом, поэтому нет смысла пытаться ее кодировать.

Однако я не думаю, что это особенно разумный подход.

Даже если вы находитесь в среде Agile, у вас есть представление о том, что вы хотите, чтобы код мог выполнять несколько итераций по строке и, следовательно, должен был кодировать это.

В то время как программы истекают и технологии меняются, если вы пишете это приложение "killer", оно будет работать намного дольше трех лет.

Ответ 6

Всякий раз, когда я что-то кодирую, я спрашиваю себя...

Нужно ли это? Если вам это не нужно, то почему вы его кодируете?

Я нахожу, что это помогает мне не добавлять лишний код. Ненужный код - это утечка. Это требует времени от других видов деятельности. Это добавляет размер и сложность кода. Он добавляет $$$ к проекту - особенно если база кода должна пройти процесс сертификации.

Ответ 7

При разработке кода вы должны помнить о возможных путях его расширения или новых функциональных возможностях, и вы должны стремиться сделать его достаточно модульным, чтобы было возможно добавление новых функций. Если есть точка, в которой одно решение сделает ее более гибкой или расширяемой, в то время как другое решение сделает ее более жесткой, если нет никакой платы за ее гибкость, тогда имеет смысл пойти с этим. Однако, если стоимость более гибкого маршрута значительна, тогда не делайте этого. Если вы точно не знаете, что вам понадобится эта функция и что затраты оправданы, вы не должны сходить с ума, пытаясь добавить такие функции; если вы это сделаете, вы, скорее всего, потратите много денег.