2020 personal reading blog software engineering jobs

2020 personal reading blog software engineering jobs

project	content
Course Link	Spring 2020 Computer Software Engineering Institute (Roger Ren Jian)
Work requirements	Personal blog jobs
Course targets	Learning theory and system software development process, software development experience accumulated through practice
This blog harvest	A preliminary understanding of the software and engineering software, reading a good book and do their own thinking

One problem: a quick look at the full textbooks ( "Building the Law"), lists you still do not understand the 5-10 questions, posted on your personal blog.

• Unit testing the most suitable program of completion?

  The original text mentioned in 2.1:

  Unit test must be written by people (author of the program) most familiar with the code. The best understanding of the code of code objects, features and limitations of implementation. Therefore, the authors write unit tests no more than a suitable candidate.

  Here, I can understand most of the program logic and understanding of running programs written procedure, it is possible to achieve 100% code coverage by writing unit tests. However, test coverage of 100% means that it must function correctly?

  From my own experience point of view, although the program author can write test cases makes the program during operation, execute every piece of code, but the author of the program, after all, just one person, there are limitations on thinking, leading to the completion of the module functional requirements when a loophole, missing some special cases, loopholes in this way of thinking even to write the test phase, in case no one is reminded not found.

  For example: In the former OO coursework expression derivation, we write a three bedroom extreme test case, since that program has been vulnerable to the attack, and then go to sleep happy. The results the next morning, someone issued a receipt we did not take into account the very simple test case to blow up the program, then restart the complete code for the function, debug, test and so on.

  Moreover, in Section 10.3 also mentioned:

  In Spec want to explain how to verify the description of functions, from the description of Spec will be able to know how to write unit tests, it is best to link test cases.

  Spec is done by the PM, so to say in order to ensure the function is perfect, as the best understanding of the functional requirements of the PM is the most suitable person planning how to write unit tests do? Author just planning on a good unit test code coverage add some test cases to ensure that anomalies can not occur at run time?

• Estimated working time in the end matter?

  Original in 6.2, we introduce the agile development, you can use burndown charts to track progress of the development project. Which estimates the remaining time, I decided to see the enthusiasm of the agile development of each person, it is very important, after all, in most cases, deadline is always the first productive force.

  The following is a practical project burndown, there are three times the value of the tracking day:

  The actual time remaining (Remaining Hour): the sum of the remaining time of all the tasks of each team member.

  Estimated time remaining (Projected Remaining Hour): remaining time everyone theoretical progress throughout the day according to projections.

  Actual time spent (Completed Hour): the actual time spent.

  But in the actual development of the project estimated time it is very difficult. Time is too short might be caused by peer pressure, peer influence working conditions, for too long, it can not mobilize the enthusiasm of the companions, especially for those of us students are almost no engineering experience, how can we estimate the difference compared with the actual difficulty little time remaining it work? I read on with questions.

  However, the text also mentioned in Section 8.6

  In order not to "quasi-guess" rather hesitant, or to let the original looks tricky guess not truthfully report progress. In the agile development process, there are many ways seemingly cottage, I come into contact with are:

  Guessing Game estimation - a few people scream, while punches, several fingers on behalf of several days

  So it seems when we can not determine the estimated time when just saying that a work estimated time remaining to? So in the case of just saying this, because this fellow might casually say time is too tight and overworked, it may be too long because of slack, or you can excuse that "the time has always been just given, I can not to complete the task "in such a short period of time. This time we can only rely on their common pursuit of a better goal to use reasonable force together to complete the task, the estimated time as a decoration does not seem to make much sense it important?

• Typical types of users seems a bit too much?

  Original mentioned in Section 10.1 of the following types of typical user for us

  Typical users could include the following:

  1. name (the more natural, the better)

  .......

  10. The preferences of the user

  Remove user content information other than the name of this does not matter, as much as a full nine, although we gave the book to build a site selling rock examples, and lists six types of users. But in fact a wide range of software projects, the stage has not yet begun the investigation, how to determine the level of detail typical user to build it? How many types of typical user have to define it? The book gives examples of typical user is to build, and then do a user survey to filter user, whether a change in the order of these two processes, thereby reducing the scope of the various contents of a typical user in advance it?

• Whether the bug testers appear immediately handed over to developers?

  Original mentioned in chapter 11.5

  Dumbo: Also, I often go to testers discovered what Bug, sometimes you take the time to research and fix them.
  A super: you can wait for the next day after the consultation and then look at whether it is worth immediately repaired.

  Boats: So, the new Bug to wait until after the next day consultation process to the developer, is not it will affect the progress?

  A super: Not necessarily. Because - the most important task in the development phase (1) developer to complete specified functions! (2) early in the project, it can not collective consultation, developers / testers can deal with "defects" directly, without waiting. (3) At any time, testers can "defect" to the developers, but only consultation of staff consultation to change the decision.

  In my opinion, bug testers immediate feedback to the developer is the best option. Because I carried out on the basis of a bug in the input process on the basis bug developed code is very likely also bug, if not promptly cut off, it will seriously affect the efficiency of development, such as once OO course, since the input processing occurs bug, leading to further development, and ultimately a significant weight change. And the bug testers to developers, allowing developers to understand after the bug to decide whether immediate repair bug, should be more good than harm?

• Successful companies really easy access innovators dilemma it?

  Mentioned in the original 16.1

  When successful companies entering middle age, then they thrive in the market matured, the year's success of innovative technology into the mainstream of mature technology, also known as "sustaining technologies" in mature markets and sustaining technological environment innovation, technology is not the main factor affecting the success or failure of the enterprise. However, disruptive innovation will bring tremendous product and market risk, these enterprise processes, values ​​and culture will repel disruptive innovation.

  Disruptive innovation will indeed be a huge risk, but perhaps disruptive innovation does not mean that companies need to throw away all of the original culture and products. Successful companies have a more solid capital than start-ups and connections, have more opportunities for trial and error, the new product also has a convenient generalization. Such as Google, Microsoft, Tencent talent into more attractive, but also more convenient to make a new product promotion. In contrast to a handful of small companies can really grasp the pulse of the times, reached the market, we believe it will roll bankruptcy. So, more successful business innovation I think is more reasonable number.

Question two: Will the "software" and "software engineering" is how these words appear - when, where, who?

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.This led many to credit Tukey with coining the term, particularly in obituaries published that same year,although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a RAND Corporation.

Of the term "software", there are three versions:

• John Wilder Tukey in 1958 published papers The Teaching of Concrete Mathematics mentioned in.
• Paul Niquette in 1995, claimed that he was in 1953, first proposed in October, but there is no evidence .
• Richard R. Carhart in 1953 in a August engineering context presented in.

[Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.

About " Software Engineering ", Wiki also said very detailed, and ultimately by Margaret Hamilton in the Apollo missions during discipline is named the "software engineering".

Question three: We all know the origins of software and software engineering, software engineering development process is there in what you find interesting trivia and stories?

• Initially, it was because Google will misspelled called Google. In fact, in registering a domain name is registered would like googol. is a mathematical term googol, which was created by a 9-year-old great nephew of American mathematician Edward Kasner, and refers to the power of 10 100, represent a 1 followed by 100 zeros. It was a very big number, this is not just to meet the company's ambitious scientific and technological intent it?
• Google is the world's largest provider of online advertising, but on the other hand Google's Chrome browser, the most popular plug-in is a plug-in ad blocking Adblock Plus, this is Google's own development. While providing advertising but while trying to get you to intercept, which is Google that will bother the user to install plug-ins, even saw the ad, the conversion rate is very low, might as well let them see, actually enhance the user experience.

Question 4: online survey about the current popular source version management software and project management software, what are, what advantages and disadvantages?

Sort of on the number of users, from the wiki can be found on the table below show Popularity:

About the advantages and disadvantages of various software, including but not limited to the reference document 1 , document 2 , document 3

• Git

  • Advantages: suitable for distributed development, emphasis on the individual. Public pressure on the server and the amount of data that will not be too large. Fast and flexible. You can easily resolve any conflict between two developers. Work offline.

  • Cons: learning cycle is relatively long. Unconventional thinking. Poor security codes, once the developer down the entire library clones can be completely open all the code and version information.

• SVN:

  • Advantages: easy management, logic clear, in line with the general thinking habits. Centralized server to better ensure security. Code consistency is very high. For the development of the small number of project development.
  • Cons: too much pressure on the server, database capacity surge. If you can not connect to the server, essentially can not work, see the above second step, if the server can not connect, can not be submitted, reduction, contrast and the like. Not suitable for open source development. But there is a very clear rights management mechanisms are generally centralized management, hierarchical management can be achieved, so that a good solution to the large number of development issues.

• Microsoft TFS：

  • 优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。

  • 缺点：搭建、维护tfs比较复杂，硬件要求也比较高。

• GitHub:

  • 优点：GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。你可以通过Github评论，提交错误。在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。
  • 缺点：如果，你是Github使用新手，首先的挑战就是摆正心态——需要不断实践和时间。他可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。

• Trac：

  • 优点：Trac做一个SCM配置管理平台，意味着它有良好的扩充。Trac的权限体系是比较完备的设计。非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
  • 缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。

• Bugzilla：

  • 优点：BUGZILLA不收费, BUGZILLA现在有中文版支持
  • 缺点：BUGZILLA只能管理缺陷

• Apple XCode

  • 优点：可以自动创建分类图表。自动提供撤消、重做和保存功能，无需编写任何编码。
  • 缺点：更新版本后，某个插件可能会失效。

• Rational：

  • 优点：建立在非常优秀的软件工程原则基础上的，例如迭代，需求驱动，基于结构化的过程开发。
  • 缺点：仅仅包含了开发过程。它没有完全覆盖软件过程。不支持组织内的多项目开发，导致组织内的大范围的重用无法实现。