Как программист: полезнее будет увеличивать число функций и добавить их конкатенацию. Также может быть очень полезно запоминать результат в переменных, чтобы избежать сильно большой вложенности выражений.
А так очень даже удобно, спасибо! Думаю, интерфейс консоли — это то, что надо :-)
Как у Java-программиста есть отличный пример грамотного добавления новых фич — IntelliJ IDEA IDE. Интерфейс практически не меняется, все привычное работает по тем же горячим клавишам, меню и настройки организованы так же… а вот количество плюшечек при этом растет от версии к версии, и сказываются они локально, только в том контексте, на который рассчитаны. В итоге при переходе от версии к версии обнаруживаешь новую удобную штуку и говоришь «Слушай, какая клевая тема! Теперь то, что я делаю по 100-500 раз на дню, можно сделать проще и быстрее!»
Хорошему программисту не нужна программа — он оперирует объектами, абстракциями, алгоритмами. Программа — это только представление модели, загнанное в форму используемого языка программирования.
Рано или поздно продукт стабилизируется, и требований новых фич становится все меньше и меньше. Соответственно, появляется время на исправление старых ошибок, и их число начинает уменьшаться. Единственный вопрос, что кончится раньше: ошибки или поддержка продукта.
Только в том случае, если бы сложность структуры всегда возрастала.
Если же сложность не превысит некоторой константы, то возможно исправление ошибки без внесения новых. Таким образом, занимаясь только исправлением ошибок (без расширения функционала системы), которые не приводят к бесконечному увеличению сложности, можно исправить все подобные ошибки.
Конечно, остается открытым вопрос наличия ошибок, приводящих к бесконечному увеличению сложности. Здесь можно ответить, что наличие подобных ошибок может быть вызвано лишь попыткой реализовать то, что впринципе нельзя реализовать.
1) Прототип. Изначально пишется для того, чтобы показывать в качестве демки. Не предполагает поддержки, расширения и т.д. Допускает наличие косяков, недочетов и т.д. Может падать. Главная цель — наглядно показать, как будет работать система, чтобы можно было на ранних стадиях как можно лучше зафиксировать требуемый функционал. Как правило реализуется заранее фиксированным набором людей в относительно короткие сроки.
2) Промышленное приложение. Пишется один раз, учитывает возможную смену требований и оформления, должно обеспечивать возможность настройки, не допускается наличие косяков, которые препятствуют использованию системы по назначению (т.е. основные use-cases), не допускается нарушение прав доступа, не допускается повреждение или утечка данных. Время жизни как минимум составляет несколько лет, в это время добавляются новые фичи, состав команды разработчиков меняется, появляются новые клиенты, использующие систему, появляются юридические документы, обязанности по которым необходимо соблюдать, и т.д.
То, что Вы описываете — это первый пункт. Поскольку у первого и второго пунктов координально разные цели, постепенное превращение первого во второе сулит существенные затраты как по бюджету, так и по времени. И стоимость ошибок, допущенных при первом подходе, при переходе во второй очень сильно возрастает.
Но тем не менее для рефакторинга выделяется специальное время, и в это время (если не вылезли критические баги) можно спокойно подумать, переделать и протестировать. А делать рефакторинг в попыхах — все равно, что втыкать палки в колеса.
P.S. Это касается средних и крупных рефакторингов. Микро-рефакторинги должны выполняться во время разработки по мере необходимости.
И, все верно, прежде чем читать подобные книги нужно получить хотя бы небольшой опыт участия в реальных проектах. Иначе предложенные подходы не с чем сравнивать, а без конкретики все это действительно быстро забывается.
1. Слова, написанные в книге, забываются, это факт.
2. Но во время чтения невольно сравниваешь свой стиль с предложенным, обнаруживаешь лучшие приемы, чем те, которые использовал, меняешь свое мнение по некоторым вопросам.
3. После этого ты можешь не помнить всего того, что написано в книге, главное — что она изменила тебя и твое мышление, и твой код стал лучше. Даже если ты не отдаешь себе в этом отчета.
И после прочтения выкидывайте из статьи пункт 10.
Комментарии нужны для описания внешних интерфейсов, т.е. тех, использовать которые будет другой программист, удаленный как по расстоянию, так и по времени.
В остальных случаях необходимо писать самодокументирующийся код, а комментарии, которые никто (или почти никто) сознательно не поддерживает, со временем изживают сами себя.
А так очень даже удобно, спасибо! Думаю, интерфейс консоли — это то, что надо :-)
Если же сложность не превысит некоторой константы, то возможно исправление ошибки без внесения новых. Таким образом, занимаясь только исправлением ошибок (без расширения функционала системы), которые не приводят к бесконечному увеличению сложности, можно исправить все подобные ошибки.
Конечно, остается открытым вопрос наличия ошибок, приводящих к бесконечному увеличению сложности. Здесь можно ответить, что наличие подобных ошибок может быть вызвано лишь попыткой реализовать то, что впринципе нельзя реализовать.
1) Прототип. Изначально пишется для того, чтобы показывать в качестве демки. Не предполагает поддержки, расширения и т.д. Допускает наличие косяков, недочетов и т.д. Может падать. Главная цель — наглядно показать, как будет работать система, чтобы можно было на ранних стадиях как можно лучше зафиксировать требуемый функционал. Как правило реализуется заранее фиксированным набором людей в относительно короткие сроки.
2) Промышленное приложение. Пишется один раз, учитывает возможную смену требований и оформления, должно обеспечивать возможность настройки, не допускается наличие косяков, которые препятствуют использованию системы по назначению (т.е. основные use-cases), не допускается нарушение прав доступа, не допускается повреждение или утечка данных. Время жизни как минимум составляет несколько лет, в это время добавляются новые фичи, состав команды разработчиков меняется, появляются новые клиенты, использующие систему, появляются юридические документы, обязанности по которым необходимо соблюдать, и т.д.
То, что Вы описываете — это первый пункт. Поскольку у первого и второго пунктов координально разные цели, постепенное превращение первого во второе сулит существенные затраты как по бюджету, так и по времени. И стоимость ошибок, допущенных при первом подходе, при переходе во второй очень сильно возрастает.
Такие критерии подходят для горе-программистов, но не для профессионалов.
Это как разница между стратегией и тактикой.
Но тем не менее для рефакторинга выделяется специальное время, и в это время (если не вылезли критические баги) можно спокойно подумать, переделать и протестировать. А делать рефакторинг в попыхах — все равно, что втыкать палки в колеса.
P.S. Это касается средних и крупных рефакторингов. Микро-рефакторинги должны выполняться во время разработки по мере необходимости.
В коде можно в крайнем случае указать ссылку на номер задачи.
Иными словами, Вы умны, уважаемый, но мудрости Вам еще стоит поучиться ©.
2. Но во время чтения невольно сравниваешь свой стиль с предложенным, обнаруживаешь лучшие приемы, чем те, которые использовал, меняешь свое мнение по некоторым вопросам.
3. После этого ты можешь не помнить всего того, что написано в книге, главное — что она изменила тебя и твое мышление, и твой код стал лучше. Даже если ты не отдаешь себе в этом отчета.
Судя по всему, нет.
Комментарии нужны для описания внешних интерфейсов, т.е. тех, использовать которые будет другой программист, удаленный как по расстоянию, так и по времени.
В остальных случаях необходимо писать самодокументирующийся код, а комментарии, которые никто (или почти никто) сознательно не поддерживает, со временем изживают сами себя.