Я знаю, как программировать, и как научиться программировать, но как / где вы узнаете, как правильно создавать системы? [закрыто]


11

Есть много вещей, которые необходимо учитывать при создании системы, например, веб-система, в которой пользователи входят и взаимодействуют друг с другом, создавая и редактируя контент. Теперь мне нужно подумать о безопасности, валидации (я даже не думаю, что я на 100% уверен, что это влечет за собой), «чтобы пользователи не наступали друг на друга» (термин для этого?), Предотвращая ошибки во многих случаев, когда данные базы данных не становятся проблематичными в непредвиденных ... ситуациях? Все эти вещи, которые я не знаю, как и где учить, есть ли книга о таких вещах? Как я уже сказал, кажется, существует огромная разница между написанием кода и написанием правильного кода, понимаете, о чем я? Я чувствую, что моей текущей работе по программированию не хватает того, что я описал, и я вижу проблемы, которые она вызывает позже, и тогда проблемы гораздо сложнее решить, потому что данные существуют, и люди их используют. Так может ли кто-нибудь указать мне книги или ресурсы или подходящее подмножество программирования (?) Для этого типа обучения?

PS: не стесняйтесь исправлять мои теги, я не знаю, о чем говорю.

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

Ответы:


10

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

  1. Учиться на неудачном опыте - вы сталкиваетесь с чем-то не так. Вы это исправите. Вы говорите: «Эй, я не должен делать это снова. В следующий раз я сделаю X». Ты явно в гуще этого.
  2. Изучение перед неудачным опытом - в конце концов, вы учитесь видеть определенные проблемы. Когда вы это сделаете, вы попытаетесь избежать этого. Может быть, вы читаете книгу, может быть, вы ищете в Интернете, может быть, вы пытаетесь некоторые эксперименты.
  3. Учиться у опытных коллег - это, безусловно, самое простое, хотя это все еще нелегко. Хитрость заключается в том, чтобы выяснить, реагирует ли коллега на неудачный опыт, который все еще актуален. В конце концов, технологии развиваются.

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


Что касается # 1), имейте в виду, что плохой опыт и ошибки, на которых вы учитесь, не обязательно должны быть вашими собственными. Проводите время в Интернете, тусуйтесь с программистами, изучайте их ужасные истории о сумасшедших ошибках, которые они совершили или сталкивались, держите их в голове во время программирования.
Шадур

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

4

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

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


Так что, полагаю, для разных вещей все по-другому, а?
MetaGuru

Многие проблемы будут, скажем, специфичными для веб-приложений, а многие будут более общими. Не уверен, что я полностью понимаю, о чем ты спрашиваешь.
Квентин Старин

3

Мне очень нравится ответ Уильяма Пьетри (+1), но я считаю, что к нему нужно добавить. Даже предполагая, что то, что вы подразумеваете под системами, состоит исключительно из программного обеспечения.

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

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

  1. Бизнес-аналитик

    Это человек, который разговаривает с заказчиком и переводит его требования в то, что может понять архитектор. В основном список правильно сформулированных требований. Это включает в себя очевидные функциональные требования (что должна обеспечивать эта система?), А также нефункциональные требования (какие общие характеристики должна выполнять система? Это может включать безопасность, надежность, доступность, устойчивость, емкость, производительность, надежность и другие подобные требования с точки зрения пользователя).

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

  2. Системный архитектор

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

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

  3. Системный дизайнер

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

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

  4. Менеджер тестов

    Эта роль очень часто забывается. Но в конце концов, если вы не можете проверить это, как вы можете доказать, что вы можете его построить? Должен быть проведен обзор результатов всех этапов: бизнес-анализа, архитектуры и проектирования кем-то, кто компетентен в тестировании и сможет выявить недостатки и, следовательно, сделать возможными ранние исправления, задолго до написания любого кода.

Это краткое резюме.

Эти парни / девчонки - это лишь обычные люди в цепочке, которые думают о том, о чем нужно думать.

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

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

Если вы хотите знать, как проектировать системы, то вам нужно начать задавать вопросы, думая нестандартно. Поставьте себя на место клиента и постарайтесь подумать, что может пойти не так, что нужно проверить. Затем соберитесь с реальным клиентом и подтолкните его, чтобы объяснить масштабы и ограничения системы, в которой они нуждаются. Кроме того, всякий раз, когда я говорю «клиент», вы должны понимать, что это касается нескольких совершенно разных людей. Есть человек, который изо дня в день использует систему для того, для чего она предназначена. Там есть оператор, техническая поддержка, менеджер, которому нужен тот или иной отчет, аудитор, команда инфраструктуры, заинтересованная сторона, которая заплатила за него, менеджер по качеству, которому нужны средства для тестирования вашей системы ... Спросите их всех (и если они один человек, попросите их надеть все эти шляпы по одной за раз), поэтому спросите их все, что им нужно, и вы хорошо начнете понимать, каковы ваши системные требования. Оттуда вы можете получить архитектуру, а оттуда дизайн.

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

HPH, асм.


2

здесь, чтобы узнать, есть ли книга о таких вещах?

Не "книга". Много книг.

Там нет королевской дороги

Как я уже сказал, кажется, существует огромная разница между написанием кода и написанием правильного кода.

Правильно.

Вы говорите об «архитектуре», программировании в целом.

Шаг 1. Прочитайте много кода. Очень много Подумайте о вещах, которые вы хотели бы сделать. Найти связанные проекты с открытым исходным кодом. Прочитайте код. Все это.

Шаг 2. Прочитайте больше кода. Намного больше.

Шаг 3. Чтение книг по архитектуре.


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

@qes: Вопрос был в том, "где вы узнаете, как правильно создавать системы?" Вы не научитесь этому, плохо создавая реальные системы. Действительно, плохая реализация реальных систем является полной противоположностью обучению.
S.Lott

3
Из Code Complete одна из вещей, которые мне понравились больше всего: «В области разработки программного обеспечения чрезвычайно ограничено использование примеров прошлых успехов и неудач. Если бы вы интересовались архитектурой, вы бы изучали чертежи [известных архитекторов] ... посетить несколько зданий ... ».
Джейкоб

@ S.Lott: кто сказал что-то плохое?
Квентин Старин

@qes: не читая предшествующий уровень техники, каковы шансы хорошо выполнить крупномасштабную программу? Для такого гения, как вы, вполне возможно, что можно просто написать хорошие программы в любое время и в любом масштабе. Но для всех остальных, кто не смотрел на крупномасштабное программирование, начинать с попытки реализовать большую систему, не читая ничего, - это путь к написанию чего-то, что содержит так много ошибок, что из этого нельзя извлечь ничего полезного. Ваш опыт может быть другим, но я знаю, что я недостаточно умен, чтобы работать без чтения.
S.Lott

1

Для усиления читайте много книг ....

Теперь, когда вы знаете, что у вас есть проблема, есть смысл сказать вам прочитать эти книги. (До того, как вы проделали настоящую работу, обсуждать эти книги бессмысленно)

Шаблоны проектирования по шаблонам Gamma, Helm, Johnson и Vlissides Языки разработки программ 1, 2, 3 и 4.

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

это тоже плохо.

Надеюсь это поможет.


1

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

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

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

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


1
+1, хотя я бы предположил, что просто делать недостаточно. Вы не будете знать, хорошо вы это сделали или плохо, пока не вернетесь к тому же коду через некоторое время. И даже тогда вы можете знать, что что-то не так, но не то, как это можно улучшить. Один из способов сократить все это - обеспечить много откликов от людей, более опытных в изучении того, чему вы пытаетесь научиться. Так что да, «делать» очень важно, но отзывы о том, что вы делаете, возможно, даже больше, чтобы ускорить процесс обучения.
Марьян Венема
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.