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

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

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

Если вы строго следуете методологиям Agile, то вам следует просто писать код для решения текущей проблемы. Это также известно как принцип ЯГНИ (вам это не понадобится).

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

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

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

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

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

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

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

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

Нужно ли это? Если это не нужно, то зачем вы это пишете?

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

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

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