How to read source codes (8)

The Nineth Chapter: System Architecture

++++++++++++++

182. A system can (and is true in a major system) simultaneously produce many different types of architectures. Examine the same system in different ways | Different parts of the analysis system | or using different levels of decomposition, it is possible to find different architectural types.

183. Collaborative applications, or semi-autonomous processes that require collaborative access to shared information or resources, typically use a centralized repository architecture.

184. The blackboard system uses a centralized repository, storing unstructured key/value pairs as a communication hub between a large number of different code elements.

185. When the process can be modeled | Designing and Implementing a series of data transformations, the data flow (or pipeline-filter) architecture is often used.

186. In an environment where automatic data processing is done in bulk, the data flow architecture is often used, especially on platforms that provide a large amount of support for the tool.

187. A clear indication of the data flow architecture is that the program uses temporary files or pipelining (pipeline) to communicate between different processes.

188. Use diagrams to model the relationships of classes in the object-oriented architecture.

189. You can input the source code into the modeling tool, and deduce the structure of the system backwards.

190. Systems with a large number of sibling subsystems are often organized in a hierarchical framework.

191. Layered architectures are typically implemented by stacking software components that have standardized interfaces.

192. Each layer in the system can think of the following layer as an abstract entity, and (as long as the layer satisfies its requirements description) does not care how the layer above uses it.

193. The interface of a layer can be either a complementary function family that supports a particular concept, or a series of interchangeable functions that support different underlying implementations of the same abstract interface.

194. A system implemented in C language, often using an array of function pointers, to express the multi-multiplexing operation of the layer interface.

195. Using the object-oriented language implementation of the system, the use of virtual method calls directly to express the operation of the layer interface.

196. The system can be organized across a variety of axes using different | unique hierarchical decomposition models.

197. Using program slicing technology, you can centralize the dependencies between data and control in your program.

198. In a concurrent system, a separate system component acts as a centralized manager, responsible for initiating | Stopping and coordinating the execution of other system processes and tasks.

199. Many real-world systems will be in the family. When dealing with such systems, do not search in vain for all-encompassing architectural diagrams; Different architectural styles should be used as separate but related entities

For positioning | Identification and understanding.

200. The state transition diagram often helps to clarify the action of the state machine.

201. When dealing with large amounts of code, it is important to understand the mechanism by which the code is decomposed into separate units.

202. In most cases, the physical boundary of a module is a single file | A collection of multiple files organized into a directory or files that have a uniform prefix.

The module in 203.C consists of a header file that provides the module's public interface and a source file that provides the corresponding implementation.

204. The object's constructor is often used to allocate resources related to the object and initialize the state of the object. Functions are typically used to release resources that the object occupies during life.

205. Object methods often use class fields to store data that controls the operation of all methods (such as lookup tables or dictionaries) or to maintain state information for the operation of a class (for example, assigning an identifier to each object

Counter).

206. In well-designed classes, all fields should be declared private, and access to them is provided using public access methods.

207. When you encounter a friend statement, stop and analyze to see the reason for bypassing the class encapsulation for the design.

208. It is not appropriate to use operators sparingly to enhance the availability of a particular class, but with operator overloading, it is inappropriate to implement the class as a class entity that has all the functionality associated with the built-in arithmetic types.

209. Generic implementations are not implemented during compilation through macro substitution or language-supported features such as C + + templates and Ada generic packages, which are implemented during run time by using pointers to data elements and pointers to functions | or the polymorphism of the objects.

210. Abstract data types are often used to encapsulate commonly used data organization scenarios such as tree | lists or stacks, or to hide the implementation details of a data type from a user.

211. The library is used for a variety of purposes: reusing source code or target code, organizing module collections, organizing and optimizing the compilation process, or enabling on-demand onboarding of various features of the application.

212. Large | Distributed systems are often implemented as a number of collaborative processes.

213. For a text-based data repository, you can decipher its structure by browsing the data stored therein.

214. You can analyze the schema of a relational database by querying the tables in the data dictionary, or by using database-specific SQL commands, such as show table.

215. Once you have identified the reusable architectural elements, you can find their original descriptions, understand the proper way to use the architecture, and the possible misuse.

216. To analyze in detail the applications built on a certain framework, the best course of action is to start with the research framework itself.

217. When reading the code generated by the wizard, do not expect too much, or you will be disappointed.

218. After learning a few basic design patterns, you will find that the way you view the code architecture changes: Your horizons and vocabulary will expand to identify and describe many common forms.

219. Frequently used patterns, but do not explicitly indicate their names, because the reuse of architectural design is often preceded by pattern formation.

220. Try to understand the architecture according to the underlying schema, even though the code does not explicitly refer to the schema.

221. Most interpreters follow a similar processing architecture, built around a state machine, and state machine operations depend on the current state of the Interpreter | program directives and program state.

222. In most cases, the Reference Architecture simply assigns a conceptual structure to the application domain, and the implementation does not have to follow this structure.

+++++++++++++++++

Tenth chapter: Code reading Tools

+++++++++++++++++

223. Vocabulary tools can efficiently find a pattern in a large code file or across multiple files.

224. Use the program editor and regular expressions to find commands and browse through large source code files.

225. Browse the source code files in read-only mode.

226. Use the regular expression ^function name to find out the definition of the function.

227. Using the character class of a regular expression, you can find variables that have names that follow a specific pattern.

228. Use the negative character class of the regular expression to avoid non-positive matches.

229. Use the regular expression symbol-1. *symbol-2, you can find symbols that appear on the same line.

230. Using the editor's tags feature, you can quickly find out the definition of an entity.

231. You can create a tool with a specific tag to increase the browsing function of the editor.

232. Use the outline view of the editor to get a bird's eye image of the source code structure.

233. Use your editor to detect parentheses in the source code | The matching of square brackets and braces.

234. Use grep to find code patterns across multiple files.

235. Use grep to position the declaration of a symbol | definition and application.

236. When you cannot express exactly what you are looking for, use the stem of the key word to find the source code of the program.

237. Use grep to filter the output generated by other tools to isolate the item you are looking for.

238. Transfer the output of grep to other tools to automate complex processing tasks.

239. Reuse the results of code lookups by streaming edits to the output of grep.

240. Filter the false grep output by selecting an output line (GREP-V) that does not match the noise mode.

241. Use Fgrep to find a list of strings in the source code.

242. Use case insensitive pattern matching (grep-i) when looking for comments, or code written in an identifier case-insensitive language.

243. Using the grep–n command-line switch, you can create a checklist of files and line numbers that match a given regular expression.

244. You can use diff to compare differences between different versions of a file or program.

245. When running the diff command, you can use Diff–b to make the file comparison algorithm ignore the trailing spaces, and use –w to ignore the differences in all white space, using –i to make the file comparison insensitive to case.

246. Don't be afraid to create your own code-reading tools.

247. When building your own code reading tools: to take full advantage of the capabilities provided by the modern rapid prototyping language; Start from the simple, gradually improve as needed; Use a variety of heuristics using code vocabulary structures; To allow some output noise or silence (unrelated output or missing output); Use other tools to preprocess the input or post-process the output.

248. To make the compiler yours: Specify the appropriate level of compiler warnings and carefully evaluate the resulting results.

249. Use the C preprocessor to clarify those programs that misuse the preprocessor features.

250. To thoroughly understand how the compiler handles a particular block of code, you need to look at the generated symbol (assembly) code.

251. By analyzing the symbols in the corresponding target file, you can clearly understand the input and output of the source file.

252. Browse through a large collection of code and object types using the source code browser.

253. Resist the temptation to beautify the external code according to your coding specifications; Unnecessary orchestration changes create different code and hinder the organization of the work.

254. Graceful printing program and editor syntax coloring can make the source code of the program easy to read.

255.CDECL programs can convert hard-to-understand C and C + + type declarations into plain English (and vice versa).

256. The actual operation of the program, often can be more profound understanding of the program's action.

257. System Call | Events and packet trackers can improve understanding of program actions.

258. The execution profiler can identify the code that needs to be optimized, validate the coverage of the input data, and analyze the action of the algorithm.

259. By examining the lines of code that have never been executed, you can identify the weaknesses of the test coverage and modify the test data accordingly.

260. To explore every detail of a program's dynamic action, you need to work with it in the debugger.

261. Print the code you find difficult to understand on paper.

262. You can draw an illustration to depict the action of the Code.

263. You can try to introduce the code you are reading to others, which generally improves your understanding of the code.

264. To understand complex algorithms or ingenious data structures, choose a quiet environment, and then concentrate on it, without resorting to any computerized or automated help.

+++++++++++++++++++++

The 11th chapter: a complete example

+++++++++++++++++++++

265. When imitating the function of the software, follow the lines of similar entities (Class | function | module). In a similar existing entity, to simplify text lookups to the source code base, you should choose a rare name.

266. Auto-generated files often have a comment on the file's switch to illustrate this situation.

267. If you attempt to analyze the code accurately, you will typically fall into a large number of classes | files and modules that will soon overwhelm us; Therefore, we must limit the code that needs to be understood to an absolutely necessary scope.

268. Adopt a breadth-first search strategy to solve the problems in code reading from multiple parties, and go to find ways to overcome them.

How to read source codes (8)