LINUX.ORG.RU

История изменений

Исправление pathfinder, (текущая версия) :

Очень интересный вопрос на который нет четкого ответа. Некоторые вещи приходят с опытом, но усваиваются они где-то на уровне спинного мозга, и вместо логики и здравого смысла мы имеем интуицию.

Но в целом предстоит решить ряд проблем:

  • Алгоритмическая проблема - собственно сама задача. Это неинтересно, так как у каждого свое
  • Проблема архитектуры - когда кода будет написано достаточно много, то актуальной станет проблема роста и смены масштабов. Необходимо избежать экспоненциального роста трудозатрат на добавление новой фичи от объема уже написанного кода. Код должен быть сделан так, чтобы его можно было в дальнейшем неограниченно модифицировать и совершенствовать (привет всем любителям писать макаронный код). Проблема смены масштабов, это когда мы думали, что программа будет работать с десятью объектами, а на практике оказалось, что надо работать с миллионом. Количественное изменение может потребовать качественно других методов работы с объектом. Приходится прикидывать, где стоит ожидать смены масштабов, а где не стоит и закладывать все это в архитектуру. Ну и хорошая архитектура предполагает некую простоту, логичность, интуитивность и красоту. Но последнее - сильно абстрактные вещи.
  • Проблема контроля качества - чем больше кода, тем тяжелее контролировать его качество. Полезно задаться вопросом, как мы все это написанное говно будем тестировать. Ручное тестирование полезно, но в крупных проектах этот процесс надо автоматизировать. Путей много. Важно запомнить одну вещь - несмотря на то, что создание автоматизированной системы тестирования всегда требует больших трудозатрат, оно все равно выгодно. В серьезном проекте одним только ручным просмотром кода и ручными проверками обойтись нельзя, а без контроля качества кода все очень плохо кончится.
  • Проблема завершенности продукта - конечно реализовывать фичи и прочие прикольные штуки интересно, но ещё надо думать о документации, процедуре инсталляции и других вещах. Кто-то это должен будет сделать. Тут можно провести аналогию с неким товаром в магазине. Когда вы покупаете микроволновку, вы ведь помимо самой микроволновки получаете инструкцию, какие-то дополнительные предметы и самое главное, все это упаковано в коробку, в которой будет легко и удобно довезти свою микроволновку до дома. Если хочешь продавать законченный продукт, то он должен быть действительно законченным.

Исходная версия pathfinder, :

Очень интересный вопрос на который нет четкого ответа. Некоторые вещи приходят с опытом, но усваиваются они где-то на уровне спинного мозга, и вместо логики и здравого смысла мы имеем интуицию.

Но в целом предстоит решить ряд проблем:

  • Алгоритмическая проблема - собственно сама задача. Это неинтересно, так как у каждого свое
  • Проблема архитектуры - когда кода будет написано достаточно много, то актуальной станет проблема роста и смены масштабов. Необходимо избежать экспоненциального роста трудозатрат на добавление новой фичи от объема уже написанного кода. Код должен быть сделан так, чтобы его можно было в дальнейшем неограниченно модифицировать и совершенствовать (привет всем любителям писать макаронный код). Проблема смены масштабов, это когда мы думали, что программа будет работать с десятью объектами, а на практике оказалось, что надо работать с миллионом. Количественное изменение может потребовать качественно других методов работы с объектом. Приходится прикидывать, где стоит ожидать смены масштабов, а где не стоит и закладывать все это в архитектуру. Ну и хорошая архитектура предполагает некую простоту, логичность, интуитивность и красоту. Но последнее - сильно абстрактные вещи.
  • Проблема контроля качества - чем больше кода, тем тяжелее контролировать его качество. Полезно задаться вопросом, как мы все это написанное говно будем тестировать. Ручное тестирование полезно, но в крупных проектах этот процесс надо автоматизировать. Путей может много. Важно запомнить одну вещь - несмотря на то, что создание автоматизированной системы тестирования всегда требует больших трудозатрат, оно все равно выгодно. В серьезном проекте одним только ручным просмотром кода и ручными проверками обойтись нельзя, а без контроля качества кода все очень плохо кончится.
  • Проблема завершенности продукта - конечно реализовывать фичи и прочие прикольные штуки интересно, но ещё надо думать о документации, процедуре инсталляции и других вещах. Кто-то это должен будет сделать. Тут можно провести аналогию с неким товаром в магазине. Когда вы покупаете микроволновку, вы ведь помимо самой микроволновки получаете инструкцию, какие-то дополнительные предметы и самое главное, все это упаковано в коробку, в которой будет легко и удобно довезти свою микроволновку до дома. Если хочешь продавать законченный продукт, то он должен быть действительно законченным.