diff options
Diffstat (limited to 'usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt')
-rw-r--r-- | usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt | 131 |
1 files changed, 0 insertions, 131 deletions
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt deleted file mode 100644 index 9cd15c3..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt +++ /dev/null @@ -1,131 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,620 -And I want to conclude this lesson with three takeaway - -2 -00:00:02,620 --> 00:00:06,190 -messages. The first one is that having an effective architecture is - -3 -00:00:06,190 --> 00:00:09,450 -fundamental in a software project. Or as I say here, - -4 -00:00:09,450 --> 00:00:13,050 -a great architecture is a ticket to a successful project. To - -5 -00:00:13,050 --> 00:00:15,290 -put it in a different way, although a great architecture - -6 -00:00:15,290 --> 00:00:17,940 -does not guarantee that your project will be successful, having a - -7 -00:00:17,940 --> 00:00:21,930 -poor architecture will make it much more difficult for your project - -8 -00:00:21,930 --> 00:00:25,280 -to be successful. The second message is that an architecture cannot - -9 -00:00:25,280 --> 00:00:28,120 -come about in a vacuum. You need to understand - -10 -00:00:28,120 --> 00:00:30,550 -the domain of the problem that you're trying to solve - -11 -00:00:30,550 --> 00:00:33,480 -in order to define an architectural solution that fits the - -12 -00:00:33,480 --> 00:00:37,220 -characteristics of the problem. So a great architecture reflects a - -13 -00:00:37,220 --> 00:00:40,500 -deep understanding of the problem domain. And finally, a great - -14 -00:00:40,500 --> 00:00:44,630 -architecture is likely to combine aspects of several simpler architectures. - -15 -00:00:44,630 --> 00:00:47,880 -It is typical for engineers to see problems that are - -16 -00:00:47,880 --> 00:00:50,590 -new, but such that parts of the problems have already - -17 -00:00:50,590 --> 00:00:53,540 -been solved by someone else. An effective engineer should - -18 -00:00:53,540 --> 00:00:56,270 -therefore, first of all, know what is out there, - -19 -00:00:56,270 --> 00:00:59,760 -know the solution space. Second, an engineer should understand - -20 -00:00:59,760 --> 00:01:02,420 -what has worked well and what has failed miserably in - -21 -00:01:02,420 --> 00:01:05,870 -similar occasions in the past. And finally, an effective - -22 -00:01:05,870 --> 00:01:10,100 -engineer should be able to suitably combine existing solutions appropriately - -23 -00:01:10,100 --> 00:01:12,870 -to come up with an effective overall solution for - -24 -00:01:12,870 --> 00:01:15,750 -the specific problem at hand. And this is just as - -25 -00:01:15,750 --> 00:01:18,960 -true in the context of software architectures. When defining a software - -26 -00:01:18,960 --> 00:01:22,330 -architecture, you should innovate only as much as you need to and - -27 -00:01:22,330 --> 00:01:24,850 -reuse as much as you can. As we said early in the - -28 -00:01:24,850 --> 00:01:27,770 -lesson, by doing so, that is, by innovating only as much as - -29 -00:01:27,770 --> 00:01:30,100 -you need to and reusing as much as you can, you will - -30 -00:01:30,100 --> 00:01:32,960 -be able to avoid reinventing the wheel. You will be able to - -31 -00:01:32,960 --> 00:01:37,320 -choose the right solution to known problems. And identify suitable solutions for - -32 -00:01:37,320 --> 00:01:40,925 -new problems. So ultimately, you will be able to realize an effective - -33 -00:01:40,925 --> 00:01:44,080 -software architecture that will help the success of your project. |