Как приступить к разработке модуля? - PullRequest
3 голосов
/ 19 октября 2011

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

Но то, что мне кажется довольно простым и понятным может показаться слишком сложным для других пользователей. Хотя это случается не так часто, иногда это случается со всеми нами (я надеюсь).

Есть ли какие-либо вопросы, которые вы должны задать себе, прежде чем разрабатывать иерархию классов / API / что-либо еще, прежде чем приступить к кодированию, кроме вопросов, которые я уже упоминал?

Если вы считаете, что вопрос лучше подходит для другого раздела SO, пожалуйста, не стесняйтесь переносить его, но я все равно хотел бы получить ответ.

Приветствие.

Ответы [ 2 ]

3 голосов
/ 19 октября 2011

Ваш вопрос очень хороший, и у него есть ответы, но настолько сложный, что ответом в основном является опыт программирования.

Существуют общие принципы создания программного обеспечения, но я думаю, что здесь,в этом коротком ответе я могу дать вам одну концепцию, которую вы можете применить.Программное обеспечение - это представление домена (например, банковское программное обеспечение предназначено для настройки финансовой системы или программное обеспечение для радаров разработано с учетом идей и принципов обнаружения радаров).Программное обеспечение, таким образом, похоже на теорию: оно идеально соответствует текущим знаниям в вашей области, позволяет делать выводы и расширения.Если станет доступно больше знаний, теория должна быть расширена, отшлифована или сделана более общей, чтобы приспособиться к этим новым знаниям, оставаясь при этом действительной для предыдущих знаний.

Следовательно, применяются все понятия о теориях:

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

Таким образом, программное обеспечение должно быть минималистичным, но не слишком большим, красивым, но практичным.

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

  • «кто несет ответственность за выполнение этой операции?»
  • "Является ли эта зависимость логичной и необходимой для работы этого объекта или это просто ложная зависимость из-за плохой организации кода?"
  • "Это функциональность высокого уровня или низкого уровня?"
  • "Я повторяю это?"
  • "Могу ли я изменить этот объект / слой / подсистему внутренне, не зная кода снаружи?"
  • "Могу ли я продлить это в будущем, не разрушив и не обесценив прошлое?"
  • «Могу ли я легко проверить и проверить эту функциональность на предмет правильного поведения?»
  • «Легко ли и интуитивно ли понять и использовать?»
  • «Могу ли я легко рекомбинировать то, что у меня уже есть, ине касаясь реализации нового поведения? "
  • " Изолирована ли эта функция, чтобы я мог показать ее внешнему миру без остальной части кода, которым я манипулирую? "
3 голосов
/ 19 октября 2011

Вы должны рассмотреть ТВЕРДЫЕ Принципы и здесь .

И о назначении ответственности применяются GRASP Patterns

...