Size: a a a

Software Design/Architecture/Zen

2021 November 23

SP

Sergey Protko in Software Design/Architecture/Zen
есть другая крайность - Фаулер. Он вот не стесняется сложно изъясняться. И там тоже можно упустить важные моменты которые он всколзь затрагивает....
источник

E

Emanresun in Software Design/Architecture/Zen
мне очень нравится Фаулер
источник

E

Emanresun in Software Design/Architecture/Zen
доходчиво пишет
источник

E

Emanresun in Software Design/Architecture/Zen
но по мне программирование это очень сложно, все что я стараюсь делать это просто управлять сложностью говнокода и локально прятать его
источник

SP

Sergey Protko in Software Design/Architecture/Zen
потому что программирование это про взаимодействие людей с системой а не про систему саму по себе)
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Я недавно на собесе открыл для себя чем же отличается сеньор от мидла. Умением создавать правила, а не просто следовать им. И полагаю все эти книги созданы совсем не чтобы показать какую-то абсолютную истину, по этому упрощения уместны.
источник

E

Emanresun in Software Design/Architecture/Zen
философски конечно, что есть система и что есть взаимодействие?)
источник

E

Emanresun in Software Design/Architecture/Zen
или можно представить что: программирование = взаимодействие людей с системой
источник

E

Emanresun in Software Design/Architecture/Zen
🤔
источник

SP

Sergey Protko in Software Design/Architecture/Zen
можно представить себе две точки на графике. На одной типичный вотерфол/аутсорс. Есть спецификация - сиди пили. На другой - эксперементы - не понятна ни проблема ни решение. Ты можешь делать лишь предположения как какие-либо изменения (фунционал новый типа) повлияют на поведение пользователей. Причем часто эти изменения косвенны и прямых причинно следственных связей построить очень сложно.

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

E

Emanresun in Software Design/Architecture/Zen
забавно что у нас в нашем деле абстракции, абстракции, абстракции, правила, паттерны, идеи все все все с маленькой звездочкой и мелким шрифтом, во время практик не ясно до конца, чему же научился
источник

E

Emanresun in Software Design/Architecture/Zen
будто просто опыту, предвидеть где возникнет проблема чуть раньше и сменить траекторию
источник

E

Emanresun in Software Design/Architecture/Zen
не могу понять, чему же я за всю свою жизнь кодинга научился, будто нечему
источник

E

Emanresun in Software Design/Architecture/Zen
кажется что основная цель: легкая читаемость, слабая связанность как вытекающее. все остальное отсюда же или нет? 🤔 память у нас слабенькая и хитро устроена, любит ассоциации но не любит просто списки, перечисления... память на графах, чем лучше неск кластеров связаны тем лучше работает
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
так или иначе все сходится в knowledge management, а кодирование это так, просто формат хранения
источник

E

Emanresun in Software Design/Architecture/Zen
как победил эту проблему?)
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
а есть какая-то проблема?)
источник

E

Emanresun in Software Design/Architecture/Zen
как менеджить знания)
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Вряд ли есть какой-то универсальный ответ, я для себя понял только одно, и это лежит на поверхности, уметь быстро искать важнее чем что-то знать.
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
Но чтобы что-то найти нужно это сначала записать. И у нас 100500 терминов на этот счет, вроде bus factor.
источник